An Introduction to IoT Protocols

Across the globe, billions of devices are today communicating and exchanging data with each other, thanks to the Internet of Things (IoT). IoT communication protocols protect and ensure security to the data being exchanged between these devices. This article introduces the most popular protocols in use today.

The IoT system can function and transfer information only when devices are online and safely connected to a communications network. This is where IoT standards and protocols make an entry. IoT devices can be connected either using an IP or a non-IP network. IP network connections are relatively complex and require increased memory and power from IoT devices, although range is not a problem. On the other hand, non-IP networks demand relatively less power and memory but have a range limitation.

IoT protocol architecture
IoT architecture depends on its functionality and implementation in different sectors. The basic process flow, on which IoT is built, has two important architectures — the 3-layer architecture and 5-layer architecture.

3-layer IoT architecture: The 3-layer architecture is the most basic one. It comprises three layers, namely, the perception, network and application layers.

• The perception layer is the physical layer, which includes all the smart sensor-based devices that collect the data from the environment.
• The network layer includes all the wireless and the wired communication technologies, and is responsible for providing connections between the devices and the applications of the IoT ecosystem. The data is then passed on to the application layer.
• The application layer is accountable for delivering application-specific services to the user. It defines various applications in which IoT can be deployed, like smart homes, cities, and health.

5-layer IoT architecture: The 5-layer architecture is an extension of the three-layer architecture with the addition of two more layers – the processing and business layers. The perception and application layers work in a similar manner as in the 3-layer architecture.

• The transport layer carries the sensor data from the perception to the processing layer and vice versa using networks such as wireless, Bluetooth, 3G, RFID, and NFC.
• The processing layer or middleware layer stores, analyses, and processes large amounts of data that come from the transport layer, utilising many technologies such as databases, cloud computing, and Big Data processing modules.
• The business layer manages the whole IoT system, including applications, businesses, and user privacy.

Types of IoT connections
An IoT system has four types of transmission channels for data communication.

Device-to-device (D2D) communication allows the devices located in close proximity to communicate with each other using Bluetooth, ZigBee, or Z-Wave protocols. To establish a connection without a network is possible through a D2D connection.

Device-to-gateway communication connects devices using an intermediary platform. Gateways serve two main functions – first, to consolidate data from sensors and route it to the relevant data system, and second, to analyse data and if any problems are found, return it back to the device.

Gateway-to-data systems communication is the data transmission from a gateway to the appropriate data system.

Communication between data systems is within data centres or clouds. For this type of connection, protocols should be easy to deploy and integrate with existing apps. They should have high availability, capacity, and reliable disaster recovery.

There are two types of IoT protocols.
Network layer protocols: IoT network protocols connect medium to high power devices over the network. End-to-end data communication within the network is allowed using this protocol. HTTP, LoRaWAN, Bluetooth, Zigbee are a few popular IoT network protocols.

IoT data protocols: IoT data protocols connect low power IoT devices. Without any Internet connection, these protocols can provide end-to-end communication with the hardware. Connectivity in IoT data protocols can be done via a wired or cellular network. MQTT, CoAP, AMQP, XMPP, DDS are some popular IoT data protocols.

IoT protocols and network standards
There are many IoT protocols available for different applications and requirements. However, each has its own advantages and disadvantages for different IoT scenarios. Some of the most widely used IoT protocols are discussed here.

Message queue telemetry transport (MQTT) protocol
This open source publish/subscribe messaging transport protocol is very lightweight and ideal for connecting small devices to constrained networks. It was designed to work in low-bandwidth conditions, such as sensors and mobile devices, on unreliable networks. This capability makes it the most preferred protocol for connecting devices with small code footprint, as well as for wireless networks with varying levels of latency due to bandwidth constraints or unreliable connections. It works on top of transmission control protocol/Internet protocol (TCP/IP) to provide reliable delivery of data. MQTT has three main components:

• Subscriber
• Publisher
• Broker

The basic workflow of this protocol involves the publisher being responsible for generating and transmitting information to subscribers through a broker. The main function of the broker is to ensure security by checking the authorisation of subscribers and publishers. This protocol is preferred for IoT devices because it provides well-organised information routing functions to small, cheap, low memory, power devices and low bandwidth networks. To ensure message reliability, MQTT uses three levels of quality of service (QoS).

• QoS0 (At most once): This is the least reliable but the quickest mode. The message is sent without any confirmation received.
• QoS1 (At least once): Ensures that the message is delivered at least once, even if duplicate messages may be received.
• QoS2 (Exactly once): This is the most reliable but also the most bandwidth-consuming mode. Duplicate messages are controlled to ensure that it gets delivered only once.

