In the article before this one, we reviewed the main aspects of network protocols in the IoT, as well as the main communication protocols being used until now. In this article, we’ll switch gears and talk about the data communication protocols. These data communication protocols are those that work in the low levels of the Open Systems Interconnection (OSI) model, without the need for an Internet connection.

IoT Data Communication Protocols

Below you’ll find a brief breakdown of the some of the different IoT data protocols, namely:

Message Queue Telemetry Transport (MQTT) 

Designed to be lightweight, so it can work in very low bandwidth networks, MQTT allows communication between nodes in both reliable and unreliable networks. MQTT follows a publish/subscribe architecture, meaning that there are nodes (brokers) that make the information available, while others (clients) can read the available information after subscribing by accessing the corresponding URL.

A use case of MQTT is in a smart factory where there are temperature sensors installed along with the production plant. The installed sensors will connect to the MQTT broker and will publish the data within sensor topics, as follows:

sensors/temperature/assemblyLineInit

Afterward, the MQTT clients, which can be of several types and quantities, will subscribe to the same topic in order to read the temperature data. An example of an MQTT architecture can be seen in Figure 1. 

MQTT's publish/subscribe architecture.

Figure 1. MQTT’s publish/subscribe architecture. Image used courtesy of MQTT

In addition, MQTT defines three levels of quality of service, depending upon the reliability, from lowest to highest:

  • Level 0: there is no guarantee of the message delivery.
  • Level 1: the delivery is guaranteed, but it is possible to receive duplicate messages.
  • Level 2: the delivery is guaranteed and there will be no duplicates.

HyperText Transfer Protocol (HTTP)

This protocol has been the origin of data communication for the World Wide Web (WWW), so logically it is being used in the IoT world. However, it is not optimized for it because of the following:

  • The HTTP is made for two systems communicating to each other at a time, not more, so it is time and energy-consuming to connect several sensors to get information.
  • The HTTP is unidirectional, made for one system (client) to be sending one message to another one (server). This makes it quite hard to escalate an IoT solution.
  • Power consumption: HTTP relies on Transmission Control Protocol (TCP), which requires a lot of computing resources, so it is not suitable for battery-powered applications.

Constrained Application Protocol (CoAP)

CoAP is a web transfer protocol to be used with limited networks with low bandwidth and low availability. It follows a client/server architecture and is built similarly to HTTP, supporting the REST model: servers make resources available with an URL, and clients can make requests of types GET, POST, PUT and DELETE.

The CoAP communication links are 1:1 and UDP-based, so the delivery is not guaranteed. CoAP is made to work in highly congested networks, where nodes do not have a lot of intelligence and are not always working. 

Data Distribution Service (DDS)

Similar to MQTT, DDS follows a publish-subscribe methodology, with the main difference being that there are no brokers. It means that all publishers (i.e., temperature sensors) and subscribers (i.e., mobile phones) are all connected to the same network. This network is known as Global Data Space (GDS) and it interconnects each node with all the other ones to avoid bottlenecks. An example of the DDS GDS can be seen in Figure 2. 

A DDS Global Data Space.

Figure 2. A DDS Global Data Space. Image used courtesy of the DDS Foundation

Furthermore, any node can leave or join the network, since they are dynamically discovered.

WebSocket

Linked to the HTTP protocol, the WebSocket technology establishes a TCP connection between a browser and a server, and then both of them exchange information until the connection is closed. Figure 3 shows a high-level comparison between HTTP and WebSocket.

Comparison between HTTP and WebSocket.

Figure 3. Comparison between HTTP and WebSocket. Image used courtesy of Scaleway

Although this protocol can be seen as an improvement of the HTTP connection, the WebSocket is still very overloaded and heavy for IoT applications.

Advanced Message Queue Protocol (AMQP)

In the beginning, AMQP was not initially created for IoT applications, but for banking environments. AMQP accepts publish/subscribe architectures, as well as request/response types. It is TCP-based, so delivery is guaranteed, as well as acknowledgment, which makes this protocol reliable, with the consequent overhead message reliability.

Compared to MQTT, AMQP offers two Quality of Service levels:

  • At most once: the sender does not wait until having an acknowledgment from the receiver to delete a message.
  • At least once: for each message, the sender will receive an acknowledgment from the receiver before deleting the message. In a case where the acknowledgment is lost, the message is re-sent.
  • Exactly once: the messages are sent only once. It requires special coordination between the sender and the receiver.

Extensible Messaging and Presence Protocol (XMPP)

It is based on Extensible Markup Language (XML) and in the past, it was known as Jabber. It is an open-source, decentralized, secure protocol to exchange XML messages.

A characteristic factor of XMPP is its addressing method and how nodes are identified. It uses a Jabber ID with the format jabberID@domain.com, which allows two nodes to interchange information regardless of the distance between them. 

OPC Unified Architecture (OPC UA)

It is a standard made for industrial communication, strongly oriented to guarantee interoperability between manufacturers, operating systems, and programming languages. The OPC foundation reported that many industrial vendors are currently (as of 2022) adopting the OPC UA as the open standard.

All in all, the OPC UA is a transport-agnostic protocol, so it supports both of the previously used architectures: request/response (such as WebSocket or HTTP), as well as the publish/subscribe (such as the MQTT).