Choosing a protocol¶
This page outlines the main differences between CoAP and MQTT, so you can choose which is best for your use case.
See Using nRF Cloud with the nRF Connect SDK for more information.
Key differences¶
The following table summarizes the differences in supported features and functionalities between CoAP and MQTT.
| Characteristics | CoAP | MQTT |
|---|---|---|
| Protocol | UDP | TCP |
| Secure protocol | DTLS 1.2 | TLS 1.2 |
| Certificate chain size | ~400 bytes | ~4 kB |
| Authentication type | Token-based | Based on client certificate |
| DTLS 1.2 CID | Supported | Not supported |
| MQTT Bridge | Not supported | Supported |
| IPv6 support | Supported | Partial |
- UDP: Enables traversing mesh networks and through access points with buffering, as there is no end-to-end connection, but a block of data traveling between points. A message retransmission mechanism provides reliability.
- TCP: Provides reliability as each message is acknowledged and delivery is confirmed.
- Certificate chain size: Optimized in CoAP for constrained devices and networks. Smaller certificates save memory on the device and reduce data transfer during the handshake.
- Authentication type: Instead of using a client certificate, a CoAP connection is authenticated using an identity JWT or REST API JWT. HTTP and MQTT require a larger server certificate containing device identification information.
- DTLS 1.2 CID: The connection ID (CID) extension in DTLS 1.2 enables connection serialization. Resuming an inactive connection does not require a handshake unless the CID is cleared from nRF Cloud. In MQTT, a handshake is required to resume the connection after an interruption.
- MQTT Bridge: Enables subscription to topics so the device can send events directly to your application service. Using CoAP, you must request events using the location history, message history, or device shadow.
CoAP¶
CoAP is suitable in cases with the following requirements:
- Your devices are running on a constrained network where TCP end-to-end connection is not supported.
- You want to reduce network costs by reducing data transfer and network load.
- You want to reduce cellular network costs when using a limited data plan.
- Your devices go into sleep mode to save battery and do not maintain a frequent connection with the cloud.
- You need only unidirectional device-to-cloud (D2C) communication, or cloud-to-device (C2D) messages can be delivered asynchronously.
Example use case¶
Your device contains sensors and periodically collects and sends sensor data to the server, for example, to monitor temperature, humidity, coarse location of livestock, or air quality.
The device is in a low-power or sleep mode when not actively collecting or sending data. Once the device is in place in the field, it does not need to do anything except report data, or any operations related to device control and configuration are not time-sensitive.
The data that the device reports is not critically time-sensitive either, and the connection might be intermittent. If the device is in a remote location, maximizing battery life and reducing the need to visit the device in person are a priority. This type of device is suited to CoAP.
MQTT¶
MQTT is suitable in cases with the following requirements:
- You anticipate more network traffic and messages between your devices and the cloud.
- Your devices are usually connected to the cloud and do not go into sleep mode.
- You want or need lower response latency.
- There is frequent bidirectional communication (D2C and C2D).
The requirements for MQTT apply to REST as well. nRF Cloud uses REST for cloud-to-cloud operations.
Example use case¶
Your device must not only report data to the server, but needs to receive messages or commands from the server. This could be, for example, a remote controller for another electronic device, an electronic lock, or a location tracker that frequently sends data to the server while it is on.
The device is plugged in or its battery can easily be recharged or changed. Reporting data or executing commands might be time-sensitive, and the device can maintain a reliable network connection. You do not need to prioritize low network traffic or power usage. The reliability of TCP and lower response latency make MQTT a better choice.