Let’s start delving into the exciting world of the Internet of Things (IoT) and begin by looking at the communication protocols available for IoT applications.
As we know, IoT is a booming field that, in a very summarized form, consists of a large number of everyday objects being or going to be connected to each other.
IoT is trendy, there’s no doubt about that. Although there is a lot of “hype” around IoT, as always happens with all trendy topics, the truth is that it has likely come to stay.
Part of the rise of IoT is the popularity of the Internet and Smartphones, the improvement of communication systems, and the emergence of small, cheap, low-power connectivity devices like the ESP8266 or ESP32.
As we saw 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.
If we think about these IoT protocols, the popular MQTT will probably come to mind quickly. 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 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 we define so that two or more devices can communicate and understand each other.
As we know, we have many ways to 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 at all.
However, in the IoT field we have certain special requirements that make the usual forms of communication between devices not entirely suitable. What are these constraints?
Constraints of M2M in IoT
First, in IoT we have (or can have) a large number of devices. Some of them will be small (with limited resources), like sensors or actuators. While others will be larger, like a server that collects information, stores data, and processes statistics.
Another requirement is that we want it to be scalable, meaning that devices can be added or removed dynamically without the global behavior of the system being modified.
It is also important to maintain weak coupling between devices. That is, we want the dependency between devices to be as low 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 must be a protocol that requires little processing power.
Related to the variety and number of devices, we will want interoperability. That is, we want our solution to work on the widest variety of devices, operating systems, and programming languages.
Furthermore, there may be a large number of simultaneous communications and, in general, a fast response is required. This requires transmitted messages to be small and, again, not require heavy processing.
Of course, we always have the security constraint in mind, as these devices are exposed to the Internet (which is not a safe place at all) and transmit private information and even control physical systems.
Finally, we need to be able to access devices easily, so we will have to deal with dynamic addresses and DHCP, possible connections with poor latency or bandwidth, dependency 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?
A possible solution, which is being widely used, is to outsource communication to a centralized notification service. In fact, it is an increasingly common infrastructure in computing, both in IoT and 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 receivers. Generically, we will call this server a ‘Router’ or ‘Broker’.
It may seem a bit strange to have a server dedicated solely to distributing messages. But in reality, we have been using similar solutions for years. For example, a mail carrier is an external service responsible for distributing messages.
This server has a fixed address (or equivalently a domain), so it is accessible by all devices, thus solving the problem of having to find the other device.
The server keeps a record of connected devices, receives messages, and distributes them to the rest of the devices, filtering recipients according to some criteria.
The devices never ‘see’ or depend on the other devices. Therefore, this infrastructure provides us with scalability.
Methodologies in IoT
Let’s review a couple of terms regarding methodologies we can find in IoT. Actually, the concepts are similar, but it’s good to understand the differences (even 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 messages to the Subscribers.
Router Remote Procedure Calls (rRPC)
rRPC is a pattern for 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 look at two of the main ones. For practical purposes, we can achieve similar functionalities in both approaches, but as in the previous case, it’s good to be aware of the difference.
However, it should also be noted that there are solutions that adopt an intermediate or hybrid behavior between both approaches.
Message queue
In a Message Queue type messaging service, the Router creates a unique message queue for each of the clients that start the subscription. The Router discriminates messages using the client identifier, although of course there are mechanisms to distribute to multiple clients.
These client message queues keep received messages until they are delivered to the client. So if a message is received when the client is not connected, it is kept in the Router and delivered when the client connects.
An example of a Message Queue is a messaging application like WhatsApp or Telegram, where the user receives messages that arrived while they were not connected. Another everyday example is your home mailbox. If you are away on vacation, when you return, all your messages are 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 topic or the content of the message.
Unlike a Message Queue, messages delivered while the client is disconnected are lost. However, this does not mean that a Message Service cannot implement some type of data persistence, for example, for analytics, history, or service quality.
An example of Message Services is a chat, where we cannot retrieve messages sent when we were not in the room. Another everyday example is a live conversation. 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 protocols intended for IoT applications, let’s look at some of the many available M2M protocols.
That’s it for this post on M2M communication protocols in IoT. We have seen the special needs of these protocols and how to solve them by 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 quickly reviewed some of the main IoT protocols currently available.
In the next post, we will look at the MQTT protocol, which will be the one we use most often in our projects, and in the following one, we will see different MQTT Brokers. Meanwhile, if you have any questions or want to add something, feel free to leave your comment!
