Comparison of IoT Protocols
The standard and real-time communication technology is an unalloyed inevitability for the development of IoT applications. However, the selection of a standard and effective messaging protocol is a challenging and daunting task for any organization because it depends on the nature of the IoT system and its messaging requirements. Messaging protocol is an ongoing dilemma for the IoT industry, hence it is important to understand the pros and cons of the widely accepted and emerging messaging protocols for IoT systems to determine their best-fit scenarios.
We have already introduced to you the MQTT, CoAP, and AMQP protocols in the previous sections. The page links have been provided below so if you have not gone over them we recommend you click on the page links given below and gain some knowledge on the respective protocols before switching over to this section.
pageMessage Queue Telemetry Transport (MQTT)pageConstrained Application Protocol (CoAP)pageAdvanced Message Queuing Protocol (AMQP)Firstly, we present a broad comparison of these messaging protocols to introduce their characteristics comparatively. Later we perform a further in-depth and relative analysis based on some interrelated criteria to gain insight into their strengths and limitations. Thus, based on this detailed evaluation, you can decide their appropriate usage in various IoT systems according to their requirements and suitability.
Comparative Analysis
Criteria | MQTT | CoAP | AMQP |
Abstraction | Publish/Subscribe | Publish/Subscribe or Request/Response | Publish/Subscribe or Request/Response |
Header Size | 2 Byte | 4 Byte | 8 Byte |
Message Size | upto 256 MB | small to fit in datagram IP | Maximum payload size |
QoS Reliability | QoS 0, 1, 2 | Confirmable or Non- Confirmable message | Settle format (at most once) or unsettle format (at least once) |
Transport Protocol | TCP | UDP | TCP |
Security | TLS/SSL | DTLS | TLS, DTLS |
Default Port | 1883/ 8883 (TLS/SSL) | 5683 (UDP Port)/ 5684 (DLTS) | 5671 (TLS/SSL), 5672 |
Relative Analysis
This section presents a further in-depth and relative analysis of these messaging protocols for IoT systems. It critically analyses the two closely associated criteria to provide corresponding strengths and limitations of each messaging protocol. Their precise and relative comparisons depend on the types of IoT systems, devices, resources, applications, and specific conditions and requirements of the system. However, this relative comparison is based on the range “Lower” and “Higher” to render a nimble and broader view of each protocol with respect to other protocols.
There is one caveat here that this relative comparison may vary in some circumstances due to the above factors and may reflect different comparative results than shown here. It also does not consider the dynamic network conditions and overhead incurred in the retransmission of packets, which may also change comparison results.
Message Size vs Message Overhead
MQTT and AMQP run on TCP thereby incur all TCP connection overheads for connection establishment and closing.
However, MQTT is lightweight and has the least header size of 2-byte per message but its requirement of TCP connection increases the overall overhead, and thus the whole message size.
CoAP runs on UDP; consequently, it does not incur connection overheads as UDP works in fire and forget basis. This reduces the overall overhead considerably, and thus the whole message size.
AMQP is also a lightweight binary protocol; however, its support for security, reliability, provisioning, and interoperability increases the overhead and message size.
This comparison does not consider retransmission scenarios that can completely change overall overheads and amounts of transmitted data and, thus the comparison results.
Power Consumption vs Resource Equipment
Let us have a relative comparison of these messaging protocols based on their normal power consumption and resource requirements. The graph highlights similar patterns as the first one, where AMQP requires the highest power and resource than any other protocol, and then it decreases for the other protocols with CoAP requiring the lowest power and resource.
Both CoAP and MQTT are designed for low bandwidth and resource-constrained devices and can be used on an 8-bit controller and 100s bytes of memory. Various experimental studies found that CoAP consumes slightly less power and resources in similar circumstances: unreliable scenario (MQTT QoS 0 vs. CoAP NON), and reliable scenario (MQTT QoS 1 or 2 vs. CoAP CON) while assuming that no packet losses have occurred.
AMQP requires slightly higher power and resources due to performing other necessary operations for provisioning and reliability. Again, this comparison does not consider dynamic network conditions and overhead incurred in the retransmission of packets.
Bandwidth vs Latency
The graph below reveals the very similar patterns as the first two, where AMQP involves largest bandwidth and latency than any other protocols, and then it decreases for the other protocols with CoAP having lowest bandwidth and latency.
The use of TCP in MQTT and AMQP is a major factor in determining the latency and bandwidth requirement. Unfortunately, TCP does not help in improving latency. It does not fully utilize the available network bandwidth for the first few roundtrips of a connection because of its slow start approach to avoid network congestion with the sender gradually opens the congestion window and doubling the number of packets in each roundtrip time (RTT).
In CoAP, a UDP transaction requires only two UDP datagrams, one in each direction; this reduces the network load response times. Various experimental studies found that MQTT consumes higher bandwidth than CoAP for transferring the same payload under the same network condition (MQTT QoS 1 or 2 vs. CoAP CON).
Moreover, when comparing MQTT QoS 2 with CoAP CON, the bandwidth usage of MQTT was approximately double that of CoAP. This is because of the four-way handshake mechanism of QoS 2.
AMQP’s extra services demand moderately higher bandwidth and latency.
Reliability (QoS) vs Interoperability
The graph below divulges that MQTT offers the highest level of quality of service with the least interoperability among the different protocols. One of the biggest benefits of using TCP as a transport protocol by MQTT and AMQP is the guaranteed delivery of a packet.
MQTT, AMQP, and CoAP protocols have different levels of QoS support.
MQTT defines three QoS levels: 0- at most once (only TCP guarantee), 1- at least once (MQTT guarantee with confirmation), 2- exactly once (MQTT guarantee with a handshake). Additionally, it also provides “last will and testament” message facilities (guarantee after disconnect).
AMQP defines two QoS levels: Settle Format (similar to MQTT QoS 0) and Unsettle Format (similar to MQTT QoS 1).
CoAP, which is deprived of the reliability of TCP, compensates for the unreliability of UDP protocol by defining a retransmission mechanism and providing resource discovery mechanism with resource description. Though CoAP does not provide explicit QoS, it facilitates the use of non-confirmable messages (NON) and confirmable messages (CON), which is very similar to MQTT QoS 0 and QoS 1.
Interoperability is the biggest issue among all IoT protocols. MQTT only supports the publish/subscribe pattern of communication, which barely covers all use cases within the IoT. In AMQP, it is common to use serialization formats such as Protocol Buffers, MessagePack, and JSON to serialize structured data in order to publish it as the message payload. CoAP is a part of the Web architecture and best suited for devices that support UDP however, making it limited to a few special kinds of IoT devices.
References
You can refer to the above links to know about the comparison of IoT protocols in more detail.
Last updated
