Messaging Queuing Telemetry Transport Characteristics

Version	Summary	Created by	Modification	Content Size	Created at	Operation
1		Jawad Ali	--	2075	2022-12-29 10:17:19	\|
2	layout	Camila Xu	Meta information modification	2075	2022-12-30 01:18:57	\|

This entry is adapted from the peer-reviewed paper 10.3390/s22249751

The Messaging Queuing and Telemetry Protocol (MQTT) is a subscription and publishing service-based communication with a centralized server. MQTT is used in manufacturing industries due to its open-source moldable nature, petroleum and natural gas, health, weather, home automation, smart farming, smart metering, remote, etc. In this research, a QoS-0 based MQTT is developed in such a manner that the transparent MQTT protocol uses Transmission Control Protocol (TCP) based connectivity with various rules for retransmission of contents if the requests are not entertained for a fixed duration. The research explores ways to improve the overall content delivery probability. The parameters are examined over transparent gateway-based TCP network after developing mathematical model for the proposed retransmission based mutant QoS-0.

QoS MQTT IoT end-to-end service assurance smart cities

1. Introduction

Physically separated and logically connected applications on distributed nodes are mostly used while developing smart cities, employing the IoE ^[1]. Such an application may include but is not limited to inventory and stock management, health and security, the entertainment industry, information segregation, information exchange, information integrity, autonomous functionality, transportation and traffic system, energy and smart gird, industrial manufacturing and process engineering, supply chain management, etc. The mode of communication can be Deice to Device (D2D) and Device to Server (D2S). D2D is based on the mechanism where devices are directly exchanging information for a certain process or service. On the other hand, in D2S or Server to Device (S2D), the distributed nodes are communicated with a server and the information exchange is on-demand. Integrated services often use a backbone server for an information exchange for various reasons.

For acquiring the optimum functionality of smart cities, a server must possess the required information or instructions that are timely needed by the connected devices ^[2]. Thus, for the stated purpose, abridged devices use various protocols, varying from application to application. The majority of these protocols serve as the foundation of the Internet of Things (IoT) and Internet of Everything (IoE). The Constrained Application Protocol (CoAP) is used for Machine to Machine (M2M) communication in smart energy and building automation. The Messaging Queuing and Telemetry Protocol (MQTT) ^[1] is used in manufacturing industries due to its open-source moldable nature, petroleum and natural gas, health, weather, home automation, smart farming, smart metering, remote, etc. Web Socket Protocol has a variety of uses such as in social media feeds, multiplayer games, collaborative editing/coding, clickstream data, financial tickets, media chats, location-based apps, online education, etc. ^[3]. The Data Distribution Service (DDS) is used on the top of edge devices/sensors for supervision, integration, and process control. Similarly, the Extensible Messaging and Presenting Protocol (XMPP) is widely employed in content syndication, collaboration tools, geolocation, file sharing, gaming, remote systems control, cloud computing, etc. These application protocols are the extensively used available protocols in the development of smart cities ^[3].

While talking about MQTT-based connectivity, it is worth noting that MQTT is used on the top of IEEE 802.15.4 and TCP/IP ^[4]. MQTT requires less power compared to other employed protocols for a range of applications where the power consumption accounts for the network performance. MQTT uses a traditional subscription and publishing-based mechanism, hence the bandwidth efficiency is managed up to a certain level.

1.1. Architecture

MQTT is a subscription and publishing service-based communication with a centralized server ^[1]. The MQTT-based network is comprised of three basic logical formations, as shown in Figure 1. The transparent gateway has one node connection that is bridged with a remote MQTT server. The aggregating gateway connects local network nodes using a singular gateway to a remote MQTT server. Hybrid gateways route packets from multiple nodes and use mesh topology for connecting with the remote MQTT server ^[2]. The above-stated gateway formations are opted for various IoT scenarios. For example, a low-density network with large bandwidth requirements may employ the transparent gateway. This way, a single actuator–single sensor-based application may be run with a speedy response ^[1].

Figure 1. Logical Formation of MQTT gateways in IoT for various applications (a) Transparent Gateway MQTT, (b) Aggregated Gateway MQTT and (c) Hybrid Gateway MQTT.