MQTT is a bi-directional communication protocol, where the clients can produce and consume data by publishing messages and subscribing to topics. Two-way communication enables IoT devices to send sensor data and simultaneously receive configuration information and control commands. Through MQTT, encrypting messages using TLS and verifying clients using modern authentication protocols becomes much easier.

Constrained application protocol (CoAP)
CoAP is a Web transfer protocol for constrained devices and networks in IoT. It can be implemented over a user datagram protocol (UDP), and is designed for applications with limited capacity to connect using light-weight machine-to-machine (LWM2M) communication — such as smart energy and building automation. LWM2M allows remote management of IoT devices, and provides interfaces to securely monitor and regulate them. CoAP architecture is based on the famous REST model, where servers make resources available under a URL, and clients access these resources using methods such as GET, PUT, POST, and DELETE. The CoAP and HTTP protocols have many similarities, with the difference that CoAP is enhanced for IoT, and more specifically for M2M. It has low overhead, along with proxy and caching capabilities, and exchanges messages asynchronously. The architecture of CoAP is divided into two main categories: messaging, which is responsible for the reliability and duplication of messages; and request/ response, which is responsible for communication.

The message layer is on top of the UDP, and is responsible for exchanging messages between the IoT devices and Internet. CoAP has four different types of messages — confirmable, non-confirmable, acknowledgment and reset. A confirmable message (CON) is a reliable message when exchanged between two endpoints. It is sent over and over again until the other end sends an acknowledge message (ACK). The ACK message has the same message ID as that of a CON. If the server faces issues managing the incoming request, it can send back a reset message (RST) instead of an ACK. For exchanging non-critical messages, unreliable NON messages can be used, where the server does not acknowledge the message. NON messages are assigned message IDs to detect duplicate messages.

Request/response is the second layer of the CoAP abstraction layer, which uses CON or NON messages to send requests. In scenarios where a server can respond immediately, a request is sent using a CON message, with an ACK message containing the response, or the error code is sent back by the server. The request and the response both have the same token, different from the message ID. In places where the server cannot respond immediately, it sends an ACK message with no content as the response. Once the response is ready, a new CON message containing the response is sent back to the client and the client acknowledges the response received.

Advanced message queuing protocol (AMQP)
AMQP is an open standard application layer protocol designed for higher security, reliability, easy provisioning, and interoperability. It is a connection-oriented protocol, which means the client and the broker need to establish a connection before they transfer data because TCP is used as a transport protocol. AMQP offers two levels of QoS for reliable message delivery — unsettle format (similar to MQTT QoS0) and settle format (similar to MQTT QoS1). The main difference between AMQP and MQTT standards is that in AMQP the broker is divided into two main components — exchange and queues. Exchange is responsible for receiving publisher messages and sending them to queues. Subscribers connect to those queues, which basically represent the topics, and receive the sensory data whenever they are available.

Data Distribution Service (DDS)
DDS is a middleware protocol for data-centric connectivity from the object management group, which provides low-latency, data connectivity, extreme reliability, and a scalable architecture for business and mission-critical IoT applications. This protocol supports multicasting techniques in data transmission and high-quality QoS in small memory footprint devices and applications. The messaging model in DDS consists of two interface layers — data-centric, publish-subscribe (DCPS) and data local, reconstruction layer (DLRL). The DCPS layer is responsible for binding the values of data objects within an application during the publish/subscribe process. The DLRL is an optional layer used for integrating DDS at the application level.

Table 1: A comparative analysis of IoT protocols

There are two main constructs in DCPS — publisher with DataWriter and subscriber with DataReader. A publisher uses the DataWriter to bind values of data objects for each defined data type. It is responsible for data distribution while adhering to the QoS policies, if any. The DataWriter describes the data that requires publishing when an application needs to write data associated with data objects. A subscriber receives published data, based on a predefined set of QoS policies, from an application. An application uses a DataReader attached to a subscriber to retrieve the data from the latte. It subscribes to data described by a DataReader, which is provided by a known subscriber. Publishing and subscribing to data objects is done by using topics. A topic is associated with a name, data type and one or more QoS policies related to the data. The QoS policies are often used to manage how the data is distributed in the messaging model. DDS provides 23 different QoS levels with features such as security, durability, reliability, and many others. Figure 7 presents a high-level overview of the communication model of the DCPS layer in DDS.

Basic similarities among the several IoT messaging protocols that exist today (Table 1) suggest that they have the potential to coexist throughout the design and deployment of IoT systems. Given the diversity among IoT device types and the protocols they can support, it is not rare for IoT systems to employ several protocols for IoT data exchange. Since messaging protocols are key components for the connectivity of IoT devices, understanding their strengths and weaknesses is important while choosing an appropriate one.