FLARE: Coordinated Rate Adaptation for HTTP Adaptive Streaming in Cellular Networks

Transcription

1 FLARE: Coordinated Rate Adaptation for HTTP Adaptive Streaming in Celllar Networks Yongbin Im, Jinyong Han, Ji Hoon Lee, Yoon Kwon, Carlee Joe-Wong, Ted Taekyong Kwon, and Sangtae Ha University of Colorado Bolder Hanyang University Jni Korea Kakao Carnegie Mellon University Seol National University s: {yongbin.im, Abstract Fog compting is an emerging architectre that aims to rn applications on mltiple devices that lie on a continm from clod servers to personal ser smartphones. These architectres allow applications to optimize over the information stored at and fnctionalities rn on each device, based on individal device capabilities. We demonstrate the benefits of this approach for mobile video streaming. Existing HAS HTTP adaptive streaming) techniqes often sffer from problems like nstable video qality and sboptimal resorce tilization. We find that a lack of coordination prevents both clientand network-side HAS techniqes from solving them. However, or fog approach can exploit existing telecommnication APIs, which expose network capabilities to applications, in order to coordinate between clients and the network. Or coordinated HAS soltion, FLARE, optimizes the total tility of all clients in a cell while maintaining stable video qality and spporting ser- and device-specific needs. We implement FLARE on a commodity LTE femtocell and se the implementation to condct the first comparison of HAS players on an LTE femtocell. By condcting extensive experiments sing the ns-3 simlator, we also demonstrate that FLARE i) enhances the average video bitrate, ii) achieves stable video qality, and iii) balances the throghpt of simltaneos video and data flows, compared to other representative HAS soltions. I. INTRODUCTION Traditional compting applications have largely been rn from either the client e.g., mobile applications triggering content downloads from a remote server or from a centralized server, e.g., clod-based fsion of data collected by mltiple distribted sensors. More recently, however, fog and edge compting approaches have begn to develop hybrid architectres in which application fnctionalities are divided between the client and server [], [2]. Sch architectres are likely to become increasingly poplar as more and more devices emerge along the clod-to-things continm between remote clod servers and personal devices like smartphones or smartwatches. We can ths envision applications that are cooperatively rn on mltiple devices along this continm. A fog architectre can bring significant benefits compared to a prely client- or server-based approach: for instance, ptting some control at the client makes it easier to cstomize the application s configration according to individal clients preferences. Client-based control can also allow these configrations to more rapidly adapt to changes in client preferences or backgrond information. A central server component, on the other hand, can improve coordination between different clients who might compete for resorces, e.g., a celllar network setting in which mltiple applications share network bandwidth. Ths, fog compting allows applications to optimize over both client and server information, leading to an intelligent division of labor between the client and server. Celllar networks are an especially compelling example of fog compting architectres. Network operators like Vodafone, for instance, are beginning to expose their network APIs application programming interfaces) as a way to find new revene opportnities and help third-party app developers [3]. These APIs can reveal statistics sch as network availability and congestion in near real-time, which can then be sed to optimize the bandwidth reqested by different client flows. OneAPI [4], for instance, allows UE applications to specify their QoS qality-of-service) reqirements and to be notified of the QoS level that the network can provide. Ths, OneAPI can be sed to develop fog applications that have a presence at both the client and the network server, leveraging information from both to optimize network bandwidth allocation. In this work, we focs on one particlar application that often dominates bandwidth sage: video streaming. A. HTTP Adaptive Streaming HAS) Recent advances in mobile commnications and video compression technologies have led to significant growth in video traffic over mobile networks. Many major video service providers, inclding Netflix and YoTbe, employ HTTP adaptive streaming HAS) to deliver this video content, largely de to its adaptability to time-varying network conditions [5] [8] and ability to se existing HTTP web server infrastrctre. The basic idea of HAS is to divide a video into mltiple segments over the time dimension, e.g., of a few seconds each. Each segment can be encoded with mltiple bitrates e.g., 64p, 8p), and in each time interval, HAS selects the bitrate of a corresponding segment. Information abot each segment, sch as its seqence, timing, bitrate, and URL, is stored in a Media Presentation Description MPD) file that is sent to the client streaming the video. Either the client or a server in the network can then choose the segment bitrates. The choice of which video segment to download depends on a variety of both client and network factors, inclding the

