Goal

1. Design Patterns for Connected DevicesHannes Tschofenig <hannes.tschofenig@arm.com>Michael Koster <michael.koster@arm.com>

2. Goal Capture common IoT design patterns 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 Hearing Aid Parrot Cadence Sensor

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 StickNFind Zepp Golf Sensor JawBone Oral-B Toothbrush

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 SmartThings Revolv Smart Home Gateway

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 Nest Tractive Dropcam

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. MapMyFitness Examples https://www.mapmyapi.com/docs/OAuth_2_Intro

15. Authentication and Authorization forConstrained Devices (ACE)

16. Benefits of ACE Resource server accessed by a number of unknown persons / devices. This is useful when pre-provisioning and pairing is impractical or cumbersome. 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

17. Benefits, cont. 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.

18. Pre-Conditions for ACE • 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.

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.