## 4 Performance Evaluation
### Detailed Results
#### 4.3.2 Scenario #2  
The results of unfairness and the number of rebuffering events in Scenario #2 are summarized in Table 7. Meanwhile, Figures 6 and 7 illustrate the time-varying performances of the methods in subscenarios 2-A and 2-B, respectively. The unfairness performances of the evaluated methods show the similar tendency as in Scenario #1. The solutions with proxy improved the fairness by 1.72 times on average comparing to the No-Proxy method. It is noticeable that the improvement was less than that in Scenario #1. Actually, this is understandable due to the characteristics of the client's ABR. As shown in Figures 6 and 7, the new clients \(a_{2}\) and \(a_{3}\) had to select their bitrate step-by-step from the lowest version when they started their streaming session, while \(a_{1}\) was already at high levels. As such, the unfairness index performed worse during this period and recovered once all clients achieved the fair bitrate (1401 Kbps for subscenario 2-A and 838 Kbps for subscenario 2-B). Likewise, the No-Proxy method still underwent rebuffering events, while the proposed FAURAS and the Proactive method showed consistent efficiency in avoiding them. However, despite the same performance being achieved in subscenario 2-A, the Reactive method failed to prevent rebuffering events in subscenario 2-B when the number of newly-join clients increased. In addition, all rebuffering events when using this method only occurred on client \(a_{1}\), who started the streaming session earlier and experienced the bandwidth change when other clients joined. The numerical statistics of the adaptation delay, along with bitrate degradation amplitude, of the network-assisted methods are shown in Table 8 in order to explain this underperformance. Figure 7: Time-varying performances of all methods in subscenario 2-B. (**a**) No-Proxy; (**b**) Reactive; (**c**) Proactive; (**d**) FAURAS. The Reactive method only allocated the bandwidth for the client and respected the gradual quality deterioration of the ABR. As shown in Figures 6b and 7b, the video bitrate only dropped by one level at a time. For this reason, this method provided the lowest \(\Delta r\) among the evaluated methods in both subscenarios. However, it resulted in the highest \(\Delta t\) that might cause the client to fail to maintain enough buffer. For the subscenario 2-A, the fair bandwidth dropped from 3 Mbps to 1.5 Mbps and the fair bitrate had to decrease by three levels from 2791 Kbps to 1401 Kbps. In this case, the client \(a_{1}\) still managed adapt to the new fair share before the buffer ran out (Figure 6b). However, in subscenario 2-B, the fair bandwidth dropped from 3 Mbps to 1 Mbps that decreased the fair bitrate by five levels from 2791 Kbps to 838 Kbps. Thus, \(\Delta t\) of the client \(a_{1}\) increased by 1.9 times and caused its buffer to deplete (Figure 7b). On the other hand, the Proactive method immediately rewrote the client's request to match with the fair bitrate. Observing from Figures 6c and 7c, the client \(a_{1}\) decreased its bitrate straight away instead of switching the bitrate steadily via intermediate levels. Obviously, the \(\Delta t\) was reduced to the lowest, hence effectively avoiding the rebuffering events. As a consequence, this method induced the largest \(\Delta r\). Meanwhile, it is shown that the proposed FAURAS framework harmonized the performance of the other two methods. For subscenario 2-A, the FAURAS and the Reactive method performed equally in terms of \(\Delta r\), which were approximately 2.24 times lower than the Proactive method. This is visualized by Figure 6d, the bitrate of client \(a_{1}\) also decreased gradually as when using the Reactive method. Therefore, they required similar \(\Delta t\) values that did not harm the playout buffers. In the case of subscenario 2-B, the \(\Delta r\) of the FAURAS was slightly higher than the Reactive method (1.8 times) but was still significantly lower than the Proactive method (3.5 times).