2 client device capabilities, the time-varying amont of available network bandwidth, and the relative priority of non-video flows in the network. Ths, HAS is niqely sited to a fog compting approach that takes advantage of client and network information. Clients cannot obtain information abot the available network resorces, the nmber of devices in the network, etc., while network entities alone cannot access some device information that impacts the optimal video bitrates. Indeed, network-side and middleware soltions cannot handle encrypted video traffic, which constittes a large share of today s data traffic [9] and obscres even the identity of video traffic from any entity placed in the network. This fog-based philosophy distingishes or work from existing HAS systems, which generally select the segment bitrates based only on information at the ser eqipment UE) clients or inside the network. We overcome these challenges by designing and implementing FLARE Fair and Link-Aware RatE adaptation), the first HAS system that ses both individal client information and newly standardized network APIs that expose network information. B. Related Work: Existing HAS Techniqes As sggested by their name, client-side HAS approaches rn an adaptation algorithm on each UE. At each given time, the algorithm estimates the available network bandwidth based on the throghpt history of recently downloaded segments. It then chooses a desired bitrate for the next video segment based on this estimate, the video encoding information, the amont of video data in its bffer, and the previosly selected bitrate [] [2]. For instance, the FESTIVE algorithm [3] considers tradeoffs between stability of the video qality, fairness, and efficiency. Tian et al. [4] similarly seek to balance the smoothness i.e., stability) of the video rate with high bandwidth tilization. However, both algorithms can yield nstable video qality in LTE wireless networks, de to highly variable link bandwidth cf. Section IV). Li et al. [] showed that the discrete natre of video bitrates makes it hard for clients to find their fair share of available bandwidth, proposing an adaptation algorithm akin to TCP congestion control. Yin et al. [] introdced a model predictive control algorithm in order to optimally combine throghpt and bffer occpancy information. Xie et al. [2] proposed a cross-layer approach in which the PHY-layer information of the LTE network is sed to estimate available bandwidth. However, all client-side techniqes sffer from the fact that a UE has no information abot the overall radio resorces in the cell. Conseqently, clients may sffer from freqent re-bffering, nfair bitrate assignments, and abrpt bitrate changes. Network-side HAS techniqes can overcome these problems, bt have their own limitations. Network-side techniqes collectively consider individal clients channel conditions and tilities and then choose clients bitrates so as to maximize their aggregate tility [5] [8]. These bitrates are enforced by setting the garanteed bit rate GBR) and/or maximm bit rate MBR) for each flow sing the base station BS) schedler or a resorce slicing techniqe. For instance, Chen et al. [5] proposed AVIS, an in-network resorce management framework that schedles HTTP-based video flows in celllar networks. However, clients realized bitrates may still be sboptimal: these approaches assme that the bitrates for the segments reqested by the UE adaptation modles will qickly converge to the bitrates chosen by the network entity, which may not occr in practice cf. Section IV-B). Moreover, the network entity is oblivios to some UE characteristics, sch as the bffer memory, comptation capability, client preferences, etc., that may affect clients desired bitrates and tilities. Indeed, if the video traffic is encrypted the network may not even be able to identify HAS flows. Some network-side HAS techniqes e.g., [5]) also sffer from a static division of resorces among video and other data flows, which can case severe ndertilization of the overall radio resorces. C. FLARE: A Fog Compting Approach to HAS We implement FLARE as a light-weight client-side plgin e.g., sing Javascript) that can be easily embedded in video service providers HAS players. FLARE coordinates with OneAPI [4] to obtain network information. Given client information from FLARE s client-side UE ser eqipment) plgin, the OneAPI server can choose a desired bitrate for each video flow based on information obtained from the network BSs, UEs, and the network s Policy, Charging, and Rles Fnction PCRF). The PCRF manages and monitors all flows in the network; ths, it can provide the OneAPI server with all relevant network information, sch as the nmber of non-video flows, for assigning network bitrates. Since the OneAPI server is provided by the network operator, it can easily interface with both or UE plgins and the PCRF. We divide the bitrate selection and enforcement between the UE plgins and OneAPI network server, garanteeing their coordination. While the OneAPI server can easily allocate bandwidth between video and non-video flows, it does not directly control the actal bandwidth allocations. Ths, we se the FLARE plgin to enforce the bitrates chosen by the OneAPI server, avoiding convergence inefficiencies de to mis-coordination between the UE and the network. We limit the information exchanged between the OneAPI server and the plgin to the minimm needed to decide the bitrates, protecting clients privacy; they can individally choose to disclose additional information to the OneAPI server. FLARE introdces three fndamental improvements to existing HAS systems. Not only are bitrates chosen based on both the network and client information, bt FLARE nifies the resorce allocation of video and data flows into a single framework. Ths, FLARE optimizes the total tility of all clients, avoiding AVIS s occasional inefficiencies in resorce tilization cased by static resorce partitioning between video and data flows. Finally, FLARE ensres a stable video qality by taking a statefl approach to the rate selection and ensring that UEs always tilize the bitrates assigned by the HAS network entity. Ths, we avoid flctations in the selected rates as well as instabilities cased by a mismatch between the

