### 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 *q*_{i} is the bitrate of the block *i*. Thus |*q*_{i+1}−*q*_{i}| is the bitrate difference between block *i* and block *i*+1, and *λ* denotes the penalty coefficient of bitrate switching. Similarly, *t*_{i} 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 {*q*_{0},*q*_{1},...,*q*_{n}}, where *q*_{0}<*q*_{1}<...<*q*_{n}. The length of each video block is *T*, and the penalty coefficient of bitrate change *Q**o**E*_{lin} is 1. Suppose the bitrate of current video block is *q*_{d}(*t*), network throughput prediction is *C*_{p}(*t*), and buffer level is *B*(*t*).

###
**Corollary 1**

If the bitrate is to be increased from *q*_{d}(*t*) to *q*_{d}(*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 *C*_{p}(*t*) with *C*_{p}(*t*)^{′}=*C*_{p}(*t*)/(1+*d*), where *d* is ranging from \(\{0, 0.05, 0.10, \dots, 0.95, 1\}\). When *d* is zero, it means *C*_{p}(*t*)^{′} is exactly *C*_{p}(*t*). When *d* is 1, it means *C*_{p}(*t*)^{′} is only half of the original predicted value *C*_{p}(*t*).

We record the decisions of the RobustMPC algorithm, and illustrate an example in Fig. 2 with a constant network throughput of *C*=1750*b**p**s*. 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 *t*_{1}, the network throughput quickly decreases. But throughput prediction result does not drop until time *t*_{2}. There is a about 5-second gap between *t*_{1} and *t*_{2}. As a result, as shown in the right subfigure, the buffer at the player side drains after *t*_{3}, and the rebuffering process continues until *t*_{4}, 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 *t*_{0}. 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 *d*_{opt} for *Q**o**E*_{lin} 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 *Q**o**E*_{curr}; if *Q**o**E*_{curr} is larger than *Q**o**E*_{opt},*Q**o**E*_{opt} is replaced with *Q**o**E*_{curr}, and *d* is recorded as *d*_{opt}.

In practice, we find that in about 94% cases, when *μ* is fixed, different *σ*s share a common optiaml *d*_{opt}. And in the rest 6% cases, for the same *μ*, the differences between *d*_{opt} 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 *p**r**e**d*_{t} in Line 12-13. And if *p**r**e**d*_{t} 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 [*b*_{t+1},*b*_{t+2},...,*b*_{t+5}] such that *Q**o**E*_{lin} is maximized for the next 5 chunks (Line 18). Finally, *b*_{t+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 *t*_{s} seconds, and get \(\left [c_{1}, c_{2}, \dots \right ]\). For each data point *c*_{i} in the queue, it could be either a change point or a growth point. We use *r*_{i} to represent how long *c*_{i} has been living. If *c*_{i} is a change point, *r*_{i}=0, and if *c*_{i} is a growth point, *r*_{i}=*r*_{i−1}+1. Given the sampling point *c*_{i}, we calculate the distribution of *r*_{i} using:

$$ P(r_{i}|c_{1:i}) = P(r_{i}, c_{1:i})/P(c_{1:i}) $$

(8)

Finally, we calculate the expectation *E*(*r*_{i}|*c*_{1:i}), and if *E*(*r*_{i}|*c*_{1:i}) is approximately 0, we judge that a change point is detected. In practice, when *c*_{i} is a change point, *r*_{i} is not necessarily 0, thus we use a thrshold *r*_{threshold} 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 *C*_{p}(*i*)^{′}=*C*_{p}(*i*)/(1+*d*) with *μ*_{i}. If *μ*_{i}<*C*_{p}(*i*)/(1+*d*), we can judge that a throughput overestimation is detected. We then reset *C*_{p}(*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 *Q**o**E*_{lin}) 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.