Each stated formation has its own facilities, uses and drawbacks. Aggregated gateways are not employed for the applications of smart cities when the nodes are geographically dispersed. It is because several nodes might be acting as actuators and controlling the nodes from physically separated locations, and this means that different MQTT gateways are used that makes the IoT network’s formation transparent (see. Figure 1a). Aggregated gateways have the limitations of poor congestion control and packet loss as well as a single point failure issue ^[1], directly degrading the performance of the applications of smart cities. On the other hand, a hybrid gateway, as in Figure 1c, uses multiple paths for communication with the server that will lack the concept of modularity for communication with a remote server on the Internet in researchers' case. A Virtual Machine, while generating data traffic for the experiment, can only provide transparent gateway-based communication. Thus, the work uses the IoT network formation based on the transparent gateway-based client to server connectivity. The rest of the rules and assumptions are listed below.

The MQTT subscribe/publish-based communication requests to the server are collectively treated as request–acknowledge messages.
The end node uses DNS for address resolution in case of connectivity with the remote server that poses a constant delay.
The SUBSCRIBER nodes as well as the PUBLISHER nodes follow an identical mechanism for communication with the server, thus the request flows through the same pathway.
The TCP-based communication “fire and forget after n attempts” strategy is considered for all the network nodes that follows retransmission-based QoS-0.
The remote server holds two sets of request queues. The published contents’ queue holds the data for the Tcnt interval and the subscribers’ requests are held for an interval denoted by Treq. These holding intervals Thold are thus defined by the storage capacity of the MQTT server as well as the connected nodes ^[2].
QoS-1, that is based on “at least one time delivery”, and QoS-2, based on “exactly one time delivery”, are covered in ^[3].

1.2. Problem Statement and System Model

The services that are provided in smart cities are categorized by latency in the information exchange, bandwidth and packet loss. For example, the data communication networks that are used in a hospital environment must be in accordance with the severity of the patient’s condition ^[4]^[5]. Moreover, it may have several levels and priorities of information exchange w.r.t parameters that are being exchanged. For example, a single patient may require multiple services, each having different sets of the data transmission rate and data update rate. Similarly, the end-to-end delay for services at a normal condition may be compromised. For example, a remote weather station may exchange weather-related information with minimum assurance for its delivery in normal weather ^[1]. The reliability parameters need an upgraded communication scheme when the situation is of an elevated priority. For example, adverse weather condition may need an immediate data sharing service for smart decision making ^[6].

The research aims to assure an adequate reliability in terms of the content delivery and guaranteed end-to-end delay in the development of smart cities’ applications. Such applications use data from multiple sources/sensors on a single topic or on a range of topics for proper functioning that varies from application to application. The PUBLISH requests from sensing nodes are considered unique while receiving data, irrespective of their physical or logical situation ^[6]. Thus, the events are considered to have a mutually exclusive w.r.t delivery time or bandwidth requirements. Likewise, the logging of data on the centralized server always put a constrain on the residing time of the data as well as the queue size. Researchers may term this as the packet expiry time or packet replacement time on the server. A single topic data may be required by different subscribers for a range of uses. For example, data from traffic junctions may be used for the re-routing of vehicles or for controlling traffic lights.

QoS-0, QoS-1 and QoS-2 are shown in Figure 2. In Figure 2, PUBLISH means post data to the MQTT Broker, and PUBREC means Publish has been Received, confirming the PUBLISH operation to a server in QoS-2 ^[3]. After receiving PUBREC, the sender sends a “Publish Release” request as PUBREL to tell the server that it has discarded the sent data from a local stack. The server also stored the packet identifier at this stage to avoid the processing of duplicate packets. The server responds with a confirmation packet of a Publish Complete (PUBCOMP) message after PUBREL. This way, the sender can repeat the process with new data. According to these QoS levels, either the packet is lost, or the packet is confirmed by an acknowledgement from the MQTT Broker server. The work proposes a one step ahead solution to improve the QoS of the MQTT-based smart cities’ connectivity applications. The MQTT protocol-based nodes are configured for a transparent gateway-based application. The nodes are running the simple process of publishing and subscribing services that are identical in nature. The work considers the number of connected nodes, the PUBLISH and SUBSCRIBE request rate, the time of content holding by the server and gateway for the retransmission-based QoS-0 MQTT IoT, for a system performance improvement in terms of the reliability and end-to-end delay. Here, a mathematical formulation is provided for achieving a guaranteed QoS by a varying number of retransmission attempts.

Figure 2. QoS-0-, QoS-1- and QoS-2-based MQTT broker with message delivery, duplication and storage status on the publishing node.

2. MQTT Characteristics

