1

From Embedded to ConnectedInternet Architecture for the Internet of Things

May 7, 2015

2

Internet Architecture for the Internet of Things

Review of IoT Design Patterns

Design Patterns are recurring solutions to common problems

Design Patterns occur at many levels in system design

Standards – Interoperability and Reusability

3

Design Patterns

Design Patterns are recurring solutions to common problems

Design Patterns occur at many levels in system design

These are some common IoT Design Patterns related to the

tradeoff of embedded vs. connected intelligence in evolving

systems

4

Connected Intelligence and Virtualization

5

Connected Intelligence Disrupts Embedded Intelligence

Thing

Software

Connected

Intelligence

Embedded Intelligence

Network

Embedded intelligence is tied

to Moore’s law at best and

bothered by power and

productivity issues

Connected intelligence is

limited only by the connection –

the entire internet is available

Connectivity is steadily

improving

6

Connected Intelligence works through Abstraction and

Virtualization

Thing

Software

Network

SoftwareAbstraction

(Network)

Firmware,

Middleware

Device

Application

Software interacts with an abstract

model of the physical thing

Virtualization is the process of

creating a software model of a thing

Products are improved and

upgraded by changing the external

software or by connecting to new

services

Value is shifted to the software

outside the device

7

Common Abstractions enable Many-to-Many interactions

Thing

Software

Software Abstractions

Data Models

Software Software

ThingThing

Data models embody common

abstractions for things

This enables diverse software

to interact with diverse things

Data models provide a

consistent data schema to

enable reuse of software

libraries and protocols

Data models allow the

abstraction of underlying

protocols to enable interaction

over diverse transport layers

8

High Level Design Patterns for IoT

9

IoT Design Pattern – Things Interacting over a Network

(using embedded intelligence)

LOCAL NETWORK

10

IoT Design Pattern – Data Aggregation and Analysis

(using cloud services)

COLLECT

FILTER

ANALYZE

11

IoT Design Pattern – Autonomic + Interactive Feedback

Loops

(combining embedded intelligence, local gateways, and

cloud services)

Things

People Software

Inform

Command

InformActuate

Autonomic

Feedback

Loop

Cybernetic

Feedback

Loop

Observe

Control

12

Protocols and Services

13

Modular Protocols - Example

Application Software

IPSO Objects

LWM2M

CoAP HTTP

6LowPAN/T

hreadIPV4/IPV6

MCU – 16KiB RAM MPU

802.15.4 WiFi, Ethernet

Hardware

HW Network

Internet Protocol

Wire Protocol + REST

API – Data and Metadata

Data Models

Application

HTTP

REST

Server

Device

Management

14

Client – Server REST Design Pattern

The end device is an origin server

for it’s data state

Application clients initiate

operations to the device

Scales to many clients

The device returns the data and a

hypermedia response describing

the content returned

Devices may also need to be

clients in order to run connected

applications and discover external

resources

15

Layered Services – Local and Remote

Application

Sensor/

Actuator

Device

Service Layer

Device with

Embedded

Application

Application

IoT

Applicatio

n

ClientServer

Peer-

Peer

Constrained

Device, e.g. 16KB

RAM, 128KB

Flash

• Registration and

Discovery

• Device Proxy and Cache

• Local or Cloud/Remote

• Local or Cloud/Remote

• Reuse of web patterns – REST/ JSON

Client

16

Middleware Services

Devic

e

Application

Software

REST

API

Service

Resource

Directory

Message

Broker

Reachable

Services

REGISTER DISCOVER

PUB/SUB PUB/SUB

UPDATE GET/NOTIFY

More Constrained

Less ReachableLess Constrained

Less Reachable

17

Internet Infrastructure Example

Devic

e

N

A

T

Application

Software

N

A

T

GW,

AP

GW,

AP

REST

API

Service

Resource

Directory

Message

Broker

IP Reachable

Web Services

IP Reachable

or

Non Reachable

Endpoints

IP Reachable

or

Non

Reachable

18

IoT Design Patterns

Devices may connect to many different devices and services

Intelligence is layered and connected intelligence can be of higher

value

Data models enable many to many connection of devices to services

Client-server REST enables dynamic sharing of resources

IP network connections are becoming common

Drive connected value in embedded design for IoT devices

Consider a wide range of services and use cases

Implement standard APIs and common data models

Keep interface design simple and follow common patterns like REST

Expose basic device functions

Use IP network connections

19

IoT Standards

20

Standards – Interoperability and Reusability

Interoperability results in a larger ecosystem of devices and

applications

Reusability of technology and designs makes it easier for new

devices and applications to be created

Open standards that provide APIs and data models for IP based IoT

CoAP

OMA LWM2M

IPSO Smart Objects

21

IoT Standards That Build On Each Other

CoAP and related standards from IETF

REST API for constrained networks and devices

HTTP Proxy provides abstraction through standard web APIs

Core-link-format (RFC 6690) provides semantic descriptors in the form of web links

Resource Directory provides an API for scalable discovery and linking using core link-format

mediatype

OMA LWM2M is based on CoAP

Provides a server profile for IoT middleware including Resource Directory and data proxy

Defines a simple reusable object model

Defines management objects and reuses REST API for onboarding and device life cycle

management

IPSO Smart Objects are based on OMA LWM2M

Defines application objects using the LWM2M Object Model

Complex objects can be composed from simple objects

Easy to add new resource and object types as needed

22

CoAP and Related IETF Standards

23

CoAP Use Case Requirements

REST API

Less

Constraine

d

Resource

Constrained

24

CoAP Scope

• Transport– CoAP currently defines:

