The Internet of Things (IoT) is a term used to describe the interconnectivity and intercommunication of everyday devices with the Internet. Everything, from a smartwatch to a smart light bulb, is part of IoT. In this article, we talk about the different protocols used to enable easy communication between IoT devices. We also discuss which IoT protocol might be ideal for your project. If you are an IoT enthusiast looking to get started with your own project, this article is a must read.
It all started in 1982 with a Coca Cola vending machine developed at Carnegie Mellon University. Designed on the back of ARPANet, this machine had the ability to report the number of Coca Cola cans still left in the machine and whether these were cold. This basic idea of combining the Internet with regular day-to-day devices or ‘things’ took root and resulted in the birth of what is today known as the Internet of Things (IoT). The term IoT itself was coined in 1999 by Kevin Ashton, the co-founder of the Auto-ID center at MIT.
Since then, IoT has come a long way, evolving into a huge industry with millions of active devices serving a broad spectrum of applications. Smart home devices such as Google Home and Amazon Alexa are good examples of how IoT is being deployed by major tech companies to provide a wide range of user-friendly services. From smart TVs and refrigerators to smart surveillance cameras and lights, IoT is everywhere today.
As shown in Figure 1, by 2025, over 75 billion active IoT devices are estimated to function across the globe. With the AI revolution well on its way, IoT plays a key role in the future of electronics. Everything, from self-driving cars to automated train and aeroplane systems, has been made possible with IoT. Major tech companies such as Intel, Dexcom and Cisco have invested heavily into developing IoT devices and circuits. If you are looking to get started with getting your feet wet in the field of IoT, there was never a better time than now.
Why do we need different protocols for IoT devices?
The rapid development of the Internet and the associated technologies that go with it has led to a surge in IoT devices. Almost everything, from your spectacles to your shoes, is now connected to the Internet. But not every device has the same processing capacity. The technology used in any wearable Apple device is far superior than, say, a basic pedometer. Add to that, Internet connectivity still remains a major issue across the globe. Even powered with the latest 5G Internet, your device is likely to suffer some sort of connectivity issues.
There are also some product-specific issues that developers come across such as the size of the device, which limits the number of chips you can fit into it. Take for instance, the latest wireless Bluetooth earbuds. The Bluetooth connectivity chips used in those devices need to be small enough to fit inside an ear and strong enough to stay connected to your phone or computer at a longer distance.
While such limitations have been a good thing, in the sense that they fuelled faster development of revolutionary technologies, they have also given rise to new ways of communication over the Internet. Since all IoT devices cannot communicate with each other on the same capacity and capability, and have different system based requirements, we require different IoT protocols to enable smooth communication and transactions.
IoT protocols
Now that we understand why we require different IoT protocols, let us take a deeper look at each of the major ones in use today. The most prominent IoT protocols are CoAP, MQTT, XMPP, DDS, AMQP and LwM2M.
Constrained application protocol (CoAP)
When it comes to communication over the Internet, there is no protocol like the HTTP. With its underlying REST framework and simplicity, HTTP is highly reliable and easy to implement. The trouble however is that it can prove heavy for most IoT devices, as these generally require a more lightweight protocol. So can there be a protocol that has all the goodness of HTTP in addition to being lightweight and easy to implement? That is the problem that the IETF Constrained RESTful environments working group tried to solve by creating CoAP in 2013. CoAP uses the user datagram protocol (UDP) for establishing communication between IoT devices, unlike HTTP which uses TCP.
CoAP uses a RESTful architecture and uses the HTTP GET, POST, PUT and DELETE methods. The beauty of CoAP, which distinguishes it from HTTP, is that UDP allows the IoT devices to communicate without having to establish a prior connection. This means that an IoT device using CoAP can relay multiple messages to multiple devices without having to wait for a handshake. This makes the communication faster while continuing to use very low bandwidth. To mitigate the risk of messages getting dropped due to a lack of connection, CoAP uses a confirmable/non-confirmable feature, using which messages that have been delivered can be marked confirmable. CoAP also uses datagram transport layer security (DTLS) for secure exchange of messages in the transport layer. Figure 2 depicts the data transaction model of the CoAP protocol.
Message queuing telemetry transport (MQTT)
Perhaps the most widely used protocol in industry level IoT products, MQTT uses a publish/subscribe model for transacting data between different devices. In this model, devices are divided into three types, namely, the producers, consumers and brokers. Producers publish data under what are called topics. A topic is basically a channel under which related data can be published by the producer. The consumer devices subscribed to that particular channel then receive the message. The entire transmission of data from a publisher to its subscribers is made possible with the help of brokers. Brokers receive messages from producers that they then filter into designated topics and share with the subscribers for each of the topics.
MQTT uses the TCP/IP protocol to enable communication between multiple devices. What makes it ideal for industry level products is that it simplifies sending and receiving messages between multiple devices. Figure 3 depicts the data transaction model of MQTT with the help of an example of a smart humidity sensor. In the example, the humidifier is the producer that publishes data to the broker under separate topics. The consumers, which in this example are the on-premise analytics and the cloud, receive the data from the broker for their respective topics. So the producer publishes the data to the broker, and the broker publishes the data to the subscribers.
Extensible messaging and presence protocol (XMPP)
XMPP started as an instant messaging communication protocol but soon evolved into becoming an IoT protocol. It is an XML based server/client model protocol. The architecture, as depicted in Figure 4, is fairly straightforward. Clients connect to an XMPP server to communicate. The server facilitates the communication sessions between the clients. Since the medium of communication is in XML, it reduces the size of the data being transmitted and makes transactions faster.
There are, however, a few drawbacks in XMPP that do not make it an ideal solution for enterprise level IoT applications. For one, there is no quality-of-service feature in XMPP unlike CoAP, which makes it unreliable. Second, it doesn’t have end-to-end encryption, which makes it insecure for sensitive data transmission.
Data distribution service (DDS)
DDS is similar to MQTT, but better. It follows a publish/subscribe model but does not require a broker for the transaction of data between devices. Add to that, it also supports multicasting and quality-of-service, which makes it ideal for usage in industry level products. The Object Management Group (OMG) first designed DDS with scalability in mind. Hence the brokerless model makes it highly scalable and adaptable to changing requirements.
As shown in Figure 5, the DDS architecture consists of a data-centric publish/subscribe layer (DCPL) in addition to an optional data-local reconstruction layer (DLRL). Scalability, resource awareness and fast paced distribution of data are ensured with the help of the DCPL layer, while the DLRL layer provides an interface for the operations of the DCPL layer.
Advanced message queuing protocol (AMQP)
AMQP is another publish/subscribe model based protocol that is primarily focused on guaranteed completion of transactions. Designed back in 2003, it was used mostly in the financial sector for obvious reasons. AMQP makes use of advanced queuing and distribution techniques to ensure security, reliability and speed.
As seen in Figure 6, the publisher publishes the message to the AMQP broker with a predesignated routing key attached to the message. Utilising the routing key, the broker queues the message for delivery to the designated consumer. These messages are bound to exchanges with the help of bindings. There are, however, a few drawbacks of the AMQP model which has restricted its mass adoption in the IoT space. For one, it is a heavy protocol that is not ideal for smaller IoT devices with a lack of bandwidth and power. Second, the guaranteed delivery of messages is not always a high priority for all IoT projects.
Lightweight M2M (LwM2M)
Designed by the Open Mobile Alliance (OMA) in 2014, LwM2M has been specifically designed to tackle the challenges of modern day IoT systems. With over 75 billion working IoT devices estimated across the world by 2025, LwM2M has been designed for scalability, speed and reliability in a constrained environment.
As shown in Figure 7, the LwM2M server stack consists of all the essential components that an IoT network requires including CoAP protocol, UDP protocol, SMS bearer and an efficient payload system. It also has DTLS security inbuilt. Additionally, LwM2M provides a device level bootstrapping facility, which gives you the ability to customise the usage of the protocol as per your requirements on a local level. It also provides a client registration interface, and access to resources and instances. This gives the user access to customise the settings on a granular level without having to revert to factory settings.
Which IoT protocol is right for your project?
What is interesting about IoT, unlike other tech projects, is that the requirements vary a lot from project to project, not only in terms of hardware but also software. For instance, an internal lighting system might require a connection with the cloud while another similar lighting system might require a more localised solution. In some projects, scalability and speed are the top priorities while for others, guaranteed completion of transactions and security might be the focus. As discussed in earlier sections, protocols play a critical role in facilitating such requirements. If the hardware is the body, the protocol is the brain of the device.
Keeping this in mind, I recommend doing a detailed audit and review of the project requirements. It is also important to research industry level IoT projects similar to yours and see which protocol they use. Here’s a list of points to consider in this regard.
1. If using a RESTful framework with all the goodness of HTTP is a major requirement for your project, then you cannot go wrong with CoAP. CoAP provides all the features of HTTP, with the additional speed and reliability provided by UDP and message labelling.
2. If your IoT devices have major battery related constraints and you require a lightweight protocol, then MQTT is more suited for your project. It is important to keep in mind that MQTT does suffer with latency issues; so use this protocol only if high latency is not a major concern for your project. 4
3. If your project is data-intensive and requires fast transaction of messages between multiple devices, then XMPP might be a protocol worth considering. But do this only if the security of the data is not a major concern as XMPP does not have any inbuilt security features. Needless to say, if your project uses XML, then the go-to protocol should be XMPP.
4. If what you are working on are large, high-performance sensor networks such as the ones used in self-driving cars and smart air-traffic control systems, then DDS is probably the ideal choice. However, due diligence is necessary before selecting any protocol, and this is even more true when you are dealing with such advanced projects. DDS is a heavyweight protocol, and requires your devices to have a decent battery life and bandwidth to be able to function.
5. AMQP is a protocol that can be considered for projects that are end-to-end applications — for instance, heavy industrial machinery that has the capacity to handle data-intensive tasks without the concern for power consumption. If transaction completion is an absolute necessity for your project, then AMQP is the most reliable protocol for it.
6. LwM2M is the ideal protocol for telemetry and device management based IoT projects. You can create industry-level large scale IoT projects with high scalability, speed and security. LwM2M has been designed specifically for IoT projects and, as such, has a wide range of applications. You can consider using it for a wide array of projects with varying requirements and consumer bases.
