IoT Communication Protocols

Hey everyone!

It’s time for another topic into the world of IoT! Today we’re gonna learn about CoAP and MQTT. Don’t worry if these sounds like alphabet soup right now, I promise it’ll all make sense soon!

So, this is actually part 4 of our IoT series (I know, right? We’re ofc super regular!). If you’ve been keeping up, you already know the basics of IoT, all about sensors and actuators, and the different ways IoT gadgets connect to the internet. If you missed those, no stress! You can always catch up with the links, it’s just a click away.

Today’s all about how these smart devices actually talk to each other. CoAP and MQTT are like the languages of the IoT world, we’ll see at how they work along with their pros and cons.

CoAP: Constrained Application Protocol

CoAP is a specialized web transfer protocol designed for Internet of Things (IoT) devices with limited resources. It’s particularly useful in smart energy and building automation systems, where devices often have constraints on processing power, memory, and battery life.

Working Of CoAP:

Components:

1. NMS (Network Management System): This is likely a central management system where administrators can monitor and control the IoT network. It’s represented by the office setup on the left side of the image.
2. HTTP-CoAP Proxy: This component bridges HTTP and CoAP protocols. It allows traditional HTTP clients (like web browsers or HTTP-based applications) to communicate with CoAP-enabled devices.
3. CoAP Devices: These are the IoT devices (represented by small icons on the right) that use CoAP for communication. They are typically resource-constrained devices like sensors or actuators.
4. Backhaul Network: This is the network infrastructure (represented by clouds) that connects the NMS to the IoT devices.

Working:

1. HTTP to CoAP Translation:

• When the NMS needs to communicate with CoAP devices, it can send HTTP requests.
• The HTTP-CoAP proxy translates these HTTP requests into CoAP messages.
• This allows seamless integration of CoAP devices into existing HTTP-based systems.

2. Direct CoAP Communication:

• The diagram also shows direct CoAP communication from the NMS to devices.
• This indicates that the NMS can natively speak CoAP, allowing more efficient communication with IoT devices.

3. Device-to-Device Communication:

• CoAP devices can communicate directly with each other using the CoAP protocol.
• This is shown by the connections between the small device icons on the right.

4. Scalability and Efficiency:

• CoAP’s lightweight nature allows for efficient communication over constrained networks.
• The protocol supports both one-to-one and one-to-many (multicast) communication patterns.

5. RESTful Interaction:

• Although not explicitly shown, CoAP follows a RESTful model similar to HTTP.
• Devices can expose resources that can be interacted with using methods like GET, POST, PUT, and DELETE.

6. Asynchronous Communication:

• CoAP supports asynchronous message exchange, which is crucial for IoT scenarios where devices might be in sleep mode to conserve energy.

7. Discovery:

• CoAP includes mechanisms for device and service discovery, allowing for dynamic network configuration.

Message Format

CoAP messages are encoded in binary-format or 0/1 format. Like other message formats, CoAP message has a header and a payload section along with an optional section. The size of CoAP header is 4 bytes or 32 bits. This size is fixed for every CoAP message. Whereas the other part of message is the optional part which includes payload and tokens of variable size ranging from 0–8 bytes. The message format of CoAP contains the following fields:

• Version — The size of version field is 2 bits. It represents the version of the CoAP protocol.
• Type Code — The size of type field is 2 bits. There are four types of messages namely confirmable, non-confirmable, acknowledgement and reset represented by the bit patterns 00, 01, 10, 11 respectively.
• Option Count — The size of option count field is 4 bits. These 4 bits, means there could be a total of 16 possible options in header.
• Code — The size of code field is 8 bits. This indicates whether message is empty, request message or response message.
• Message ID — The size of message ID field is 16 bits. It is used to detect the message duplication and types of messages.
• Tokens [Optional] — The size of tokens field is variable which ranges from 0–8 bytes. It’s used to match a response with request.
• Options [Optional] — The options field in CoAP message has a variable size. It defines the type of payload message.
• Payload [Optional] — Similar to options field, the payload field has a variable size. The payload of requests or of responses is typically a representation of the requested resource or the result of the requested action.

Message Types:

• Confirmable (CON): Requires acknowledgment
• Non-confirmable (NON): Doesn’t require acknowledgment
• Acknowledgement (ACK): Confirms receipt of a CON message
• Reset (RST): Indicates a received message was not processed

Applications of CoAP

