Towards secure and network state aware bitrate adaptation at IoT edge

Abstract

Video streaming is critical in IoT systems, enabling a variety of applications such as traffic monitoring and health caring. Traditional adaptive bitrate streaming (ABR) algorithms mainly focus on improving Internet video streaming quality where network conditions are relatively stable. These approaches, however, suffer from performance degradation at IoT edge. In IoT systems, the wireless channels are prone to interference and malicious attacks, which significantly impacts Quality-of-Experience (QoE) for video streaming applications. In this paper, we propose a secure and network-state-aware solution, SASA, to address these challenges. We first study the buffer-level constraint when increasing bitrate. We then analyze the impact of throughput overestimation in bitrate decisions. Based on these results, SASA is designed to consist of both an offline and an online phase. In the offline phase, SASA precomputes the best configurations of ABR algorithms under various network conditions. In the online phase, SASA adopts an online Bayesian changepoint detection method to detect network changes and apply precomputed configurations to make bitrate decisions. We implement SASA and evaluate its performance using 429 real network traces. We show that the SASA outperforms state-of-the-art ABR algorithms such as RobustMPC and Oboe in the IoT environment through extensive experiments.

Introduction

With the rapid development of wireless communication and sensing technology, IoT (Internet of Things) has enabled a variety of applications such as environmental monitoring, smart manufacturing, and health caring [1–7]. In these applications, video streaming is of great importance. For example, cameras are deployed at optical lens factories to monitor the production process and perform quality check [8]. And people also use cameras to detect falls of the elderly [9] automatically. According to recent studies [10–14], video analytics algorithms such as detection and recognition are susceptible to video/image quality distortions. Therefore, delivering steady and high-quality videos is critical for IoT applications [15–18].

In recent years, many efforts have been made to improve Internet video streaming quality with adaptive bitrate (ABR) algorithms [19–23]. And state-of-the-art ABR algorithms have been widely used in popular online video services such as Netflix and Hulu. Generally speaking, the goal of ABR algorithms is to play the video at the highest possible bitrate while minimizing rebuffering events. Typically, an ABR algorithm operates in the following manner. The video file is first segmented into short chunks. And then, chunks are encoded at multiple bitrates independently. For each video chunk, the ABR algorithm adaptively chooses a proper bitrate to download in order to optimize different QoE metrics such as the average bitrate of video playback, the time of rebuffering during playback, and the smoothness of picture in video playback [24].

Existing approaches, however, are inadequate for providing high QoE at IoT edge since IoT systems pose additional challenges to video streaming. Firstly, most devices at IoT edge adopt low power wireless communication to transfer data [25–27]. Secondly, these systems are often deployed in harsh or remote environments such as factories, oilfields, etc. Thus, wireless link quality is volatile and vulnerable to environmental interference [28, 29] and malicious attacks [30, 31]. Existing algorithms suffer from such link dynamics in IoT systems and may result in misleading bitrate selection. Take Robust MPC algorithm [19] for example. As shown in Fig. 1, when link throughput decreases at t₀, the Robust MPC algorithm cannot capture this sudden change in time. The predicted network throughput stays stable untile t₁. As a result, the buffer at the player side drains after t₃, and the rebuffering process continues until t₄, which significantlyb impacts QoE.

Fig. 1

Throughput overestimation of RobustMPC

In this paper, we study the adaptive bitrate streaming problem at IoT edge. To overcome these challenge, we propose a secure and network state aware bitrate adaptation algorithm SASA. Specifically, we model a video session as a piecewise-stationary sequence of network states. We then devise an algorithm to detect the change of network state automatically. Once it changes, we search a precomputed table for best parameter configurations and apply them in realtime.

We validate SASA design using 429 throughput traces collected by Akhtar et al. [21]. We use Mahamahi emulation tool [32] to mimic IoT network behavior. And SASA is implemented in a reference DASH client dash.js [33]. Through comparison with state-of-the-art ABR algorithm RobustMPC [19] and Oboe [21], we show that the median QoE improvement of SASA is 4.5% and 4.2% respectively.

