IoT Standards and Protocols In detail

When talking about the Internet of Things, we always think about communication. Interaction between sensors, devices, gateways, servers, and user applications is the essential characteristic that makes the Internet of Things what it is. But what enables all this smart stuff to talk and interact are the IoT protocols which can be seen as languages that the IoT gear uses in order to communicate. This article is an overview of the most popular IoT protocols used on the market to-date.

IoT protocols - Detailed

Constrained Application Protocol (CoAP)

While the existing Internet infrastructure is freely available and usable for any IoT device, it often proves too heavy and power-consuming for most IoT use cases. Created by the IETF Constrained RESTful Environments working group and launched in 2013, Constrained Application Protocol (CoAP) was designed to translate the HTTP model so that it could be used in restrictive device and network environments.
Designed to address the needs of HTTP-based IoT systems, CoAP relies on the User Datagram Protocol (UDP) for establishing secure communication between endpoints. By allowing for broadcasting and multicasting, UDP is able to transmit data to multiple hosts while retaining communication speed and low bandwidth usage, which makes it a good match for wireless networks typically employed in resource-constrained M2M environments. Another thing that CoAP shares with HTTP is the RESTful architecture which supports a request/response interaction model between application endpoints. What is more, CoAP adopts the basic HTTP get, post, put and delete methods, thanks to which ambiguity can be avoided at the time of interaction between clients.

Similarly to MQTT, CoAP features Quality of Service which is used to control the messages sent and mark them as ‘confirmable’ or ‘nonconfirmable’ accordingly which indicates whether the recipient should return an ‘ack’ or not. Other interesting features of CoAP are that it supports content negotiation and resource discovery mechanism. Apart from transferring IoT data, CoAP leverages Datagram Transport Layer Security (DTLS) for the secure exchange of messages in the transport layer. CoAP fully addresses the needs of an extremely light protocol in order to meet the demands of battery-operated or low-energy devices. All in all, CoAP is a good match when it comes to existing web service-based IoT systems.

Message Queuing Telemetry Transport (MQTT)

Probably the most widely adopted standard in the Industrial Internet of Things to date, Message Queuing Telemetry Transport is a lightweight publication/subscription type (pub/sub) messaging protocol. Designed for battery-powered devices, MQTT’s architecture is simple and lightweight, providing low power consumption for devices . Working on top of TCP/IP protocol, it has been especially designed for unreliable communication networks in order to respond to the problem of the growing number of small-sized cheap low-power objects that have made their appearance in the network in the recent years.
MQTT is based on subscriber, publisher and broker model. Within the model, the publisher’s task is to collect the data and send information to subscribers via the mediation layer which is the broker. The role of the broker, on the other hand, is to ensure security by cross-checking the authorisation of publishers and subscribers. MQTT offers three modes of achieving this (Quality of Service), thanks to which the publisher has the possibility to define the quality of its message:

- QoS0 (At most once): The least reliable mode but also the fastest. The publication is sent but confirmation is not received.
- QoS1 (At least once): Ensures that the message is delivered at least once, but duplicates may be received.
- QoS2 (Exactly once): The most reliable mode while the most bandwidth-consuming. Duplicates are controlled to ensure that the message is delivered only once.

Having found wide application in such IoT devices as electric meters, vehicles, detectors, and industrial or sanitary equipment, MQTT responds well to the following needs:

- Minimum bandwidth use, Operation over wireless networks, Low energy consumption, Good reliability if necessary, Little processing and memory resources.

Despite its characteristics, MQTT can be problematic for some very restrictive devices, due to the fact of the transmission of messages over TCP and managing long topic names. This is solved with the MQTT-SN variant that uses UDP and supports topic name indexing. However, despite its wide adoption, MQTT doesn’t support a well-defined data representation and device management structure model, which renders the implementation of its data management and device management capabilitie entirely platform- or vendor-specific.

Extensible Messaging and Presence Protocol (XMPP)

Developed in 1999 by the Jabber open source community and originally meant for real-time messaging, this communication IoT protocol for message-oriented middleware is based on the XML language. It allows for real-time exchange of structured but extensible data between two or more network clients.
Since its inception, XMPP has been widely applied as a communications protocol. Over time and with the emergence of a lightweight XMPP specification: XMPP-IoT, it has gone on to be used in the context of the Internet of Things. Being an open community supported standard, XMPP IoT’s strengths are addressing and scalability capabilities, which makes it perfect for consumer-oriented IoT deployments.

Among the drawbacks of using XMPP in IoT communication, it should be noted that it offers neither Quality of Service nor end-to-end encryption. Due to these limitations, among others, it is predicted that its application within IoT will stay loosely connected to the industry, as the protocol definitely won’t become a standard used day-in day-out for the purposes of data exchange and management of resource-constrained devices, just as MQTT or LwM2M are.

Data-Distribution Service (DDS)

Similarly to XMPP, the DDS protocol has been developed on the basis of the publish-subscribe methodology. Designed by the Object Management Group (OMG), the DDS protocol for real-time M2M communication enables scalable, reliable, high-performance and interoperable data exchange between connected devices independent of the hardware and the software platform. Unlike MQTT and CoAP IoT protocols, DDS supports brokerless architecture and multicasting to provide high quality QoS and ensure interoperability.
The architecture of the DDS protocol is based on the Data Centric Publish-Subscribe layer (DCPS) and the optional Data-Local Reconstruction Layer (DLRL). While the DCPS layer is responsible for a resource-aware, scalable, and efficient data distribution to subscribers, the DLRL offers an interface for DCPS functionalities, allowing for transmission of data among the IoT-connected objects.

While not being a typical IoT solution, DDS still finds its application in some Industrial Internet of Things deployments, such as: air-traffic control, smart grid management, autonomous vehicles, transportation systems, robotics, power generation, and healthcare services. Overall, DDS can be used for the management of data exchange between lightweight devices and interconnection of large, high-performance sensor networks. It can also send and receive data from the cloud.

Advanced Message Queuing Protocol (AMQP)

AMQP is an open standard publish/subscribe type protocol originated in 2003 which has its roots in the financial services sector. While it has gained some ground within the information communication technology, its use is still quite limited in the IoT industry. The AMQP specification describes such features as message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security. Probably the greatest benefit of AMQP is its robust communications model. Unlike MQTT, AMQP can guarantee complete transactions—which, although useful, is not always something that the IoT applications require.
Due to its heaviness, AMQP is not suitable for sensor devices with limited memory, power or network bandwidth, yet for individual IoT use cases, it may be the only protocol viable for end-to-end application, including such examples as industrial heavy machinery or SCADA systems where the devices and the network are considerably more capable as a rule.

Lightweight M2M (LwM2M)

What differentiates LwM2M from other protocols applied in IoT is that is has been specially designed to meet the requirements for comprehensive handling of resource-constrained devices. Launched in 2014 by Open Mobile Alliance (now OMA SpecWorks), it provides a well-defined standard for IoT data communication and device management.