## 2 Related Works
### Pub/Sub Protocols  
In the publish/subscribe communication pattern, all communications between nodes are made available via a broker. The broker accepts messages published by devices on specific topics and forwards them to clients subscribed to those topics, ultimately controlling all aspects of communication between devices. This allows decoupling message generation and consumption in both space and time, as well as greatly decreasing the complexity of the client side communication. For these reasons, publish/subscribe protocols are of great use in the IoT ecosystem. MQTT is the most popular pub/sub protocol currently. Based on the TCP protocol at the transport layer, MQTT allows a simple communication between devices through a central entity, named the broker, which interconnects clients sending and receiving data, named publishers and subscribers, respectively. MQTT follows the pattern of topic-based publish-subscribe communication models: subscribers can express their interest in a particular topic by issuing an appropriate request to the broker, so to receive updates every time a new message published to that topic is transmitted from a publisher. MQTT requires clients to connect to a broker before publishing messages or subscribing to topics. Each publication and subscription is coupled with a specific QoS level, chosen among three values: QoS level 0 implies fire-and-forget delivery, relying on the underlying robustness of the TCP layer; QoS level 1 refers to an \"at least once\" delivery, with acknowledgments required by the publisher (or to the subscriber) and retransmissions taking place in case the acknowledgment is not received; QoS 2 avoids publication duplicates with a four-way handshake among the publisher and the broker. Apart from this native QoS mechanism, several works have addressed other options for improving the quality of MQTT transmission; in [14], an adaptation framework for N-to-1 periodic communications is presented. The subscriber explicitly transmits to the publishers control messages for changing the publication rate so that the subscriber CPU utilization remains within fixed bounds. Similarly, the work in [15] addresses flow control towards subscribers. A new MQTT control message is introduced, with subscribers explicitly asking publishers to regulate their data emission. The newly proposed control message contains commands such as pause sending,unpause, send with higher rate or lower rate for each topic. Differently, the work in [16] proposes an automatic adaptation of the publication QoS level based on the estimated network RTT. The publication frequency is decreased if an increase in RTT is observed, to avoid network congestion. On the same line, the work in [17] proposes a QoS controller for MQTT in a Electric IoT scenario monitoring a power grid, among field gateways and the broker connecting them. The controller works around an optimization problem which attempts to minimize the weighted sum of packet-loss ratio and delay, which are both modeled analytically. The problem is transformed into a MAB (multi-armed bandit) problem, and solved through reinforcement learning. In detail, each field gateway estimates packet-loss values and transmission delay of each packet and calculates the reward for the current QoS configuration, in order to select the next QoS level to minimize the objective function. Some works have addressed the QoS in different terms: as an example, the work in [18] studied a distributed scenario with multiple MQTT brokers and special devices called gateways in charge of keeping track of the QoS (in terms of latency) between clients and brokers. Clients connect to gateways that select the best broker for them in order to minimize latency and perform load balancing. Finally, very few works have addressed QoS control for the MQTT-SN protocol, the lightweight version of MQTT developed for resource-constrained scenarios.