3 UE s reqested and assigned bitrates. We demonstrate these improvements throgh the following contribtions: We propose FLARE, a coordinated rate adaptation approach that ses a fog compting architectre for selecting client bitrates in celllar networks. FLARE incorporates both client- and network-side information and garantees coordination between network- and client-side bitrate selection. For ease of deployment, FLARE reqires minimal modifications to rn on existing HAS video players. We introdce and develop a plgin-style modle that can be easily embedded on video players, can commnicate with the network entity withot casing privacy isses, and can work with cryptographic protocols sch as Secre Sockets Layer SSL). We develop FLARE on a commodity LTE femtocell BS, implementing its fnctionalities in the MAC layer. We then evalate FLARE s performance in the testbed and show that it otperforms existing HAS players. Or extensive simlation stdy demonstrates that FLARE significantly improves on both client- and network-side algorithms in varios settings in terms of the average video bitrate p to a 69% and 66% improvement compared to AVIS [5] and FESTIVE [3], respectively), stability of video qality p to 85% and 95% improvement compared to AVIS and FESTIVE, respectively), and balance of resorces allocated to video and data flows. We docment the benefits of a fog compting approach to HAS by comparing prely client- and network-based approaches to FLARE. We find that client-side HAS algorithms sffer from i) throghpt imbalances between data and video flows [3], ii) nstable video selection de to a lack of network-side information [3], [9], and iii) freqent rebffering and drastic bitrate changes de to aggressive rate selection [9] Figres 4 and 5). Network-side HAS soltions, on the other hand, sffer from i) instability in the selected bitrates de to indirect rate enforcement [5], [6] and ii) sboptimal flow tilities over time de to static resorce allocation among video and data flows [5] Figres 6 and 7). We describe FLARE s design principles and rate adaptation algorithms in Section II before discssing FLARE s operations and LTE femtocell testbed implementation in Section III. We then evalate FLARE compared to other HAS soltions in Section IV. We finally discss some of FLARE s deployment challenges before conclding in Section V. II. FLARE DESIGN We first discss the design principles sed in or coordinated HAS system, FLARE, in Section II-A, and then present or rate adaptation algorithm in Section II-B. A. Design Considerations We design FLARE s client- and network-side components and their interactions by following for main principles. Compatibility with existing systems: Most major video service providers e.g., YoTbe) have adopted cryptographic protocols to deliver their videos safely. It is therefore difficlt to detect HAS video flows and enforce their bitrates in the middle of the end-to-end path as proposed by [5], [6]. Policy information OneAPI server PCRF GBR setting RB/throghpt information PGW/PCEF Video, bitrate, capability, preference information FLARE plg-in Mobile Users 4 Kbps 2 Kbps Base Station Internet Media Server Fig.. FLARE s main entities in an LTE network are the OneAPI server and UE plgins circled), which decide the UE bitrates depending on information like their link conditions, tility, and ser/device stats. To handle this challenge, we adopt an existing standard, OneAPI [4], to coordinate between the network and clients. Clients can indicate which flows contain video traffic by commnicating with OneAPI. We implement FLARE as a light-weight client-side plgin sing a Javascript file, which can be easily embedded in existing video services. Minimal modification: To ensre that or system is deployable, we minimize the changes reqired in the crrent celllar network core. Instead, we create a control overlay on top of existing infrastrctre. Privacy protection: While individal client information sch as video clickstream logs can help FLARE assign clients the optimal bitrates, clients may not wish to reveal this information de to privacy concerns. We ths minimize the information reqired from each client, thogh clients may reveal more information at their discretion. Scalability: Optimizing the bitrate selections for all clients in a cell reqires a significant amont of comptational power: since there are a finite nmber of possible bitrates for each video segment, the optimization problem is a discrete, NPhard problem cf. Section II-B). We propose a continos optimization framework to redce the comptational complexity in order to accommodate a large nmber of clients. Figre shows FLARE s architectre. The FLARE plgin at each UE decides which client information to send to the OneAPI server. The OneAPI server, which has access to the crrent network state from the BS, then decides clients bitrates with a scalable, continos optimization framework, enforcing these decisions throgh the network PCRF policy, charging, and rles fnction), PCEF policy, charging, and enforcement fnction), and the FLARE UE plgin. A single OneAPI server can manage mltiple BSs, thogh the bitrates are calclated independently for each network cell. We next describe the details of the OneAPI server s bitrate optimization before otlining FLARE s operations in Section III. B. FLARE Coordination We now explain how the network and client coordinate to decide the optimal bitrates. We assme that all video flows follow HAS, all data flows se TCP, and the OneAPI server 6 Kbps

4 Algorithm : Algorithm for calclating the video bitrates and allocating resorces for video and data flows. for i > do Gather { client information; } Find b i, n i, L i U from BAI i ; Solve 3 4) or its relaxation for r, R i, adding constraints from client information as necessary; L i { = maxk k Z+ r k) R i } ; if L i, L i i δl i,..., L ) = L i + then L i = L i + ; else { } L i = min L i, L i ; R i = r L i ) for each U; knows the nmber of data flows in each network cell throgh its connection with the PCRF cf. Figre ). We sppose that the OneAPI server rns a bitrate optimization algorithm once per bitrate assignment interval BAI). In each BAI, FLARE attempts to maximize the total tility of video and data flows, which we define as U β θ R i ) + α log T i, ) θ D following [6], [2], sbject to capacity and stability constraints. Here U denotes the set of video flows, D the set of data flows, and R i and T i the bitrate and throghpt respectively of client, or flow, for BAI i. The client-specific parameters β and θ represent the importance of video traffic to client and the screen size a larger screen reqires a higher bitrate for good resoltion) respectively. We se a logarithmic tility fnction for the data flows to accont for the fact that larger throghpts yield smaller marginal increases in tility. Video bitrates similarly exhibit decreasing marginal tility as they increase, bt we constrain the maximm tility achieved to in order to model the fact that, once the bitrate can spport the device resoltion, sers notice very little difference in the video streaming. The parameter α controls the importance of data relative to video flows. We can simplify ) by defining r, the fraction of resorce blocks RBs) allocated to video flows: Lemma : Sppose that the sm of the throghpts of all data flows is proportional to r, the portion of RBs allocated to the data flows, and that each data flow receives a fixed fraction of the total data throghpt throghot its lifetime. Then optimizing ) is eqivalent to optimizing U β θ R i ) + nα log r). 2) Proof: We find from or assmptions that log T i = log X i θ r) ) log θ ) ) D D = n log r) + ) log X i log θ ) ) D where Xi is flow s throghpt with no video flows r = ) and n is the total nmber of data flows. Since X i and θ are constants, we can neglect their sms when maximizing ), instead choosing r and the R i to maximize 2). We now formlate FLARE s network capacity and bitrate stability constraints. We let r = {r ), r 2),..., r M )} denote the bitrates available for the video on flow, with r k) r k + ) for all k, and choose R i r. We se) L i to denote the index of the chosen R, i i.e., R i = r L i. We constrain the total allocated RBs for video flows to be no more than the total available for video flows: U BR i b i n i rn, where N is the total nmber of RBs, B is the length of the BAI, and n i and b i are respectively the nmbers of RBs assigned and bytes transmitted to client in BAI i. Note that or constraint incorporates knowledge from the previos BAI, i, to estimate the flow s reqired RBs in BAI i. We also leverage this past information to introdce a stability constraint that prevents large increases in flows bitrates in consective time intervals: R i r L i + ), for i >. We do, however, permit large drops in the flow s bitrate if necessary to maximize 2), e.g., several new clients enter the system. The main idea is then to solve max β θ r [,],R i R i r U s.t. U ) + nα log r) 3) BR i b i n i rn, R i r L i + ) 4) Since 3 4) is a mixed integer optimization problem that may inclde many flows, it is difficlt to solve efficiently. A fll examination of soltion algorithms for 3 4) is beyond the scope of this work, which focses on bilding FLARE, bt we propose one possible soltion: sing a continos relaxation in order to make the problem tractable. Proposition : The continos relaxation of 3 4), in which we replace R i r with the constraint r ) R i r M ), is a convex optimization problem. Proof: We note that the constraints 4) are linear in the optimization variables r and R i ; ths, it sffices to show that 3) is a concave fnction of r and R i. Omitting the detailed calclations, concavity follows from the fact that log x and x are both concave fnctions of x. We can se a standard convex optimization solver to solve or relaxation. Given a soltion r, R i, we discretize each R i by ronding it down to the nearest available bitrate, which we denote as r L i ). Algorithm formalizes this method of calclating the bitrate. Note that it can wellapproximate the optimm if there are a large nmber of available bitrates. We add two extra steps beyond solving 3 4): gathering information from the client in order to formlate We can accommodate client-side bandwidth limitations that can occr in wired networks by ronding R i to the minimm of r L i ) and x, where x is client s maximm bandwidth for HTTP video streaming.

