Internet Of Things (IoT) – Part 3

Author:
Innokrea Team

Date of publication: 2024-01-18

Caterogies: Information

Today we will delve into the more technical aspects of IoT devices and discuss application layer protocols in more detail. What technologies are available, which specific programming packages can be applied, and how do the various IoT-specific protocols differ from each other? All of this today. Welcome to our reading!

IoT – Application Layer

In our last article, we discussed the layered approach in computer networks and how the IoT system works at the network level. Today, we will start with what is most important for programmers from a networking perspective, which is the application layer and protocols such as MQTT and COAP.

IOT

Figure 1: Protocols used in IoT, TCP/IP model, source: fb.com/IoTResearch

If we want to see the trends in IoT application protocols, we can use Google Trends, which indicates the most frequently searched technologies.

IOT

Figure 2 – Google Trends chart

https://trends.google.com/trends/explore?date=today%205-y&q=MQTT,COAP,XMPP,AMQP

It’s worth examining the trends for individual technologies, as there are some differences in interest distribution, especially in countries like China and the USA. However, globally, MQTT is the predominant solution, which we will try to present below.

MQTT in IoT – What Is It and What Is Its History?

MQTT (MQ Telemetry Transport) is a lightweight protocol that was created in 1999 and operates on a publish/subscribe model. It is used for message queuing and is a widely used solution in IoT devices. The MQTT standard defines two types of entities in the network: the client and the message broker. In 2012, one of the most popular open-source brokers, Mosquitto 1.0, was created. In 2013, the widely used cloud-based solution HiveMQ was created. In 2014, an update to the MQTT standard was released as version 3.1.1, and then in 2018, MQTT 5 was introduced.

IOT

Figure 3 – MQTT history, source: hivemq.com

Characteristics of MQTT

MQTT possesses several characteristics that both make it similar to and different from other application layer protocols like HTTP. Some of these characteristics include:

Connection via TCP: MQTT is built on top of the TCP protocol, ensuring that every message sent will reach the intended device. Recently, there has also been an implementation based on the QUIC transport protocol, combining the reliability of TCP with the speed of UDP (MQTT over QUIC).
Reliable Communication over Unreliable Media: MQTT ensures reliable communication even over unreliable media, such as any TCP/IP model access protocol (Wi-Fi, LTE, Ethernet). When a client loses connection due to factors like weather conditions, messages marked with appropriate QoS flags will be cached and sent when the client regains connection with the broker.
Security: MQTT is similar to other protocols like HTTP when it comes to security, which can be achieved through TLS support. Regarding security aspects, MQTT can be transmitted through TLS tunnels (MQTT over TLS), which also includes support for certificates and mutual authentication. MQTT also allows authentication based on login credentials, similar to a regular web application.
Data-Agnostic: MQTT is data-agnostic, meaning it has no restrictions on the type of data that can be transmitted. This allows for the transmission of various data formats, such as JSON or XML. This approach is referred to as a data-agnostic protocol.
Scalability: The publish-subscribe approach in the MQTT communication model is scalable, and the broker itself can be provided in a clustered form. This is the case with solutions like HiveMQ, a cloud-based broker. This is advantageous because in this communication model, the broker is a critical element and a potential single point of failure (SPOF).

MQTT Connection

The connection between a client and a broker begins with the establishment of a TCP connection (if not using QUIC) and then the exchange of MQTT-specific packets.

IOT

Figure 4 – MQTT packets used for managing the connection between a client and a broker, source: Ravi Kishore Kodali, researchgate.net

As seen in the above illustration, MQTT uses several types of messages for communication, which we will briefly describe:

CONNECT: This is the initial message that an MQTT client sends to the broker to establish a connection. It contains essential information such as the protocol version, client identifier, clean session flag, keep-alive interval, user authentication data, and other crucial connection parameters. This message initiates an MQTT session, enabling the client to subscribe to specific topics, publish messages, and actively interact with the broker.

IOT

Figure 5: Contents of the CONNECT message, source: hivemq.com

Last Will Mechanism in MQTT allows the client to specify a message that the broker will publish on a specific topic in the event of an unexpected loss of the client’s connection. The client defines the topic on which the last will should be published and the content of the message. Parameters related to Last Will include:

Topic: Defined by the client, this is the topic on which the message will be published.
Quality of Service (QoS): The QoS level (0, 1, or 2) for publishing on the topic.
Retain Flag: If set to “true,” the message will be retained by the broker after publication on the topic.
Message Content: The message that the client wishes to publish in the event of a connection loss.

CONNACK: The CONNACK message is the broker’s response to the client’s CONNECT message, informing the client whether the connection has been accepted or rejected. In case of connection refusal, CONNACK may also contain an error code indicating the reason.
PINGREQ: This message is sent by the client to initiate a “keep-alive” check with the broker. It serves as a mechanism to confirm whether the connection is still active and responsive. If the broker does not receive a response in the form of a PINGRESP message within a specified keep-alive interval, it may terminate the connection.
PINGRESP: The PINGRESP message is the broker’s response to the client’s PINGREQ message, confirming the client’s request for activity control and affirming that the connection remains active. PINGREQ and PINGRESP are useful for detecting and handling lost connections and ensuring synchronization between clients and the broker.
DISCONNECT: The DISCONNECT message is initiated by the client to safely terminate the MQTT session. It allows the client to inform the broker of its intention to disconnect and enables the session to end in a controlled manner, ensuring resource release and avoiding abrupt disconnection.
PUBLISH: The PUBLISH message is used by an MQTT client to publish a message on a specific topic to the MQTT broker. It includes the topic name and the message content. PUBLISH messages can be sent with different Quality of Service (QoS) levels: 0 (At most once), 1 (At least once), or 2 (Exactly once), depending on the desired message delivery guarantees. The message content can contain various data types, such as sensor readings, status updates, or other information that clients wish to share.
SUBSCRIBE: The SUBSCRIBE message is used by an MQTT client to subscribe to one or more topics and receive messages published on those topics. The client specifies the topics it wants to subscribe to and the desired QoS level for each topic. The broker responds with a SUBACK message, confirming the client’s subscriptions. Once subscribed, the client will receive any messages published on the subscribed topics by other clients.

There are also many other types of MQTT messages such as PUBACK, PUBREC, PUBREL, PUBCOMP, UNSUBSCRIBE, UNSUBACK.

Summary

We hope that today’s post was interesting, especially for technical people. We’ve touched on various aspects of technology related to both programming and computer networks. If you’re interested, we invite you to join us next week as we continue to explore the IoT topic.