Transcript 5YP EDA Tools Corporate Engineering

Design Patterns for
Connected Devices
Hannes Tschofenig <[email protected]>
Michael Koster <[email protected]>
1
Goal
1. Capture common IoT design patterns
2. Determine need for interoperability
2
Design Patterns
3
Device-to-Device Communication
 Characteristics:





Device talks directly to other device (often smart phone).
Security based on direct relationship between the device
(pairing). Mostly done at the link layer.
Communication rarely uses IP but instead relies on link layer protocol
mechanism.
Users almost always have to download smart phone apps to access full
range of supported device functionality.
Smart phone app may cache data and does not need always-on Internet
connectivity.
 Interoperability need:


Interoperability of the entire stack (including data model) if the two devices
are from different vendors.
Re-use of radio standards only where vendor-specific profile data are used
but requires app to be downloaded.
 Standardization:


Bluetooth Smart Profiles
(https://developer.bluetooth.org/TechnologyOverview/Pages/BLE.aspx)
Vendors often extend existing profiles and sometimes publish them.
 Examples: Wearables with Bluetooth Smart
4
Examples
Wahoo HeartRate Monitor
Beacons
Hearing Aid
Parrot
Cadence Sensor
5
Device via Smart Phone to Cloud
 Characteristics:
 Extension of the device-to-device communication pattern.
 Device uploads data to cloud service indirectly via the smart phone
 Device interacts with smart phone up and a specific cloud service.
Users have to download app for specific device/cloud service.
 Interoperability need:
 Radio technology only to work with regular smart phone; gateway
acts as an application gateway that implements the vendor-specific
functionality.
Generic smart phone gateway only available as debugging app?

 Standardization:
 Bluetooth Smart (dominant)
 Examples: Wearables and Bluetooth Smart devices
6
Examples, cont. from device-to-device
StickNFind
Zepp Golf
Sensor
Oral-B Toothbrush
7
JawBone
Device via Gateway to Cloud
 Characteristics:
 Device uploads data to cloud service indirectly via a network gateway



(which often implements several radio technologies).
Device is pre-configured to work with specific gateway manufacturer
and specific cloud service, including security credentials.
Apps/websites allow user-friendly, remote access/monitoring
Gateways have various degree of application layer understanding.
 Could allow local operation as well (in case there is no Internet
connectivity) although not happening today.
 Could do some form of filtering like Cisco Krikkit/IOx
 Interoperability need:
 Often radio technology only; gateway acts as an application gateway
that implements the vendor-specific functionality.
 Standardization:
 IEEE 802.15.4, WiFi, Z-Wave, Bluetooth (Smart)
 Examples: Smart Home, smart meters
8
Examples
NXP Janet-IP
Philips Hue
SmartThings
9
Revolv Smart Home Gateway
Device to Local Gateway
 Characteristics:
 Variant of “device via gateway to cloud” with local-only operation.
 Peer-to-peer model available as well.
 Open source projects:
 OpenRemote:
http://www.openremote.org/display/HOME/OpenRemote
OpenHAB: http://www.openhab.org/
Alljoyn: https://www.alljoyn.org/


 Interoperability need:
 Entire stack standardized or completely proprietary.
 Standardization:
 Unknown.
 Examples: No commercial products known.
10
Device-to-Cloud
 Characteristics:
 Device uploads data to cloud service directly using available network


infrastructure (e.g., WLAN).
Device is pre-configured to work with specific cloud service only.
Devices often require always-on reachability. Often an evolution of
the “device-to-gateway” scenario.
 Interoperability need:
 Radio technology and IP-connectivity to local network for Internet
access
 Standardization:
 WiFi (dominant), cellular, special radio technologies (e.g., SigFox).
 Devices have to deal with regular network access / IP connectivity
issues.
 Example: Smart home
11
Examples
Withings Scale
LittlePrinter
Tractive
12
Dropcam
Nest
Backend Data Portability
 Characteristics:
 Devices upload data to the cloud operated by a specific vendor.
 Analyzing different data from various sources is, however, valuable.


End users also want to export their data.
Backend data sharing of protected data via OAuth-alike mechanisms
and RESTful APIs.
Security: Protection against unauthorized access requires registration
of users and their devices. Consent mechanism for sharing.
 Interoperability need:
 Today, proprietary APIs are used although Web design patterns, UIs,
and security mechanisms (OAuth) are re-used.
 Standardization:
 Information and data models, OAuth / OpenID Connect.
 Examples: Very common among cloud services
13
Examples
MapMyFitness
https://www.mapmyapi.com/docs/OAuth_2_Intro
14
Authentication and Authorization for
Constrained Devices (ACE)
15
Benefits of ACE
1.
Resource server accessed by a number of
unknown persons / devices.
 This is useful when pre-provisioning and pairing is impractical or
cumbersome.
16
Resource server does not need to have always-on
connectivity to the authorization server
(i.e., it can perform authorization checks locally).
Resource Server
Client
2.
Benefits, cont.
3.
4.
Offers central authorization management
(using the support of the authorization server).
Allows client to resource server communication over
multiple hops when C->RS communication takes place over
IP/UDP/DTLS/CoAP.
 For single-hop C->RS communication other options (such as a
Bluetooth Smart profile) may be more appropriate.
17
Pre-Conditions for ACE
1.
2.
18
Entire protocol stack must be standardized to offer
interoperable and working solution.
Company selling resource server has to be interested in
interoperability with random other vendors.
Many-to-One Access Condition
 With a one-to-one relationships a pairing approach becomes
more reasonable.
 Example: personal heart-rate strap is only accessed by my personal
watch
 If the number of parties accessing a device is fairly small then
pairing is also an option.
 Example: Home situation where door lock can be paired the smart
phones of various family members.
 Previously unknown party requirement ensures that preprovisioning is not a feasible model.
 Example: large number of door locks in an enterprise environment
19
No Internet Connectivity
 Without Internet connectivity by the resource server all
necessary information has to be provided from the client.
 Providing resource servers with Internet connectivity does,
however, offer new possibilities.
 Example: social network integration with locks as shown by Brivolabs
(including credential and access control provisioning, and remotely
locking & unlocking)
 Offering support for intermittent connectivity may be seen as
a backup.
20
Client-to-RS Communication over Multiple Hops
 Communication over a single hop (as it is the case with
Bluetooth Smart or NFC) raises the question about the need
for IP connectivity.
 Multi-hop connectivity:
 Mesh communication has not been standardized for Bluetooth Smart.
 draft-ietf-6lowpan-btle aims to cover a different use case, namely

Internet connectivity for IoT device via BTLE access.
With Zigbee IP a multi-hop solution for IEEE 802.15.4 has been
defined. Unfortunately, the deployment status is grim.
 IP-based multihop communication appear to be a solution.
 Examples can be found in the lighting space.
 Does raise challenge of service discovery.
21
Centrally managed authorization
 In the current way today authorization is managed separately
by each cloud provider for the day they control.
 Although the UI design pattern for smart phones and Web
permission dialogs are somewhat similar they have not been
standardized.
 Centrally managing authorization requires understanding of
the information and data models (i.e., about the data that is
shared) and privacy implications of the sharing.
 This was subject of standardization work in Kantara under the
User Managed Access (UMA) work (which is an extension to
OAuth).
22
Next Steps
 Completeness: Do these patterns reflect what you see?
 Add protocol related guidance to each pattern.
23