## 4 QoS Controller Implementation
### Operational Modes  
The controller is designed so as to work according to three different operational modes. Two modes accept delivery performance constraints directly from the subscribers and set their QoS levels in order to satisfy such constraints, possibly exploring other QoS levels when the performance requirements are largely matched. A third mode works autonomously, aiming at finding the best tradeoff between latency and hitrate for each subscriber. Each operational mode is described by a specific state machine, illustrated in Figure 6 and detailed below:  
* _Latency-constrained mode:_ in many real time and mission critical IoT applications [21], the subscribers have a tight constraint on the maximum delay that can be experienced. This operational mode allows the subscribers to express a latency constraints, \(\hat{\mathcal{L}}\), through a a specific control message transmitted after their connection to the broker. Upon the reception of such message, the controller will control the QoS level  
Figure 4: Message latency in function of the number of retransmissions using different packet error rates in the simulations. Figure 5: Message latency over the number of retransmission using Linear vs. exponential retransmission timeout policy. aiming at maximizing the hitrate achievable by each subscriber, subject to the latency constraint. With reference to Figure 6a, the controller initially sets all subscribers QoS level to 2, which corresponds to the maximum hitrate achievable. Then, at every decision window, the controller evaluates the hitrate \(\mathcal{H}\) and latency \(\mathcal{L}\) of each client as aforementioned. If the estimated latency \(\mathcal{L}\) is greater than \(\hat{\mathcal{L}}\), the controller reduces the subscriber QoS to 1. At the next evaluation window, if the estimated latency is still above the constraints, the level is further reduced to QoS 0. In such a state, the controller also evaluates the current hitrate \(\mathcal{H}\) of the subscribers: if the end to end latency satisfies the constraint by at least \(\Delta_{\mathcal{L}}\) seconds and \(\mathcal{H}\) is below \(1-\Delta_{\mathcal{H}}\), the controller increases the QoS to 1 (we set \(\Delta_{\mathcal{L}}\) and \(\Delta_{\mathcal{H}}\) empirically). At the next evaluation window, the QoS can be still increased to QoS 2 if \(\mathcal{L}\) still satisfies the constraint by at least \(\Delta_{\mathcal{L}}\) and the hitrate \(\mathcal{H}\) is not at its maximum. * _Hirrate-constrained mode:_ to address delay-tolerant scenarios that require a specific amount of hitrate performance, the controller can also be set to work so as to minimize the end-to-end latency subject to a minimum hitrate constraint. The state diagram for this operation mode is illustrated in Figure 6b. In this case, the controller accepts the target hitrate \(\hat{\mathcal{H}}\) during the subscription phase and initially sets the QoS level of all subscribers to 0. Then, it proceeds at evaluating the current hitrate \(\mathcal{H}\) and end-to-end latency \(\mathcal{L}\). If \(\mathcal{H}<\hat{\mathcal{H}}\), the QoS level is increased to QoS 1. At the next round, if the target hitrate is still not reached, the QoS level is increased to QoS 2, where the hitrate reaches its maximum by definition. At each controller round, the QoS level may be decreased from QoS 2 to QoS 1 if the observed average end-to-end latency is below a specific threshold \(\hat{\mathcal{L}}\). Indeed, low end-to-end latency observed at QoS 2 implies good network conditions, therefore suggesting that a decrease in QoS would not impact the hitrate level too much, still reducing the latency and decreasing the number of control messages exchanged between the subscribers and the broker. After reaching QoS 1, the controller may still decrease the QoS to QoS 0 if the hitrate is at least \(\Delta_{\mathcal{H}}\) above the target hitrate and the observed latency is below \(\hat{\mathcal{L}}\), again suggesting good network conditions.