5 or optimization problem, and an additional constraint on the chosen bitrate to ensre stability. Enhancing stability: Since freqent bitrate changes can adversely affect video sers experience [2], [22], the last step of Algorithm ensres that the bitrate does not increase from the previos BAI nless the increase has been recommended i.e., L i = L i + ) for the previos δ L i + ) BAIs. Here δ is a parameter that controls the freqency of bitrate increases, with a slower increase for higher bitrates [3]. While this limiting can lead to less efficient resorce tilization, it ensres a fair rate allocation by preventing any single client from sddenly hogging system resorces throgh receiving a higher bitrate. Incorporating client information: Since we allow each client to choose which information to send to the OneAPI server cf. Section II-A s design principles), we do not explicitly specify how the server ses this information. Clients can choose to send information like their bffer memory and comptation capability, or to send specific bitrate preferences. For example, if the crrent amont of bffered video in the client) is relatively small or the client wishes to limit its mobile data costs, the client can specify an pper bond on its bitrate to qickly fill the bffer or limit the amont of data transferred. On the other hand, if a client decides to send its video clickstream data withot specific preferences to the OneAPI server, the server might detect that the client is skimming the video e.g., freqent clicks of forward/backward bttons) and select the minimm bitrate. Since we se an optimization framework to choose the bitrates, we can easily incorporate these client preferences as additional constraints. III. FLARE OPERATIONS AND IMPLEMENTATION We now present or realization of Section II s design principles and rate adaptation algorithm. We first discss FLARE s operations before describing or implementation. A. FLARE Operations Figre shows the overall architectre on which FLARE s operations take place. FLARE s video streaming begins when a UE sends an HTTP GET Reqest message to reqest a Media Presentation Description MPD) file and the media server sends the MPD file to the UE. The MPD is parsed to extract the available bitrates for each video flow, and the FLARE plgin at the UE client sends these bitrates to the OneAPI server, after removing any information that can be sed to identify the video. The plgin can also send information on the clients preferences or device/bffer stats. In each BAI, the OneAPI server rns Algorithm to select each client s bitrate based on the client information, as well as the nmber of resorce blocks available, RB assignment history, selected bitrate history, available video bitrates for clients videos, video traffic policy, and ser/bffer/device information. Each selected video bitrate is transferred to the FLARE plgin at the corresponding UE, and the video player ses the bitrates for selecting the next video segment. When enb Protocol Stack PDCP RLC MAC PHY Data Plane Schedler Modle RB & Rate Trace Modle itbs Override Modle Management Plane Continos GBR Updater Statistics Reporter Commnication Modle Fig. 3. New modles implemented in the LTE enodeb. transmitting the video bitrates, the OneAPI server commnicates with the PCEF to set the GBR of each video flow according to its selected bitrate, ths providing stable service to the UE. Note that these message exchange procedres can be standardized by extending related existing standards for telecommnications APIs sch as [23]; the detailed design of these protocols, however, is ot of the scope of this paper. B. LTE Femtocell Testbed Implementation Or testbed setp is illstrated in Figre 2. It consists of for entities: UEs, an LTE femtocell enodeb, a OneAPI server, and a media server. We modify the MPEG-DASH/Media Sorce demo player [9] to implement FESTIVE [3] and FLARE players. We develop an LTE base station sing a commercial LTE femtocell enodeb enb), JL-62 [24]. It spports Mhz-bandwidth FDD operations on E-UTRA Band 7 [25] with 2 dbm transmission power, and 5 RBs are available per transmission time interval TTI), which is ms. We add the following modles in the medim access control MAC) layer of the enb, as illstrated in Figre 3: The Schedler Modle performs GBR-based per-tti schedling for video traffic in two phases. In Phase I, the schedling algorithm ses GBR-based schedling for video flows, and in Phase 2, the remaining RBs are allocated to both video and data flows with a legacy proportional fair schedling algorithm. The RB & Rate Trace Modle traces the RB and rate records for each video flow. The RB records are pdated by the Schedler Modle. We se the rate records to calclate the transmitted bytes for FLARE operations. The itbs Override Modle allows s to emlate timevarying link bandwidth by changing the index of the Transport Block Size itbs). Each TBS index itbs) defines its own modlation and coding scheme [26], and hence this allows s to set the transmission rate. The Continos GBR Updater dynamically changes the GBR, which is normally [27] assigned only when the traffic bearer is set p. The Statistics Reporter collects the RB and rate records of video flows from the RB & Rate Trace Modle and sends them to the Commnication Modle. The Commnication Modle is located in the enodeb and enforces GBR rates received from the OneAPI Server. It also sends a periodic statistics report on the per-client RB tilization and throghpt) to the OneAPI Server.

