Introduction
IoT technology has triggered an exponential growth of connected devices. Businesses that operate huge networks of connected devices will require increased resources in terms of connectivity and power. As a result, it becomes extremely important for the devices to be ultra-low powered while using limited processing and network resources.
In general, connected devices are meant to send aggregated data to the cloud or local servers by using communication protocols for further analysis. There are many protocols for communication between end nodes and servers. The most popular and widely used is the HTTP, a protocol which has to transmit a large amount of payload data for very small size of information data. As such, this means more processing power resulting in higher power consumption.
However, since IOT nodes are very low powered, they have to work on 8-bit microcontrollers with limited CPU performance. The communication network might be LoWPAN having a very low throughput and high packet error rate. Such requirements have driven the emergence of lightweight communication protocols using fewer network resources like CoAP (Constrained Application Protocol) ideally suited for M2M and Home Automation applications.
Main Features of CoAP
- REST Model for small devices: This enables CoAP servers to serve resources under a URL using methods like GET, POST, PUT and DELETE.
- Flexible Integration: Data can be transferred from HTTP applications to CoAP applications and vice-versa using cross-protocol proxies.
- Multiple Data Models: Can carry multiple types of data payloads. Data format can be of type XML, JSON, CBOR or any other.
- Low Footprint: CoAP is designed to work with microcontrollers which have 10KB of RAM and 100KB of code space.
- Low Overhead: CoAP is designed to work with UDP over IP network and meant to use minimal network resources.
- Integrated Discovery: The CoAP resource directory provides a way to discover the properties of the nodes in the network.
- Observe: The client node can make a GET request to the server with a observe flag so that server can reply to nodes on state changes avoiding periodic requests by the nodes.
CoAP Communication Model
CoAP is a Service Layer protocol influenced by HTTP and uses the same Server-Client or Request-Response model along with REST architecture. Though it is a single layer protocol, it logically uses a two-layer approach using a Messaging code and Request-Response code, both forming part of the CoAP header.
The CoAP messaging model is based on the exchange of messages over UDP. CoAP uses a 4Bytes fixed length binary header followed by compact binary options and a payload. To prevent duplication each message contains a unique Message-ID which is of 16bit length and thus allows up to 250 messages to be transferred in one second from one point to another with the default protocol parameters. Marking a message as Confirmable (CON) provides reliability as the sender expects an acknowledgment from the recipient within a set timeout. If ACK is not received, sender resends the message with an exponential backoff or decrease in the rate of retry. The recipient acknowledges with the message ID to the sender when it processes the message. If it happens that the recipient is unable to process the message and also unable to provide a suitable error code it replies with an RST message instead of an ACK. Messages not needing acknowledgement can be sent as a Non-Confirmable message (NON) and are not acknowledged by the recipient. NON Messages also contains message ID to avoid duplication and the recipient might reply with an RST message if it is not able to process the message.
CoAP request and response semantics are carried in CoAP messages as options, which include method code or response code. A token is used to match responses to requests from the underlying messages. If the request is through confirmable message and the response to the request is available instantly, the response can be piggybacked into the acknowledgment. This avoids separate transmission of the response from the server and ACK from the client upon successful reception of the response. If the acknowledgement is lost the client will make the request again. If the response is not available immediately, the server responds with a blank acknowledgement to avoid retransmission of the request by the client. The response is sent by the Server in a confirmable message when the response gets ready and has to be acknowledged by the client. If the request is carried in a non-confirmable message, the server can send the response using confirmable or non-confirmable message.
CoAP also supports caching of the responses to make the response fast and is enabled using freshness and validity information available with the response.
Frame Format
CoAP messages are encoded in a simple binary format including a 4 Byte header, Token, Options, and Payload. For any type of message, the header is compulsory since it may contain Token or Options or Payload. Different fields in a CoAP message are:
CoAP Version: (2 Bit) is a part of the fixed header and defines the version of the CoAP used.
Message Type: (2 Bit) defines the type of the message.
0: Confirmable (CON)
1: Non-Confirmable (NON)
2: Acknowledgement (ACK)
3: Reset (RST)
Token Length: (4 Bit) indicating the length of the token variable which can be up to 8 bytes.
Request/Response Code: (1 Byte) c.dd split into class c of 3 bits and details dd of 5 bits.
Table 1: CoAP Method and Response Codes
Unique Message ID (2 Bytes): is a 16-bit number in the network byte order. It is used to detect message duplication. Message ID is also used to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.
Token value is used to correlate requests and responses. Every request carries a client-generated token that the server MUST echo without modification in any resulting response. A token is intended for use as a client-local identifier or a Request ID for differentiating between concurrent requests. The client should generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique.
Options follow Tokens. Both requests and responses may include a list of one or more options. Options are used to provide Information like URI and payload media type. CoAP defines a single set of options that are used in both requests and responses like Content-Format, ETag, Location-Path, Location-Query, Max-Age, Proxy-Uri, Proxy-Scheme, Uri-Host, Uri-Path, Uri-Port, Uri-Query, Accept, If-Match, If-None-Match, and Size1. Not all options are defined for use with all methods and response codes.
Payload can be a representation of resource or result of a requested action and is the primary content or data. The content format is specified by the internet media type, which can be plain-text, XML, Json etc. Diagnostic payloads explain the client-server error in human readable format and do not have the content-format option. Packets containing information like ACK, RST do not need payloads. A special byte 0xFF marks the end of the options and start of the payload.
Applications and Tools
There are numerous tools available to work with CoAP, ranging from Server Side applications to end nodes. Some of the applications and tools are listed below,
Server Side:
- Californium, nCoAP, Leshan: JAVA Implementation for Servers.
- LibCoAP: Implementation in C
- CoAP.NET, CoAPSharp: C# Implementation for Servers.
End Nodes:
- Erbium: Implementation for Contiki IOT OS
- LibCoAP, SMCP, MicroCoAP: Implementation in C
- MR-CoAP: JAVA Implementation of CoAP
Browser based:
- Copper is available as an extension for Firefox web browser to test out CoAP.
Commercial Implementation:
- ARM ‘mbed OS’ comes with CoAP implementation. Website thethings.io provides cloud services to carry out CoAP based projects; it supports devices to send data using CoAP.
Top Comments