IoT Standards and Protocols Guide—Protocols of the Internet of Things
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.
Why should you care about IoT protocols?
To express the above concept using an example, what differentiates a smart device from its ordinary counterpart is that while the latter stays mute in case of a breakdown, the former is able to talk to other devices (and not only the ones of the same type) if it encounters any problems and, if need be, to communicate the failure to the user or automatically call for help. But every such instance of interaction is only possible when there is a medium of communication, a common ‘language’ that all the devices in a given IoT ecosystem would share and be able to use. Within the Internet of Things, the medium is provided by the IoT protocols: either the Internet protocols already long in use, or the IoT protocols especially developed for connected device communication.
IoT protocols are a crucial part of the IoT technology stack—without them, hardware would be rendered useless as the IoT protocols enable it to exchange data in a structured and meaningful way. Out of these transferred pieces of data, useful information can be extracted for the end user and thanks to it, the whole deployment becomes economically profitable.
This is one of the reasons why the Internet of Things needs standardized IoT protocols. They help to avoid further fragmentation, thus minimizing the risk of security threats.
While it seems that this is an affirmation which all agree on, few efforts have been made so far to propose a world-wide standard that would unify all IoT communication. Nevertheless, in the past few years the Internet of Things has seen the emergence of protocols that aim to take up the challenge and offer versatility without trade-offs for security and deployment speed and simplicity. One such IoT protocol to address the concrete needs of a variety of device management use cases to provide fit-for-purpose solutions while proposing a universal standard is OMA Lightweight M2M, which will be discussed later in the text.
On the other hand, fragmentation in IoT is the result of the very nature of the Internet of Things itself: the heterogeneity within IoT represented by the multiplicity of its technologies and standards matches the diversity of the Things in the world that IoT aims to connect. Similarly, there are many aspects of IoT communication, each with its own type of protocols to suit its purposes. IoT protocols can be divided in terms of the role they play within the network. Among many others, there are protocols used in connectivity infrastructure (e.g. 6LowPAN), communications (Wi-Fi, Bluetooth), data transmission (MQTT, CoAP, XMPP), security (DTLS), and device management as well as telemetry (LwM2M).
For the purposes of the present article, we present a survey of some widely-recognized Internet of Things protocols with a special focus on protocols enabling the management of resource-constrained devices.
Overview of IoT protocols
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 capabilities 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. If you want to learn why LwM2M is a perfect choice for device management and telemetry in IoT, check out our article LwM2M—Lightweight M2M Standard—Protocol and its Benefits to read more.
Over the last two decades, the Internet of Things has kept expanding rapidly over the globe. Having worked its way to numerous industry branches such as manufacturing, healthcare, automotive, security, transportation and more, it has significantly empowered enterprises and brought them economic value.
Today, the Internet of Things supports dozens of different IoT protocols. In view of this, many IoT experts have started to call for a global protocol standardization. Yet, being inherently fragmented, the IoT market will probably never be in actual need of an all-embracing standard. Just as there are newer and newer applications and use cases cropping up within the IoT industry, fit-for-purpose IoT protocols for their deployment will continue to emerge along the way. Again, it should be emphasized that safe and effective device management is the keystone of a sustainable development of IoT networks worldwide. This is one of the reasons why describing and making sense of the various IoT protocols really matters. Therefore, what is really needed is the knowledge of one’s own business needs and requirements, awareness of the advantages and drawbacks of the protocols offered by the market, and the ability to pick the one that best suits a given use case.