6 a) Or FLARE testbed. b) Testbed architectre. Fig. 2. Or FLARE testbed consists of UEs, an LTE femtocell base station, a OneAPI server, and a media server. The OneAPI server receives the per-client RB tilization and throghpt information from the enb s commnication modle and the video information e.g., video rate, dration) from the FLARE UE plgin when each video begins streaming. Based on the received information, it decides the bitrate or GBR) for each video client sing Algorithm and sends the chosen bitrates to the enodeb and FLARE plgin for enforcement in each BAI. We se KNITRO [28], a well-known solver for nonlinear optimization, to implement the bitrate calclation in the OneAPI server. TABLE I SUMMARY OF THE STATIC SCENARIO RESULTS. FESTIVE GOOGLE FLARE Average video rate Kbps) Average time that the bffer is nderflowed sec) Average nmber of bitrate changes Jain s fairness index of average video rates Average throghpt of data flow Kbps) IV. EVALUATION We evalate FLARE on the LTE femtocell testbed described in Section III-B before presenting simlation reslts that evalate or bitrate selection algorithm in varios environments. Or testbed evalation Section IV-A) compares or FLARE implementation to two client-side approaches, in both a static scenario and a dynamic scenario in which the network conditions change over time. Since the testbed considers only one network cell and ths cannot flly emlate UE mobility, we then se the ns-3 simlator [29] to compare FLARE s bitrate adaptation algorithm to both client- and network-side algorithms in mobile scenarios Section IV-B). This simlation setp also allows s to investigate FLARE s bitrate adaptation algorithm in more detail. We find that, in both the testbed and simlation scenarios, FLARE yields higher average bitrates with fewer bitrate changes than the algorithms we compare against. Moreover, FLARE can efficiently calclate nearoptimal bitrates, and its algorithm parameters can flexibly balance the relative priorities of data and video flows. A. Testbed Performance Evalation Experiment setp. We compare FLARE with two clientside rate control algorithms: the MPEG-DASH/Media Sorce demo player, which we call GOOGLE [9], and FES- TIVE [3]. We modify the MPEG-DASH/Media Sorce demo player to implement the FESTIVE and FLARE players. We implement tracing fnctions on the HAS player to log the segment transmissions, selected bitrates, and bffer stats. GOOGLE makes two link bandwidth estimates, b l and b s, based respectively on the long- and short-term histories of recently received segments and selects the highest available video rate that is.85 min { b l, b s}. Unless otherwise stated, we solve the exact bitrate optimization problem 3 4). For or experiments, we encode a video into 2, 3, 45, 79,, 32, 228, and 275 Kbps. We generate one video flow each on three devices by rnning the HAS players, and one data flow on a device by rnning Iperf [3]. We consider a static scenario in which the Modlation and Coding Scheme MCS) of each device does not change, and a dynamic scenario in which the MCS changes over time. For the static scenario, we set the itbs vale to 2. For the dynamic scenario, we change the MCS by gradally increasing the itbs from to 2 for the first 2 mintes, decreasing it back to for the next 2 mintes, and repeating this cycle for mintes. To model UE heterogeneity, each UE starts the cycle with a different offset. We se a commercial EPC emlator [3] to emlate signaling e.g., bearer setp) with the core network entities. Stable rate selection in the static scenario. We first show the performance of FESTIVE, GOOGLE, and FLARE in the static scenario in terms of the video rates, bffer sizes of the video flows, and throghpt of the data flow in Figre 4. FESTIVE selects the video rate conservatively, reslting in slow convergence to a stable state, and hence achieves a relatively large throghpt for the data flow. De to its nawareness of the overall radio stats, video flows bitrates change freqently. On the other hand, GOOGLE selects the video rate aggressively, casing freqent re-bffering interrptions whenever the amont of bffered video data falls below second. GOOGLE assigns the fewest radio resorces to the data flow, yielding lower overall data flow throghpt. Unlike FESTIVE and GOOGLE, FLARE, as shown in Figre 4c, selects the video rates in a stable manner. FLARE initially increases the video bitrate conservatively, and then consistently chooses a video rate of 79 Kbps while maintaining stable bffer sizes dring the measrement period. The data flow also receives a stable, moderately high throghpt. Table I smmarizes the static scenario s reslts. While FLARE achieves a slightly lower throghpt for the data flow, it dramatically redces the nmber of bitrate variations and bffer

