Radio Network-aware Edge Caching for Video Delivery in MEC-enabled Cellular Networks

Radio Network-aware Edge Caching for Video Delivery in MEC-enabled Cellular Networks Yiming Tan, Ce Han, Ming Luo, Xiang Zhou, Xing Zhang Wireless Signal Processing and Network Laboratory Key Laboratory of Universal Wireless Communication, Ministry of Education Beijing University of Posts and Telecommunications (BUPT), Beijing,, P.R. China Email: tanyiming@bupt.edu.cn Abstract With the rapid development of Mobile Internet, online Video-on-Demand (VoD) services, primarily K video, grow tremendously with the key performance indicators of lower latency, higher bandwidth, and higher bitrate. However, due to the long-distance between the user equipment (UE) and Internet Service Provider, Quality-of-Service (QoS) in terms of low playback delay and high transmission rate cannot be guaranteed. Therefore, Mobile Edge Computing (MEC), at the edge of the cellular network, is highly recommended with the benefits of lower uncertainty and end-to-end latency. The UE can enjoy better customized services with more appropriate bitrates as a result. In this paper, we propose a practical framework of MEC-enabled cellular network with radio network-aware edge cache and a radio network-aware cache updating algorithm. The framework uses Dynamic Adaptive Streaming over HTTP (DASH) and Radio Network Information Service (RNIS) is leveraged to accelerate multi-media services. Under this framework, RNIS collects information and delivers it to the MEC server based on the context. A testbed based on a real G Long Term Evolution (LTE) Base Station is developed carrying out experiments under this framework. Compared to traditional networks, the result shows that our approach maintains a smooth high quality of experience (QoE). Keywords: Mobile edge computing, cache, adaptive video, quality of experience. I. INTRODUCTION With the development of Internet and multimedia technology, VoD services are increasingly needed. People are no longer satisfied with watching videos on their personal computers but enjoying high-definition videos anytime, anywhere on their phones, which poses enormous requirement for cellular networks. In the future, the th generation (G) cellular network can not only improve network capacity with higher reliability but also reduce air interface delay. To provide UEs with better QoE, some methods of reducing the video transmission distance are proposed, such as the Information- Centric Networking [] and Mobile Edge Computing []. Recently, European Telecommunication Standards Institute (ETSI) has presented the conception of MEC, aiming to support network intelligence in G []. In CDNs, content providers deploy server resources near the network edge thus to reduce latency. However, in MEC, the content can be cached somewhere closer to network edge between the base station and EPC within the mobile network operators (MNO) infrastructure, rather than between EPC and Internet server out of the MNO. Most importantly, MEC helps eliminate the risk of backhaul limit. At the network edge, MEC captures real-time content information from RAN side and makes full use of it to ensure the QoE of UE []. With real-time content information, remote server or MEC server can optimize the user s traffic to guarantee QoE. For example, throughput estimation information can help video server to make TCP congestion control decisions. Also, this information can be used to ensure application matches the estimated capacity at the radio network downlink. The purpose of these methods is to make full use of wireless network resources to ensure users QoE in real time. The traditional approach to optimize QoE has perceived the network conditions on the mobile, which is inefficient and slow. Caching at network edge has been regarded as a critical function in MEC design. MEC has certain computing and storage capabilities to reduce the computational pressure on user devices. The excellent storage capacity can help UE get rid of the risk of suffering from backhaul limit. Also, MEC can be utilized to provide a more flexible and context-aware caching decision []. The content adaptation function can be deployed at the network edge to ensure users QoE in the dynamic mobile network. DASH has become a popular the over-the-top video delivery protocols that follow the principle of HTTP adaptive streaming and was standardized in []. Many video providers like YouTube have adopted it. Under DASH, each video is compressed into multiple representations, and each representation of this video is divided into multiple segments. The information about segments and qualities are contained in a manifest file called Media Presentation Description (MPD). So the DASH client can select different segment of presentation to play without any influences. When UE requests a segment, the DASH client will choose a suitable representation to adapt to the dynamic network. In the literature, some research efforts have been invested based on DASH [] []. In this paper, we propose a practical framework based on MEC-enabled cellular networks with radio network-aware edge cache, in which multi-media services, such as VoD, are accelerated by MPEG-DASH and RNIS. The purpose of our proposal is to collect the information at the network edge and to assist MEC cache the video segment with suitable representations. So users can get high-definition video directly 9----//$. IEEE 9

