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, especially in terms of IoT device management.
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.
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.
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:
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:
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.
Creating a Wi-Fi network requires devices that can send wireless signals which means devices such as telephones, computers or routers, to name a few. At home, a router is used to transfer the internet connection from a public network to a private home or office network. WiFi provides an Internet connection to nearby devices that are within a certain range. Another way to use WiFi is to create a WiFi hotspot, i.e. telephones or computers may share a wireless or wired internet connection with other devices by broadcasting a signal.
WiFi uses radio waves that broadcast information on specific frequencies, such as 2.4 GHz or 5 GHz channels. Both frequency ranges have a number of channels through which different wireless devices can work, which helps to distribute the load so that the individual connections of the devices are not interrupted. This largely prevents overflowing of wireless networks.
A range of 100 meters is the typical range of a standard WiFi connection. The most common range, however, is limited to 10-35 meters. The effective network coverage is greatly affected by antenna strength or transmission frequency. The range and speed of a WiFi Internet connection depends on the environment and whether it provides internal or external coverage. Thus, the speed of various devices using the WiFi internet connection increases as the computer approaches the main source, while the speed decreases as the computer moves away from the source.
ZigBee-based networks are characterized by low power consumption, low throughputs (up to 250 kbps) and connectivity range of 100 meters between nodes. Typical applications include sensor networks, personal networks (WPAN), home automation, alarm systems and monitoring systems.
Its initial specification was recognized as an IEEE standard in 2003 and the first OEM modules compliant with it ZigBee appeared in mass sales at the beginning of 2006.
ZigBee was developed as a standard for self-configuring, short-range radio networks, intended for use in telemetry systems, for communication between various types of sensors, monitoring devices, as well as for wireless reading of measurement results from energy and heat meters, etc. The ZigBee standard is a relatively simple, resistant to communication errors and unauthorized readings, packet data exchange protocol, which is often implemented in devices with relatively small requirements, such as microcontrollers, sensors etc.
ZigBee is easy to install and maintain because it is based on self-assembly and self-healing grid topology. It also easily scales to thousands of nodes, and nowadays there are many suppliers offering devices that support this open standard.
Bluetooth is a technology that allows wireless connection of various electronic devices, such as a telephone, keyboard, computer, laptop, mouse, palmtop, printer, headset or speakerphone, and more. If you’re down for a more wiki-like definition, this is an open standard described in the IEEE 802.15.1 specification and its technical specification includes three classes of ERP 1-3 transmission power with a range of, respectively, 100, 10 and 1 meter in open space. The most common class is the second one (10m) which allows you to connect devices that are in different rooms and even on different floors.
The standard uses radio waves in the 2.4 GHz ISM frequency band and the device enabling the use of this standard is a Bluetooth adapter.
In Bluetooth technology, data is sent in the form of packets to one of 79 channels (in the case of the oldest Bluetooth 1.0 standard) with a bandwidth of 1 Mhz which ensures a maximum transfer speed of 721 kbit/s. In the case of the latest Bluetooth 4.0 standard, there are 40 channels with a bandwidth of 2 Mhz, which guarantees a maximum data transfer of up to 3 Mb/s. It is worth knowing that newer bluetooth standards that guarantee faster data transfer and greater security are also compatible with older versions.
What’s interesting, Bluetooth contains patents that can be used for free in products classified as Bluetooth-compatible. The qualification costs 5-10 thousand (USD), but potential users can easily find a new product on the list published for this purpose.
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)
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. 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. 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 it 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.
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.
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).
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.