Wireless Sensor Networks Module 3: Application Protocol - CoAP

Transcription

1 Wireless Sensor Networks Module 3: Application Protocol - CoAP Dr.-Ing. Koojana Kuladinithi, TZI, University of Bremen koo@comnets.uni-bremen.de

2 Contents Module 3: Application Protocols for WSNs Introduction Internet Protocols Design Issues for WSNs CoAP (Constrained Application Protocol) Design requirements Protocol description Message formats Results TinyOS Tutorial 2

3 IP based Application Protocols IP provides packet networking over heterogeneous links UDP: Best-effort (packets may be silently dropped, duplicated or delayed and may arrive out of order) - the fastest and most simple way of transmitting data TCP: Reliable connection oriented IP uses a socket based approach, end-points are defined by 16bit source and destination ports and source and destination IP addresses Internet socket (Src IP address, src port, dest IP address, dest port) Application protocols use socket API Datagram socket (UDP) Stream socket (TCP) Raw socket (IP) Image Source: 3

4 IP based Application Protocols, cont.. Widely used internet protocols (TCP, HTTP, FTP; SIP and SOAP) Considerable work has to be done for adapting to 6LoWPAN Existing protocols for WSNs (mainly based on UDP) MQTT: Message Queue Telemetry Transport is developed by IBM CAP: ZigBee Compact application Protocol SLP: simple Service Location Protocol Etc.. Image Source: 4

5 IP based Application Protocols, cont.. IP based application protocols over 6LoWPAN 6LoWPAN supports the compression of UDP ports down to a range of 16 - should be enough for limited number of applications that can be run TCP header is not easy to compress TCP is not efficient over lossy wireless multi-hop networks Why UDP for 6LoWPAN? Simple, compressible and suits most application protocols needs Multicast support Reliability? 5

6 Application Protocols for WSN MQTT (Message Queue Telemetry Transport) by IBM Lightweight publish/subscribe protocol over TCP/IP Fixed-length header (2 bytes) One-to-many message distribution 3 QoS for message delivery (At most once, at least once, exactly once) Applications, e.g. Facebook Messenger XML-based protocols (SOAP) M2MXML Messages are strict ASCII Devices are identified by 128-bit UUID BiTXml RESTful protocols HTTP CoAP CoAP: Constrained Application Protocol, proposed by the IETF 6

7 Design Issues Link Layer Payload size, limited bandwidth, lossy Multicast support Networking Limited compressed UDP port Host issues Sleeping cycles Identification (64 bit, 16 bit addresses) Compression Header and payload compression End-to-end or by an intermediate node Security Application layer security Firewalling at the edge router Image Source: 7

8 Web Services: XML/HTML De-facto for inter-server communications All Internet servers speak HTTP/XML SOAP or REST architecture Advantages Formal message sequences Internet-wide support Most Internet applications use web services, which depend on the basic Representational State Transfer (REST) architecture XML Messages SOAP HTTP TCP IP L2/DLL L1/PHY Disadvantages for embedded services Inefficient, complex 8

9 REST Architecture Representational State Transfer (REST) Describes client-server and cacheable communications protocol, such as HTTP, to make simple calls between network devices REST-style architectures consist of clients and servers Clients initiate requests to servers Servers process requests and return appropriate responses Requests and responses are built around the transfer of representations of resources 9

10 REST Architecture Resources: mostly identified by its URI (Uniform Resources Identifier) Resources may be web-address, a physical resource or simply a document located somewhere on a server Representations: content type of a resource Representation defines the format of the resource Typical representations are HTML, XML or JSON, But, may be also binary, plain-text, MIME types, etc Methods: allows clients to retrieve, modify or delete resources by use of their representations to manipulate resources The basic operations/methods on a resource are GET, PUT, POST and DELETE Image Source: Thomas Pötsch,, Master Thesis,

11 Resources Protocols (e.g. HTTP, CoAP) Sources of specific information (e.g. sensors, web-content) Identified by an Uniform Resource Identifier (URI) Manipulation through Methods (e.g. GET, PUT) Represented as jpg, plain-text, etc. Web-Content GET Sensors GET coap://[fec0::3]:61616/temp jpg plain-text binary plain-text Center-point: 12, 10 Radius: C CoAP: Constrained Application Protocol, proposed by the IETF 11

12 Web Services for WSNs Today s web services are no good for embedded systems FTP, HTTP, XML, SOAP Web services for embedded devices RESTful architecture for good web integration UDP based transport with multicast support Overhead suitable for constrained networks Complexity suitable for constrained nodes Built-in web discovery and security The Constrained RESTful Environments (CoRE) working group aims at realizing the REST architecture for constrained nodes and networks e.g. 8-bit microcontrollers with limited RAM and ROM networks (e.g. 6LoWPAN) 12

