1

Design Patterns for Connected Devices

Hannes Tschofenig <hannes.tschofenig@arm.com>Michael Koster <michael.koster@arm.com>

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.