The remainder of this paper is organized as follows. We discuss related work in “Related work” section. Then, in “Our approach: SASA” section, we present the motivation of this work and the detailed system design. Furthermore, an evaluation is presented in “Evaluation” section. Finally, we conclude this paper and discuss future work in “Conclusion” section.

Related work

Existing ABR algorithms can be mainly divided into three categories, according to their different focus, i.e., bandwidth-based algorithms, buffer-based algorithms, and hybrid algorithms.

Bandwidth-based algorithms

The main idea of bandwidth-based methods is first to estimate link bandwidth and then adjust bitrate accordingly. FESTIV [34] estimates bandwidth to be the harmonic mean of observed throughput over recent chunks. It then designs a delayed update approach to achieve a tradeoff between fairness, stability, and efficiency. Sun et al. [35] systematically quantify throughput predictability using a large-scale dataset and propose a Hidden-Markov-Model based throughput predictor to enhance bitrate selection.

Bandwidth-based algorithms rely on accurate and stable throughput prediction. In practice, however, throughput estimations are usually biased, and accurate bandwidth prediction in wireless networks is still challenging [36, 37].

Buffer-based algorithms

Buffer-based algorithms argue that link bandwidth estimation is usually unreliable. Thus they rely on buffer level information to adapt bitrate. BBA-0 [38] chooses video bitrate simply based on current buffer occupancy. It shows that such a method can reduce the rebuffering rate by 10-20% compared to Netflix’s then-default ABR algorithm. Spiteri et al. [39] formulate bitrate adaptation as a utility maximization problem. They propose an online control algorithm BOLA which adopts Lyapunov optimization techniques to maximize video quality and minimize rebuffering.

The advantage of buffer-based algorithms is they only need to keep the buffer at a pre-defined level. But the drawback is, throughput information during video streaming is discarded.

Hybrid algorithms

Li et al. [40] observes that when multiple video streaming clients compete at a network bottleneck, the TCP throughput observed by a client cannot indicate its fair-sharing bandwidth. Thus they employ a probe-and-adapt method at the application layer and propose a four-step algorithm PANDA to reduce the instability of video bitrate selection. Yin et al. [19] develop a formal control-theoretic model of the bitrate adaptation problem and propose a model predictive control algorithm by solving a non-trivial discrete optimization problem at each time step. Pensieve [41] models a reinforcement learning problem and selects bitrates for future chunks solely based on the performance of past decisions. Oboe [42] focuses on auto-tune parameters of ABR algorithms to different network conditions in realtime. It significantly improves the performance of algorithms such as RobustMPC and BOLA. As illustrated in Fig. 1, these algorithms suffer from performance degradation in unstable network conditions.

SASA differs from existing studies in the following aspects. First, we study both the buffer-level constraint and impact of throughput overestimation in bitrate decisions and apply the results in the design of SASA. Second, SASA consists of an offline phase in which the best configurations are precomputed under various network conditions. Third, SASA adopts an online Bayesian changepoint detection algorithm to detect network changes and apply precomputed configurations to make bitrate decisions.

Our approach: SASA

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₀,q₁,...,q_n}, where q₀<q₁<...<q_n. The length of each video block is T, and the penalty coefficient of bitrate change QoE_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=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.

Fig. 2

Observation 1: Bitrate selection results when d is 0 and 0.4

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₁, the network throughput quickly decreases. But throughput prediction result does not drop until time t₂. There is a about 5-second gap between t₁ and t₂. As a result, as shown in the right subfigure, the buffer at the player side drains after t₃, and the rebuffering process continues until t₄, 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₀. 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.

Fig. 3

Observation 2: Throughput overestimation of Oboe

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.

Fig. 4

The architecture of SASA

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 QoE_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 QoE_curr; if QoE_curr is larger than QoE_opt,QoE_opt is replaced with QoE_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 pred_t in Line 12-13. And if pred_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 QoE_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 QoE_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.

Evaluation

