The document discusses internet architecture patterns for connecting embedded devices in the Internet of Things. It describes common design patterns including using embedded intelligence, connected intelligence through virtualization and abstraction, and combining local and cloud-based services through feedback loops. It also reviews standards like CoAP, LWM2M, and IPSO smart objects that provide interoperability through modular protocol stacks and common data models.

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

4. 4
Connected Intelligence and Virtualization

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

8. 8
High Level Design Patterns for IoT

9. 9
IoT Design Pattern – Things Interacting over a Network
(using embedded intelligence)
LOCAL NETWORK

10. 10
IoT Design Pattern – Data Aggregation and Analysis
(using cloud services)
COLLECT
FILTER
ANALYZE

11. 11
IoT Design Pattern – Autonomic + Interactive Feedback
Loops
(combining embedded intelligence, local gateways, and
cloud services)
Things
People Software
Inform
Command
Inform
Actuate
Autonomic
Feedback
Loop
Cybernetic
Feedback
Loop
Observe
Control

12. 12
Protocols and Services

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

16. 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 Reachable
Less Constrained
Less Reachable

17. 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. 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. 19
IoT Standards

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

22. 22
CoAP and Related IETF Standards

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

25. 25
CoAP Maps HTTP-like protocol to a binary format

26. 26
CoAP Example: GET Transaction
Response with Data Payload
Confirmable Request

27. 27
CoAP Asynchronous Notification

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”&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. 32
OMA LWM2M

33. 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. 34
OMA LWM2M Object Template - Position Object Example

35. 35
IPSO Smart Objects

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

37. 37
IPSO Smart Object Starter Pack

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/