This article provides a general introduction to the Constrained Application Protocol (CoAP) for those interested in a lightweight, easy-to-implement data transfer solution for devices with limited hardware resources, also known as ‘constrained devices’. CoAP is a UDP-based protocol defined by the RFC 7252 specification. CoAP is very similar to HTTP, has a similar client-server model, is based on request-response messages and is based on the REST model.
The REST (Representational State Transfer) model, in a nutshell, is an architectural style that defines a certain pattern of information exchange between two devices, one acting as a server and the other as a client. The role of the server is to provide clients with access to different types of resources. Each client may need to access different types of resources, so in order to group and separate them, each is assigned a textual identifier called a URI (Uniform Resource Identifier).
Different types of operations can be performed on resources, e.g. read, add, create, delete, modify. The methods used are GET, POST, PUT, DELETE.
Message format
The CoAP message format, also known as PDU (Protocol Data Unit), has 4 main components: the header, the token, the options and the payload. The payload marker is an additional 1 byte value 0xFF that is only present if there is a payload in the message.
- Header has a fixed size of 4 byte for UDP ( 6 for TCP). It contains the following fields:
- version (2 bits), which specifies the CoAP version. Currently for the CoAP version 1 it will be 0x01 value
- type (2 bits) indicates the message type, which can be:
- 0 for Confirmable (CON)
- 1 for Non-confirmable (NON)
- 2 Acknowledgment (ACK)
- 3 Reset (RST)
- Code (8 bits) specifies the request method (e.g. GET, PUT, POST) or response status code
- Token Length – length in bytes of the „token” part send after header
- Message ID (16 bit) unique message identifier
- Token is an optional field used to correlate request and responses
- Options contains additional metadata about the request or response like URI path, URI query, content format. More about it you can read in RFC 7252 Section 5.4
- Payload which is the main data, preceded by a payload marker (0xFF) if present
Message types
There are 4 types of messages in CoAP to support reliability and message acknowledgement.
- Non-confirmable
Used for messages that don’t require any acknowledgement. The sender doesn’t expect a response, and there is no retransmission if the message is lost. Used for non-critical messages, where occasional message loss is acceptable, such as periodic sensor readings or status updates - Confirmable
Used for important messages where confirmation of delivery is essential, such as sending commands or updating device status. When a client sends a confirmable message, it expects an acknowledgement message from the recipient as a response to its original message. The message ID in this ACK message must match the “message ID” from the original client request message so the client can correlate them. If the sender doesn’t receive an ACK message with the expected ID within a specified time, it will retransmit the message until it either receives an ACK or reaches a maximum retransmission limit - Acknowledgement
Used to acknowledge receipt of a Confirmable (CON) message. When a server receives and processes a CON message, it sends an ACK with the same message ID to confirm that it received the message. An ACK is not a stand-alone message; it always corresponds to a previous CON message. It indicates receipt and optionally contains a response if the CON was a request. - Reset
Used to indicate that a message has been received but cannot be processed. An RST message is sent when a node receives a message with an unknown or invalid token or message ID, or when it cannot process the message for some reason. Often used when the recipient does not recognize the message ID or token, perhaps due to loss of state information or an error.
Message types short summary:
| Message Type | Abbreviaton | Reliability | Ack required | Summary |
|---|---|---|---|---|
| Confirmable | CON | YES | YES | Critical requests needing confirmation |
| Non-confirmable | NON | NO | NO | Non-critical data such as telemetry |
| Acknowledgment | ACK | —- | —- | Confirms receipt of a CON message |
| Reset | RST | —- | —- | Indicates inability to process a message |
Message identifier
The message id is a 16 bit field with 65,536 possible values, which is sufficient to generate a unique value over a short period of time. The first message id should be randomized for each client to reduce the change of collisions in concurrent message exchanges. The next one can simply be incremented by one. The purpose of unique message identifiers in CoAP is to provide reliability, duplicate detection and to match requests with responses.
- Reliability in Confirmable Messages: When a client sends a confirmable message it expects an acknowledgement message form the server in return. The message ID in this ACK message should match the “message ID” from the client’s original request message so that the client can correlate them. If the client doesn’t receive the ACK message with the correct “Message ID” within a certain amount of time, it can retransmit the CON message to ensure the reliability of message delivery
- Duplicate Detection: CoAP uses the message ID to detect duplicate messages, which can occur due to network problems or retransmissions. If a server receives a message with the same Message ID as a message it recently processed, it knows the message is a duplicate and can ignore it or respond with an ACK without processing it again.This prevents duplicate processing of the same message, which is essential for constrained devices where processing power and memory are limited.
- Requests and Responses matching: As mentioned above, each request has a unique message ID, and each response (ACK or Non-Confirmable) contains the same message.
Message codes
They are used to determine what type of responses or requests are sent, for example, whether they indicate a successfully processed request or an error. They have a similar role to status codes in HTTP, e.g. 200 to indicate a correctly processed request or 500 to indicate an internal server error. The main difference is that these codes are slightly more optimized.
This code is transmitted on a single byte that is divided into two parts:
- The category of the message, e.g. request or response, is indicated by the class on the 3 older bits.
| 0.xx | Request codes (Methods) |
| 2.xx | Success responses |
| 4.xx | Client error responses |
| 5.xx | Server error responses |
- Details The next 5 lower bits specify exactly what the request or response is about
CoAP vs MQTT
These two widely used communication protocols in IoT seem to have similar application, but there is a significant difference in architecture that determines in which cases one is more suitable than the other.
CoAP uses a request/response method, while MQTT has a publish/subscribe method, but they are not the same. CoAP has a one-to-one direct architecture between client and server without a middleman like MQTT which uses a central broker to send messages between different devices (clients and servers). In CoAP, clients cannot communicate directly with other clients. They can „watch” endpoint sources with data from other devices. Similarly, in MQTT, a client can send data to another client, but it must be routed through a „broker”. CoAP uses UDP as the transport protocol, which is not as reliable as the TCP-based connection that MQTT uses. However, this results in high power consumption because the connection between the client and the broker must be maintained. MQTT supports multiple nodes connected at the same time. Unlike the TCP-based protocol, CoAP has a connectionless architecture, so devices can communicate between two endpoints without prior agreement. In summary, MQTT is ideal for event-based systems where you have multiple nodes interacting based on their sensor values, for example. CoAP is better suited for systems that monitor state changes, where you can pass state information between client and server.
CoAP Request Codes (Method Codes)
| Code (Class.Detail) | Method |
|---|---|
| 0.01 | GET |
| 0.02 | POST |
| 0.03 | PUT |
| 0.04 | DELETE |
CoAP Response Codes
Success Responses
| Code (Class.Detail) | Meaning |
|---|---|
| 2.01 | Created |
| 2.02 | Deleted |
| 2.03 | Valid |
| 2.04 | Changed |
| 2.05 | Content |
Client Error Responses
| Code (Class.Detail) | Meaning |
|---|---|
| 4.00 | Bad Request |
| 4.01 | Unauthorized |
| 4.03 | Forbidden |
| 4.04 | Not Found |
| 4.05 | Method Not Allowed |
Server Error Responses
| Code (Class.Detail) | Meaning |
|---|---|
| 5.00 | Internal Server Error |
| 5.01 | Not implemented |
| 5.02 | Bad Gateway |
| 5.03 | Service Unavailable |
| 5.04 | Gateway Timeout |
| 5.05 | Proxying Not Supported |
As you can see, most of these error codes are very similar to those used in HTTP. However, the format is slightly different.
In summary, the COAP protocol is a lightweight application layer protocol designed for use in constrained environments such as IoT devices. It enables efficient communication over low-power networks by following a request-response model similar to HTTP, but optimized for resource-constrained devices. It is designed for devices with limited processing power and memory. Supports operations such as GET, POST, PUT, and DELETE. Uses UDP instead of TCP to reduce communication overhead. Supports multicast, caching, and asynchronous communication. Typical applications include: smart home systems, industrial IoT applications, remote monitoring and control of sensors and actuators.