from the edge rather than obtain a standard-definition video from the remote server. We propose a radio network-aware cache updating scheme for radio network-aware content localization to improve video quality and reduce buffering time in the video application. Unlike many caching schemes focusing on cache hit ratio through popularity-based decisions, our goal is to secure the QoE for subscribers in the RAN network by radio network-aware caching and selecting the appropriate segment via DASH. Many methods need to calculate the popularity of both video segments and representations to make the caching strategy. If the caching system makes the decision just following the user request, bitrates of all cached content will be lower because of the limit of backhaul and latency between the remote server and UEs. To meet the demand of high-bitrate video from the user, videos should have other properties to be determined to cache at the network edge. We proposed that each video has two kinds of popularity. Each video or segment has two kinds of popularity, requested popularity and expected popularity. The expected popularity is based on the RAN information supported by RNIS. With the help of RNIS and popularityaware, high-quality video can be cached to ensure throughput. Moreover, to ensure that user can watch high-quality video smoothly, the updating algorithm is essential too. In order to provide the fluency of high-definition video while playing, our replacing algorithm attempts to make it by selecting a series of continuous suitable representation of segments from the cache and deleting segments of low popularity representation from others cache. In [], the cache can be placed at the G network edge for popular content. In [9], the authors proposed an edge caching system according to RAN information and the Channel Quality Index (CQI). But, it doesn t consider the users QoE of buffering time and just focuses on RAN information. Authors in [] proposed an algorithm about replace video cache to ensure video quality and switch times. However, that article doesn t use the RAN information for cache replacing. Our proposed scheme is based on popularity and RAN information to cache segments and replace segments. The purpose is improving video quality and reducing rebuffering time. The rest of this paper is organized as follows. The System architecture and parameters are introduced in Section II. Section III includes the popularity-aware caching and radio network-aware cache updating algorithm. In section IV, we evaluate the performance of the system. Finally, Section V summarizes this study. II. SYSTEM ARCHITECTURE AND PARAMETERS A. System Architecture The overall system architecture is presented in Fig.. The enbs connect to the MEC server which consists of a routing subsystem, RNIS, and a cache server. The cache manager in cache server decides which video segment and which representation should be cached. The EPC part retains a standard solution, that means we adopted a commercial EPC to connect with the MEC equipment. Because of the universality UE RAN Context enb Radio Access Network Latency ms RNIS Cache Server MEC Edge Network Latency <ms Routing Subsystem Backhual Evolved Packet Core Latency <ms User plane data User plane offloading data Control plane signaling EPC Fig. : System Architecture Overview Public Network Latency ms Internet of the RAN and EPC, we focus on illustrating the MEC in this paper. The routing subsystem is responsible for requests forwarding and network connectivity. After configuring the cache policy, the subsystem can handle in-coming video requests to determine whether redirect them to remote servers or the MEC server (e.g., a jetty server). The subsystem will collect the content information about the user requests and send it to Cache. That information is about video, segment and representation popularity. Correctly, the routing subsystem resolves General Packet Radio Service Tunneling Protocol (GTP) packets from UEs into IP packets and then matches the destination IP with the local routing table. If it matches, the MEC server will redirect the request to the local resource; Otherwise, the packet will be forwarded to the Internet. This procedure is transparent to the user. RNIS is a fundamental functional component of MEC that captures real-time RAN status and saves this information to a database or sends some information necessary to cache. In this paper, we use SINR and RSRP to measure the RAN condition. Cache server is built to cache or prefetch the most popular videos for future requests. It is a decision-maker and decisionexecutor for caching and replacing at the MEC. It determines the video cached based on the user s request for the video and the condition of the RAN side. Therefore, the suitable representations of individual segments are cached for a local application. As for cache replacing strategies, it must be an intelligent and efficient algorithm. The specific algorithm will be presented in the next section. It s an excellent way to improve the hit rate and the QoE. Since the video is splited into multiple segments, the frequency of each segment must be different, hence causing the cached segment dispersion. B. System Parameters We now describe in more detail the model that we consider in this work. Let s consider the set of S segments about a popular video competing to be stored at a cache-enabled MEC server. Let s for the sth segment and s [,,., S], the domain of s is denoted as S. The MEC server has the storage size M. For each video segment, we assume that there are R levels of representations, in which level corresponds to the lowest performance and level R corresponds to the highest performance. We use r to indicate the level r representation

