The decision to request a particular video rate invokes several side effects. For ex- ample, increase in video quality, change in buffer level, increase in the video qual- ity fluctuation etc. Some of these events may result in a short-term improvement
and perhaps a long-term negative impact on QoE, and vice-versa. With the Classic Framework (Figure 3.1) or Framework 1 (Figure 3.2) it is difficult for an adaptation logic optimises QoE since it lacks a complete picture. Typically, the predictive model derived from these frameworks is represented as thus:
R() =f(u(t)). (4.4)
Where u(t) is the controlled variable of the Equation 4.1 and the output is generally the video rate of the chunk i+ 16l (see the Definition 3.2). This section proposes a new framework called Framework 2. The framework is aimed at an ABR algorithm designer with the information needed to make an optimal decision. In other words, the framework shall allow for the construction of a functionR() that takes both two presented state equations (Equation (4.1) and (4.2)) into consideration.
On comparing Equation (4.1) and (4.2) a salient fact emerges. By mapping the right-hand side of two equations, we can see a direct relationship between the change in state at the system level ( ˙x), and at the user experience plane ( ˙U X). This rela- tionship is what makes it difficult to design an ABR algorithm that optimises QoE without directly tracking the changes in user experience.
Considering the left-hand side of the two equations, there is a mapping between the system’s controlled input (u(t)) and the user delight (DI). This mapping mandates the establishment of a relationship between the system’s input and the video quality perceived by a user. This is consistent with the Definition 4.1, which relies on the fact that increase in video quality delights users. To guarantee this, a user must have control over the variable that affects the DI(t) most. But the challenge here is that there are a plethora of video quality metrics, to avoid tightly coupling the framework to anyone of them video rate is used as a proxy for the video quality. However, this requires a function expressive enough to map the video rate to any of available objective video quality metrics.
User Experience
ABR
External Components Internal Components System Boundary Adaptation ModuleBuffer Management Throughput Estimation
Figure 4.2: The activity diagram of the proposed unified framework
chapter, we use the broader Definition 3.1. Since as seen in the previous chapter, the buffer level at any time during the streaming session can be controlled and accurately measured it should be the controlled input to the system. Therefore, a model that formalises the relationship between the buffer state changes and video rate taking into consideration both the current video rate and the maximum rate, and how the change in video affects user experience is needed.
Finally, comes the mapping between user annoyance (AI) and the exogenous (z(t)) component of the system state equations. This mapping shows that the exogenous component (which is the part outside of the control of an ABR designer) is responsible for most of the annoyance a user suffers. As can be observed from Definition 3.3, the only other state variable is the throughput. However, in Section 2.3 it has been shown that the dynamics of TCP throughput is the leading cause of video quality fluctuation, which in turn is seen in Definition 4.2 to be the primary source of user annoyance. Furthermore, a typical content provider has little or no influence over
the TCP throughput of the last-mile channel. Hence TCP throughput, not user experience should be the exogenous component. Instead of directly trying to control it, Policy 1 presents a policy that mitigates its negative impact, but when a streaming client operates in a wireless environment where throughput always changes this is not the optimal solution. Therefore, what is required is to model the extent to which fluctuation in throughput affects the likelihood of the system reaching its target.
Figure 4.2 presents the outcome of the preceding discussion. It shows the activity diagram of the Framework 2. The first thing to note is that compared to the previous frameworks especially the Classic Framework, the system is now greatly simplified. As can be seen, TCP throughput is now an external component. Hence no attempt is made directly at controlling it. By adhering to Policy 1, TCP is allowed to function as designed. Note, this does not do away with the need of accurate throughput estimation. In fact, it helps in such an estimate, since it allows TCP to converge at its actual capacity without being dragged down by the unnecessary feedback loops.
The buffer management module is now the entry point. However, there is a dashed line from throughput estimation module to buffer management indicating that though the throughput is not an internal component, it is an exogenous variable used for adjusting the system state. The most important change to the previous frameworks is that in Framework 2, the user experience function is an active internal component providing input together with the buffer management to the adaptation logic. This allows any algorithm built to adapt video quality in a manner that jointly optimises both resource utilisation and user experience metrics. It should also be noted that the framework can easily be modified to consider other factors. For instance, an ABR that may desire to optimise power usage can easily include battery level as an adjustment factor in addition to the throughput.