Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Design Patterns for Connected Devices Hannes Tschofenig Michael Koster.

Similar presentations


Presentation on theme: "1 Design Patterns for Connected Devices Hannes Tschofenig Michael Koster."— Presentation transcript:

1 1 Design Patterns for Connected Devices Hannes Tschofenig Michael Koster

2 2 Goal 1. Capture common IoT design patterns 2. Determine need for interoperability

3 3 Design Patterns

4 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 5 Examples Wahoo Heart- Rate Monitor Beacons Cadence Sensor Parrot Hearing Aid

6 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 7 Examples, cont. from device-to-device Zepp Golf Sensor Oral-B Toothbrush StickNFind JawBone

8 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 9 Examples Philips Hue NXP Janet-IP Revolv Smart Home Gateway SmartThings

10 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 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 12 Examples LittlePrinter Withings Scale Tractive Nest Dropcam

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

15 15 Authentication and Authorization for Constrained Devices (ACE)

16 16 Benefits of ACE Resource Server Client 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 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 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 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 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 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 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 23 Next Steps  Completeness: Do these patterns reflect what you see?  Add protocol related guidance to each pattern.


Download ppt "1 Design Patterns for Connected Devices Hannes Tschofenig Michael Koster."

Similar presentations


Ads by Google