Proven by Intelligence

IoT Protocols: CoAP and MQTT

CoAP and MQTT are currently the most widely used communication protocols in the Internet of Things (IoT) environment for low-resource devices. As both protocols cover similar service areas, they are often subject to comparison.

CoAP and MQTT share the following common characteristics:

• Open standard
• More suitable for constrained environments than HTTP
• Provide asynchronous transmission mechanisms
• Operate over IP
• Possess implementation scope
• Aim for open-standard messaging protocols

Now, let's explore each protocol individually.

CoAP

(Constrained Application Protocol)

CoAP, or Constrained Application Protocol, is a lightweight REST protocol based on UDP, standardized by the IETF (RFC7252). As its name suggests, CoAP is designed for "constrained nodes and constrained networks."

CoAP operates on a client-server (or request-response) model, making it a One-To-One protocol well-suited for transferring state information between a client and a server. Since it is designed over UDP, the client and server provide a connectionless datagram service. Asynchronous transmission occurs over UDP, and reliability issues arising from not using TCP are addressed by CoAP's internal retransmission and timer management options. CoAP is designed following HTTP REST principles, which makes interoperability with HTTP easy via a simple proxy.

CoAP - Content Negotiation

Designed with HTTP principles in mind, CoAP also supports Content Negotiation. The client uses the Accept option to convey its preferred resource type, and the server informs the client of the data type to be sent via the Content-Type. Similar to HTTP, clients and servers operate independently, allowing for the addition of new types without affecting each other.

CoAP - QoS (Quality of Service)

CoAP allows request and response messages to be sent as "Confirmable" or "Nonconfirmable." For Confirmable messages, the receiver must send an ACK message back to the sender. Nonconfirmable messages do not require an ACK.

CoAP - Observe

CoAP provides a feature to "Observe" resources. If the Observe flag is set in a CoAP GET request, the server can continuously receive data for that resource from the client even after the initial data transfer. This enables the server to continuously monitor the state of specific resources on the client. The Observe flag can be activated or deactivated via settings.

CoAP - Resource Discovery

CoAP supports a standard mechanism for resource discovery. When a CoAP client sends a request to /.well-known/core, the server provides the client with a list of resources including metadata in response. This message format is termed "Link Format," and its Media Type is 'application/link-format.'

CoAP - Security

Since CoAP operates over UDP, it cannot provide security using SSL/TLS. Instead, CoAP offers security through DTLS (Datagram Transport Layer Security). DTLS provides the same level of security as TLS but ensures data transmission over UDP. Both TLS/DTLS use asymmetric key encryption for the handshake process to generate and exchange keys, which are then used for symmetric key encryption to exchange data. CoAP devices implementing DTLS typically support RSA or ECC cryptographic algorithms for key generation and exchange. For data transfer, AES is supported as the encryption algorithm using these generated keys.

MQTT

(Message Queuing Telemetry Transport)

MQTT (Message Queuing Telemetry Transport) is an ISO standard Publish/Subscribe messaging protocol (ISO/IEC PRF 20922) suitable for connecting numerous clients and for remote telemetry.

MQTT is a protocol suitable for One-to-Many and Many-to-Many communication mediated by a broker. Clients can publish messages to the broker or subscribe to the broker to receive messages.

Messages are distinguished by topics, and the broker sends messages to clients subscribed to those topics. Clients can subscribe to multiple topics simultaneously. The MQTT broker acts as an intermediary server, collecting messages from various devices and sending them to the necessary devices.

To help understand, consider a simple MQTT network:

Resource: MQTT and CoAP, IoT Protocols

In such a network, if three clients A, B, and C are all connected to a broker via TCP, and clients B and C subscribe to the topic 'temperature', then when client A publishes a value to the 'temperature' topic, the broker delivers that value to B and C. MQTT is ideal for this type of One-to-Many, Many-to-Many communication model.

MQTT - Topic Matching

Topics in MQTT are hierarchically structured using '/' (e.g., kitchen/oven/temperature). Clients can subscribe to multiple topics at once using wildcards '+' and '#'. '+' matches a single directory, while '#' matches multiple directories.

• kitchen/+/temperature=kitchen/foo/temperature
• kitchen/+/temperature ≠kitchen/foo/bar/temperature
• kitchen/# =kitchen/fridge/compressor/valve1/temperature

MQTT - QoS (Quality of Service)

MQTT provides three QoS options for reliable messaging:

• Fire and forget (Level 0): Messages are delivered at most once. Loss is possible as there is no confirmation of transmission.
• Delivered at least once (Level 1): Messages are delivered at least once. Transmission is confirmed, but duplicate delivery is possible.
• Delivered exactly once (Level 2): Guarantees exactly one delivery. However, it may lead to increased end-to-end transmission latency.

As the level increases, quality improves, but performance degradation, such as processing speed, may occur. Therefore, selection needs to be based on the specific characteristics of the service.

MQTT - LWT (Last Will and Testament)

Every MQTT client can send a designated message to a specific topic if its connection to the broker is lost. This is called LWT (Last Will and Testament). When a message is registered, the broker automatically sends the designated message to the specified topic if that client disconnects.

MQTT - Security

MQTT provides user authentication through Username/Password for connecting to the broker. However, these values are transmitted as unencrypted plaintext. For more robust security, an encrypted channel using SSL/TLS can be applied.

CoAP vs. MQTT Comparison

Resource: MQTT and CoAP, IoT Protocols

CoAP and MQTT are both suitable protocols for IoT environments, but they have fundamental differences in their communication models.

MQTT is a Publish-Subscribe, Many-to-Many communication protocol designed for transferring messages between multiple clients via a central broker. Clients publish messages, and the broker decides where to route and copy them, thereby decoupling producers from consumers. MQTT is best suited for communication buses handling live data.

CoAP is primarily a Request-Response, One-To-One communication protocol suitable for models that transfer state information between a client and a server. It is best suited for services that continuously monitor the state of resources per device. Additionally, CoAP offers a service discovery feature based on REST, which has the advantage of minimizing additional work when connecting new clients.

As CoAP and MQTT have distinct characteristics, the benefits gained from adopting and operating services with them also differ. When developing IoT services, it's necessary to consider these characteristics and choose the appropriate protocol for the market environment.

Rapid-IoT/NeoIDM, as an IoT platform, supports both CoAP and MQTT. Users operate services using IoT technologies from NeoIDM, which handles the protocols and various sensors/devices, allowing them to select the protocol based on device and service characteristics.

▶ Resources:

 MQTT and CoAP, IoT Protocols, https://www.eclipse.org/community/eclipse_newsletter/2014/february/article2.php

COAP vs MQTT, https://iotbyhvm.ooo/coap-vs-mqtt/)