In this section, we compare the performance of SASA with state-of-the-art algorithms Oboe and RobustMPC.

Experiment setup

Dataset The data used in our experiment is extracted from Oboe dataset [48]. These traces are collected over three months under various network conditions such as WiFi and 3G/4G. And the video clips downloaded by clients are between 4-6 minutes.

Experimental Metrics Following Oboe [21] and MPC [19], we focus on the average bit rate of video playback, rebuffering time as well as the change of bitrate, and measure the overall performance through QoE_lin which is a linear combination of above metrics. For rebuffering penalty coefficient ρ and the bit rate switching penalty coefficient λ in the QoE_lin, we set ρ=4300 and λ=1 following [21].

Hardware Settings We deploy video chunks as static files on an Nginx server. The available bitrates are {300, 700,1200,1850,2850,4300} Kbps. The server is with a 4-core, 1.2Ghz, Intel i7 CPU, and the operating system is Ubuntu 16.04.

Software Settings To mimic network behaviors in the IoT environment, we adopt the Mahimahi mm-link tool [32] to simulate network throughputs. And we use selenium (version 3.141.0) to control the Chrome browser (version 73.0) to play the video, and then collect the browser log to get the video playback index. The client’s video buffer size is 20 seconds.

System performance

QoE In Fig. 5a, the CDF curves represent SASA’s improvement over RobustMPC and Oboe respectively. The median improvement of SASA over RobustMPC is 4.5%. And the median improvement of SASA over Oboe is 4.2%.

Fig. 5

Comparision with RobustMPC and Oboe

Average Bitrate Figure 5b depicts the average bitrates of the three algorithms. The average bitrates are relatively close. For example, the median value of average bitrates is 2455.2 Kbps for SASA, 2467.7kbps for RobustMPC, 2458.9 Kbps for Oboe. We can also see that bitrate switches in SASA and Oboe are relatively stable, compared with RobustMPC.In terms of median value, the bitrate changes of SASA and Oboe are 153.2 Kbps, while that of RobustMPC is 172.4 Kbps.

Rebuffering Time From Figure 5, it can be seen that SASA has the shortest rebuffering time and the best performance, followed by Oboe, and RobustMPC has the longest rebuffering time. For 22.9% of the sessions, SASA experienced a rebuffering phenomenon, with an average rebuffering time of 1.49 s. For 26.2% of the sessions, Oboe experienced a rebuffering phenomenon, with an average rebuffering time of 1.96 s. For 50.9% of the sessions, RobustMPC experienced a rebuffering phenomenon, with an average rebuffering time of 1.37 s. Compared with RobustMPC, SASA decreases the rebuffering time in 42.1% of sessions, with an average reduction of 0.99s. In 5.6% of sessions, SASA increases the rebuffering time, with an average increment of 0.73s. Compared with Oboe, in 8.0% sessions, SASA reduces the rebuffering time, with an average reduction of 2.24s. And in 1.0% sessions, SASA increases the rebuffering time, with an average increment of 0.67s.

From previous data, we can see that compared with Oboe and RobustMPC, the rebuffering time is reduced in SASA. The reduction is attributed to changepoint detection since the network throughput overestimation. We illustrate an example in Fig. 6. Oboe detects the change of network state at time t₁, but the network throughput prediction is not lowered, resulting in rebuffering at time t₂. On the contrary, after detecting the sudden drop of throughput at t₁, SASA adjusts the predicted value of throughput by decreasing d, thus avoiding rebuffering events. However, even with changepoint detection, rebuffering events still occur. And in a few sessions, the rebuffering time increases. We will discuss the reasons in the following sections.

Fig. 6

An example of reducing rebuffering time by changepoint detection

To evaluate the impact of network throughput prediction, we modify the parameter k in prediction. We estimate network throughput based on the most recent chunk, while the default way is based on the recent five chunks (k_default=5). As shown in Fig. 7, we can easily find that when k=1, the variation of the network is more significant than that default. In specific, the bitrate decision tends to be less stable. In specific, we find that the median of average bitrate when k=1 is 0.7% higher than that when k=5. But the corrsponding QoE_lin is 1.4% less.

