ARM CoAP Tutorial

1
ARM IoT Tutorial
Zach Shelby
April 30th, 2014
CoAP: The Web of Things Protocol

3
3
M2M Internet of Things
Little Data
Big Data
Web
Evolution from M2M to IoT
The Web
Things
Services

4
CoAP:The Web of Things Protocol
§  Open IETF Standard
§  Compact 4-byte Header
§  UDP, SMS, (TCP) Support
§  Strong DTLS Security
§  Asynchronous Subscription
§  Built-in Discovery

5
From Web Applications to IoT Nodes
Web Application
1000s of bytes
HTTP
IP
TLS / TCP
DTLS / UDP
Binary Web Object
CoAP
IP
100s bytes
10s of bytes
IoT Backhaul
IoT Node Network
Proxy Router
Web Object
DTLS / UDP
Binary Web Object
CoAP
6LoWPAN

6
CoAP is One Key IoT Standard
Local
Network
Protocols,
Security
Application
ZigBee IP ZigBee NANBT Smart IP
TLS Based SecurityWeb: CoAP & HTTP
Lightweight M2M Application Objects ZigBee Web Objects
Mature New
ZigBee IP 1.X
CoRE
6LoWPAN

11
An HTTP Request
See RFC2616 - Hypertext Transfer Protocol v1.1

14
CoAP: Constrained Application Protocol

17
What CoAP is (and is not)
§  Sure, CoAP is
§  A very efficient RESTful protocol
§  Ideal for constrained devices and networks
§  Specialized for M2M applications
§  Easy to proxy to/from HTTP
§  But hey, CoAP is not
§  A general replacement for HTTP
§  HTTP compression
§  Restricted to isolated “automation” networks

