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].

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 our 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 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. We 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.