IoT Communication Protocols

• IoT is expanding, increasing the number of connected devices and the need for effective communication protocols.
• Messaging protocols in IoT architectures manage communication at the application layer.

Common IoT Communication Protocols

• Message Queuing Telemetry Transport (MQTT): Lightweight publish-subscribe messaging ideal for constrained devices.
• Representational State Transfer (RESTful): Stateless, widely-used protocol relying on HTTP, suitable for diverse applications.
• Constrained Application Protocol (CoAP): Specifically designed for resource-limited IoT devices, uses UDP which facilitates low overhead.
• These protocols must function across varied electronic devices with differing hardware specifications, presenting interoperability challenges.

MQTT

• It is a lightweight messaging protocol, based on TCP, suitable for resource-constrained IoT devices using unreliable or low-bandwidth networks.
• Devices communicate indirectly via a central message broker using a publish/subscribe model.
• The central message broker handles subscriptions and topic management.

MQTT Messages

• Composed of a fixed header (minimum 2 bytes), a variable header (optional, up to 12 bytes), and an optional payload.
• The variable header contains details like quality of service (QoS) level, connection flags (username/password access), keep-alive timing and the topic names.
• The actual data is contained within the optional payload (not present in all message types).

MQTT Special Features

• Retained Messages: The broker saves the latest message per topic to resend upon client subscription or reconnection.
• Last WILL and Testament: Clients store messages to inform subscribers automatically if unexpected disconnections occur.
• Persistent Sessions: The broker stores subscription information and undelivered messages, automatically resuming upon client reconnection.

MQTT Quality of Service Levels

• There are three QoS levels to ensure reliable message delivery

QoS Level 0

• Delivery Approach: "At most once" (fire and forget).
• Acknowledgment: No acknowledgment is awaited.
• Message Handling: No retransmission; sender does not know if the message was received.
• Lightweight: Most lightweight QoS level.

QoS Level 1

• Delivery Approach: "At least once".
• Acknowledgment: Sender waits for an acknowledgment from the receiver.
• Message Handling: Each message has a unique packet identifier in the variable header.
• Acknowledgment Message: Receivers send a PUBACK message with the packet identifier.

QoS Level 2

• Delivery Approach: "Exactly once" (safest but slowest).
• Handshake: Requires a four-part handshake (request/response flows).

QoS Level 2 Process

• Step 1: Sender sends a PUBLISH packet with a unique packet identifier.
• Step 2: Receiver acknowledges with a PUBREC packet.
• Step 3: Sender replies with a PUBREL packet to release the message.
• Step 4: Receiver forwards the message to subscribers and responds with a PUBCOMP packet to confirm completion.
• Retransmission occurs if the sender does not receive a PUBREC within a specified time

MQTT-SN

• It is an extension of MQTT designed for low-cost, low-power devices, and constrained networks like Wireless Sensor Networks (WSNs).
• Optimized for embedded devices on non-TCP/IP networks (e.g., ZigBee).

MQTT-SN Components

• MQTT-SN Client: Publishes data and connects to an MQTT-SN Gateway.
• MQTT-SN Gateway: Connects WSN nodes with MQTT brokers and translates between MQTT-SN and MQTT.

Gateway Types

• Transparent Gateway: Serves one MQTT-SN client and maintains a direct connection to the MQTT broker.
• Transparent Gateways can lead to scalability problems as each client needs a dedicated gateway.
• Aggregating Gateway: Manages multiple MQTT-SN clients and maintains a single connection to the MQTT broker.
• Aggregating Gateways reduce message overhead by preprocessing messages.

Gateway Integration Types

• Integrated Gateway: Embedded within an MQTT broker.
• Stand-Alone Gateway: Operates independently from the MQTT broker.

MQTT-SN Offers

• Point-to-Point Data Transfer: Unicast service for messages between two endpoints.
• Broadcast Service: Ensures messages from a node can be received by all nodes within its transmission range.
• Multiple Gateway Connection: Clients can connect to multiple gateways simultaneously.

RESTful Web Service

• These use the REST architecture, based on a request-response model using the HTTP protocol and HTTP methods: GET, PUT, POST, DELETE.
• Servers expose resources (e.g., text, images, sensors) identified uniquely by a URI.

RESTful Web Service Communication Involves Three Steps

• Connection establishment (TCP three-way handshake: SYN, ACK exchanges).
• Request/Response exchange (server replies with data and status code).
• Connection closing (again via TCP three-way handshake).

RESTful Web Service Challenges

• HTTP has no message-size limit, causing large overhead.
• Every request includes all control information due to the statelessness of RESTful, increasing message size and latency.
• TCP connection setup/teardown generates overhead, problematic for real-time and small data transmissions.
• QoS support relies solely on TCP reliability, with no additional built-in QoS mechanisms.
• RESTful (HTTP/TCP) is inefficient for constrained IoT networks, thus, alternative REST-based protocols (e.g., CoAP) have been developed.

Constrained Application Protocol (CoAP)

• Designed for constrained environments with special requirements.
• Uses binary encoding for headers, methods, and status codes to reduce overhead.
• Runs over UDP instead of TCP, which reduces overhead but affects reliability.

CoAP Protocol Layers

• Request/Response Layer implements the RESTful paradigm and supports HTTP-like methods: GET, PUT, POST, DELETE.
• Provides basic RESTful services and can interact with HTTP through proxies/gateways.
• CoAP messages use UDP for asynchronous exchanges and have low header overhead.
• Example URI format: coap://example.com:5683/sensors/temp.json
• Message Layer handles retransmission of lost packets and defines four message types: CON, NON, ACK, RST.
• CON (Confirmable): Requires acknowledgment (ACK) for reliable communication.
• NON (Non-Confirmable): Sent without acknowledgment, used for periodic data.
• ACK (Acknowledgment): Confirms receipt of a CON message.
• RST (Reset): Used to reset communication if needed.

CoAP Additional Features

• Observe Option enhances the request/response model and allows clients to receive notifications of resource state changes without polling.
• The Observe Option adds the client to the list of observers for a specific resource.

CoAP Interoperability

• Fully interoperable with REST through proxies/gateways.
• Supports both request/response and publish/subscribe patterns.