• Real Time Monitoring in Grid — Smart cities can monitor the distribution and generation of power remotely. The CoAP sensors could be embedded inside the transformers and the data could be transferred over GPRS or 6LowPAN.
• Defense utilities — The armory and tanks are now-a-days fitted with sensors so that information could be communicated remotely without any interference. The CoAP sensors could detect any intrusion. This makes them capable to transfer more data even under low bandwidth network.
• Aircraft utilities — The Aircraft sensors and actuators could be connected with other sensors and communication can take place using smart CoAP based sensors and actuators.

Advantages of CoAP

1. Efficiency: CoAP is designed to be efficient in terms of bandwidth and power consumption, making it ideal for constrained environments.
2. Interoperability: Follows a RESTful model similar to HTTP, which makes it easy to integrate with existing web technologies and services.
3. Flexibility: Supports asynchronous communication and can handle both unicast and multicast traffic, providing flexibility in communication patterns.
4. Scalability: Built-in discovery and resource observation mechanisms support the dynamic and scalable nature of IoT networks.
5. Security: CoAP can be secured using DTLS (Datagram Transport Layer Security), providing confidentiality, integrity, and authentication for communication between devices.

Disadvantages of CoAP

1. UDP-Based: Relies on UDP, which does not provide guaranteed delivery, ordering, or congestion control, unlike TCP. This can be mitigated through CoAP’s confirmable message feature, but it may not be suitable for all applications.
2. Limited Bandwidth: While CoAP is efficient, the use of a small header size and UDP may limit the amount of data that can be effectively transmitted in a single message.
3. Resource Constraints: Although designed for constrained devices, implementing DTLS for security can still be resource-intensive, potentially impacting device performance.

IoT Application Layer Protocols- MQTT

MQTT (Message Queue Telemetry Transport) is a lightweight messaging protocol specifically designed for devices with limited resources, making it ideal for IoT (Internet of Things) applications. It operates on a publish-subscribe model over TCP, utilizing minimal bandwidth and low power, which allows efficient communication between devices in high-latency environments.

Publish-Subscribe Model

In MQTT, communication happens between multiple clients without requiring direct connections between them. Instead, all communication goes through an intermediary known as a broker. The broker acts as a central hub that manages message delivery, ensuring that messages are sent to the appropriate clients who have subscribed to specific topics.

MQTT Clients and Broker

• Clients: Clients can either publish or subscribe to messages based on specific topics. A client can also perform both functions.
• Broker: The broker plays the critical role of receiving published messages, filtering them by topic, and distributing them to the relevant subscribers. It can handle thousands of concurrent client connections, depending on its implementation. Additionally, the broker stores persistent session data, including any missed messages, ensuring no loss of communication for clients with intermittent connectivity.

Working Mechanism

• Publishing: When a client (device) wants to send data, it publishes the message to the broker. This message is associated with a specific topic.
• Subscribing: Clients can subscribe to the topics they are interested in, meaning they will receive any messages published to those topics by other clients.

A major advantage of this model is the decoupling of the publisher and subscriber roles. Clients do not need to directly interact with each other; instead, they rely entirely on the broker to handle the communication. This allows:

• Efficient bandwidth usage since clients only receive messages they have explicitly subscribed to.
• Flexibility in connectivity, meaning publishers and subscribers do not need to be online simultaneously for message exchange.

Broker’s Role in Communication

If a subscriber is temporarily disconnected, the broker can store the messages in a buffer and deliver them once the subscriber reconnects. Similarly, if a publishing client disconnects unexpectedly, the broker can disconnect the subscribers and still send cached messages, ensuring continuity.

Message Format

1. Fixed Header (Present in all MQTT control packets)

• Message Type: Identifies the type of control packet (e.g., PUBLISH, SUBSCRIBE, DISCONNECT).
• DUP Flag (Duplication Flag): Used to indicate whether a message has been resent. If this flag is set, it means the message was previously sent, but no acknowledgment (ACK) was received. This helps prevent message loss.
• QoS (Quality of Service): Defines the level of assurance for message delivery. MQTT supports three levels of QoS:

MQTT offers three levels of Quality of Service (QoS) to ensure reliable message delivery based on the requirements:

QoS 0: Best-Effort Delivery (At Most Once)

• Description: The simplest form of delivery, where messages are sent without any guarantee of arrival.
• How It Works: The publisher sends the message to the server, which forwards it to subscribers. However, no acknowledgment is required from the receiver.
• Result: The message might be received once or not at all. There is no retry mechanism if the message is lost.

