Upload
sigourney-emerson
View
10
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Design Patterns for Connected Devices Hannes Tschofenig Michael Koster . Goal. Capture common IoT design patterns Determine need for interoperability. Design Patterns. Device-to-Device Communication. Characteristics: - PowerPoint PPT Presentation
Citation preview
1
Design Patterns for Connected Devices
Hannes Tschofenig <[email protected]>Michael Koster <[email protected]>
2
Goal
1. Capture common IoT design patterns
2. Determine need for interoperability
3
Design Patterns
4
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
5
Examples
Wahoo Heart-Rate Monitor
Beacons
Cadence SensorParrot
Hearing Aid
6
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
7
Examples, cont. from device-to-device
Zepp Golf
Sensor
Oral-B Toothbrush
StickNFind
JawBone
8
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
9
Examples
Philips Hue
NXP Janet-IP
Revolv Smart Home GatewaySmartThings
10
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.
11
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
12
Examples
LittlePrinter
Withings Scale
Tractive NestDropcam
13
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
14
MapMyFitnesshttps://www.mapmyapi.com/docs/OAuth_2_Intro
Examples
15
Authentication and Authorization for
Constrained Devices (ACE)
16
Benefits of ACE
Res
ou
rce
Ser
ver
Cli
ent
1. Resource server accessed by a number of unknown persons / devices. This is useful when pre-provisioning and pairing is impractical or
cumbersome.
2. Resource server does not need to have always-on connectivity to the authorization server (i.e., it can perform authorization checks locally).
17
Benefits, cont.
3. Offers central authorization management (using the support of the authorization server).
4. 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.
18
Pre-Conditions for ACE
1. Entire protocol stack must be standardized to offer interoperable and working solution.
2. Company selling resource server has to be interested in interoperability with random other vendors.
19
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 pre-provisioning is not a feasible model. Example: large number of door locks in an enterprise environment
20
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.
21
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.
22
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).
23
Next Steps Completeness: Do these patterns reflect what you see? Add protocol related guidance to each pattern.