## 5 Experimental Evaluation
### Runtime Behavior  
* _Autonomous mode:_ As a first experiment, we run the simulation framework with five subscribers, activating the controller in autonomous mode after 120 s. The following parameters have been used to setup the controller: \(\tilde{\mathcal{H}}_{low}=0.5\), \(\tilde{\mathcal{H}}_{high}=0.8\) and \(\tilde{\mathcal{L}}=7\)s. We focus on a specific realization where one of the subscriber (Sub 1) is characterized by a very high PER of 0.6, while the others have a PER of around 0.1. Figure 10 shows the hitrate and latency experienced by the subscribers throughout the simulation. At the beginning, all subscribers start at QoS 0, and therefore experience very low latency. As one can see, when the controller is activated at 120 s, the QoS of Sub 1 is increased from QoS 0 to QoS 1, causing an increase in hitrate and a corresponding increase in latency. No further changes are performed by the controller, according to the state machine illustrated in Figure 6c, since the reached hitrate for Sub 1 is already higher than \(\tilde{\mathcal{H}}_{high}\) and its new latency is below \(\tilde{\mathcal{L}}\). All the other nodes require no changes, since their hitrate is already higher than \(\tilde{\mathcal{H}}_{high}\).
* _Hitrate-constrained mode:_ As a second experiment, we run the same network simulation as before, activating the controller in hitrate-constrained mode. The following parameters have been used: the target hitrate \(\mathcal{H}\) has been set to 0.85, the hitrate margin \(\Delta_{\mathcal{H}}\) to 0.1 and the latency threshold \(\tilde{\mathcal{L}}\) to 5 s. In this case, two nodes (Sub 3 and Sub 4) are characterized by a PER greater than 0.2. Figure 11a illustrates the behavior of the hitrate experienced by nodes in the simulation, while Figure 11b does the same for the end-to-end latency. As one can see, after the controller is started, the QoS of nodes 3 and 4 is increased to QoS 1, greatly improving the hitrate. After some iterations though, the QoS of Sub 3 is reduced to QoS 0 as the hitrate is above the safe margin \(\Delta_{\mathcal{H}}\), while the latency is below the threshold. This produces a new hitrate which violates the input constraint. Such a behavior would produce a loop between the two states, with the controller continuously increasing and decreasing the QoS level. To avoid such issue, we implemented a QoS loop detection mechanism, which forces the higher QoS level in case a loop is detected. In this specific case, the controller forces QoS 1 on Sub 3.
* _Latency-constrained mode:_ Finally, we also report the runtime behavior for a scenario where the controller was run in latency-constrained mode, setting the target latency \(\tilde{\mathcal{L}}\) to 2 s and the latency and hitrate margins (\(\Delta_{\mathcal{L}}\) and \(\Delta_{\mathcal{H}}\)) to 1 s and 0.2, respectively. In this simulation, nodes 1 and 4 are characterized by a PER above 0.35, while the other subscribers have a PER below 0.1. All nodes start with QoS 2 by default setting. As one can see from Figure 12b, subscribers 1 and 4 are initially characterized by latencieshigher than the target one: therefore, upon its activation, the controller reduces their QoS from QoS 2 to QoS 1 after 120 s. This has the effect of reducing the latency on the one hand, but on the other hand also decreases the hitrate of the two nodes (Figure 11(a)). Note that sub 1 (red line) has a faster decrease of hitrate compared to node 4. Anyway, for both subscribers, since the newly estimated latency is above the constraint of 2 s, the controller sets their QoS to 0, further decreasing their hitrate.  
Figure 11: _Cont._  
Figure 10: Autonomous mode scenario. The black dotted lines indicate the thresholds used during the simulation.