– UDP binding with DTLS security

– CoAP over SMS or TCP possible

• Base Messaging– Simple message exchange between endpoints

– Confirmable or Non-Confirmable Message

– Answered by Acknowledgement or Reset Message

• REST Semantics– REST Request/Response mapped onto CoAP Messages

– Method, Response Code and Options (URI, content-type etc.) define REST exchanges, very similar to HTTP (HTTP 404 response semantics (not found) mapped to CoAP 4.04 response code)

• Asynchronous Notifications– Observer option for GET allows asynchronous state update

responses from a single request – actually a separate IETF Draft

25

CoAP Maps HTTP-like protocol to a binary format

26

CoAP Example: GET Transaction

Response with Data Payload

Confirmable Request

27

CoAP Asynchronous Notification

28

RFC 6690 CoRE Link-Format Example

<4001/0/9002>;rt=“oma.lwm2m”;ct=50;obs=1

Resource Type

Content TypeObservable

29

Local Network Discovery Example Flow

Could return a link-format document:

</3//9>;obs;rt=“urn:X-ipso:batt-level”;ct=”50”,

</3//0>;rt=”urn:X-ipso:dev-mdl”;ct=”50”,

</3//1>;rt=”urn:X-ipso:dev-mfg”;ct=”50”,

</3305/0/5800>;obs;rt=”urn:X-ipso:pwr-w”;ct=”50”,

</3305/0/5805>;obs;rt=”urn:X-ipso:pwr-accum-wh”;ct=”50”,

</3303/0/5700>;obs;rt=”urn:X-ipso:temp-C”;ct=”50”

CoAP

ServerCoAP

Client

DISCOVERY

GET /.well-known/core

2.05 Content

Could use

multicast

30

Resource Directory Discovery

See draft-ietf-core-

resource-directory

• A central directory approach is also useful

– Supports sleeping nodes

– No multicast traffic, longer battery life

– Remote lookup, hierarchical and federated distribution

• CoRE Link Format is used in Resource

Directories

– Nodes register their resource links to an RD

– Nodes refresh the RD periodically

– Nodes may unregister (remove) their RD entry

Application

GET /rd-lookup/ep</nodea/sensor/temp>

</nodeb/actuator/led>

31

Resource Directory Example Flow

See draft-ietf-core-resource-directory

core.rd

serviceREGISTRATION

POST /rd?ep=“235598376”&lt=19999

</3303/0/5700>;rt=“urn:X-ipso:temp-C”

Endpoint

2.01 Created Location:/rd/235598376

DISCOVERY

GET /rd-lookup?ep&rt=“urn:X-ipso:temp-C”

2.05 Content

</235598376/3303/0/5700>;rt=“urn:X-ipso:temp-C”

Endpoint

32

OMA LWM2M

33

OMA LWM2M Reference Architecture

• Bootstrap Interface

– Configure Servers & Keying

– Pre-Configured, Smart Card, or Server

Initiated Bootstrap

– CoAP REST API

• Registration Interface

– RFC6690 and Resource Directory

• Management Interface Using Objects

– Management Objects and Resources

– Standard Object Template

– M2M Device is CoAP REST API Server

• Reporting Interface

– Object Instances and Resources Report

– Asynchronous notification using CoAP

Observe

34

OMA LWM2M Object Template - Position Object Example

35

IPSO Smart Objects

36

IPSO Smart Objects Use the LWM2M Object Model

REST API with a URI template

Objects

Object Instances

Resources

Reusable resource and object

IDs

Common definitions for concepts

Map to semantic terms e.g.

Temperature, Current Value

IDs are registered with the OMNA

Data Types and Access Types

String, Decimal, Boolean

Read, Write, Create, Delete

Execute, Discover

3303/0/5700

Object ID, defines object type

Object Instance, one or more

Resource ID, defines resource

type3303 is Temperature

5700 is Current Value

3303/0/5700 refers to the current

value of temperature sensor

instance 0

37

IPSO Smart Object Starter Pack

38

IPSO Smart Objects

More Smart Object Types are being defined, e.g. sensors for Speed,

Pressure, Weight

Smart Object types are being defined for controls and action

bindings

Defining Composite objects made from basic objects e.g. Motor,

Coffee Maker

Semantic annotation of Smart Objects using Core Link-Format

Freedom to define new objects and register them with OMNA

Smart Objects work with any protocol that provides the basic URI

template, data types, and operations

39

Modular Protocol Stack

Application Software

IPSO Objects

LWM2M

CoAP HTTP

6LowPAN/T

hreadIPV4/IPV6

MCU – 16KiB RAM MPU

802.15.4 WiFi, Ethernet

Hardware

HW Network

Internet Protocol

Wire Protocol + REST

API – Data and Metadata

Data Models

Application

HTTP

REST

Server

Device

Management

40

Summary

Value is shifting to connected software applications

Common data models enable reusable software in devices and

applications

IP networking and related standards provide points of interoperability

with modular protocol stacks

Embedded software can expose standard APIs and data models to

enable IoT value through connected software

41

References

IPSO Smart Object Guideline

http://www.ipso-alliance.org/smart-object-guidelines

OMA LWM2M Specification

http://openmobilealliance.hs-sites.com/lightweight-m2m-specification-from-

oma

IETF CoAP and Related Specifications

CoAP (RFC 7252):

http://tools.ietf.org/html/rfc7252

CoRE Link-Format (RFC 6690):

http://tools.ietf.org/html/rfc6690

CoRE Resource Directory: http://tools.ietf.org/html/draft-ietf-core-resource-

directory-01

CoAP Community Site

http://coap.technology/