7 Video rate Kbps) User User 2 User a) The video rates in FESTIVE Video rate Kbps) User User 2 User b) The video rates in GOOGLE Video rate Kbps) User User 2 User c) The video rates in FLARE Bffer amont Seconds) User User 2 User 3 Data ser d) Video flows bffers and data flow s throghpt in FESTIVE Throghpt Kbps) Bffer amont Seconds) User User 2 User 3 Data ser e) Video flows bffers and data flow s throghpt in GOOGLE Throghpt Kbps) Bffer amont Seconds) User User 2 User 3 Data ser f) Video flows bffers and data flow s throghpt in FLARE Fig. 4. FESTIVE, GOOGLE, and FLARE are compared in terms of the video rates, bffered amonts of the video flows, and throghpt of the data flow in the static scenario. FLARE selects the bitrate very stably, and maintains a larger bffer, compared to FESTIVE and GOOGLE. Throghpt Kbps) Video rate Kbps) User User 2 User a) The video rates in FESTIVE Video rate Kbps) User User 2 User b) The video rates in GOOGLE Video rate Kbps) User User 2 User c) The video rates in FLARE Bffer amont Seconds) User User 2 User 3 Data ser d) Video flows bffers and data flow s throghpt in FESTIVE Throghpt Kbps) Bffer amont Seconds) User User 2 User 3 Data ser e) Video flows bffers and data flow s throghpt in GOOGLE Throghpt Kbps) Bffer amont Seconds) User User 2 User 3 Data ser f) Video flows bffers and data flow s throghpt in FLARE Fig. 5. FESTIVE, GOOGLE, and FLARE are compared in terms of the video rates, bffered amonts of the video flows, and throghpt of the data flow in the dynamic scenario. FLARE selects bitrates similar to the link capacity, with less flctation, compared to FESTIVE and GOOGLE. Throghpt Kbps) TABLE II SUMMARY OF THE DYNAMIC SCENARIO RESULTS. FESTIVE GOOGLE FLARE Average video rate Kbps) Average time that the bffer is nderflowed sec) Average nmber of bitrate changes Jain s fairness index of average video rates Average throghpt of data flow Kbps) nderflows compared to FESTIVE and GOOGLE respectively. Fast bitrate adaptation in the dynamic scenario. We next compare FESTIVE, GOOGLE, and FLARE in the dynamic scenario, as shown in Figre 5. FESTIVE shows a similar pattern to that of the static scenario: the video bitrates oscillate freqently and with little visal correlation with the twominte MCS cycles, while the data flow throghpt also changes freqently bt is high on average Figres 5a and 5d). GOOGLE shows less bitrate oscillation, bt more freqent rebffering, as in the static scenario Table I). Indeed, these reslts incorporate changes that we have made to redce GOOGLE s freqent rebffering: we send an HTTP GET reqest for the next segment when the remaining bffered video length reaches 4 seconds instead of the static scenario s 5 seconds. FLARE, however, does not reqire rebffering and rapidly adapts its bitrates to the network conditions. As shown in Figre 5c, the changes in bitrates for FLARE are similar to the MCS change pattern configred for the dynamic scenario. Table II smmarizes the reslts in the dynamic scenario; only GOOGLE sffers from rebffering, while FESTIVE yields the highest data throghpt bt more bitrate changes than FLARE. Even thogh FLARE does not directly consider the bffered amonts of video when selecting the bitrates, it never cases

8 TABLE III SIMULATION SETTINGS..8.8 Simlator ns Simlation time Territory Nmber of video UEs Placement of UEs Fading model Video segment dration = B Video bitrates TCP 2 seconds 2m x 2m 8 32 to 28 for the experiments in Figre 9) random trace based model seconds, 25, 5,, 2, 3 Kbps, 2,..., 2 Kbps for the experiments in Figres 8 to ) Westwood Schedler Priority Set Schedler [32] TABLE IV DEFAULT PARAMETER VALUES FOR FLARE, FESTIVE, AND AVIS α AND δ ARE TAKEN FROM FIGURES AND 2, θ AND β FROM [6], AND FESTIVE AND AVIS PARAMETERS FROM [3], [5]). FLARE FESTIVE AVIS α δ θ β k p α α W. 4.2 Mbps a bffer nderflow, even in the worst channel condition cf. Table II). We believe that this is de to two reasons. First, FLARE considers the channel stats of each UE in its optimization framework; ths, it is less likely to reqest segments whose bitrates are larger than the available bandwidth. Second, while video segments are serviced with the GBR, the data traffic is serviced with non-gbr in FLARE. Ths, the Schedler Modle can opportnistically se the RBs of data traffic for video flows when the OneAPI server s bitrate optimization algorithm cannot keep pace with wireless link dynamics. B. Simlation of Bitrate Adaptations Simlation setp. We finally condct an extensive simlation stdy on or proposed soltion, FLARE, sing ns- 3 [29] with the LTE modle. The simlator will allow s to explore FLARE s bitrate adaptation algorithm for richer mobility settings and different video and data flow reqirements, compared to or femtocell testbed. For comparison, we also evalate a client-side algorithm FESTIVE [3]) and a network-side algorithm AVIS [5]). For AVIS, we rn a simple rate adaptation algorithm on a UE that reqests the highest possible rate based on the estimated throghpt, and set the GBR/MBR sing the schedler in the BS instead of resorce slicing techniqes. Table III smmarizes or simlation settings. We modify the Priority Set Schedler modle in ns-3 to add the MBR assignment and to retrieve information abot each client s assigned RBs and transmitted bytes. We set the parameters for each scheme as shown in Table IV. In most cases, there are 8 clients in each rn, and we carry ot 2 rns for each plot. Since HAS operates on top of TCP, we do not se traditional performance metrics like the Peak Signal-to-Noise Ratio PSNR), which is FLARE AVIS FESTIVE Average bitrate Kbps) a) Average client bitrate vales FLARE AVIS FESTIVE Nmber of bitrate changes b) Rate changes per client. Fig. 6. Performance s in static scenarios over 6 clients. FLARE shows higher average bitrates and better stability than AVIS or FESTIVE. mostly sefl in lossy environments with UDP. Instead, we se the average bitrate, nmber of bitrate changes, and Jain s fairness index for actally transmitted bitrates), which more accrately reflect sers qalities-of-experience in HAS. Stable, high bitrates in static scenarios. We first compare or ns-3 reslts to the testbed implementation by considering a static scenario with stationary UEs. Figres 6a and 6b show the s cmlative distribtion fnctions) of the average bitrate vales and nmbers of bitrate changes over 6 clients for each scheme. FLARE s average bitrates respectively exceed those of AVIS and FESTIVE by 24% and 39%, with 26% and 66% fewer bitrate changes than AVIS and FESTIVE, which is consistent with the testbed s static scenario reslts in Table I. In AVIS, the network sets only the GBR/MBR, while the rate controller in the UE selects the actal video bitrate, reslting in freqent mismatches between the bitrates set by the network and the ones selected by the UEs. FESTIVE performs worse than the others de to its nawareness of the link conditions in a cell. FLARE s fog compting approach eliminates both of these shortcomings. The average Jain s fairness index is comparably high at.989,.989, and.986 for FLARE, AVIS, and FESTIVE, respectively, meaning that all three schemes are very fair across time FLARE AVIS FESTIVE Average bitrate Kbps) a) Average client bitrate vales FLARE AVIS FESTIVE Nmber of bitrate changes b) Rate changes per client. Fig. 7. Performance s in the mobile scenarios over 6 clients. The stability performance difference between FLARE and the other schemes is larger than that of the static scenario Figre 6b). Stable bitrate selection in mobile scenarios. We next consider mobile scenarios where the UE operates in vehicles. FLARE s advantages are even more prononced in this scenario compared to the static one, as shown in Figres 7a and 7b. FLARE shows a 53% and 47% improvement in the average bitrate compared to AVIS and FESTIVE, and the average nmbers of rate changes decrease by 85% and