and r [,,., R]. We further use (s, r) for the sth segment file with level r representation. Cached Uncached 9. S Fig. : Video Cache Schematic..... Assume that some segments with many representations are stored at MEC server. Let C be the set of (s, r) that are cached in the MEC server. In Fig., C is the set of all red blocks which mean cached in the cache server. The c i is the ith element of C. To clearly describe the contents of the cache, we use C j to represent the contents of the jth segment in the cache. C j can be expressed as: C j = subnet(c, j) = {(s, r) s = j, (s, r) C} () In Fig., C j indicates the set of all red block in jth segment. The M C denotes total file size of (s, r) in C. Therefore, the storage capacity constraint of the cache is given by sizeof(c) M C = ( filesizeof(c i )) M. () i= For each segment with a different representation, let p r s be the binary variable indicating the popularity of the sth segment with level r representation. Therefore, the popularity of the sth segment is given by p s = R p r s. () r= Let K be the number of all users and u k be the kth user, k [,,., K]. For each user u k, let x k and y k denote the average RSRP and SINR obtained by the RNIS about kth user. All users information about RSRP and SINR is represented by X and Y. The users information will be used to determine the level of video s representation. III. RADIO NETWORK-AWARE CACHING AND UPDATING A. Popularity-aware Caching OF CONTENT There are two basic principles that determine a cached video: network condition and video popularity. Firstly, the video must be requested a certain number of times. The popularity of the cached video segment p r s should above the threshold. And the hit ratio of the cached video and cache efficiency can be high enough. Secondly, the representation of segment should match the network condition. The high-quality video requires higher network bandwidth or even better equipment. In a weak network environment, the channel quality is poor and the best level that user can playback smoothly becomes lower. Assume that the most suitable bitrate of the user u k at this time is b k, b k is lower than all segments level in the cache: (s, r) C, b k < r () The user can t afford the high-quality video from the cache server and keep a long time of frozen playback to wait for video resources from the remote server. At the same time, low bitrate video may give users better enjoyment. So, it is essential to choose a suitable bitrate of the video according to the user s radio network information. In order to get the relationship between network conditions and video quality, we test the requested video bitrate many times at different locations in the lab. Based on the large amount of data, we summarize which kind of bitrate is suitable for different situations. We use SINR and RSRP to measure the RAN condition. The details of the mapping relations are listed in Table. TABLE I: Mapping Relations RSRP SINR (Bitrate) -dbm > x -dbm db> y db - (Mbps) -dbm> x -dbm db> y db - (Mbps) -dbm> x -9dBm db> y db - (Mbps) -9dBm> x -9dBm db> y db - (Mbps) -dbm> x -9dBm db> y db - (Mbps) -dbm> x -dbm db> y db - (Mbps) -dbm> x -9dBm db> y db - (Mbps) -dbm> x -9dBm db> y db - (Mbps) Table I shows the mapping relations between RSRP and SINR and video bitrate. In our scenario, we think low bitrates video (level -, respectively.mbps, Mbps, Mbps) can be transmitted smoothly between the remote server and the user. So we only need to cache the high bitrates video (over level ) in the cache server. The testing is based on the lab environment and may not get all channel conditions. The table can t consider all mapping conditions. We set two popularity properties for each representation of segment, obtained popularity and expected popularity. Obtained popularity is the number of times the video actually obtained. Expected popularity is the number of times the matched network resource bitrate of the video was expected. Because of the limited backhaul, the user obtained a bitrate lower than the bitrate which matches the allocated network resource. At this time, the expected video popularity will be increased rather than the obtained video. Therefore, the popularity is the sum of obtianed popularity and expected popularity. This caching strategy is deployed at the cache