13 CoAP: Constrained Application Protocol, proposed by the IETF CoRE Working Group: draft-ietf-core-coap-07 (RFC 7252, published in June 2014) 13

14 CoAP: Constrained Application Protocol A specialized web transfer protocol for use with constrained networks and nodes M2M applications (smart energy, building automation, etc) To monitor simple sensors (e.g. temperature sensors, light switches, and power meters) To control actuators (e.g. light switches, heating controllers, and door locks) To manage devices 14

15 CORE Architecture Image Source: 77 th IETF core WG presentations Use of web services on the Internet depends on the Representational State Transfer (REST) architecture RESTful protocol to cater the special requirements of a constrained environment Simple RESTful protocol transport Create, Read, Update, Delete, Notify Small, simple header 4 byte base header TLV options, typically bytes per option URI support: e.g. coap://fec0::1:5683/temp Subset of content types Subset of HTTP-compatible response codes UDP bindings default port = 5683 C: Constrained node - sensor nodes Non-constrained nodes - server, proxy, node, etc 15

16 CoAP Requirements C: Constrained node - sensor nodes 14 requirements of CoAP are defined in draft-shelby-core-coap-req-04 Image Source: from CoRE WG, IETF-77 Anaheim meeting 16

17 Transaction Messages of CoAP Confirmable (CON) To know it did arrive or to deliver the reply Return message type ACK/RST Acknowledgment (ACK) ACK to the CON message (identified by a message ID) Payload carries more data Reset (RST) To let the client know the CON message is received, but processing failed E.g. node has rebooted Non-Confirmable (NON) Do not require an ACK E.g. repeated readings from a sensor Client Server -- CON + GET/ temperature [MID=0x7d34] GET=1 MID=0x7d "temperature" (11 B) Client Server < ACK [MID=0x7d34] =69 MID=0x7d "22.3 C" (6 B) Note: slightly different format is used in RFC

18 Methods of CoAP GET: retrieves the information of the resource identified by the request URI PUT: requests that the file/resource identified by the request URI to be updated with the enclosed message body. If does not exists, it creates a new resource PUT is idempotent POST: Submits data to be processed to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both POST is non-idempotent DELETE: requests that the resource identified by the request URI to be deleted 18

19 Overview of CoAP CoAP interaction is similar to the client/server model (CoAP end points) URI and Content-type support (like in HTTP) Message exchange is similar to HTTP Request action is originated by a client (using a Method code) Request is for a Resource (identified by a URI) on a server Response is sent with a Response Code 19

20 Overview of CoAP, cont.. Unlike HTTP, CoAP deals Operates over UDP, with reliable unicast and multicast support - Retransmission (= reliable unicast) A CoAP end-point keeps track of open Confirmable messages it sent that are waiting for a response - Simple Congestion Control - exponential back-off mechanism Deals with message interchanges seperately - Server might need longer time to obtain the representation of resource. This results in the client retransmitting the request 20

21 Overview of CoAP, cont.. Two sublayer approach Deals with Request/Response interactions (using Method and Response codes) Deals with UDP protocol and Asynchronous type of interactions Built in Resource Discovery Well-known resource URI which returns a list of resources offered by that constrained server GET /.well-known/core </sensors/temp>;sh="/t";ct=0,41;n="temperaturec", </sensors/light>;sh="/l";ct=41;n="lightlux" 21

22 Overview of CoAP, cont.. Operates over UDP, with reliable unicast and best-effort multicast support CON vs NON messages? If CON/NON messages cannot be processed, Server sends RST message Why MID & Token? 22

23 Message Format of CoAP Ver T OC Code Message ID Options (if any) Payload (if any) Ver: Version, T: Transaction Type (CON,NON,ACK ) OC: Number of options Code: Method or Response Code Message ID: A unique ID assigned by the originator Note: slightly different format is used in RFC

24 CoAP Response Codes Source: draft-ietf-core-coap-07 Structure of the 8 bit Response code class detail classes: 2 Success 4 Client error 5 Server error class detail : 04 E.g., "Not Found" is written as indicating a value of decimal

25 An Example of CoAP Messages Client Server -- CON + GET/ temperature [MID=0x7d34] GET=1 MID=0x7d "temperature" (11 B) Tx Type Num of Options URI Path option Client Server < ACK [MID=0x7d34] =69 MID=0x7d "22.3 C" (6 B) : =