9 .8 static vehiclar.8 of video clients increases, bt remains mch smaller p to 2 ms) than a segment dration - seconds) Data flows Video flows Average bitrate Kbps) a) of the average bitrate vales over 6 clients..2 static vehiclar Nmber of bitrate changes b) of the nmbers of rate changes over 6 clients. Fig. 8. FLARE with continos bitrate optimization. The average bitrate is redced by less than 5% for the two scenarios, and the stability is retained video sers 64 video sers 28 video sers Comptation Time msec) Fig. 9. s of comptation times for the bitrate selection with 32, 64, and 28 video clients in a cell. The comptation time increases with the nmber of video clients, bt remains mch smaller than a segment dration. 95% compared to those of AVIS and FESTIVE, respectively. FLARE s bitrate stability constraints in Algorithm ensre that rate increases occr less freqently than FESTIVE and AVIS) in the presence of the mobile scenarios highly varying link bandwidths, which reslts in conservative se of the wireless resorces compared to the static scenario Figre 6). The average fairness indices, however, show a similar pattern to the static case:.999,.988, and.993 for FLARE, AVIS, and FESTIVE, respectively. Scalable bitrate selection. We now evalate the optimality and scalability of FLARE s bitrate selection. Figres 8a and 8b show the bitrates chosen when we se the continos relaxation approximation to solve 3 4) in Algorithm. The average throghpt is 4% and 6% less for the static and mobile scenarios compared to those in the original FLARE algorithm. The stability varies bt is generally retained: the nmber of bitrate changes decreases by 8% in the static scenario, bt increases by 48% in the mobile scenario while remaining nder 6). The average Jain s fairness indices are.999 and.997 for the static and mobile scenarios, respectively. The comptation time for each bitrate assignment is less than 4 ms for most cases 735 ot of 74). Only 5 cases took arond 4 ms, which is negligible compared to a segment dration on order of seconds. As the nmber of video clients increases, we find that the comptation times for the bitrate selection algorithm remain low. We plot the s of the comptation times with 32, 64, and 28 video clients in a cell, respectively, in Figre 9. De to coarse-grained measrement, some comptation times are plotted as zero. The comptation time increases as the nmber Average throghpt Kbps) a) of the throghpt of video and data flows in FLARE Nmber of bitrate changes b) of the nmbers of bitrate changes for video flows in FLARE. Fig.. When video and data flows coexist, FLARE balances the throghpt of video and data flows while maintaining bitrate and throghpt stability. Flexibility to different video and data flow reqirements. We finally investigate the throghpt balance between video and data flows with FLARE. We simlate 8 video and 8 data clients and show the reslting bitrates and throghpts in Figre a. There is no noticeable difference in the nmber of video bitrate changes compared with or previos experiments, as shown in Figre b. FLARE consistently prioritizes video flows over data flows. FLARE can adjst to different data and video flow priorities by changing the vale of α, which balances the throghpt of data flows compared to video flows cf. 3) in Section II-B). As α increases from.25 to 4, Figre shows the average throghpt and standard deviation for each type of flow. We observe that the average throghpt of the data flows smoothly increases and that of the video flows decreases as α increases. We finally examine the effect of the parameter δ on the relative priorities of achieving a higher bitrate verss bitrate stability. Recall that in Algorithm, recommended bitrate increases are not sed ntil the next higher bitrate index is + ) BAIs. To see the impact of different vales of δ in practice, we increment δ from to 2 in or experiments. Figre 2 shows the average bitrate and nmber of bitrate changes as δ varies. Overall, the average bitrate decreases as δ increases, since a higher δ means that the rate is increased more conservatively. Likewise, the stability increases as δ increases, indicating that FLARE can sccessflly adjst to different bitrate selection criteria. selected for δl i V. CONCLUSIONS In this paper, we propose a new HAS techniqe called FLARE that ses a fog compting approach to address existing HAS techniqes lack of coordination between clients and networks. In FLARE, a network entity and clients cooperate to decide the bitrate of a video flow. FLARE takes advantage of existing telecommnications APIs to minimize its reqired modifications at the network core, while minimizing changes at the client by embedding a plgin modle on the HAS video player. FLARE optimizes the total tility of video and data flows in a cell, while stable in the video qality. Experimental evalations with ns-3 and an LTE femtocell implementation demonstrate that FLARE significantly enhances the average

