Let’s start delving into the exciting world of Internet of Things (IoT) and we begin by looking at the communication protocols available for IoT applications.
As we know, IoT is a booming field that, in a very summarized way, consists of a large number of everyday objects being or going to be connected to each other.
IoT is in vogue, there is no doubt about that. Although there is a lot of “hype” surrounding IoT, as always happens in all trendy topics, the truth is that it has predictably come to stay.
Part of the rise of IoT is the popularity of the Internet and Smartphones, the improvement of communication systems, and the appearance of devices with small, cheap, and low-power connectivity such as the ESP8266 or the ESP32.
As we have seen in the definition, communication between devices is the cornerstone of IoT. Therefore, we will start by looking at some existing communication protocols in the IoT field.
When we think about these IoT protocols, we will surely quickly think of the popular MQTT. However, not everything in the IoT field is MQTT. In this post, we will see different protocols, some of their characteristics, and the motivation for their existence.
In the next post in the IoT series, we will focus on MQTT, which as we have said is one of the most common and accessible protocols in our maker projects.
Why a protocol for IoT?
A communication protocol is a set of rules that we define so that two or more devices can communicate and understand each other.
As we know, we have many ways to communicate and perform M2M (machine-to-machine) communication. Currently, with the development that telecommunications have had and the boost that the Internet has provided, this is not a problem.
However, in the field of IoT, we have certain special requirements that make the usual ways of communication between devices not entirely suitable. What are these constraints?
Constraints of M2M in IoT
First of all, in IoT we have (or can have) a large number of devices. Some of them will be small (low-resource), such as sensors or actuators. While others will be larger, such as a server that collects information, stores data, and processes statistics.
Another requirement is that we want it to be scalable, that is, devices can be added or removed dynamically without modifying the overall behavior of the system.
It is also important to keep the coupling between devices weak. That is, we want the dependence between devices to be as minimal as possible, and ideally zero.
Another requirement is that some of the devices will be embedded devices, with low cost and limited computing capacity. Therefore, it has to be a protocol that requires little processing capacity.
Related to the variety and number of devices, we will want interoperability. That is, our solution should work with the greatest variety of devices, operating systems, and programming languages.
In addition, there may be a large number of simultaneous communications and, in general, a quick response is required. This requires that the transmitted messages be small and, again, do not require a lot of processing.
Of course, we always have the security constraint in mind, since these devices are exposed to the Internet (which is not a safe place) and transmit private information and even control physical systems.
Finally, we have to be able to access the devices easily, so we will have to deal with dynamic addresses and DHCP, possible connections with poor latency or bandwidth, dependence on network infrastructure, firewalls, etc.
Communication solutions in IoT
So how do we get a number of devices, distributed in unknown locations and networks, to communicate with each other reliably and scalably?
One possible solution, which is being widely used, is to outsource the communication to a centralized notification service. In fact, it is an increasingly common infrastructure in computing, both in IoT applications and in non-IoT applications.
In short, the solution consists of having a central server that is responsible for receiving messages from all sending devices, and distributing them to the receiving devices. In general, we will call this server ‘Router’ or ‘Broker’.
It may seem a bit strange to have a server only responsible for distributing messages. But in reality, we have been using similar solutions for years. Not to go any further, a mailman is an external service responsible for distributing messages.
This server has a fixed address (or equivalently a domain), so it is accessible to all devices, solving the problem of having to find the other device.
The server keeps a record of the connected devices, receives the messages, and distributes them to the rest of the devices, filtering the recipients according to some criteria.
The devices never ‘see’ or depend on the rest of the devices. Therefore, this infrastructure provides us with scalability.
Methodologies in IoT
Let’s review a couple of terms regarding methodologies that we can find in IoT. In reality, the concepts are similar, but it is convenient to understand the differences (if only to speak properly).
Publish / Subscribe (PubSub)
The Pub/Sub methodology is a messaging pattern where an agent, the ‘Subscriber’, informs the Router that it wants to receive a type of messages. Another agent, the ‘Publisher’ can publish messages. The Router distributes the messages to the Subscribers.
Remote Procedure Calls (rRPC)
The rRPC is a pattern of remote execution of procedures where an agent, called ‘Callee’, communicates to the Router that it provides a certain procedure. Another agent, called ‘Caller’, can call this procedure. The Router invokes the procedure in the Callee, collects the result of the process, and communicates it to the Caller that invoked it.
Service Infrastructures in IoT
There are several approaches to implementing a PubSub or rRPC pattern. Let’s see two of the main ones. In practical terms, we can achieve similar functionalities in both approaches, but just as in the previous case, it is advisable to be aware of the difference.
However, it should also be noted that there are solutions that adopt an intermediate or hybrid behavior between the two approaches.
Message Queue
In a Message Queue type messaging service, the Router generates a unique message queue for each of the clients that initiate the subscription. The Router discriminates messages using the client’s identifier, although of course there are mechanisms to distribute to multiple clients.
These client message queues keep the received messages until they are delivered to the client. So if a message is received when the client is not connected, they are kept in the Router and delivered when it connects.
An example of a Message Queue is a messaging application like WhatsApp or Telegram, where the user receives the messages they have received while they were not connected. Another everyday example is your home mailbox. If you are on vacation, when you return you have all your messages waiting for you.
Message Service
Another approach is a pure messaging service or Message Service. In this case, the router immediately distributes messages to connected clients. Messages are filtered by some criteria, such as the theme or content of the message.
Unlike a Message Queue, delivered messages while the client is disconnected are lost. However, that does not mean that a Message Service cannot implement some type of data persistence, for example, for analytics, historical data, or quality of service.
An example of a Message Service is a chat, where we cannot retrieve the messages sent when we were not in the room. Another everyday example is a conversation in person. If someone says something while we are in another room, even if we enter we have missed what was said before.
Protocols for IoT
Now that we have seen the need and approach of the protocols intended for IoT applications, let’s look at some of the many available M2M protocols.
- MQTT (MQ Telemetry Transport) is a PubSub protocol for Message Service that operates over TCP. It stands out for being lightweight, simple to implement. It is suitable for low-power devices, such as those commonly found in IoT. It is optimized for active routing of a large number of clients connected simultaneously.
- AMQP (Advanced Message Queuing Protocol) is a PubSub protocol for Message Queue. AMQP is designed to ensure reliability and interoperability. It is intended for corporate applications, with higher performance and low-latency networks. It is not as suitable for IoT applications with low-resource devices.
- WAMP (Web Application Messaging Protocol) is an open protocol that runs over WebSockets, and provides both PubSub and rRPC applications.
- CoAP (Constrained Application Protocol) is a protocol designed to be used in low-capacity IoT devices. It uses the REST model of HTTP with reduced headers, adding support for UDP, multicast, and additional security mechanisms.
- STOMP (Streaming Text Oriented Messaging Protocol), is a simple protocol that uses HTTP and text messages to achieve maximum interoperability.
- XMPP (Extensible Messaging and Presence Protocol) is an open protocol based on XML designed for instant messaging applications.
- WMQ (WebSphere MQ) is a Message Queue protocol developed by IBM.
That’s it for this post about M2M communication protocols in IoT. We have seen the special needs of these protocols and how to solve them with an outsourcing to a messaging service.
We have also seen the concepts of PubSub and rRPC and the differences between a Message Service and a Message Queue. Finally, we have quickly reviewed some of the main IoT protocols currently available.
In the next post, we will see the MQTT protocol, which will be the one we most commonly use in our projects, and in the following post we will see different Brokers for MQTT. In the meantime, if you have any questions or want to add anything, you can leave your comment!