Due to the low overhead and connectionless approach CoAP protocol meets all the requirements of battery powered IoT devices. Learn more what are the key differences and why CoAP should be the protocol of choice when designing an NB-IoT device.
Overview
CoAP protocol is similar to HTTP but has been redesigned to meet the requirements of battery powered devices with limited CPU and RAM resources. The protocol uses UDP/IP as the transport layer. The result is a protocol that uses much smaller packets, is simpler compared to HTTP and has a smaller footprint (the smallest CoAP message is 4 bytes compared to 26 bytes of the smallest HTTP message). Moreover, CoAP has been designed to easily translate to HTTP for simplified integration with the web – the protocols interoperate through simple proxies. Just like HTTP, CoAP is based on a client / server model. Client sends a request to server and server sends back a response. Clients may GET, PUT, POST and DELETE resources.
MQTT is a publish/subscribe messaging protocol designed for lightweight M2M communications. It has a client/server model, where every device is a client and connects to a server, known as a broker. The protocol uses TCP/IP as the transport layer. MQTT is message oriented. Every message is published to an address, known as a topic. Clients may subscribe to multiple topics. Every client subscribed to a topic receives every message published to the topic.
Headers overhead
The basic header structure and length for both MQTT and CoAP messages are similar. For the CoAP protocol, the minimum option size is 4 bytes, including the messageID. The MQTT protocol also requires a minimum of header of 4 bytes:
- 2 bytes – fixed header,
- 2 bytes – packet Identifier.
MQTT is based on TCP and requires lossless packet replacement. Therefore, UDP protocol and other connectionless network transport layers such as NB-IoT are not suitable for MQTT, due to the possibility of data loss and packet reordering. CoAP is based on UDP and does not require lossless and ordered delivery and provides fragmentation at a higher level.
Comparison of MQTT and CoAP messaging models
MQTT involves complete packet overhead of TCP/IP packets:
- IPv4 headers – 20 bytes (IPv6 headers – 40 bytes)
- first two handshake messages – 24 bytes
- final ACK – 20 bytes
In contrast, CoAP packets :
- IPv4 headers – 20 bytes (IPv6 headers – 40 bytes)
- UDP headers – 8 bytes
- CoAP options – 11 bytes (CoAP header size may vary depending on the CoAP options used, and length of the uri. The size in the example is the size of the CoAP header sent by Efento sensors)
Considering that in most cases each data transmission (e.g., MQTT NOTIFY control packet) requires a TCP ACK (20 bytes), the CoAP savings will be even higher.
Comparison of headers overhead
Protocol overhead
MQTT requires connection initiation with the MQTT broker. For this purpose, the client uses two messages: PUBLISH, PUBACK. After the MQTT connection has been established, the client can publish data by sending PUBLISH messages to the server. The MQTT protocol uses three levels of QoS:
- QoS 0 – messages arrive at most once, hence can be lost when connection problems occur,
- QoS 1 – messages are assured to arrive but duplicates can occur,
- QoS 2 – messages are assured to arrive exactly once.
The most applied is QoS 1 (at least one delivery) to make the transmission reliable, the PUBACK MQTT control package confirms the data publication each time. If data sending is infrequent and requires TCP and MQTT to reestablish connections each time, then the relative overhead becomes huge for small data payload. This is not an optimal solution when the devices are kept in the power saving mode most of the time, only waking up to send a small payload and returning to the power saving mode after that.
CoAP does not require connection and session configuration at the TCP/IP level.The CoAP protocol uses two kinds of messages:
- Confirmable message
- Non-confirmable message
When exchanging messages between two endpoints, these messages can be reliable. In CoAP, a reliable message is obtained using a Confirmable message (CON). Using this kind of message, the client can be sure that the message will arrive at the server. A 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 Non-confirmable (NON) are messages that don’t require an Acknowledgement by the server.
CoAP/MQTT communication between the client and the server.
Data usage comparison
Let’s compare the difference in the data usage between CoAP and MQTT based on the payload generated by the NB-IoT Efento temperature and humidity sensor, which takes measurements every 5 minutes and sends the data to the server every hour. The data payload containing the measurements is the same for both protocols and has a size of 84 bytes. The differences in the size of the entire data frame is caused by the protocol’s overhead. Sending the same data over the CoAP protocol uses around 70% less data compared to MQTT. That allows the devices to operate longer on the batteries (they are in the active state for shorter periods of time, as they need to send less data) and consume less network bandwidth, which is important in case of large IoT deployments planned for the coming years.
Comparison of uplink data usage required to send a payload of 84 bytes between CoAP protocol (123 bytes) and MQTT (401 bytes).
Sending the same data during a month (uplink only) over the CoAP protocol uses around 70% less data compared to MQTT