10 Average throghpt Kbps) Data flows Video flows Alpha Fig.. Average flow throghpts with different α vales, showing the tradeoff between data flows throghpts and video flows bitrates. =3 =2 Fig. 2. Average client bitrate with different δ vales. The average bitrate decreases as δ increases, i.e., the bitrate becomes more stable. throghpt or bitrate) and stability of video qality compared to state-of-the-art client-side and network-side soltions FES- TIVE and AVIS), while flexibly balancing video and data flows according to their relative priorities. In a practical deployment, FLARE can coexist with conventional HAS players by servicing their traffic like other data traffic withot any bitrate garantees; traffic from these HAS players wold then not interfere with FLARE. Users wold then have an incentive to adopt FLARE in order to receive GBR video rates. Moreover, FLARE can be easily extended to plink video streaming with minor modifications. Ths, it represents a practical HAS techniqes that not only improves on existing HAS techniqes, bt also demonstrates the feasibility of fog compting approaches to network applications. ACKNOWLEDGMENTS This work was partly spported by NSF grant CNS , an Institte for Information & Commnications Technology Promotion IITP) grant fnded by the Korean government MSIP) B9-6-23, Development of Access Technology Agnostic Next-Generation Networking Technology for Wired-Wireless Converged Networks), and the research fnd of Hanyang University HY-27-N). The snsamsng smart camps research center at Seol National University provides research facilities for this stdy. REFERENCES = [] M. Chiang and T. Zhang, Fog and iot: An overview of research opportnities, IEEE Internet of Things Jornal, vol. PP, no. 99, 26. [2] Openfog architectre overview, White Paper, OpenFog Consortim Architectre Working Grop, Feb. 26, OpenFog-Architectre-Overview-WP-2-26.pdf. [3] Making Money Throgh API Exposre, indstries/commnications/comm-making-money-wp pdf. [4] OMA OneAPI Profile of RESTfl Network APIs V4., release-program/crrent-releases/oneapiprofilerest-v4-. [5] MPEG DASH standard. [6] Adobe HTTP Dynamic Streaming. hds-dynamic-streaming.html. [7] Apple HTTP Live Streaming. [8] Microsoft Smooth Streaming. smooth-streaming. [9] R. Hackett, Most Internet traffic will be encrypted by year end. Here s why. Fortne, 25, netflix-internet-traffic-encrypted/. [] Z. Li, X. Zh, J. Gahm, R. Pan, H. H, A. C. Begen, and D. Oran, Probe and adapt: Rate adaptation for HTTP video streaming at scale, IEEE Jornal on Selected Areas in Commnications, vol. 32, no. 4, pp , 24. [] X. Yin, A. Jindal, V. Sekar, and B. Sinopoli, A control-theoretic approach for dynamic adaptive video streaming over http, ACM SIG- COMM Compter Commnication Review, vol. 45, no. 4, pp , 25. [2] X. Xie, X. Zhang, S. Kmar, and L. E. Li, pistream: Physical layer informed adaptive video streaming over lte, in ACM MOBICOM. ACM, 25, pp [3] J. Jiang, V. Sekar, and H. Zhang, Improving fairness, efficiency, and stability in http-based adaptive video streaming with festive, in ACM CoNEXT, 22. [4] G. Tian and Y. Li, Towards agile and smooth video adaptation in dynamic HTTP streaming, in ACM CoNEXT, 22. [5] J. Chen, R. Mahindra, M. A. Khojastepor, S. Rangarajan, and M. Chiang, A schedling framework for adaptive video delivery over celllar networks, in ACM MOBICOM, 23. [6] D. De Vleeschawer, H. Viswanathan, A. Beck, S. Benno, G. Li, and R. Miller, Optimization of HTTP adaptive streaming over mobile celllar networks, in IEEE INFOCOM, 23. [7] S. Cicalo, N. Changel, R. Miller, B. Sayadi, and V. Tralli, Qalityfair http adaptive streaming over lte network, in IEEE ICASSP. IEEE, 24, pp [8] W. P, Z. Zo, and C. W. Chen, Video adaptation proxy for wireless dynamic adaptive streaming over http, in 22 9th International Packet Video Workshop PV). IEEE, 22, pp [9] MPEG-DASH / Media Sorce demo. com/. [2] M. Uchida and J. Krose, An Information-Theoretic Characterization of Weighted alpha-proportional Fairness, in IEEE INFOCOM, 29. [2] N. Cranley, P. Perry, and L. Mrphy, User perception of adapting video qality, International Jornal of Hman-Compter Stdies, vol. 64, no. 8, pp , 26. [22] A. Balachandran, V. Sekar, A. Akella, S. Seshan, I. Stoica, and H. Zhang, A qest for an internet video qality-of-experience metric, in ACM HotNets, 22. [23] OMA RESTfl Network API for Qality of Service V., technical-information/release-program/crrent-releases/ oma-restfl-network-api-for-qality-of-service-v-. [24] JL-62 LTE Enterprise Indoor Small Cell, prodcts/prodcts lte jl62 d.asp. [25] 3GPP, Evolved Universal Terrestrial Radio Access E-UTRA); User Eqipment UE) radio transmission and reception, Sep. 29, Rel-9 v9... [Online]. Available: 36.htm [26] 3GPP, Evolved Universal Terrestrial Radio Access E-UTRA); Physical layer procedres, Sep. 29, Rel-8 v8.8.. [Online]. Available: [27] 3GPP, Evolved Universal Terrestrial Radio Access E-UTRA) and Evolved Universal Terrestrial Radio Access Network E-UTRAN); Overall description; Stage 2, Sep. 29, Rel-9 v9... [Online]. Available: [28] KNITRO, [29] ns-3. [3] Iperf, [3] Accelerate Development of LTE Evolved Packet Core Prodcts with Aricent Soltions. Soltion Brief LTE EPC.pdf. [32] G. Monghal, K. I. Pedersen, I. Z. Kovacs, and P. E. Mogensen, QoS oriented time and freqency domain packet schedlers for the UTRAN long term evoltion, in IEEE VTC, 28.