18
CoAP Features
§  Embedded web transfer protocol (coap://)
§  Asynchronous transaction model
§  UDP binding with reliability and multicast support
§  GET, POST, PUT, DELETE methods
§  URI support
§  Small, simple 4 byte header
§  DTLS based PSK, RPK and Certificate security
§  Subset of MIME types and HTTP response codes
§  Built-in discovery
§  Optional observation and block transfer

19
Transaction Model
§  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 piggybacked on CoAP Messages
§  Method, Response Code and Options (URI, content-type etc.)

23
Request Example
Piggy-backed Response

Conﬁrmable Request

27
Caching
§  CoAP includes a simple caching model
§  Cacheability determined by response code
§  An option number mask determines if it is a cache key
§  Freshness model
§  Max-Age option indicates cache lifetime
§  Validation model
§  Validity checked using the Etag Option
§  A proxy often supports caching
§  Usually on behalf of a constrained node,
§  a sleeping node,
§  or to reduce network load

29
Observation
See draft-ietf-core-observe

30
Block transfer
See draft-ietf-core-block

31
Getting Started with CoAP
§  There are many open source implementations available
§  mbed includes CoAP support
§  Java CoAP Library Californium
§  C CoAP Library Erbium
§  libCoAP C Library
§  jCoAP Java Library
§  OpenCoAP C Library
§  TinyOS and Contiki include CoAP support
§  CoAP is already part of many commercial products/systems
§  ARM Sensinode NanoService
§  RTX 4100 WiFi Module
§  Firefox has a CoAP plugin called Copper
§  Wireshark has CoAP dissector support
§  Implement CoAP yourself, it is not that hard!

33
What is Web Linking?
§  Links have been around a long time
§  Web Linking formalizes links with defined relations, typed links
§  HTML and Atom have allow links
§  RFC5988 defines a framework for Web Linking
§  Combines and expands the Atom and HTML relation types
§  Defines a unified typed link concept
§  A link can be serialized in any number of formats
§  RFC5988 revives the HTTP Link Header and defines its format
§  Atom and HTML are equivalent serializations

34
What is Web Linking?
§  A type link consists of:
§  Context URI – What the link is from
§  Relation Type – Indicates the semantics of the link
§  Target URI – What the link is too
§  Attributes – Key value pairs describing the link or its target
§  Relations include e.g. copyright, author, chapter, service etc.
§  Attributes include e.g. language, media type, title etc.
§  Example in HTTP Link Header format:
Link: <http://example.com/TheBook/chapter2>; rel="previous"; title="previous
chapter" !

35
Resource Discovery
§  Service Discovery
§  What services are available in the first place?
§  Goal of finding the IP address, port and protocol
§  Usually performed by e.g. DNS-SD when DNS is available
§  Resource Discovery
§  What are the Web resources I am interested in?
§  Goal of finding URIs
§  Performed using Web Linking or some REST interface
§  CoRE Link Format is designed to enable resource discovery

36
CoRE Link Format
§  RFC6690 is aimed at Resource Discovery for M2M
§  Defines a link serialization suitable for M2M
§  Defines a well-known resource where links are stored
§  Enables query string parameters for filtered GETs
§  Can be used with unicast or multicast (CoAP)
§  Resource Discovery with RFC6690
§  Discovering the links hosted by CoAP (or HTTP) servers
§  GET /.well-known/core?optional_query_string
§  Returns a link-header style format
§  URL, relation, type, interface, content-type etc.

37
CoRE Resource Discovery
!
!
!
!
!
!
!
</dev/bat>;obs;rt="ipso:dev-bat";ct="0",!
</dev/mdl>;rt="ipso:dev-mdl";ct="0",!
</dev/mfg>;rt="ipso:dev-mfg";ct="0”,!
</pwr/0/rel>;obs;rt="ipso:pwr-rel";ct="0",!
</pwr/0/w>;obs;rt="ipso:pwr-w";ct="0",!
</sen/temp>;obs;rt="ucum:Cel";ct="0"!

38
Resource Directory
§  CoRE Link Format only defines
§  The link format
§  Peer-to-peer discovery
§  A directory approach is also useful
§  Supports sleeping nodes
§  No multicast traffic, longer battery life
§  Remote lookup, hierarchical and federated distribution
§  The CoRE Link Format can be used to build Resource Directories
§  Nodes POST (register) their link-format to an RD
§  Nodes PUT (refresh) to the RD periodically
§  Nodes may DELETE (remove) their RD entry
§  Nodes may GET (lookup) the RD or resource of other nodes
See draft-ietf-core-resource-directory

39
Resource Directory
See draft-ietf-core-resource-directory

40
How to get Semantic?
§  So how to use CoRE in real applications?
§  Resources need meaningful naming (rt=)
§  A resource needs an interface (if=)
§  See [draft-vial-core-link-format-wadl] on using WADL for this
§  A payload needs a format (EXI, JSON etc.)
§  Deployment or industry specific today
§  oBIX, SensorML, EEML, sMAP etc.
§  SenML is a promising format [draft-jennings-senml]
§  CBOR is a standard for binary JSON [RFC7049]
§  Promising data semantics for use with CoAP
§  OMA Lightweight M2M [http://j.mp/lwm2m]
§  IPSO Objects [http://www.ipso-alliance.org/smart-object-committee-charter]
§  CoRE Interfaces [draft-ietf-core-interfaces]

41
CoRE Link Format Semantics
§  RFC6690 = Simple semantics for machines
§  IANA registry for rt= and if= parameters
§  Resource Type (rt=)
§  What is this resource and what is it for?
§  e.g. Device Model could be rt=“ipso.dev.mdl”
§  Interface Description (if=)
§  How do I access this resource?
§  e.g. Sensor resource accessible with GET if=“core.s”
§  Content Type (ct=)
§  What is the data format of the resource payloads?
§  e.g. text/plain (0)

42
CoRE Interfaces
§  CoRE Interfaces [draft-ietf-core-interfaces]
§  A paradigm for REST profiles made up of function sets
§  Simple interface types
!

ARM CoAP Tutorial

More Related Content

What's hot (20)

Similar to ARM CoAP Tutorial (20)

Recently uploaded (20)

ARM CoAP Tutorial

Editor's Notes