top of page

CoAP or MQTT is best over NB-IoT?

CoAP protocol is similar to HTTP but has been redesigned to meet the requirements of battery powered devices with limited CPU/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.


Header 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.


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 – 10 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 a typical 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.


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.



If you compare the difference in the data usage between CoAP and MQTT based on the payload generated by the a typical NB-IoT sensors, which takes measurements every 10 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.


Source of Informations: Misc

48 views0 comments

Recent Posts

See All

IoT Cloud Bridge

Fully Customisable NB-IoT & LoRaWAN Sensor Gateway

Tested IoT Solutions for various Application and Challenges

Advanced Metering Infrastructure Data Concentrator 

Remote Liquid Level Monitoring based NB-IoT & LoRaWAN

Remote Weather Monitoring based NB-IoT & LoRaWAN

Remote Flow and Flood Monitoring based NB-IoT & LoRaWAN

Remote Waste Bin Monitoring based NB-IoT & LoRaWAN

Remote Distance Monitoring based NB-IoT & LoRaWAN

Remote Air Quality Monitoring based NB-IoT & LoRaWAN

Remote Greenhouse Gas Monitoring based NB-IoT & LoRaWAN

  • LinkedIn

Truesync IoT Systems and its Logos are registered trademark of Truesync IoT Systems Global Ltd. England, UK.

Incorporated in England and Wales with Company No. 13010651

2021 Truesync.io. All rights reserved

bottom of page