Proactive Video Chunks Caching and Processing for Latency and Cost Minimization in Edge Networks
Emna Baccour, Aiman Erbad, Amr Mohamed, Kashif Bilal, Mohsen Guizani
11 Proactive Video Chunks Caching and Processing forLatency and Cost Minimization in Edge Networks
Emna Baccour ∗ , Aiman Erbad ∗ , Amr Mohamed ∗ , Kashif Bilal † , and Mohsen Guizani ∗∗ CSE department, College of Engineering, Qatar University. † COMSATS Institute of Information Technology, Pakistan.
Abstract —Recently, the growing demand for rich multimediacontent such as Video on Demand (VoD) has made the datatransmission from content delivery networks (CDN) to end-users quite challenging. Edge networks have been proposedas an extension to CDN networks to alleviate this excessivedata transfer through caching and to delegate the computationtasks to edge servers. To maximize the caching efficiency inthe edge networks, different Mobile Edge Computing (MEC)servers assist each others to effectively select which contentto store and the appropriate computation tasks to process. Inthis paper, we adopt a collaborative caching and transcodingmodel for VoD in MEC networks. However, unlike other modelsin the literature, different chunks of the same video are notfetched and cached in the same MEC server. Instead, neighboringservers will collaborate to store and transcode different videochunks and consequently optimize the limited resources usage.Since we are dealing with chunks caching and processing,we propose to maximize the edge efficiency by studying theviewers watching pattern and designing a probabilistic modelwhere chunks popularities are evaluated. Based on this model,popularity-aware policies, namely Proactive caching policy (PcP)and Cache replacement Policy (CrP), are introduced to cacheonly highest probably requested chunks. In addition to PcPand CrP, an online algorithm (PCCP) is proposed to schedulethe collaborative caching and processing. The evaluation resultsprove that our model and policies give better performancethan approaches using conventional replacement policies. Thisimprovement reaches up to 50% in some cases.
Index Terms —collaborative chunks caching, edge network,joint processing, viewing pattern, proactive caching.
I. I
NTRODUCTION
In the last decade, the video content traffic witnessed anexplosive growing, especially with the upgrade of the nextgeneration mobile networks and the advancement of smartdevices. For example, authors in [1] stated that, in 2016,audio and video streaming contents presented the largest trafficcategory. This traffic is accounted for 60% of the overall datatraffic and it is predicted to increase to 78 % by 2021 [2].Notably, the huge multimedia traffic load is caused by theredundant delivery of the same popular videos.In order to solve the problem of repeated video transmissionand support the continuously growing content delivery, MECnetworks have been introduced to complement the cloud andCDN networks. In fact, in MEC networks, the base stations(BSs) are equipped with servers having small caching andcomputing capacities. These resources allow the network tofetch a content from the CDN only one time, then, cache andserve it in the proximity of viewers without duplicating thetransmission. Since the MEC network presents an opportunity to enhance the Quality of experience (QoE) of mobile usersand alleviate the data load over the transit links, it arousesthe research interest. The authors in [3] proposed a
CachePro approach where they used the storage and computing capa-bilities of one MEC server to store videos at the edge basestations. However, since one MEC server has a limited storageand computation capacity, collaborative and intelligent cachingare introduced. In
CoCache [4], authors implemented videosharing to minimize the network cost while authors of
JCCP approach [5] implemented the Adaptive Bitrate streamingtechnology (ABR) to jointly transcode and share new bitrateversions of videos. In the existing literature, authors proposeto bring the requested long video from the cloud and to storeit or transcode it in one of the MEC servers.However, in real life scenarios, video content is usuallypartitioned into small chunks of few seconds which can betransferred independently. Also, viewers only watch smallparts of a video before leaving the session as stated in [6] and[7]. This makes requesting the whole video from the CDNa waste in terms of cost and delivery latency. According toOoyalas Q4 2013 reports [8], the average watch time, perplay, of VoD on mobiles is only 2.8 minutes. Ending a videounexpectedly without fully watching it incurs: (a) a lowercache hit ratio due to caching a number of unwatched videoparts. This leads to a rapid cache storage saturation and a lowercaching efficiency because of storing a long video in the samebase station; (b) a lower processing efficiency and a highertranscoding cost caused by generating videos that will not befully watched, in addition to a rapid resource consumptionbecause of transcoding a long video in one server. In thesame context, authors in [7] showed that the watching time ofvideos can be studied since it is impacted by the length, thepopularity and the category of a video. Hence, based on thesechallenges, we propose to derive a study of chunks popularitybased on users viewing pattern. Then, using this model, aproactive caching to load the cache with popular videos and areactive cache replacement are introduced. We, also, propose aframework where servers can collaborate to cache or transcodechunks of the same video. This framework will be presentedin a greedy heuristic.The main contributions of this paper are summarized asfollows: • We present our collaborative chunks caching and process-ing. By proposing the possibility of caching one video indifferent cooperative MEC servers, resource utilizationcan be improved. a r X i v : . [ c s . MM ] D ec • We propose a probabilistic model where we study thepopularity of different chunks of videos based on userspreference. • We introduce our popularity-aware caching policies (PcPand CrP) that use the probabilistic model for chunkscaching and evicting. • We design a PCCP greedy heuristic to schedule thechunks loading and transcoding. • We evaluated our model compared to previously de-scribed caching approaches (CachePro, CoCache andJCCP).Our paper is organized as follows: In section II, we present ourproposed caching and processing collaborative system, wherewe study the viewing pattern of videos and we express thepopularity of chunks. Then, the PcP and CrP policies arepresented along with the PCCP greedy heuristic. A detailedexperimental evaluation is provided in section III. Finally, insection IV, we draw the conclusions.II. P
ROACTIVE CACHING AND PROCESSING OF VIDEOCHUNKS
In this section, we will describe our caching system imple-mented on distributed MEC servers in RAN networks. Thedescription of the architecture is followed by the study ofviewing pattern and the presentation of the probabilistic model.This model is used, next, to introduce the popularity-awarecaching policies (PcP and CrP). Finally, the greedy heuristicsuggesting a collaborative caching for different chunks isdescribed.
A. System model
In our system, the network consists of multiple base stations(BSs), each BS is associated with a MEC server providingcomputation, storage and networking capacities. The areagrouping communicating base stations is called cluster . In thispaper, we intend to use the servers for caching and compu-tation and we assume that these servers can share resources.Then, the shared streams can be transmitted to mobile usersif requested. In addition, the transcoder embedded with theserver can transcode the shared video to the required bitrateversion if needed. Hence, the requested data can be receivedeither from the cache or the transcoder. A video transcodingis the lossy compression of a higher bitrate version to alower version. The architecture of our system is describedin Figure 1. In our system, a cluster can comprise K basestations accommodating caching servers. A cluster is denotedby K = { , , ...K } . The collection of videos shared in thecluster is indexed by V = { , , ...V } . We assume that allrequested videos have M bitrate versions. Each video can bepartitioned into chunks with similar length. The set of chunksrelated to a video v is denoted as v = { v , v , ..., v i , ..., v c } , c is the number of chunks in the video v . All video chunkshaving a bitrate version l have the same size proportional tothe bitrate, denoted as s l . The set of all chunks that can berequested by a viewer is denoted as ˘ V = { v li | v i ∈ v, v ∈V , l = 1 , , ... M} . We consider that a video chunk v li canbe obtained by transcoding the video chunk v hi , if l ≤ h , Fig. 1: Illustration of the proposed collaborative chunkscaching and processing system: (1) The chunk can be servedfrom home server; (2) The chunk can be served from thehome server after being transcoded; (2) The chunk can beserved from the neighbor server; (3) The chunk can also beserved and transcoded in the neighbor server; (4) The chunkcan be served from the neighbor BS server and transcoded atthe home server; (6)-(7) The chunk can be served from thecloud either directly or after being transcoded loacally. ∀ v i ∈ v, v ∈ V and l, h ∈ { , , ... M} . We consider thatviewers can only request and receive videos from the closerBS, denoted as home node. In addition, we consider that eachserver k is provisioned with a cache capacity equal to S k bytes. We model the video content caching by introducing thevariable C v li k ∈ { , } , ∀ v i ∈ v, v ∈ V , ∀ l ∈ { ... M} , ∀ k ∈ K , where C v li k = 1 , if v li is stored at the BS k and C v li k = 0 , if not. The cache capacity of a cache serverassociated to a BS k is expressed by (cid:80) v li ∈ ˘ V s l .C v li k ≤ S k .Since transcoding videos is a computational intensive task andbecause of the real-time requirements of converting videosto the requested bitrate, we consider separate instances foreach transcoding task, that are large enough to transcode thehighest considered representation of videos. Let P k representthe processing capacity (number of transcoding instances) ofthe k th caching server. The description of different chunksfetching scenarios presented in Figure 1 will be deferred toulterior subsections. B. Users viewing pattern
To study the viewing pattern, we will identify first the pa-rameters that impact the preferences of users (video categories,length, popularity, etc). Then, we will define our viewingmodel and identify the most likely chunks to be requested
TABLE I: Fit coefficients of PDF of the drop positions for different categories.
Category ( cg y ) α y β y γ y P-square Category ( cg y ) α y β y γ y P-squarePeople 2.39 0.56 0.0023 0.999 Howto 2.74 0.52 0.0153 0.999Gaming 1.98 0.45 0.0146 0.999 Comedy 2.89 0.65 -0.0250 0.999Entertainment 2.41 0.56 -0.0064 0.999 Education 2.40 0.54 -0.0104 0.999News 4.70 0.95 -0.298 0.999 Science 2.53 0.53 0.013 0.999Music 2.45 0.51 0.0178 0.999 Autos 2.68 0.58 0.0016 0.999Sports 4.34 0.92 -0.267 0.999 Activism 2.50 0.59 -0.0228 0.999Film 2.32 0.62 0.0205 0.999 Pets 3.089 0.69 -0.066 0.999 within the collaborative cluster. In fact, authors in [9] studiedthe characteristics of several types of videos and proved thatthe popularity p v of a video v follows a Zipf distribution witha skew parameter α . Studies in [10] showed that videos popu-larities depend strongly on its category. Additionally, authorsstated that the popularity of different categories changes froma viewer to another. Another interesting conclusion is that thepopularity of a category depends also on the location of theviewer. Other researchers studied the viewing pattern and thewatching time of VoD contents, among them we can cite [6].These studies concluded that viewers only watch small parts ofa video before leaving the session and that short videos havehigher probabilities to be fully watched. Other previous works(e.g. [7]) proved that in addition to its length, the popularityand the category of a video can impact its watching time.These conclusions motivate us to identify the probability thata user requests a specific chunk based on the popularity andthe category of the video, and the watching time pattern.
1) Probability of requesting a video:
We define a set Cg = { cg , ..., cg G } of G categories. We define, also, a setof users U j connected to a BS j at the studied period. Wedefine for each user u jk a set U P j = { p ( cg y | u jk ) | ∀ y =1 ..G, ∀ k = 1 ..K } , where p ( cg y | u jk ) is the probability ofrequesting videos from a category cg y ( y ∈ { ..G } ) by theuser u jk . The probability that a video belonging to a category cg y is requested by users U j connected to a BS j can becalculated by summing the probabilities that cg y is selectedby different users: p j ( cg y ) = (cid:80) | U j | k =1 p ( u jk ) p ( cg y | u jk ) , (1) where | U j | is the number of users connected to the BS j and p ( u jk ) is the probability that a user u jk requests a video. Weassume that all viewers have the same probability to request avideo, p ( u j ) = ... = p ( u j | U j | ) = 1 | U j | . Hence, the probabilityof requesting a video belonging to a category cg y within theBS j can be expressed as follows: p j ( cg y ) = 1 | U j | (cid:80) | U j | k =1 p ( cg y | u jk ) . (2) Next, we will identify the probability of requesting a video v belonging to a category y , namely P j,y,v . First, let p ( cg y , v ) be the probability of choosing a video v from videos inside acategory cg y . This probability can be written as follows: p j ( cg y , v ) = (cid:40) p v (cid:80) Vi =1 p i × I cg y i , if I cg y v = 1 . , otherwise . (3) where V is the total number of videos, p v is the popularityof v inside the library and I cg y v is a binary variable whichindicates if v belongs to cg y or not. The difference between theprobabilities p j ( cg y , v i ) and p j ( cg y , v i ) is the popularity ofvideos within the BSs j and j . The probability of requesting a video v belonging to a category cg y from the whole librarycan be expressed as follows: P j,y,v = p j ( cg y ) × p j ( cg y , v ) (4) The next step is to calculate the probabilities p j,y,v,v i ofrequesting chunks v i of a video v . As we stated previously,the watching time and the behavior of viewers depend on thelength, category and popularity of the requested videos andthis viewing pattern has different distributions depending onthe studied data [7]. Hence, without loss of generality, wewill first analyze and extract the viewers behavior based on aspecific dataset [11]. Any other data can be used to identify theviewing behavior. Also, we suppose that we study a populationthat has the same behavior of chunks viewing.
2) Probability of requesting a chunk of video:
To studythe viewers behavior and model the video watching pattern,we will use a real-life video dataset. Specifically, we willuse video logs extracted from one of the most popular videoproviders ”YouTube” collected by authors in [11] and named
TweetedVideos . This dataset contains more than 5 Millionvideos published in July and August, 2016 from more than onemillion channels. The dataset contains also several metadataof videos including view count which gives an idea aboutthe popularity of videos, the watch time and video duration.In this paper, we suppose that the users request chunks ofvideos from the edge servers and different chunks have similarduration. Hence, we decompose each video v into chunks andwe attribute to each chunk a position v i . These positions arenormalized from 0 to 1. We further model the drop positiondistribution which means the chunk position where the viewersstopped watching the video and the drop probability in eachchunk. Figure 2 presents the PDF distribution of the droppositions Dp of videos from 14 different categories in thedataset. We can see that the drop position PDFs follow thesame shape which is similar to a Weibull model but withdifferent coefficients. This validates that the category of videoimpacts the viewing behavior. Figure 3 shows the integrity ofour Weibull fit expressed as follows for a category cg y : Dp y ( c ) = α y β y ( c − γ y β y ) α y − e − ( c − γ y β y ) αy (5)where Dp y ( c ) is the drop distribution of chunk position c of a video belonging to a category cg y . α y , β y and γ y arethe coefficients of the Weibull distribution; α y > , β y > and −∞ < γ y < + ∞ . Different Weibull coefficients corre-sponding to different categories of the dataset TweetedVideos are presented in Table I. This table includes also the P-squareindicators which is the goodness of fit measure. We can seethat the P-square is close to 1 for all categories which proves
Fig. 2: Dropping behavior modeling. Fig. 3: Drop position distribution fit.that the Weibull fit can model the distribution of the droppositions.Using the Weibull distribution, we can now derive theinstantaneous drop probability and the watching probabilityof a random chunk position v i . To simplify our model, wesuppose that viewers leaving a video must have watched thelast chunks completely. It means a viewer who dropped avideo v at a chunk v i must have watched this chunk. Hence,the probability of watching a chunk v i can be expressed asfollows: p v ( v i ) = 1 − (cid:82) c = v i c =0 Dp y dc (cid:82) c =1 c =0 Dp y dc = (cid:82) c =1 c = v i Dp y dc (cid:82) c =1 c =0 Dp y dc . = (cid:82) c =1 c = v i Dp y dc. = (cid:104) e − ( v i − γ y β y ) αy − e − ( − γ y β y ) αy (cid:105) . (6) where − (cid:82) c = v i c =0 D p ( v i ) is the probability of watching a videofrom position 0 to v i (not leaving a video between positions0 and v i ) and (cid:82) c =1 c =0 Dp y dc is the probability of watching allchunks which is equal to 1. We define, now, the popularity ofa chunk v i of a video v belonging to a category cg y as theprobability of requesting a video v and consuming its chunk v i . From equations (2) and (3), we can estimate this popularityas: P j,y,v,v i = P j,y,v × p v ( v i ) . = p j ( cg y ) × p j ( cg y , v ) × p v ( v i ) . (7) After deriving the expression of chunk popularity, we willdefine our popularity-aware policies in the next section.
C. Popularity-aware caching policies
In this section, we present two caching policies based onthe popularity of chunks studied in the previous subsection;Proactive caching Policy PcP for cache pre-loading and Cachereplacement Policy CrP for reactive cache removal. However,we need to introduce, first, our proposed distributed andsynchronized video catalogue that contains the metadata ofeach stored video and helps to manage the data caching. Thiscatalogue is associated with each cache. In fact, each catalogueis updated reactively for every new event e.g., accessing,caching or removing occurring in the related base station.This updated catalogue is shared in real time with other nodes so they can update their catalogues accordingly. Sucha collaborative catalogue management helps to enhance thevideo selection delay by making video searching local andminimizing the communication overheads. A snapshot of asynchronized catalogue is illustrated in Figure 4.Fig. 4: Snapshot of a synchronized catalogue.
1) CrP:
CrP is a reactive caching replacement policy thatpresents two new features: The first feature is the minimumreplication strategy. Indeed, in previous edge caching studies,each fetched video is cached at the local cache whether itexists in the cluster or not, which means multiple copies ofthe same video can be cached. Even when the cache is full,other potentially needed videos have to be deleted to providespace for the duplicated video. In our system, a second copyof the video is only stored when the cache is available andthis video is marked in the catalogue as
Replica=1 . In case ofstorage unavailability, only a single copy of the video is cachedin the collaborative cluster. In our system, a video chunk iscalled a
Replica , if a similar or a higher bitrate representationexists in the cluster because it is always possible to create alower video quality from a higher one. In this way, when thecache is unavailable, if a higher representations exists, thereis no need to store lower ones. The second new feature is thepopularity-aware caching and removing. Indeed, if the cacheis available, the incoming chunk request is stored even if itis a replica or an unpopular content. In case the storage isunavailable, all P j,y,v,v i in the catalogue are ranked and theLess Popular Chunk (LPC) is selected. If the requested videochunk is a replica and its popularity is less than LPC, thischunk is not cached. The above approach guarantees that thehighest popular chunks are cached and the number of storedvideos is maximized due to the minimum replication policyand the LPC rule. The detailed CrP policy is presented inalgorithm 1. Algorithm 1
CrP Input: S j , v li , ctg, C j , Output: updated S j , ctg, C j isReplica = 0 , Add = 0 if v li ∈ ctg then isReplica = 1 if S j < s l then LP C = min ( P j,.,.,. ) ∗ if isReplica = 1 then if LP C < P j,y,v,vi then * RcP-Removing part: while S j < s l do - Prioritize removing unpopular replicas v l i over unique unpopular chunks S j = S j + s l , C vl i j = 0 Add = 1 else if LP C > P j,y,v,vi then while S j < s l do - Remove Higher popular chunks v l i with P j,y,v,vi − LP C < T H S j = S j + s l , C vl i j = 0 Add = 1 else * RcP-Removing part else
Add = 1 if Add = 1 then S j = S j − s l , C vlij = 1 - Add v li to ctg - Update v li to recent time in ctg - Update other catalogues else - Relay to the viewer without caching * P j,.,.,. is the set of popularities of different chunks stored in the BS j
2) PcP:
We, also, propose a proactive caching policy wherewe populate the cache with the most popular chunks that aremost likely to be requested. This pre-load is done based onthe preference of active users connected to the base station asstudied previously in section II-B. More specifically, high pop-ular chunks are stored with the higher bitrate one by one untilfilling the cache. If the cache is still available, popular chunksare pre-loaded again with a lower representation. Meanwhile,the catalogue is updated with
Replica and popularity status.This task is done at the initialization of the network and hasan initial cost. The proposed PcP is illustrated in algorithm 2.
Algorithm 2
PcP Input: S , ..., S K , P ,.,.,. , ..., P K,.,.,. Output: C , ..., C K , ctg , S , ..., S K Cache initialization: C = 0 , ..., C K = 0 Catalogue initialization: ctg = ∅ level= M for j ∈ { , .., K } do while S j > do - Select the higher popular chunk max ( P j,.,.,. ) - Update ctg S j = S j − s level , C vlevelij = 1 if All chunks are cached then level=level-1
D. Proactive Chunks Caching and Processing (PCCP)
To illustrate the different events that can occur when a userconnected to a BS j requests a chunk of video v li , we intro-duce our greedy algorithm, named Proactive Chunks Cachingand Processing (PCCP) and detailed in algorithm 3. At theinstallation of the system, different caches and catalogues areinitialized with the popular video chunks. On each chunk request arriving to the BS j , the catalogue is checked to findthe chunk with the requested bitrate. If available, the vieweris served from the home node j (see Figure 1, scenario 1)and the CrP policy is called to update the access time ofthe video. In addition to the requested chunk, W d potentiallyrequested chunks from the same video are fetched. In thisway, when the user requests to watch the next part, the videowill be streamed without stalls. If the requested bitrate is notavailable at home node, a higher representation is searchedlocally (see Figure 1, scenario 2) and the possibility of servingthe video from a neighboring BS is also studied. The optionthat has the lower cost is adopted. If the requested bitratedoes not exist in the cluster and a local transcoding is notpossible, a higher representation is searched in neighbor nodes.Depending on resources availability, the chunk of video canbe transcoded at the neighboring node or locally (see Figure1, scenarios 3,4 and 5) . If these options cannot be performed,the request is served from the CDN, either by bringing thesame or a higher bitrate (see Figure 1, scenario 6 and 7). TheCrP policy is applied to update the cache j and the catalogue.It means, depending on the popularity of the requested chunk,the caching and removing are accomplished. Algorithm 3
PCCP Initialize P ,.,.,. , ..., P K,.,.,. , S , ..., S K ( C , ..., C K , ctg , S , ..., S K )= PcP ( S , ..., S K , P ,.,.,. , ..., P K,.,.,. ) for j ∈ { , .., K } do for each video request v li incoming to BS j do for w ∈ { , .., W d } do if C vli + wj = 1 then -Stream from home BS j - CrP ( S j , v li + w , ctg, C j ) else if M (cid:80) h = l +1 C vhi + wj ≥ and P j > then if C vli + wk = 1 , k ∈ K then if Cb l > Ct l then -Transcode and Stream from home BS j - CrP ( S j , v li + w , ctg, C j ) else -Fetch from neighboring BS k - CrP ( S j , v li + w , ctg, C j ) else -Transcode and Stream from home BS j - CrP ( S j , v li + w , ctg, C j ) else if C vli + wk = 1 , k ∈ K then -Fetch from neighboring BS k - CrP ( S j , v li + w , ctg, C j ) else if M (cid:80) h = l +1 C vhi + wk ≥ , k ∈ K and P k > then if P j > P k then -Fetch from k and transcode at BS j - CrP ( S j , v li + w , ctg, C j ) - CrP ( S j , v hi + w , ctg, C j ) else -Transcode and Fetch from node k - CrP ( S j , v li + w , ctg, C j ) else if P j > then -Fetch v M i + w from CDN and transcode at home BS j - CrP ( S j , v M i + w , ctg, C j ) - CrP ( S j , v li + w , ctg, C j ) else -Fetch v li + w from CDN - CrP ( S j , v li + w , ctg, C j )
20 40 60 80
Cache size % C ac h e h i t r a t i o % PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (a)
20 40 60 80
Cache size % -1 A ve r a g e access d e l ay p e r r e qu es t ( m s ) PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (b)
20 40 60 80
Cache size %
CDN C o s t ( $ ) PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (c)
Processing capability (Mbps) C ac h e h i t r a t i o % PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (d)
Processing capability (Mbps) A ve r a g e access d e l ay p e r r e qu es t ( m s ) PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (e)
Processing capability (Mbps) CDN C o s t ( $ ) PCCP heuristic, Wd=0PCCP heuristic, Wd=1JCCPCoCacheCachePro (f)
Fig. 5: Performance comparison based on varying cache capacity and a processing capacity =15Mbps: (a) Cache Hit ratio (b)Average access delay per request, (c) CDN cost; Performance comparison based on varying processing capacity and a cachesize =10% of library: (d) Cache Hit ratio, (e) Average access delay, (f) CDN cost.III. P
ERFORMANCE EVALUATION
A. Simulation Settings
In this section, we will evaluate the performance of oursystem under different network configurations including stor-age capacity, processing capacity and popularity of videos. Inour simulation, we considered that our network consists of3 neighboring BSs attached to 3 MEC servers ( K = 3 ). Letthe video library V consist of 1000 different videos chosenrandomly from the dataset in [11] and belonging to G =
14 categories described previously in Table I. All videos aredivided into chunks of 30 seconds each. We selected onlyvideos with a duration lower than 1500 s (50 chunks) tolimit the size of the set P j,.,.,. . Each video has 4 differentrepresentations ( M = 4 ). As configured in [5], we will setthe bitrate variants related to each representation to be 0.45,0.55, 0.67, 0.82 of the original video bitrate version. In thispaper, we consider that all videos have the same originalbitrate which is 2 Mbps. The popularity (number of views)of the chosen videos follows a Zipf distribution having askew parameter α = 0 . . The parameters of users arrival andrequests along with the cluster parameters are summarized inTable II.The latency of getting a chunk of video for various scenariosfollows a uniform distribution in a range of (a) [5-10] msfrom the cloud remote servers (b) [1-2.5] ms when fetchingdifferent versions from the neighboring BSs (c) [0.25-0.5] msfrom the home server. Several parameters are evaluated toprove the performance of our system: (a) cache hit ratio: is the number of requests that can be fetched or transcodedin the edge network (home or neighbor servers). (b) Average
TABLE II: Simulation parameters.
Variable Distribution/parameters valueNumber of MEC servers const, K =3Total number of video requests const, R = R = R = V =1000 randomly chosenfrom [11]Video popularity zipf, α =0.5Number of video categories const, G =
14 (see Table I)Category preference UP j randomVideo sizes ≤ M =4, from 200 kbpsto 2MbpsWatching time Exponential, mean watch timefrom [11]Chunk size 30sNumber of viewers const, | U | = | U | = | U | = λ =5, inter-arrival time=30sMax cache size Library sizepopularity threshold T H =0.001 access delay: is the average latency to receive videos fromdifferent caches or from the CDN. (d)
CDN cost: is the costof fetching the chunks of videos from the CDN. The CDNcost is calculated as 0.03$ per GB. Our system is comparedto different recently proposed systems, which are CachePro[3],CoCache[4], and JCCP[5].
B. Simulation Results1) Impact of caching and processing resources:
The cachesize and the processing capacity are important parametersto test the efficiency of a caching system. Figure 5 showsthe performance of different cache systems achieved for the described cluster for different cache and processing sizes. Theresults show the performance of our system in terms of cachehit ratio, access delay and cost. It can be seen that our PCCPheuristic with its CrP and PcP policies performs significantlybetter than the other caching systems even for low cache sizesor processing capability. For example, when the cache sizeis equal to 10% of the library size, PCCP achieves a hitratio equal to 0.79 when
W d = 0 and 0.97 when
W d = 1 compared to JCCP, CoCache and CachePro achieving a cachehit ratio equal to 0.56, 0,46 and 0.51 respectively. We cansee that our system performs more than 20 % better than theother systems without proactively fetching the next chunks(
W d = 0 ). This can be explained by: (a) The proactive cachingpolicy (PcP) that stores the highest popular chunks, whichimproves the probability to find the videos inside the cluster,(b) Collaboration between BSs to store different chunks ofthe same videos which makes caching a video possible, evenwhen the cache is full, (c) Avoiding to store the whole video,since it is proved that viewers rarely watch the content to theend, which provides more space to cache a higher number ofchunks, (d) The reactive caching policy (CrP) that stores onlyhigh popular chunks in the cache, removes only less popularchunks and avoids the replication of videos to maximize thenumber of cached videos. When
W d = 1 , we can see thatthe hit ratio becomes very high, which is explained by thefact that the next potentially requested chunks are fetched andserved beforehand. Such prediction of the incoming requestscontributes to increasing the hit ratio. The system with aprediction window
W d = 1 incurs more cost and datafetching compared to the system without prediction. This canbe explained by the additional cost of the chunk that is servedbut not watched by the user abandoning the video. This costwaste can be accepted since the loaded content is only a smallchunk with a minimal cost.
2) Impact of video popularity:
Varying the popularities ofvideos has an important impact on our system since it is basedon the preference of viewers.
Processing capability (Mbps) C ac h e h i t r a t i o % PCCP, Wd=0, , =0.5PCCP, Wd=1, , =0.5PCCP, Wd=0, , =0.7PCCP, Wd=1, , =0.7 (a) Processing capability (Mbps)
CDN C o s t ( $ ) PCCP, Wd=0, , =0.5PCCP, Wd=1, , =0.5PCCP, Wd=0, , =0.7PCCP, Wd=1, , =0.7 (b) Fig. 6: Performance comparison based on Zipf parameterwith a cache size = 10% of the library size : (a) Cache Hitratio, (c) CDN cost.Figure 6 presents the impact of changing the Zipf parameter α on cache hit and CDN cost. Specifically, a large α (highskewed popularity) represents a library with a small number ofvideos with similar popularities. It means the library contains videos with very high popularities and videos with very lowpopularities. In our simulation, we created another videolibrary from the same dataset [11] containing videos with alarger α = 0 . , which makes the library contain videos withhigher difference in terms of popularity. In this way, videoswith very high popularity will be highly requested. Whereas,unpopular videos will be rarely or never requested. Figures6(a) and 6(b) show that a higher skewed library gives betterresults in terms of cache ratio. This is explained by the factthat only a part of videos are frequently requested which arestored in the cluster thanks to the PcP policy. Also, even ifthe cache is low (10% of the library size), the size is enoughto cache highly popular chunks which enhances the cache hit.IV. C ONCLUSION
In this paper, we propose that different MEC servers col-laborate to cache and transcode different chunks of one videocontent. In order to maximize the edge caching, we studiedvideos viewing pattern and we proposed CrP and PcP contentplacement policies for estimating the placement of videochunks in the BS caches based on a probabilistic model. Then,to schedule sharing videos between MEC servers, a greedyalgorithm (PCCP) is proposed. The extensive simulation ofour heuristic proves the performance of PCCP compared toother caching approaches in terms of cost, cache hit ratio andaccess delay. A
CKNOWLEDGMENT
This publication was made possible by NPRP grant 8-519-1-108 from the Qatar National Research Fund (a member ofQatar Foundation). The findings achieved herein are solely theresponsibility of the author(s).R
Cisco white paper , 2017.[3] H. Ahlehagh and S. Dey, “Video-aware scheduling and caching in theradio access network,”
IEEE/ACM Transactions on Networking , vol. 22,no. 5, pp. 1444–1462, Oct 2014.[4] J. Dai, F. Liu, B. Li, B. Li, and J. Liu, “Collaborative caching in wirelessvideo streaming through resource auctions,”
IEEE Journal on SelectedAreas in Communications , vol. 30, no. 2, pp. 458–466, 2012.[5] T. X. Tran, P. Pandey, A. Hajisami, and D. Pompili, “Collaborativemulti-bitrate video caching and processing in mobile-edge computingnetworks,”
CoRR , 2016.[6] H. Yu, D. Zheng, B. Y. Zhao, and W. Zheng, “Understanding userbehavior in large-scale video-on-demand systems,”
SIGOPS Oper. Syst.Rev. , vol. 40, no. 4, pp. 333–344, 2006.[7] Y. Chen, B. Zhang, Y. Liu, and W. Zhu, “Measurement and modeling ofvideo watching time in a large-scale internet video-on-demand system,”
IEEE Transactions on Multimedia
IEEE/ACM Transactions on Networking , vol. 17, no. 5, pp.1357–1370, 2009.[10] Z. Li, J. Lin, M.-I. Akodjenou, G. Xie, M. A. Kaafar, Y. Jin, and G. Peng,“Watching videos from everywhere: A study of the pptv mobile vodsystem,” in
Proceedings of the 2012 Internet Measurement Conference ,ser. IMC ’12. ACM, 2012, pp. 185–198.[11] S. Wu, M. Rizoiu, and L. Xie, “Beyond views: Measuring and predictingengagement on youtube videos,”