↑ Click the above“IoT Time and Space” to follow us
This article is sourced from: Why Hardware Matters, if there is any infringement, please contact us for deletion; published by the “IoT Time and Space” WeChat public account (IoT-LPWAN), please indicate the source when reprinting.
IoT Communication Protocols
Communication protocols can be considered a language that allows two or more devices to communicate with each other. Just like there are no rules, there is no square, communication protocols also follow a set of rules, enabling two devices to transmit meaningful information to each other. Communication protocols are crucial in distributed systems, where the same protocol may have different components operating independently at multiple locations. The system may be diverse during its operational processes, so a set of common instructions is needed for communication.
The rise of IoT is significantly attributed to Cyber-Physical Systems (CPS). The concept of physical devices connected to the internet for data transmission and reception is the essence of IoT solutions. Meanwhile, this also increases the complexity of existing communication protocols and the internet.
The development of IoT has brought many possibilities, but the only viable solution is real-time effective connections between machines (M2M) via the internet. A device connected to the internet is merely considered a product of interpersonal interaction, not a natural outcome. Therefore, communication between protocols and the internet always develops on an unreliable and slow basis.
MQTT Protocol
MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol originally developed by IBM. It is designed for communication between numerous remote sensors and control devices with limited computing capabilities, operating in low bandwidth and unreliable networks.
The advantage of the MQTT protocol is that it supports all platforms, effectively connecting all networked items to the internet.
It has the following main features:
1. Uses a publish/subscribe messaging model, 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 publishing relies entirely on the underlying TCP/IP network. Distributed messages may be lost or duplicated. For instance, this level can be used for environmental sensor data, where a single data loss is acceptable as it will be sent again shortly.
QoS 1: “At least once”, ensuring that messages can reach their destination, but may be duplicated.
QoS 2: “Exactly once”, ensuring that messages arrive only once. For example, this level can be used in a billing system, where duplicated or lost messages could lead to incorrect charges.
5. Small transmission size, minimal overhead (fixed-length header is 2 bytes), with minimized protocol exchange to reduce network traffic;
6. Uses Last Will and Testament feature to notify relevant parties of client abnormal disconnections;
In the MQTT protocol, 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 image illustrates the three levels of message publishing QoS 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 image illustrates the publish/subscribe messaging model of MQTT.
Publish/subscribe messaging model:
It’s like using a phone to check stock prices.
Those checking stocks subscribe to messages based on their selected stocks, and the main station only sends related messages to those who subscribed. After each stock’s information is updated, it will be sent to the main station.
This should help everyone understand the publish/subscribe messaging model; however, during communication, 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, possessing limited memory and computational capabilities, making traditional HTTP protocols appear too large and unsuitable for IoT applications. Therefore, the IETF’s CoRE working group proposed CoAP, which is based on a REST architecture, with UDP as the transport layer and 6LowPAN (IPv6 over Low-Power Wireless Personal Area Networks) as the network layer.
CoAP adopts the same request-response working mode as HTTP. There are four different message types in CoAP.
CON – Confirmable request, requiring a response from the other party when sent.
NON – Non-confirmable request, the other party does not need to respond when sent.
ACK – Acknowledgment message, responding to received CON messages.
RST – Reset message, sent when the recipient receives a message containing an error, or no longer cares about the content sent by the sender.
The 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.
Primarily a one-to-one protocol
For example:
A device needs to query the current temperature information from the server.
Request message (CON): GET /temperature, the request content will be encapsulated in the CON message.
Response message (ACK): 2.05 Content “22.5 C”, the response content will be contained 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, potentially becoming an important component of IoT. This protocol supports all platforms and can connect almost all networked items to the outside world, serving as a communication protocol for sensors and actuators (e.g., connecting homes via Twitter).
CoAP
CoAP stands for Constrained Application Protocol. In recent years, experts have predicted a growing number of interconnected devices, far exceeding the number 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 miniature devices. In a world composed of PCs, information exchange is facilitated through TCP and application layer protocol 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 as HTTP does. The CoAP protocol is very compact, with the smallest data packet being only 4 bytes.
Both MQTT and CoAP are effective IoT protocols, but there are significant differences between them. For instance, MQTT is based on TCP, while CoAP is based on UDP. Analyzing from the application perspective, the main differences are as follows:
1. The MQTT protocol does not support tags or other information to help clients understand the message type, meaning all MQTT clients must know the message format. In contrast, the CoAP protocol has built-in discovery support and content negotiation, allowing devices to discover data exchange methods.
2. MQTT maintains a long connection while CoAP is connectionless. MQTT clients maintain a long TCP connection with the broker, which does not pose problems in NAT environments. Using CoAP in a NAT environment requires some NAT traversal techniques.
3. MQTT is a many-to-many protocol where multiple clients communicate through a central broker. It decouples consumers and producers by allowing clients to publish messages, with the broker determining message routing and replication. MQTT acts as a real-time messaging bus. CoAP is fundamentally a one-to-one protocol for passing state information between the server and client.
Conclusion:
Based on the current trends in IoT application development, the MQTT protocol holds certain advantages. Major cloud service providers worldwide, such as Alibaba Cloud, AWS, Baidu Cloud, Azure, and Tencent Cloud, all support the MQTT protocol. Another reason is that the MQTT protocol matured earlier than CoAP, giving MQTT a certain first-mover advantage.
Long press the QR code to follow the “IoT Time and Space” public account