server, which uses the popularity information provided by routing subsystem and the radio network condition supplied by RNIS. B. Radio Network-aware Cache Updating Algorithm There are a lot of algorithms for cache replacement. For example, least-frequently-used (LFU) and least-recently-used (LRU) are very classic eviction algorithms. LFU algorithm e- liminates the data according to the lowest reference frequency. LRU algorithm discards the least recently used items first. In our scenario where the video is cached in fragments, LFU and LRU both do not work well. Because these algorithms only consider each segment as a separate file, regardless of the overall video continuity. The speed from the cache server is faster than the remote server, and the quality of the adjacent segment may be different. So the absence of segments brings a long time of frozen playback and fluctuation of bitrate. The continuity of cached video is an important factor to ensure user s QoE. In order to maximize the users QoE, on the one hand, the popularity of the cache must be the top and the quality of video should be good enough. On the other hand, the number of the segment should be enough to ensure video continuity. Our algorithm focuses on the cache replacement and selects which files to save when the size of the cache file exceeds the limit. Above all, we select a series of contiguous cached segments based on users RAN information not to be deleted. Then, following the general principle, cache server deletes the lowest popularity segment file from unselected cache files. The purpose of the algorithm is ensuring the continuity of cached segment. Each user can play the video smoothly from cache server at the MEC. b b b b C output C temp 9 S 9 S (a) (b) C output Deleted File C output Deleted File 9 S (c) b b b b C output Deleted File 9 S (d) Fig. : The example of the cache after executing the algorithm for two users Firstly, for each user, obtain the most suitable level x k for the current environment information (RSRP and SINR) from the Table I. System iterates all segment s and finds the largest level r below x k from the cache C, then insert the (s, r) into Algorithm Radio Network-aware cache updating algorithm : Input: C, X, Y : Output: C output : function CACHE UPDATING(C, X, Y) : C output null : for k=,,.k do // b k is the best level user can play smoothly in the current situation : Obtain b k from Table I by x k and y k : for s=,,.s do // for each segment, select c with the maximum level that isn t greater than b k from C : c = arg max (s,r) C (r b k ) 9: C output = C output {c } : end for : end for : Obtain the set of other unselected cached files as: C temp = C C output : repeat : if C temp null then //remove the least popularity element from C temp : C temp = arg max p r s (s,r) C temp : else : for s=,,.s do : C output s = subnet(c output, s) 9: end for : Obtain the segment with the least popularity and over one representation in C output : s = arg max {s s S, sizeof(c output s )>} p s : if s exists then // remove the maximum representation from C output s : C output = { arg max r} (s,r) C output s : else // remove element with least popularity from C output : C output = { arg max p r s} (s,r) C output : end if : end if : until M C temp + M C output M : C output + = C temp 9: end function C output as the algorithm s output. Like Fig. (a), all cached files are divided into two parts. The purpose of the first step is to ensure that each user can get the appropriate level of segment continuously from the cache. Then, insert other unselected files (s, r) from C into C temp. At this point, if the C temp is not empty, delete the file with the lowest popularity in C temp until the cache file size meets the restrictions. Like Fig. (b), delete the element of C temp. Otherwise turn to the next step for deleting files from C output. This step focuses on deleting file from C output to meet the space limit. Iterate through all cached segments with more than

(a) No caching (b) LFU Requested Bitrate (Mbps) Request Bitrate Average Bitrate Requested Bitrate (Mbps) Request Bitrate Average Bitrate Experiment time (seconds) Experiment time (seconds) (c) The proposed radio network-aware updating (d) Percentage of requested segment bitrate Requested Bitrate (Mbps) Request Bitrate Average Bitrate Experiment time (seconds) Percentage of All Request % % % % % % Mbps and lower Mbps and Mbps Mbps and Mbps Requested Bitrate No caching LFU The proposed Fig. : Video segment bitrate comparison among cache replacement schemes one representations. Delete the larger representations from the least popular segment. Like Fig. (c), delete the th segment with level. This stage ensures that as many users can get video from the cache server. If all cached segments have only one representation, like Fig. (d), delete the segment with one representation in ascending order of popularity until space meets the limit. enb Cache Server ms By netem A. Testbed experiments IV. EVALUATION AND ANALYSIS As shown in Fig., a testbed based on a real G LTE Base Station is developed under this framework carrying out experiments. We use softwares to implement the functions of MEC, EPC and content server. In Fig., a MEC server has been deployed at the mobile network edge rather than inside EPC. MEC server has the RNIS, routing subsystem, cache function module. And the cache model has equipped M storage for video cache. We used the PING command to test the network latency, the latency between UE and enb through the air interface is about ms. Because MEC is located at the edge of network which is closer to the user, the latency is less than ms. The latency between the EPC and the content server is around ms tested by netem. In our scenario, the content server has one video that is minutes long. The testing video is trimmed from the DASH data set and divided into segments, and each segment s duration is seconds. Each segment has eight representations that include.mbps, Mbps, Mbps, Mbps, Mbps, Mbps, UEs Routing Subsystem MEC Server EPC Fig. : Experiment setup on the LTE testbed Content Server Mbps, Mbps. We used Xiaomi X phones as UEs to perform the experiments and connected to the Band LTE network. Each phone runs on Android.. operating system and uses Google Chrome browser to play the video by the DASH client. B. Performance Metrics We evaluate the following performance metrics to analyze the scheme we proposed. Downlink throughput: this refers to each UE s download throughput of each video segment (in Mbps). In this test, we use the obtained video quality to measure downlink throughput. Rebuffering duration: this refers to the total time duration that a user spends in playback freezing.

