1. 1
From Embedded to Connected
Internet Architecture for the Internet of Things
May 7, 2015
2. 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. 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
5. 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. 6
Connected Intelligence works through Abstraction and
Virtualization
Thing
Software
Network
Software
Abstraction
(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. 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
13. 13
Modular Protocols - Example
Application Software
IPSO Objects
LWM2M
CoAP HTTP
6LowPAN/T
hread
IPV4/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. 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. 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
18. 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
20. 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. 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
23. 23
CoAP Use Case Requirements
REST API
Less
Constraine
d
Resource
Constrained
24. 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
28. 28
RFC 6690 CoRE Link-Format Example
<4001/0/9002>;rt=“oma.lwm2m”;ct=50;obs=1
Resource Type
Content Type
Observable
29. 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
Server
CoAP
Client
DISCOVERY
GET /.well-known/core
2.05 Content
Could use
multicast
30. 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. 31
Resource Directory Example Flow
See draft-ietf-core-resource-directory
core.rd
service
REGISTRATION
POST /rd?ep=“235598376”<=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
36. 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
type
3303 is Temperature
5700 is Current Value
3303/0/5700 refers to the current
value of temperature sensor
instance 0
38. 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. 39
Modular Protocol Stack
Application Software
IPSO Objects
LWM2M
CoAP HTTP
6LowPAN/T
hread
IPV4/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. 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. 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/