CoAP

CoAP, standing for Constrainted Application Protocol, is a transport layer protocol inspired by the HTTP philosophy. This protocol has been specially conceived fot constrained nodes, i.e. modules with few memory and few battery. It uses similar mechanisms to HTTP and adapts them to the IoT world.

## Description

CoAP is based on UDP rather than TCP. Indeed, it is lighter and thus more adapted to constrained applications. It is a stateless protocol without reliability mechanisms, but CoAP allows to implement acknowledgement mechanism at a higher level. Even if it is originally designed over UDP, CoAP can also be used with TCP and even on SMS messages. As CoAP is based on the IP layer, it is very easy to interface it with other IP protocols such as UDP and TCP (and so HTTP) through simple proxies. The purpose of the proxy is simply to perform a translation between the targeted protocols.

CoAP uses smaller headers (binary encoded rather than ascii) to exploit the bandwith with a higher efficiency. It is thus more adapted to nodes with few memory, in RAM as well as in code memory. Indeed it can run on devices with as few as 100kB memory. The data are transported in either standardized formats such as json, or in free format chosen by the user.

CoAP is based on the REST model. This represents a communication where all resources are represented by a unique address on a server, called the URI. These resources can be accessed by sending different requests to the server, and asking for a specific URI. This model is the base of HTTP. In CoAP, each node contains data and so each node can act as a server and as a client successively.

CoAP is defined by an open standard (RFC7252) which has been stable over past years. Multiple implementations of CoAP in various language are available nowadays. Some of them are proprietary but many implementations are open sourced and freely available.

## HTTP comparison

While CoAP and HTTP have many common points, they differ on different aspects that can orient the choice of a protocol. Globally, CoAP is more fitted for constrained requirements like for the IoT applications, and it should generally be used in such cases.

As described higher, CoAP uses header contraction by coding addresses directly in binary. HTTP is designed to be human-readable and encodes the header in ascii, but it makes the messages heavier and decreases the bandwidth efficiency.

HTTP is a unicast protocol. It means that a message can be sent to only one target, and if you want to reach multiple nodes you have to send the message multiple times, which is a supplementary load for the sender and for the network. CoAP supports multicast: it is possible to send a message to multiple targets at once. This mechanism works by defining client groups: when a message is sent to a group, the network (i.e. the routing hosts) will automatically duplicate it and send it to all the members of the group. This reduces the sending load of the first host.

HTTP features four types of request: GET, PUT, POST and DELETE. These methods allow different actions on the targeted resource, e.g. deleting a file of modifying its content. The CoAP protocol implements all these request types, and adds new possibilities through the OBSERVE and DISCOVER requests. The first allow a host to be notified of each value change for a specific resource (which can be very convenient for some IoT applications). The latter allows you to know what resources are hosted on an unknown node.

## See also

* MQTT
* HTTP
* OPC
* 6LoWPAN

## Sources

http://coap.technology/

Al-Fuqaha, Ala, et al. "Internet of things: A survey on enabling technologies, protocols, and applications." *IEEE Communications Surveys & Tutorials* 17.4 (2015): 2347-2376.

Singh, Kiran Jot, and Divneet Singh Kapoor. "Create Your Own Internet of Things: A survey of IoT platforms." *IEEE Consumer Electronics Magazine*
6.2 (2017): 57-68.
Zach Shelby, “ARM IoT tutorial: CoAp, the web of things protocol”, April 2014