System model
We define QoE as a linear combination of the average bitrate of video playback, the time of rebuffering during playback, and the smoothness of picture in video playback following [19, 24]:
$$ QoE_{lin}=\sum_{i=1}^{N}q_{i}-\lambda\sum_{i=1}^{N-1}|q_{i+1}-q_{i}|-\mu\sum_{i=1}^{N}t_{i} $$
(1)
N is the number of video blocks, and qi is the bitrate of the block i. Thus |qi+1−qi| is the bitrate difference between block i and block i+1, and λ denotes the penalty coefficient of bitrate switching. Similarly, ti is the rebuffering time when downloading the block i, and μ is the penalty coefficient of rebuffering.
Following recent studies on wireless channels and network performance [43–45], we assume that wireless links are quasi-static. That means, we can model the network state as a stable process in phases. Specifically, in each phase, the link throughput follows a normal distribution denoted as \(\mathcal {N}(\mu _{i}, \sigma _{i})\). Thus, the network state change can be expressed as
$$ \mathcal{N}(\mu_{i}, \sigma_{i}) \rightarrow \mathcal{N}(\mu_{i+1}, \sigma_{i+1}), $$
(2)
where \(\mathcal {N}(\mu _{i}, \sigma _{i})\) and \(\mathcal {N}(\mu _{i+1}, \sigma _{i+1})\) represent the link throughput distributions in phase i and i+1 respectively.
Motivation
In this section, we study the performance of a state-of-the-art ABR algorithm RobustMPC and illustrate two key observations that motivate our system design.
Observation 1: buffer-level constraint
The first observation is that, when the network state is stable, existing algorithms such as RobustMPC use throughput prediction results to adjust bitrate, which may lead to unstable QoE. In this paper, however, we find that we should adjust bitrate not only based on network throughput but also buffer level.
Without loss of generality, assume that in a stable network state, the network throughput is always constant C. The available bitrates of video blocks are {q0,q1,...,qn}, where q0<q1<...<qn. The length of each video block is T, and the penalty coefficient of bitrate change QoElin is 1. Suppose the bitrate of current video block is qd(t), network throughput prediction is Cp(t), and buffer level is B(t).
Corollary 1
If the bitrate is to be increased from qd(t) to qd(t+1), the following equation must hold to avoid rebuffering events:
$$ q_{d}(t+1) \leq (B(t) + 4T) * \frac{C_{p}(t)}{5T} $$
(3)
Proof
Accoding to B(t)’s definition, we have
$$ B(t+i) = B(t+i-1) - \frac{T*q_{d}(t+i)}{C_{p}(t)} + T $$
(4)
If we want no rebuffering events during downloading the following 5 consecutive blocks, we have
$$ B(t+i-1) \geq \frac{T*q_{d}(t+i)}{C_{p}(t)} $$
(5)
Combining (4) and (5), we get
$$ B(t) \geq \frac{5T * q_{d}(t+1)}{C_{p}(t)}-4T $$
(6)
Therefore, the following equation holds
$$ q_{d}(t+1) \leq (B(t) + 4T) * \frac{C_{p}(t)}{5T}. $$
(7)
□
From the above analysis, we can see that if we want to switch to a higher bitrate, a higher level of a buffer is needed. In other words, it means we can reduce the bitrate switching by appropriately reducing the predicted throughput with a discount factor d.
In order to verify Corollary 1, we study a real trace generated from [21] with constant network throughput. In the study, we replace the original network throughput Cp(t) with Cp(t)′=Cp(t)/(1+d), where d is ranging from \(\{0, 0.05, 0.10, \dots, 0.95, 1\}\). When d is zero, it means Cp(t)′ is exactly Cp(t). When d is 1, it means Cp(t)′ is only half of the original predicted value Cp(t).
We record the decisions of the RobustMPC algorithm, and illustrate an example in Fig. 2 with a constant network throughput of C=1750bps. It depicts that, when d is set to 0, the bitrate is adjusted frequently, which may cause users to receive different quality video blocks. On the contrary, when d is set to 0.4, bitrate selection tends to be stable. The reason is, at d=0.4, the network throughput estimation is lower than its true value. Thus MPC algorithms will not increase bitrate until enough content is accumulated in the buffer. Moreover, after it switches to a higher bitrate since there are enough buffer contents, it can also stay at the higher bitrate for a longer period.
Observation 2: throughput overestimation
The second observation is that, when the network condition is unstable, throughput decrease may lead to rebuffering events. The reason is, most ABR algorithms rely on moving average methods such as EWMA (Exponentially Weighted Moving Average) to predict network throughput [19], and an essential characteristic of moving average methods is that they lag the input data. In unstable network environments, such lags will result in throughput overestimation when network throughput decreases. And the overestimation is a cause of rebuffering events.
Figure 1 illustrates an example from a dataset consisting of 500 video sessions. From the left subfigure, we can see that at time t1, the network throughput quickly decreases. But throughput prediction result does not drop until time t2. There is a about 5-second gap between t1 and t2. As a result, as shown in the right subfigure, the buffer at the player side drains after t3, and the rebuffering process continues until t4, which significantly impacts QoE.
Similar results can also be found in the Oboe algorithm [21]. Oboe dynamically adjusts the parameters of RobustMPC to reduce rebuffering events. However, through trace study, we find that throughput overestimation still exists.
For example, as shown in Fig. 3, there is a sudden network throughput at time t0. Since Oboe adjusts network prediction results based on the previous five blocks, it cannot capture this sudden change. Consequently, the network throughput is overestimated, leading to rebuffering events.
SASA design
Based on previous observations, in this paper, we propose a two-stage approach called SASA to dynamically adjust ABR algorithms at IoT edge.
The system architecture is shown in Fig. 4. First, live video streams from multiple cameras are forwarded to the edge server. In order to keep the data secure, the edge server adopts RC4 [46] as the stream cipher to encrypt/decrypt video streams. And in the offline phase, an analytical client generates offline network throughput traces and mimics the behavior of network condition changes. Then the virtual player invokes ABR algorithms to iterate all cases to find the optimal discount factor d that maximizes QoE. The results are saved in the configuration table. In the online phase, when the analytical client receives encrypted live video streams, it first records realtime network throughput traces. Afterward, a change point detection algorithm is performed to detect network throughput changes. If a change point is detected, bitrate decisions are made based on pre-computed results according to precomputed results in the configuration table.
Offline phase
Offline phase
As illustrated in Algorithm 1, in order the iterate all the possible network conditions, we enumerate μ from 0.05Mbps to 10Mbps with an interval of 0.05Mbps in Line 1. For each μ, we set the standard deviation σ to be \([0, 0.05\mu, 0.1\mu, \dots, 0.95\mu, \mu ]\) and get 2200 traces (Line 2). In Line 4, for each trace, we search the optimal discount factor dopt for QoElin within range [0,1]. The searching process is as follows (Line 5-9): we first configure the virtual player with network throughput \(\mathcal {N}(\mu, \sigma)\) and discount factor d; then we record the resulting QoE as QoEcurr; if QoEcurr is larger than QoEopt,QoEopt is replaced with QoEcurr, and d is recorded as dopt.
In practice, we find that in about 94% cases, when μ is fixed, different σs share a common optiaml dopt. And in the rest 6% cases, for the same μ, the differences between dopt are with 0.1.
Online phase
Algorithm 2 illustrates the online phase of SASA. During the downloading process, SASA records network throughput values every 100ms. In Line 2-4, if current video chunk is not downloaded, we simply record the throughput value in queue. After current video chunk is downloaded, SASA detects the change point of network throughput trace usning an online Bayesian change point detection algorithm (Line 6). If a change point is detected, the configuration engine starts to work (Line 7-10). It first finds an optimal value of discount factor d in the configuration table and then reconfigures this parameter for ABR algorithms. In addition, if the current change point is a sudden decreasing point, we calculate predicted throughput of predt in Line 12-13. And if predt is larger than μ, we set the throughput prediction value to μ (Line 14-16). Afterward, based on equation (7), we choose a set of optimal bitrates [bt+1,bt+2,...,bt+5] such that QoElin is maximized for the next 5 chunks (Line 18). Finally, bt+1 is selected as the new bitrate (Line 19).
Change Point Detection In order to detect network throughput changes in realtime, we adopt an online Bayesian changepoint detection algorithm [47] here. When a video chunk is being downloaded, we first measure network throughputs every ts seconds, and get \(\left [c_{1}, c_{2}, \dots \right ]\). For each data point ci in the queue, it could be either a change point or a growth point. We use ri to represent how long ci has been living. If ci is a change point, ri=0, and if ci is a growth point, ri=ri−1+1. Given the sampling point ci, we calculate the distribution of ri using:
$$ P(r_{i}|c_{1:i}) = P(r_{i}, c_{1:i})/P(c_{1:i}) $$
(8)
Finally, we calculate the expectation E(ri|c1:i), and if E(ri|c1:i) is approximately 0, we judge that a change point is detected. In practice, when ci is a change point, ri is not necessarily 0, thus we use a thrshold rthreshold instead. We then get the network state (μi,σi) by calculating the average value and standard deviation of recent points and search the configuration table for optimal d.
Throughput Overestimation Detection After a change point is detected, we also have to detect throughput overestimation. We compare the network throughput prediction Cp(i)′=Cp(i)/(1+d) with μi. If μi<Cp(i)/(1+d), we can judge that a throughput overestimation is detected. We then reset Cp(i)′ to be μi.
Implementation
We implement a virtual player to mimic the behavior of a client. In the online phase, the virtual player can simulate the process of buffering and playing process of video chunks, as well as network throughput changes. During the playing process, it calls ABR algorithms to obtain the bit rate decision, simulates the playing process of video, and finally output the user experience index of playing (average bit rate, rebuffering time, bitrate switching situation, and QoElin) to measure the performance. In the offline phase, the virtual player simulates the video playing process with no actual block buffering and video playing. Thus it can quickly find the optimal d in the whole search space. In our experiment, it simulates playing a 193-second video only in less than 1s.
The main functions in Fig. 4 are achieved by rewriting Dash.js [33]. The advantage of rewriting Dash.js is, it is purely on the client side. Thus the server settings can remain unchanged. The rewriting is mainly related to the following three modules: ABRRulesCollection, ABRController, ThroughputHistory. In Dash.js, the client obtains a video block by sending an XMLHttpRequest. It records the throughput trace in the downloading process of the video block by setting the onprogress callback function. When the block is downloaded, the throughput traces at the time of downloading are transferred to the ThroughputHistory module, Nevertheless, these traces are not saved and processed in the existing dash.js. We rewrite the ThroughputHistory module, save the traces in the video block download process, and provides an interface for other modules to obtain these traces. ABRccontroller module is the main interface of the ABR algorithm in dash.js. It invokes the getmaxquality interface of the ABRRulesCollection module to get the bit rate decision of the next block. ABRRulesCollection calls a variety of ABR algorithms, obtains their decisions respectively, and then selects one of them as the final decision. In this paper, we implement SASA in dash.js and add it to the ABRRulesCollection module.