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 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 2 tutorials 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 destinationip 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: book/ 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: book/ 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 thatcan 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 (2bytes) 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: book/ 7

8 Web Services: XML/HTML De facto for inter server communications All Internet servers speak HTTP/XML XML Messages SOAP or REST architecture SOAP Advantages Formal message sequences Internet wide support Most Internet applications use web services, which depend on the basic Representational State Transfer (REST) architecture 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: to manipulate resources Representation defines the format of the resource Typical representations are HTML, XML or JSON, butmaybe be also binary, plain text text, MIMEtypes types, etc Methods: allows clients to retrieve, modify or delete resources by use of their representations 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 REWorking Group: draft ietf core coap 07 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 y 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 coap req 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) Client Server -- CON + GET/ temperature [MID=0x7d34] 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 GET=1 MID=0x7d "temperature" (11 B) Client Server < ACK [MID=0x7d34] =69 MID=0x7d "22.3 C" (6 B)

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 exsists, it creates a new resource 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 dt of existing iti resources or both 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) URIandContent Content type typesupport (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 links 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: Mthd Method or Response Code Message ID: A unique ID assigned by the originator 23

24 CoAP Codes Source: draft ietf core coap 07 f Structure t 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 4.04 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)... p "temperature" (11 B)... URI Path option Tx Type Num of Options 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 d if dff differs from the destination UDP port request) Uri Query: Indicates additional options for the request Etc.. 26

27 Use of CoAP in Logistic Applications More details: 27

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

29 Analysis of Results 29

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

31 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,

32 HTTP vs CoAP 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 BareHTTP server access from barehttpclient using UDP CoAP 32

33 CoAP vs HTTP (RTT) Test on GPRS, not , because of HTTP not available on CoAPwasn t availablefortinyosat at thattime time CoAP might be of interest for M2M on GPRS as well Similar RTT for multi hop 6LoWPAN 33

34 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 34

35 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 35

36 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 36

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

38 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,

39 Acknowledgement Some content and figures on these slides are taken from content/uploads/2009/12/6lowpan bookslides full pdf, under the CreativeCommons Commons Attribution Noncommercial Share Alike 3.0 Unported License. To view a copy of this license, visit nc sa/3.0/ 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

40 Tutorial 1: Virtenio Nodes / Contiki 40