Rebuffering Duration (Seconds) Rebuffering Duration Fig. : Rebuffering Duration We compare our radio network-aware cache updating algorithm against two reference schemes. No caching: UEs request videos directly from the content server with no MEC cache support. The latency between UE and server is about ms latency. LFU: The Cache server performs the least-frequently-used replacement strategy. C. Downlink Throughput Fig. shows the bitrates of UE requested video segment with our algorithm and other two benchmark schemes. The result involves video request within seconds of each scheme. Our result indicates the video segment bitrate of UE requested. It can be observed that no caching system at the network edge, the video s bitrate are apparently lower than the result of caching scheme. Numerically, the average bitrate is.mbps,.mbps, and.mbps for no cahing, LFU and our proposed respectively. Due to the long latency (ms) between the UE and the content server, and without the MEC s help for a caching system, the user requested quality is significantly worse. From Fig. (d) we can see that caching schemes can increase the percentage of high bitrate video requests, and our strategy works better. Obviously, caching scheme can substantially improve the quality of video segment to ensure the users QoE. Furthermore, our scheme can get higher throughput than LFU. It is proved that the continuity of cached video segments is essential for improving throughput. D. Rebuffering Duration Besides average bitrate, the rebuffering time can degrade users QoE too. In this subsection, we analyze this metric and the results are presented in Fig.. We investigate the rebuffering duration during the experiment. When the video streaming session becomes the frozen, it will send less request to the content server for lower bitrate. It is observed that our scheme has the least time of video rebuffering. The scheme has about s rebuffering duration (.%) less than no caching scheme. However, LFU scheme has s (.%) more than no caching scheme. The main reason is that each segment is cached separately in LFU scheme. In DASH client, the huge differences between adjacent segments bitrate may increase the rebuffering time. DASH client cannot choose the suitable bitrate in time. Our scheme focuses on continuous caching to reducing this situation. Hence, Maintaining the continuity of cached video can reduce the rebuffering duration and ensure users QoE. V. CONCLUSIONS In this paper, we present radio network-aware edge caching framework which aims to improve users QoE in the future G communication network. With the RNIS, MEC can capture the information about RAN conditions. The information of RAN side can be used for our radio network-aware caching and updating algorithm, and help to decide which segment of representation should be cached at the network edge. In a word, our testbed in MEC-enabled cellular networks can cache videos of different bitrates locally that is closer to users. It can help ease the pressure on the backhaul and improve the QoE of users. We test it on a real LTE MEC-enabled network with multiple users and DASH client. Firstly, the result shows that caching content at the network edge can improve the video quality and ensure users QoE. Secondly, the effect also demonstrates that our radio network-aware cache updating strategy is better than LFU in reducing the rebuffering time, and guarantees users QoE further. ACKNOWLEDGMENT This work is supported by the National Science Foundation of China (NSFC) under grant, and. REFERENCES [] G. Xylomenos et al., A Survey of Information-Centric Networking Research, IEEE Communications Surveys & Tutorials, vol., no., pp. -9, Second Quarter. [] Mobile Edge Computing - a key technology towards G. [Online]. Available: http://www.etsi.org/images/files/etsiwhitepapers/ etsi wp mec a key technology towards g.pdf. [] Mobile edge computing use cases & deployment options. [Online]. Available: https://www.juniper.net/assets/us/en/local/pdf/whitepapers/ -en.pdf [] S. Wang, X. Zhang, Y. Zhang, L. Wang, J. Yang and W. Wang, A Survey on Mobile Edge Networks: Convergence of Computing, Caching and Communications, in IEEE Access, vol., pp. -9,. [] ISO. ISO/IEC 9-: dynamic adaptive streaming over HTTP (DASH) C Part : Media presentation description and segment formats. [Online]. Available: http://www.iso.org/iso/home/store/catalogue ics/ catalogue detail ics.htm?csnumber=. [] Z. Li et al., Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale, IEEE Journal on Selected Areas in Communications, vol., no., pp. 9-, April. [] D. J. Vergados, A. Michalas, A. Sgora, D. D. Vergados and P. Chatzimisios, FDASH: A Fuzzy-Based MPEG/DASH Adaptation Algorithm, IEEE Systems Journal, vol., no., pp. 9-, June. [] X. Wang, M. Chen, T. Taleb, A. Ksentini and V. C. M. Leung, Cache in the air: exploiting content caching and delivery techniques for G systems, IEEE Communications Magazine, vol., no., pp. -9, February. [9] J. O. Fajardo, I. Taboada and F. Liberal, Improving content delivery efficiency through multi-layer mobile edge adaptation, IEEE Network, vol. 9, no., pp. -, Nov.-Dec.. [] C. Ge, N. Wang, S. Skillman, G. Foster, and Y. Cao, QoE-Driven DASH Video Caching and Adaptation at G Mobile Edge, in Proc. ICN. ACM,, pp. -.