CoAP Protocol Tutorial: Step by step guide

This tutorial is a guide about CoAP (Constrained Application Protocol) and how to use it in the Internet of things.  In brief, CoAP is an IoT protocol that has interesting features specifically designed for constrained devices:

CoAP is a simple protocol with low overhead specifically designed for constrained devices (such as microcontrollers) and constrained networks

Nowadays, IoT is a great reality, and one of the most interesting and promising technology trend. In short, IoT is an ecosystem where objects, people, devices are interconnected and exchange data.

What is CoAP protocol?

CoAP is a protocol used in IoT:

• CoAP stands for Constrained Application Protocol and it is defined in RFC 7252
• it is a protocol useful in M2M data exchange
• it is very similar to HTTP even if there are important differences that we will cover later

Main features

The main features of this protocol are:

• Web protocol used in M2M with constrained requirements
• Asynchronous message exchange
• Low overhead and very simple to parse
• URI and content-type support
• Proxy and caching capabilities

As you may notice, some features are very similar to HTTP. Although these similarities,  CoAP must not be considered a compressed HTTP protocol because it is specifically designed for IoT. Therefore, it optimizes the M2M data exchange.

How CoAP protocol works?

From the abstraction protocol layer, it is possible to represent this protocol as:

As you can see there are two different layers that make CoAp protocol:

• CoAP Message: deals with UDP and with asynchronous messages
• CoAP Request/Response: layer manages request/response interaction based on request/response messages

CoAP Message types

CoAP supports four different message types:

• Confirmable
• Non-confirmable
• Acknowledgment
• Reset

Before going deeper into the CoAp protocol structure is useful to define some terms that we will use later:

Endpoint: An entity that participates in the protocol. Usually, an Endpoint is identified with a host

Sender: The entity that sends a message

Recipient: The destination of a message

Client: The entity that sends a request and the destination of the response

Server: The entity that receives a request from a client and sends back a response to the client

CoAP Message Model

This is the lowest layer of CoAP. Therefore, this layer deals with UDP exchanging messages between endpoints. Moreover, each CoAP message has a unique id. This is useful to detect message duplicates.  A CoAP message has these parts:

• a binary header
• a compact options
• payload

Later, we will describe the message format in more detail.

As said before, the CoAP protocol uses two kinds of messages:

• Confirmable message
• Non-confirmable message

A CoAP confirmable message is a reliable message. When exchanging messages between two endpoints, these messages can be reliable. In the CoAP protocol, a reliable message is obtained using a Confirmable message (CON). As a result, using this kind of message, the client can be sure that the message will arrive at the server. A CoAP Confirmable message is sent again and again until the other party sends an acknowledge message (ACK). The ACK message contains the same ID of the confirmable message (CON).

The picture below shows the CoAP message exchange process:

If the server has troubles managing the incoming request it can send back a Rest message (RST) instead of the Acknowledge message (ACK):

The other message category is the Non-confirmable (NON) messages. These are messages that don’t require an Acknowledge by the server. Consequently, they are unreliable messages. In other words, these are messages that do not contain critical information to deliver to the server. For example, to this category belongs messages that contain values read from sensors.

Even if these messages are unreliable, they have a unique ID.

Request/Response Model

The CoAP Request/Response is the second layer in the abstraction layer. The CoAP protocol sends the request using a Confirmable (CON) or Non-Confirmable (NON) message. There are several scenarios depending on if the server can answer immediately to the client request or the answer if not available:

• If the server can answer immediately to the client request then if the request is carried using a Confirmable message (CON) then the server sends back to the client an Acknowledge message containing the response or the error code:

As you can notice in the CoAP message there is a Token. The Token is different from the Message ID and it is used to match the request and the response.

• If the server can’t answer to the request coming from the client immediately, then it sends an Acknowledge message with an empty response. As soon as the response is available then the server sends a new Confirmable message to the client containing the response. At this point the client sends back an Acknowledge message:

• If the request coming from the client is carried using a NON-confirmable message then the server answer using a NON-confirmable message.

CoAp Message Format

This paragraph covers the CoAP Message format. Until now, we have discussed different kinds of messages exchanged between the client and the server. Now it is time to analyze the CoAP message format. The CoAP protocol is meat for constrained environments and for this reason, it uses compact messages. Therefore, to avoid fragmentation, a CoAP message occupies the data section of a UDP datagram. A message has these parts:

Where:

Ver: It is a 2 bit unsigned integer indicating the version

T: it is a 2 bit unsigned integer indicating the message type: 0 confirmable, 1 non-confirmable

TKL: Token Length is the token 4 bit length

Code: It is the code response (8 bit length)

Message ID: It is the message ID expressed with 16 bit

and so on.

CoAP security aspects

One important aspect when dealing with IoT protocols is the security aspects. As stated before, this protocol uses UDP to transport information. Consequently, it relies on UDP security aspects to protect the information. As HTTP uses TLS over TCP, CoAP protocol uses Datagram TLS over UDP. DTLS supports RSA, AES and so on. Anyway, we should consider that in some constrained devices some of DTLS cipher suits may not be available. It is important to notice that some cipher suites introduce some complexity and constrained devices may not have resources enough to manage it.

CoAP vs MQTT

An important aspect to cover is the main differences between CoAP protocol and MQTT. As you may know, MQTT is another protocol widely used in IoT. There are several differences between these two protocols. The first aspect is the different paradigm used. MQTT uses a publisher-subscriber while CoAP uses a request-response paradigm. MQTT uses a central broker to dispatch messages coming from the publisher to the clients. CoAP is essentially a one-to-one protocol very similar to the HTTP protocol.  Moreover, MQT is an event-oriented protocol while CoAP is more suitable for state transfer.

Wrapping up

At the end of this tutorial, you have discovered what is the CoAP protocol and it fits in the IoT. It is a widely used protocol in constrained environments. It is very similar to HTTP even if there are some subtle differences.