Fig. 7

Impact of network throughput prediction results. In (a), network throughput is estimated based on the most recent chunk. In (b), network throughput is estimated using the recent five chunks

Analysis of rebuffering

As presented above, SASA avoids the overestimation of network throughput, thus reducing the rebuffering frequency and rebuffering time. However, rebuffering events still occur in SASA, and the rebuffering time in some sessions is longer than that in RobustMPC and Oboe. We perform experiments and find that the main reasons are as follows:

Rebuffering at the beginning. According to the implementation mechanism of dash.js, after the second video chunk, it needs to maintain a minimum buffer size. That is, when the content in the buffer is less than a certain threshold, it will stop playing and cause a rebuffering event. Such a rule makes rebuffering events frequently happen between the second and third chunk. And the corresponding rebuffering time accounts for 51.8% of the total rebuffering time Since this is due to the implementation of dash.js, the rebuffering time of SASA, RobustMPC, and Oboe are similar at the beginning.

Rebuffering caused by throughput reduction. During the process of downloading a chunk, a sudden drop in network throughput will raise a rebuffering event. Even if SASA detects such a changepoint in realtime, the reconfiguration of ABR algorithms takes effect only when the current chunk is finished downloading. Therefore, there is a delay between the detection and rebuffering event.

Besides, we also find some cases when SASA encounters rebuffering events while Oboe does not. Figure 8 illustrates an example in our experiment. At time t₀, SASA makes bitrate decisions for the next chunk. Since the current network throughput is stable, it chooses a larger bitrate. However, as soon as it starts downloading the next chunk, network throughput decreases at time t₁. Even if SASA detects such a change in realtime, it cannot adjust bitrate until the current chunk is finished downloading. As a result, a rebuffering event happens at time t₃. On the other side, since Oboe detects the network change at t₂, which is later than SASA, it lowers network throughput estimation and avoids rebuffering.

Fig. 8

Rebuffering events for SASA and Oboe

In our experiment, the rebuffering time caused by throughput reduction accounts for 21.4% of the total value. In the absence of a reliable and precise throughput prediction algorithm, it is difficult to find an optimal mechanism that can be applied in every scenario.

The network throughput is lower than the minimum bitrate. When network throughput keeps at a lower value than minimum bitrate for a long time, even if ABR algorithms always select the lowest bit rate, rebuffering events will frequently occur. In our experiment, we find such a situation is rare, and only 0.7% of the total traces are in this case. However, once it appears, it is likely to cause a long time of rebuffering, and the rebuffering time accounts for about 24.5% of the total value. Rebuffering events caused by low network throughput are hard to avoid because the only way to solve this is to accumulate the contents of the buffer until exceeding a certain threshold.

Impact of changepoint detection

We also evaluate the impact of changepoint detection results. By varying the parameter r_threshold in changepoint detection, we can get different changepoint detection results. As illustrated in Fig. 9, we find that for different r_threshold in {100ms,200ms,300ms,400ms},QoE_lin, average bitrate, and average bitrate change are not affected. But with a smaller r_threshold, the average rebuffering time is smaller and more stable. So we choose r_threshold=200ms.

Fig. 9

Impact of r_threshold in changepoint detection

System cost analysis

We also evaluate the computation cost for both offline and online phases. In the offline phase, for each network state (μ,σ), it needs 8 seconds to find the optimal d. Since there are 200*20 network states, it needs 8.9 hours in total. In the online phase, we find that for each chunk, it needs 100ms for changepoint detection and 20ms for ABR reconfiguration.

Conclusion

In this paper, we study network state aware transmission in IoT systems. Our solution is motivated by two examples in real traces. We find that existing ABR algorithms are not suitable for IoT systems because they are not aware of network dynamics in IoT. We propose SASA, which can automatically detect network state changes and adjust bitrate decisions. Through extensive experiments, we demonstrate the median QoE improvement of SASA is 4.5% and 4.2% respectively compared with state-of-the-art methods.