Priority‑enabled MQTT: a robust approach to emergency event messaging

on the

efficient message delivery is essential in many applications, especially in emergencies.The MQTT standard maintains message transmission dependability by defining three quality-of-service (QoS) levels, namely, 1. QoS-0: At most once, 2. QoS-1: At least once, and 3. QoS-2: Exactly once.
However, the current MQTT for IoT does not prioritize processing emergency messages.The transmission of information regarding a patient's abFCFS state for medical purposes and an emergency requiring an emergency stop of related field facilities when an abFCFSity occurs in a specific facility at a manufacturing site are representative examples that should be handled first and foremost [7][8][9][10].We also require historical data for analytics and reporting.Most MQTT brokers do not include a built-in mechanism for saving MQTT data to a database.
This paper provides a way to overcome the presented IoT protocols' difficulties and limitations.The MQTT protocol in the proposed approach coordinates the publishing of messages between publishers based on specified priority queues, allowing emergency messages to be sent on time and reducing message latency.The proposed method can also save MQTT data from sensors to a MySQL database for later analysis and reporting.

Contributions
The contributions of this paper are listed below: 1. Introducing a prioritized MQTT emergency message delivery system to ensure highpriority transmission.2. Implementing a message storage mechanism in the MySQL database, enabling comprehensive analysis of stored data.3. Estimating and comparing the end-to-end delay between the proposed prioritized approach and the conventional FCFS approach, providing insights into latency improvements.4. Assessing and comparing the total time required to publish messages via Urgent, Critical, and FCFS queues, highlighting the efficiency of the proposed prioritization.5. Evaluating and comparing the mean response time of messages, offering a comprehensive understanding of the performance differences between the proposed and FCFS approaches.
6. Analyzing and comparing mean jitter at the subscriber end in both the proposed prioritized approach and the FCFS approach, contributing to a thorough examination of message delivery stability.

Paper organization
The rest of the paper is formulated as follows: The related works to improve the priority mechanism for the MQTT protocol are discussed in the "Related work" section.
The "Problem statement" section discusses the problem statement and objectives.The "Proposed system" section discusses the proposed system with architecture and analytical analysis of queues.In the "Results and discussion" section, Results and Discussions for existing and proposed approaches are compared and analyzed.Finally, in the "Conclusions" section, the conclusion of the paper and future work is presented.

Related work
This section discusses related works that use MQTT communication to improve the priority feature.The authors of [11] proposed an algorithm to prioritize messages using a multiscanned priority message sorting algorithm, with Mosquitto broker and smart factory applications in IoT as examples.To reduce the latency of the data packets needed for time-sensitive applications, the authors of [12] described the prioritization of the traffic information gathered using sensors in a gateway for the MQTT-SN.To reduce uplink traffic load, the developers of [13] suggested the Backoff method, which applies an exponential delay factor to suspect publishers.Additionally, depending on the recently determined frequency rate, a priority scheduling algorithm is offered to classify publishers as high or low priority.
In [14], a technique for detecting out-of-order notifications on top of an existing topicbased Event Notification Service is presented.The results demonstrate that events published on various subjects are either sent in the same sequence to all subscriber clients of those topics or labeled as out-of-order.The authors of [15] suggested a novel way to enhance the capabilities of MQTT by transmitting Urgent messages first.The Mosquitto broker is modified to build a "U-Mosquitto" broker capable of processing emergency messages.
The paper [16] explores existing literature on methods for assigning priority to MQTT messages and introduces an approach for identifying and processing Urgent messages in MQTT applications.The focus is prioritizing specific messages from Critical sources in IoT environments.The work in [17] utilizes Software Defined Networking, particularly the OpenFlow protocol, to enforce temporal behavior through network reservations.Extensive emulation and implementation results demonstrate the approach's feasibility, showcasing adequate segregation and prioritization of time-sensitive MQTT traffic.
Uchida et al. [18] introduced assigning priority values to IoT data based on abFCFSity, storing them in broker node priority queues.The experiments with a prototype system demonstrate the effectiveness of the Enhanced MQTT method.
The conventional methods to enhance MQTT communication priority involve modifications to the MQTT protocol packet structure or broker configuration.Some papers propose approaches without experimental validation.In contrast, the proposed method introduces a priority enhancement mechanism in MQTT communication without altering the standard structure.The practical approach validates the proposed method across parameters such as delay, jitter, response time, and total time taken.Results demonstrate that the proposed method responds rapidly to emergencies, showcasing its effectiveness in real-world scenarios.The approach not only preserves the integrity of the MQTT protocol but also ensures a reliable and swift response in Critical situations, addressing the limitations of existing methods.

Problem statement
The problem statement of this work is to enhance the MQTT message delivery between publisher and subscriber in emergency events by supporting priority support.The objectives of this work include: 1. To provide priority support by creating virtual queues to enhance message delivery.2. To compare average response time and total time taken by Critical, Urgent, and FCFS queues.3. To compare end-to-end delay and mean jitter of Critical and FCFS queues.

