## 4 QoS Controller Implementation  
The QoS controller has been designed to run on board the broker, leveraging its central role in the network as well as its superior computational and memory resources compared to general IoT clients. The main rationale behind the controller creation is the following: instead of asking for a particular level of QoS, IoT clients subscribing to the broker request a specific delivery performance, either in terms of hitrate or end-to-end latency. The QoS controller then selects the most appropriate QoS level to satisfy the clients' requests. Furthermore, as emerged from the results shown in Figure 3, it is clear how the subscribers' QoS play a lead role in determining the final delivery performance: therefore, the suggested QoS controller works only on the subscribers side. We implement a specific controller functionality in the broker process, which observes the delivery performance experienced by subscriber clients. In details, the broker works with temporal windows of \(W\) seconds: at the end of each temporal window, the broker estimates two performance measures for each subscriber:  
* _Current hitrate \(\mathcal{H}\):_ for evaluating the percentage of correctly forwarded messages, the broker waits for explicit notification from each subscriber. In other words, every \(W\) seconds each subscriber publishes to the broker the number of received messages \(r\). In such a way, the broker can estimate the hitrate as the ratio between \(r\) and the number of forwarded messages \(f\).
* _Average end-to-end latency \(\mathcal{L}\):_ depending on the resources available on the clients, two options are available. If clients are all synchronized, the creation timestamp of each publication might be inserted in the publish messages so that subscribers might directly compute the end-to-end delay and notify to the broker its average value every \(W\) seconds. However, synchronization of clients might be complex to obtain in such a resource-constrained scenario. As a cheaper alternative, we propose to perform end-to-end delay estimation directly on the broker, by observing the number of application layer retransmissions performed. Indeed, the latency experienced by publish messages is directly correlated with the number of retransmissions performed by the broker towards the subscribers. The broker may therefore learn the relationship existing between latency and number of retransmissions and estimate the former from the latter. To verify this, we have used the simulation framework to transmit messages at different bit error rate values. Figure 4 shows the latency obtained by QoS 1 (from message publication to arrival of the PUBACK message at the broker) and QoS 2 messages (from message publication to arrival of the PUBREL message at the broker) depending on the number of retransmission observed. As one can see, there is a direct relationship between the number of retransmissions and the end-to-end latency: this happens because the application layer retransmission timer \(T_{retry}\) is in the order of seconds and dominates over the MAC layer retransmission timer values of the 802.11b CSMA-CA access protocol by over three order of magnitude. Moreover, no matter what is the retransmission policy applied by the broker, the relationship between number of retransmissions and latency can be easily learned: as an example, Figure 5 shows two different retransmission policies, a linearly incremental retransmission timeout (in blue) and an exponential backoff where the retransmission timeout is doubled each time (in red).