26 CoAP Options Content-Type: Specifies the format of the application payload Max-Age: Maximum age for a message to be cached Proxy-Uri: Defines an absolute URI to a proxy Token: Matches a seperate response to a request Uri-Host: Specifies the Internet host of a resource (only added if not representing the destination IP address of the request) Uri-Path: Specifies the resource of the host Uri-Port: Specifies the port of the host (only added if differs from the destination UDP port request) Uri-Query: Indicates additional options for the request Etc.. 26

27 Use of WSNs in Logistic Applications WSN Protocols IPv6 Header Compression : 6LoWPAN RPL: Routing for Low Power Lossy networks - OF0 (Objective Function 0): - MRHOF (Minimum Rank Objective Function with Hysteresis - Trickle Algorithm CoAP: Constrained Application Protocol - Like HTTP, UDP, Reliable 27

28 Use of CoAP in Logistic Applications More details: 28

29 CoAP over SMS SMS CoAP access from a Mobile More details at draft-becker-core-coap-sms-gprs 29

30 Analysis of Results 30

31 Evaluation of libcoap implementation GET /st and /r are seperate messages higher retrieval time and number of transmitted bytes Separate transactions Source: Thomas Pötsch,, Master Thesis,

32 CoAP Implementation on TinyOS (libcoap) Increase to CoAP with resources is mostly because of additional components TelosB node : 48K bytes of flash memory, 10K bytes of RAM Image Source: Thomas Pötsch,, Master Thesis,

33 HTTP vs CoAP Internet GPRS CoAP/HTTP Server CoAP/HTTP Client CoAP Request/HTTP GET CoAP Response/HTTP OK HTTP on TCP based protocols - Apache2 HTTP server access from Firefox browser - Apache2 HTTP server access from Epiphany browser - Apache2 HTTP server access from wget - BareHTTP server access from barehttpclient using TCP HTTP on UDP based protocols CoAP - BareHTTP server access from barehttpclient using UDP 33

34 CoAP vs HTTP (RTT) Test on GPRS, not , because of HTTP not available on CoAP wasn t available for TinyOS at that time CoAP might be of interest for M2M on GPRS as well Similar RTT for multi-hop 6LoWPAN 34

35 CoAP vs HTTP (# Bytes) Firefox downloads favicon Firefox, Epiphany, and wget add user agents Apache2 adds Content-Type etc Bare server and clients are less chatty UDP reduces at lot CoAP has retransmission 35

36 CoAP in a Nutshell Transaction Messages: CON, NON, ACK, RST Methods: GET, PUT, POST, DELETE Pre-processed URI in different options Resource discovery built-in /.well-known/core Caching/Proxying HTTP like response codes Mapping to HTTP 36

37 Summary: IP based WSN Protocols Module 1: 6LoWPAN Header compression Module 2: Routing for WSNs Module 3: Application protocol, CoAP for WSNs WSN Protocols GOAL: Simple, scalable, energy-efficient, low overhead protocols - Simple (for devices with limited memory & storage) - Scalability (for several hundred to a few thousand nodes) -.. IP for WSNs? Long-life and stability of standards Scalability and maintainability Easy learning curve Seamless Internet integration 37

38 M2M/Sensor Networks use case landscape Source: Harbor Research M2M / Pervasive Internet Market Forecast Report. 2009

39 Trends of Future Communication CAGR: Compound Annual Growth Rate CAGR: Compound Annual Growth Rate M2M traffic will grow 22-fold from 2011 to 2016 (86% p.a.) An average M2M device generates 266 MB traffic p.m. (71 MB in 2011) M2M will account for ~5% of total mobile data traffic ( ~4% in 2011) Source: Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update,

40 Acknowledgement Some content and figures on these slides are taken from under the Creative Commons Attribution- Noncommercial-Share Alike 3.0 Unported License. To view a copy of this license, visit References Thomas Pötsch, Implementation, Simulation and Measurements of the CoAP Protocol, Master Thesis,, University of Bremen, 2011 Koojana Kuladinithi, Olaf Bergmann, Thomas Pötsch, Markus Becker & Carmelita Görg: Implementation of CoAP and its Application in Transport Logistics. Extending the Internet to Low power and Lossy Networks (IP+SN 2011). Chicago, USA. 11th of April

41 Tutorial - 1: TinyOS (blip and Coap) 41

42 Contiki and TinyOS TinyOS Contiki Application UDP App & Transport Application UDP TinyRPL BLIP Network ContikiRPL uipv6 RPL (OF0, MRHOF, Trickle Algorithm, etc) 6LoWPAN Header Compression (stateless) Network Prefix CSMA CSMA Low Power Control LL Radio Duty Cycling LL Parameters CC2420 driver CC2420 driver IEEE PHY IEEE Radio Channel PAN ID 42