MQTT is light weight and content-oriented protocol. Locally, MQTT can be used for the IoE and IoT, i.e., amongst IP-less as well as IP-based network nodes. The explored case uses the wired network of IP-based nodes that are connected to a local gateway on a single node–single gateway scheme basis. Mosquito clients are deployed on local nodes in an emulated environment for real world connectivity by providing the NAT to LAN bridge with the Internet. This provided real world environment, sufficient to receive effective and authentic readings of the parameters that are under observation.

2.1. Retransmission-Based QoS-0 MQTT Mutant Protocol

By the mechanism of retransmission in the QoS-0, the instantaneous delivery probability, that is explored for the static network characteristics in ^[5], is affected. The requestee node retransmits the TCP/IP-based request if the packet is either lost between the node and gateway or on the Internet. Additionally, the gateway data buffer as well as the request queue at the server are kept of a minimum size. It is for the fact that the MQTT gateways usually have a limited cache for storing data. The queue is only handled at the server, so the gateway limitations are traded off by retransmit protocol. This process makes the midway delays static for usual processes and define (make constant) it instantaneously.

2.2. Proposed Asynchronous MQTT

Researchers have assumed that one node is posting for a single topic and multiple topic-based posting is assumed to be separate nodes and separate events. The rest of the communication scheme between the publisher and subscriber node is explained in the following steps, as in Figure 3.

Figure 3. End-to-end delay and packet travel system model for QoS-0 retransmit Mutant MQTT.

Step 1: The end node connects with the gateway using the CONNECT/CONNACK mechanism and then researchers publish the contents using the publish–retransmit mechanism.
Step 2: The received data from the end node is transmitted by the gateway to the remote MQTT server as CONNECT/CONNACK and then a publish–retransmit basis over a reliable TCP/IP wired network.
Step 3: The end user connects to the gateway using the CONNECT/CONNACK mechanism as in Step 1 and then the same end user registers with the gateway using SUBSCRIBE and SUBACK for an already available topic on the server.
Step 4: The subscriber side gateway registers the end user with the server using the connect request followed by the subscribe request that is acknowledged by the server as the SUBACK.
Step 5: The server sends the available date of the subscribed topic to the end user side gateway via the Internet using PUBLISH and PUBACK instructions.
Step 6: The gateway on the end user’s side fitches the data to the end user using PUBLISH and PUBACK.

The above-stated steps pose a certain probability of failure for a send and forget mechanism. This send–retransmit and forget mechanism is used for the asynchronous IoT system in Figure 3. The availability of the data on the server is arguable.

References

Khriji, S.; Benbelgacem, Y.; Chéour, R.; Houssaini, D.E.; Kanoun, O. Design and implementation of a cloud-based event-driven architecture for real-time data processing in wireless sensor networks. J. Super Comput. 2022, 78, 3374–3401.
Andrew, B.; Rahul, G. OASIS MQTT Version. Available online: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html/ (accessed on 1 July 2021).
Handosa, M.; Gračanin, D.; Elmongui, H.G. Performance evaluation of MQTT-based internet of things systems. In Proceedings of the Winter Simulation Conference (WSC), Las Vegas, NV, USA, 3–6 December 2017; pp. 4544–4545.
Kavitha, K.; Suseendran, G. Priority based Adaptive Scheduling Algorithm for IoT Sensor Systems. In Proceedings of the International Conference on Automation, Computational and Technology Management (ICACTM), London, UK, 24–26 April 2019; pp. 361–366.
Pham, C.; Bounceur, A.; Clavier, L.; Noreen, U.; Ehsan, M. Radio channel access challenges in LoRa low-power wide-area networks. In LPWAN Technologies for IoT and M2M Applications; Academic Press: Cambridge, MA, USA, 2020; Volume 1, pp. 65–102.
Govindan, K.; Azad, A.P. End-to-end service assurance in IoT MQTT-SN. In Proceedings of the 12th Annual IEEE Consumer Communications and Networking Conference (CCNC), Las Vegas, NV, USA, 9–12 January 2015; pp. 290–296.

© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.

Upload a video for this entry

Information

Subjects: Engineering, Electrical & Electronic

Contributors MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to https://encyclopedia.pub/register :

Jawad Ali

Mohammad Haseeb Zafar

Chaminda Hewage

Raheel Hassan

Rameez Asif

View Times: 473

Update Date: 30 Dec 2022

Table of Contents

Video Upload Options

Confirm