Proposed system
This section presents the proposed system to enhance MQTT message delivery in emergency events using priority support.Figure 1 shows the proposed architecture for MQTT communication.This work is implemented using an application where users can publish the messages in the three provided topics: Urgent, Critical, and FCFS.The highest priority is the Urgent queue to transmit the messages immediately.Messages in the Critical queue are less Urgent than those in the Urgent queue but still demand high reliability.Messages saved in the FCFS queue are the same as in the current MQTT standard.Figure 2 depicts the flow of the proposed architecture.The MQTT publisher client can publish messages on Urgent, Critical, and FCFS topics.Upon receiving messages, the RabbitMQ broker classifies the messages based on topics and assigns respective predefined priority queues.The published messages are stored in a database for further analysis.Due to the highest priority, the Urgent queue messages are published to the consumers first, followed by the Critical and then the FCFS queue.
The proposed approach has the following benefits: 1. Delivery of MQTT messages in emergency events: When managing emergencies in IoT and messaging apps, it is crucial to prioritize and consider some vital messages.This is fixed by establishing distinct virtual queues for various message types dependent on the importance of the message.2. Resolving Bottleneck problems: Some applications may use an exceptionally high volume of messages; under these circumstances, the brokers may experience bottleneck issues.This circumstance typically occurs in publisher-subscriber-based applications when a single client subscribes to several topics (using wildcard topics).In these situations, we might observe a decline in the network's processing power and bandwidth in the computers that host these MQTT clients.The MQTT data to the RabbitMQ broker's AMQP queue is temporarily transferred to fix this.

Storing MQTT data into database:
For Sensors to publish data to their Subscribers, MQTT is an excellent protocol.However, historical data is necessary for analytics and reporting.Most MQTT brokers do not have any built-in functionality for saving MQTT data to databases.The suggested method enables the database storage of MQTT data.Figures 3 and 4 depict the messages stored in the Urgent and Critical queues for further analysis.

Analysis of queues
Consider an M/G/1 queue where the messages are divided into three priority classes: • Class 1 has the highest priority, and class i has the lowest priority.
The notations used in the analysis are listed below in Table 1.In the same method, we deduce the Pollaczek-Khinchinin mean findings for the Urgent (highest priority) queue as expressed in Eq. ( 1).(5

C(i)
Mean number of waiting queue-i messages in the queue.

W(i)
Mean waiting time of queue-i messages.
The load of queue i, ρ i = i μi .

Ri
The mean residual service time in the broker upon arrival of messages.
Let us compute the average stay time T i of class − i messages.It is split into three parts.
1.The customer's own mean service time μi .2. The average time it takes to serve messages in classes 1, ..., i ahead in the queue: The mean-time it takes to serve messages in higher classes 1, ..., (i − 1) that comes while the class-i message is still in the system.
We obtain the equations below using the Pollaczek-Khinchinin mean value formula and Kleinrock's conservation theorem.

Experimental
Wireshark [19] is crucial in measuring the end-to-end delay between MQTT publish and AMQP received timing.The study involves the transmission of messages through three different queues with priority support and a single queue using the FCFS approach.Wireshark, a packet analyzer, captures and analyzes the packets exchanged between clients and the broker during message transmission.By inspecting the packet data, Wireshark enables the calculation of end-to-end delay for each scenario.Specifically, ten messages are published to each topic under both prioritized and FCFS conditions, allowing for a detailed examination of the impact of the proposed prioritization approach on the temporal aspects of message delivery.This explicit use of Wireshark ensures accurate and comprehensive data collection, contributing to a more detailed analysis of the experimental results.
1. Time T 1 is the mqtt publish(mqtt ping request) timing in the wireshark.2. Time T 2 is the amqp receive(amqp connection start with ack) timing in the wireshark Considering the Adapter for loopback traffic transmit(wireshark capture) timestamps T 1 and T 2 , end-to-end delay for each message is measured as:

Results and discussion
The experimental findings of this paper are described in this section.The experimental results show the importance of separate queues for emergency events.Figure 5 depicts the total time taken via three queues.It is evident that the time taken by the FCFS approach is more.For more extended communication, it is always better to have separate queues to avoid delay at the receiver end. Figure 6 depicts the mean end-toend delay in publishing messages through three queues.The delay is more for FCFS in comparison to Urgent and Critical queues.Figure 7 depicts the mean variation in delay in publishing messages via three queues.The mean jitter is more for the FCFS approach as bandwidth is depleted, then data packets must be reassembled at the receiver's end, adding to the amount of jitter.Figure 8 depicts the mean response time of publishing messages through three queues.FCFS requires more time to publish messages.The Urgent and Critical queues outperform the FCFS queue in all the results.This is because all messages are published via the FCFS queue, which requires more computation, bandwidth, and adding more to the jitter.Because of all these reasons, a separate queue for emergency events is necessary for extended MQTT communication.

Conclusions
In a publish/subscribe system, prioritizing the emergency messages across topics is a challenging issue that, if not addressed, could negatively influence several application types that depend on it.This paper described a new strategy for supporting high-priority messages in IoT for fast and reliable delivery of messages without modifying the MQTT standards.The proposed method queued communications based on priority levels, such as Urgent, Critical, and FCFS.Furthermore, the proposed method saves the messages in the MySQL database for later analysis.We experimentally implemented the proposed approach using the RabbitMQ message broker, Wireshark, and Python to evaluate its performance.We compared the proposed method and the existing system based on end-to-end delay, total time, response time, and jitter.The outcome shows that the proposed approach performs better than the current FCFS approach.

Fig. 2
Fig. 2 Flowchart of MQTT message delivery with priority support

Fig. 5 Fig. 6
Fig. 5 Total time taken to publish messages by Urgent, Critical, and FCFS queues