QoS 1: Guaranteed Delivery (At Least Once)

• Description: Ensures that the message is delivered at least once, but it may be received more than once.
• How It Works: The publisher sends the message, and the receiver must send an acknowledgment (PUBACK). If no acknowledgment is received, the message is resent.
• Result: The message will be delivered at least once, but there is a chance of duplication due to retries.

QoS 2: Exactly Once Delivery (Highest Reliability)

• Description: Guarantees that the message is delivered exactly once, without duplication or loss.
• How It Works: The most reliable level of service, it uses a two-step process:

1. The receiver acknowledges the message with a PUBREC packet.
2. The sender responds with a PUBREL packet, and the receiver confirms with a PUBCOMP packet.

• Result: This ensures that the message is received only once, regardless of how many retries are necessary.
• Retain Flag: This is found only in PUBLISH messages. When set, it instructs the broker to retain the message and deliver it to new subscribers as soon as they subscribe. This ensures that subscribers receive the latest message immediately without waiting for the publisher to send a new one.

2. Remaining Length

This part of the header defines the remaining size of the message after the fixed header. It includes the variable header and payload, giving the MQTT broker an idea of how much more data to expect.

3. Variable Header (Optional)

The variable header is present in some MQTT control packets but is not mandatory in all. It contains additional information, such as:

• Client ID: Every client connecting to a server has a unique client ID, which helps in identifying and managing sessions.
• Message Identifier: In certain messages, especially those using QoS levels 1 or 2, this identifier is used to track messages for acknowledgment purposes.

The variable header allows for flexible handling of different control packet types (like SUBSCRIBE, UNSUBSCRIBE, and PUBLISH) and manages parameters like topics, message identifiers, and return codes.

MQTT sessions between a client and server follow four steps: establishing the session, authenticating the client, exchanging data, and ending the session. When the server sends a message to multiple clients, it handles each client separately.

4. Payload (Optional)

The payload is the data being transmitted, and it may or may not be present depending on the type of control packet. For example:

• PUBLISH packets contain the message being sent by the publisher.
• SUBSCRIBE packets contain topic filters for subscriptions. The maximum size for the payload is up to 256 MB, making MQTT suitable for transmitting large amounts of data when needed, though it is typically optimized for small messages.

Control Packet Examples

Key Features

• Ideal for machine-to-machine (M2M) communication in low-bandwidth, high-latency environments.
• Uses TCP with a publish-subscribe model for efficient communication.
• Suitable for low-power, resource-constrained devices.
• Clients can subscribe to all or specific data using a wildcard.
• The broker decouples publishers and subscribers, managing message delivery.
• Publishers and subscribers don’t need to be aware of each other.
• Messages can be buffered by the broker during network failures.
• Publishers and subscribers don’t need to be online at the same time.
• Operates on TCP using port 1883.

Advantages of MQTT Protocol:

1. Low Bandwidth and Power Efficiency: MQTT is ideal for resource-constrained devices due to its lightweight nature and minimal data overhead.
2. Scalability: MQTT supports thousands of clients communicating through a single broker, making it highly scalable for IoT networks.
3. Reliable Communication with QoS: The three levels of Quality of Service (QoS) allow users to choose the level of message reliability, from “at most once” to “exactly once.”
4. Asynchronous Communication: The publish-subscribe model enables communication between devices without needing them to be online simultaneously, improving flexibility in IoT environments.
5. Support for Last Will and Testament (LWT): This feature allows devices to notify other clients of unexpected disconnections, ensuring real-time status updates in case of failures.

Disadvantages of MQTT Protocol:

1. TCP Dependency: MQTT runs on top of TCP, which can lead to higher latency and overhead in certain network conditions compared to protocols like UDP.
2. Limited Security Features: By default, MQTT does not provide built-in encryption or authentication. Securing communications often requires additional protocols such as TLS, adding complexity.
3. Single Point of Failure (Broker): The broker acts as the central hub. If the broker fails or is attacked, the entire system may be disrupted unless redundancy is built in.
4. Overhead for QoS 2: While QoS 2 guarantees message delivery exactly once, it introduces significant overhead due to the multiple-step acknowledgment process.
5. Less Suitable for Real-Time Applications: Due to its reliance on TCP and the overhead of the publish-subscribe model, MQTT may not be the best choice for real-time applications requiring low-latency responses.

So, here this topic ends. Do share some more info you have related to this. See you next Thursday with something more interesting for sure. Ta-Ta!