A glance in IoT protocols
We are living in a world where technology innovation is something usual. People are less impressed when they see a phone with better performance or a tablet with another great feature. Living in this interconnected world makes us ask ourselves how all these devices communicate.
Worldwide, there are hundreds of IoT protocols used by different providers. Some of them are well-known all over the world, such as MQTT (Multi-Client Publish/Subscribe Messaging) or CoAP which is a lightweight version of the HTTP protocol. Each protocol has a special purpose and was designed for specific use cases.
- DDS – designed for Device-to-Device communication, successfully used to communicate between machines over a very fast bus
- MQTT – designed for Device-to-Server communication, used for collecting data (especially telemetric data) from devices and sending them to a server
- XMPP – designed for Device-to-Server communication, used when the collected data needs to be interpreted by people (it is based on XML)
- AMQP – designed for Server-to-Server, a protocol designed to interconnect servers, but now used worldwide for communication between Devices and Servers
As we can see, each protocol was designed for a specific use case. It is almost impossible for us to say what the best protocol is. Based on our needs and requirements, we can select the one that best fits our needs.
DDS comes from Data Distribution Service and is a protocol designed for Device-to-Device communication. It is successfully used when we need to distribute data among devices, connect devices and share data among them.
This protocol allows us to distribute millions of messages per second over the wire with a very small latency to one or more devices. The power of this protocol stays in its simplicity, giving us the possibility to create a system formed of different devices that communicate in real time.
DDS is based on a publish/subscribe model at Node level. In DDS, a Node can play the role of publisher, creating so-called topics that can be published in samples. Each Node will deliver the samples to the subscribers. This standard is created over UDP/IP. The last version of the protocol specification was published last year (September 2014) – version 2.2.
The entire communication is not only decoupled, but DDS handles all the actions that are usually performed from the application, such as recipient location, retry policy and failover mechanism. It allows users to specify the Quality of Services (QoS) expected from the system. This way, users have the ability to configure the system in the optimal way for their needs.
DDS it is implemented in a 100% distributed system, to avoid any point of failure. The components that form DDS create a so-called Global Data Space where new nodes and devices can be dynamically discovered.
The most important characteristic of this protocol is real time. Data needs to be delivered to the right devices in the right moment. No messages can be lost or delayed.
DDS is used worldwide for power grids, flying management systems or financial trading. It is known as a reliable protocol that has the following 3 characteristics:
- Real time (atomicity at tens of microseconds)
- Dependability (99.999% availability)
- High Performance (millions of messages per seconds with low latency)
MQTT comes from Message Queue Telemetry Transport. This protocol was created for telemetry and data collection. The main purpose of this protocol is to collect data from devices and transport them in a safe channel to the backbends.
It is widely used when we need to collect telemetry data from many devices from the field. This protocol is simple, perfect to be used with small devices that have limited capabilities.
This protocol is built to work around a central hub where data is delivered, stored and processed. Because time is not a problem when working with telemetry data, this protocol is not a real-time protocol. Compared to DDS, we could say that this protocol is slow. This is not a problem because information related to telemetry doesn’t need to reach the backend immediately.
One of the most import characteristics of this protocol is its reliability. Because you don’t want to lose data, this protocol is built over TCP/IP protocol. That is why it is widely used for monitoring purpose especially in the oil, transportation and car industries, where monitoring is a very important and crucial part of the business.
As many other IoT protocols, MQTT is based on the publish/subscribe pattern. At the backend endpoint is it very commonly connected with an ESB (Enterprise Service Bus) system or other messaging systems. It is important to know that even if the word “queue” appears in the name of the protocol, there is no kind of support for queueing – only for publish/subscribe.
Because it was designed for low bandwidth with high latency networks, it is successfully used over dial-up connections or satellite links. The footprint of the protocol is very small and can be successfully used even in the lowest bandwidth networks.
This protocol is widely used because of the following 3 characteristics:
- Low bandwidth (the protocol footprint is very small)
- Simple API (5 methods that define the protocol)
- Pushing messaging (telemetry)
XMPP comes from Extensible Messaging and Presence Protocol. Initially called Jabber, it is a protocol designed for IM and used by messaging systems like Pandion, Jitsi, iChat, Pidgin or Xabber. XMPP can be implemented easily on different platforms and can be easily interpreted by people, compared to other IoT protocols that are not human-readable.
It is a text-based protocol, based on XML standard. Thanks to this, the debugging and integration of this protocol is simple. It runs over TCP/IP and has support for addressing schema in email format (username@customDomain.com). This characteristic is useful when you need to create an IM system that allows person-to-person communication. Many implementations of this protocol are over HTTP, only a few of them are over TCP/IP. This is because the protocol is based on XML standards.
XML is also a weakness of this protocol, because the size of the messages is large. To be able to support this protocol, you need to have a network that doesn’t have bandwidth problems.
The reliability of this protocol is offered by the TCP/IP implementation. From a speed point of view, this protocol is slow (even very slow compared to DDS), but perfect for person-to-person communication. In XMPP, the time is measured in seconds, not milliseconds. The main cause of the latency is the pooling mechanism that is used to check if new messages are available. There are a few implementations that are not based on pooling (exception from the rule).
One of the most important characteristics of this protocol is security. From this point of view, it is one of the safest protocols that are available. In combination with the addressing schema, it can be successfully used not only for IM, but there are also multiple different scenarios where information from sensors and actuators can be aggregated and displayed on a UI using XMPP.
Since there is full support for domains and subdomains in the XMPP protocol, it is not complicated to create a decentralized architecture over XMPP that contains different service providers. Because this protocol is based on XML/HTML, it can successfully run over 80 and 8080 ports.
The most important characteristics that define XMPP are:
- Security (it is a very safe protocol because it is over TCP/IP and can be easily integrated with HTTPs)
- Scalability (supporting a high number of devices)
- Addressing Schema (simple and efficient, having support for domains)
AMQP comes from Advanced Messaging Queuing Protocol. Compared to the protocols that have been presented so far, this protocol is built around queuing. It is one of the most reliable protocols that are on the market and it is the most frequently used protocol for communication between devices – IoT protocol.
It is like a super protocol in comparison with the other 3 and has the best characteristics of each of the ones presented above. All the communication takes place over TCP/IP and one of its very important characteristics is that there’s no loss of data. Each message sent over AMQP will reach its final destination. This is why AMPQ is one of the most reliable protocols.
Imagine the AMQP protocol like a jungle of queues with messages flowing between them. That is how the protocol offers a good point-to-point connection with acknowledged confirmation of each message that is received. This allows AMQP to run over networks that are not reliable and where connection is poor. Having a queuing mechanism behind a protocol, the system doesn’t need to be up all the time.
AMQP tracks all the messages that are sent over the wire and ensures that each message will be delivered. Even in the case of a server failure, or a connection error, the protocol and system is powerful enough to recover the messages and send them again.
On top of this, AMQP supports transactions, giving us the possibility to execute transactions and commits. Based on this feature, AMQP can be used in multiple scenarios and situations. In combination with queuing, multiple communication scenarios can be implemented.
The most important characteristics of AMQP are:
- Reliability (messages are not lost)
- Queuing (full support for queuing)
- Transaction (support for commits)
Each protocol has its own characteristics that are useful in different scenarios. That is why it is impossible to say what the best protocol is. DDS is for real-time communication between devices, MQTT is great when we need to collect telemetry data, XMPP is very simple and perfect for IM scenarios and AMQP is the perfect protocol for connecting devices to backend.
Besides these protocols, there are other hundreds of IoT protocols available on the market. We should keep in mind that there is no perfect protocol and each protocol has its own unique characteristics. When we select the protocol, we should keep in mind all the features we need, from functional to non-functional ones.
Keep in mind that for each business, real time has a different meaning – it can be milliseconds, seconds or even hours in some situations. Based on all business requirements, we will be able to select the protocol that satisfies all our needs.