IoT Communication Protocols
Communication protocols can be considered a language, allowing two or more devices to communicate with each other. Just like there are rules for any system, communication protocols also follow a set of rules to pass meaningful information between devices. Communication protocols are crucial in distributed systems, where different parts of the same protocol operate independently at multiple locations. As systems run processes, they may vary, so a set of common instructions is necessary for communication within the system.
The rise of IoT owes much to Cyber-Physical Systems (CPS). The concept of physical devices connecting to the internet and transmitting and receiving data is fundamental to the realization of IoT solutions. At the same time, this increases the complexity of existing communication protocols and the internet.
The development of IoT has brought many possibilities, but the only feasible way is for machine-to-machine (M2M) communication to achieve real-time effective connections over the internet. A device connected to the internet is merely seen as a product of human interaction, not a natural outcome. Therefore, communication between protocols and the internet always evolves on an unreliable and slow basis.
MQTT Protocol
MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol originally developed by IBM, designed for communication between numerous remote sensors and control devices with limited computing capacity, operating in low bandwidth and unreliable networks.
The advantage of MQTT is that it supports all platforms, virtually connecting all IoT devices to the internet.
It has the following key features:
1. Uses a publish/subscribe message pattern, providing one-to-many message publishing and decoupling between applications;
2. Message transmission does not require knowledge of the payload content;
3. Uses TCP/IP for network connectivity;
4. There are three levels of message publishing Quality of Service (QoS):
QoS 0: “At most once,” message delivery relies entirely on the underlying TCP/IP network. Distributed messages may be lost or duplicated. For example, this level can be used for environmental sensor data where a single data loss is acceptable because a second transmission will occur shortly after.
QoS 1: “At least once,” ensures the message can be delivered, but duplicates may occur.
QoS 2: “Exactly once,” ensures the message is delivered only once. For example, this level can be used in a billing system where duplicates or losses can lead to incorrect charges.
5. Small transmission size, minimal overhead (fixed-length header is 2 bytes), and minimized protocol exchanges to reduce network traffic;
6. Uses Last Will and Testament features to notify relevant parties of client abnormal interruptions.
An MQTT packet consists of three parts: fixed header, variable header, and payload. The transmission format of MQTT is very compact, with the smallest packet being only 2 bits and no application message header.
The following figure shows the three Quality of Service levels for reliable message delivery in MQTT.
The publish/subscribe model allows MQTT clients to communicate in one-to-one, one-to-many, many-to-one, and many-to-many ways.
The following figure illustrates the publish/subscribe message pattern of MQTT.
Publish/subscribe message pattern:
It’s like using a mobile phone to check stock prices.
People checking stocks subscribe to messages based on their selected stocks, and the main station only sends relevant messages to those who subscribed. Each time stock information updates, it will be sent to the main station.
This should help everyone understand the publish/subscribe message pattern; however, during the communication process, the publisher can also be a subscriber.
MQTT Frame Structure
CoAP Protocol
CoAP stands for Constrained Application Protocol. Many devices in the current IoT landscape are resource-constrained, with limited memory and computing power, making traditional HTTP protocols too bulky and unsuitable for IoT applications. Therefore, the IETF’s CoRE working group proposed CoAP, which is based on a REST architecture, using UDP for the transport layer and 6LowPAN for the network layer (IPv6 for low-power wireless local area networks).
CoAP adopts the same request-response working mode as HTTP. There are four different message types in CoAP:
CON – A request that requires confirmation; if a CON request is sent, the other party must respond.
NON – A request that does not require confirmation; if a NON request is sent, the other party does not have to respond.
ACK – A response message acknowledging the receipt of a CON message.
RST – A reset message; when the receiver receives a message containing an error, or if the receiver no longer cares about the sender’s content, a reset message will be sent.
CoAP message format uses a simple binary format, with a minimum size of 4 bytes.
A message consists of a fixed-length header + an optional number of options + a payload. The length of the payload is calculated based on the datagram length.
It is primarily a one-to-one protocol.
For example:
A device needs to query the current temperature from the server.
Request message (CON): GET /temperature, the request content will be packed inside the CON message.
Response message (ACK): 2.05 Content “22.5 C”, the response content will be placed in the ACK message.
CoAP Frame Structure
Differences Between CoAP and MQTT
MQTT
MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol developed by IBM that may become an important part of IoT. This protocol supports all platforms and can almost connect all IoT devices to external connections, serving as a communication protocol for sensors and actuators (for instance, connecting homes via Twitter).
CoAP
CoAP stands for Constrained Application Protocol. In recent years, experts predict that more devices will connect to each other, with their numbers far exceeding that of humans. In this context, IoT and M2M technologies have emerged. While connecting to the internet is convenient for humans, it is quite challenging for tiny devices. In a world dominated by PCs, information exchange is implemented through TCP and application layer protocols like HTTP. However, for small devices, implementing TCP and HTTP protocols is clearly an excessive requirement. To enable small devices to connect to the internet, CoAP was designed. CoAP is an application layer protocol that runs over UDP rather than TCP like HTTP. CoAP is very compact, with the smallest packet being only 4 bytes.
Both MQTT and CoAP are effective IoT protocols, but they have significant differences. For instance, MQTT is based on TCP, while CoAP is based on UDP. From an application perspective, the main differences are as follows:
1. MQTT does not support type or other helpful tags for Clients to understand, meaning all MQTT Clients must know the message format. Conversely, CoAP has built-in discovery support and content negotiation, allowing devices to peek at each other to find data exchange methods.
2. MQTT is a long connection, while CoAP is connectionless. MQTT Clients maintain a TCP long connection with the Broker, which does not pose problems in NAT environments. If using CoAP in a NAT environment, some NAT traversal techniques are needed.
3. MQTT is a many-to-many protocol where multiple clients communicate through a central broker for message delivery. It decouples consumers and producers by allowing clients to publish messages, with the broker determining message routing and replication. MQTT serves as a real-time communication bus for message passing. CoAP is essentially a one-to-one protocol for passing state information between Server and Client.
Conclusion:
Analyzing the current trends in IoT application development, MQTT has certain advantages. This is because major cloud service providers, both domestic and international, such as Alibaba Cloud, AWS, Baidu Cloud, Azure, and Tencent Cloud, all support MQTT. Another reason is that MQTT matured earlier than CoAP, giving it a first-mover advantage.