Proactive Video Chunks Caching and Processing for Latency and Cost Minimization in Edge Networks

TL;DR

This paper proposes a collaborative, popularity-aware caching and transcoding model for edge networks to optimize video delivery, reducing latency and costs by up to 50% through proactive and adaptive policies.

Contribution

It introduces a novel probabilistic model and policies for chunk-based caching and transcoding in MEC networks, enhancing resource utilization and performance.

Findings

Proposed policies outperform conventional methods by up to 50%.

Collaborative caching improves resource efficiency in edge networks.

Popularity-aware strategies effectively predict and cache high-demand video chunks.

Abstract

Recently, the growing demand for rich multimedia content such as Video on Demand (VoD) has made the data transmission from content delivery networks (CDN) to end-users quite challenging. Edge networks have been proposed as an extension to CDN networks to alleviate this excessive data transfer through caching and to delegate the computation tasks to edge servers. To maximize the caching efficiency in the edge networks, different Mobile Edge Computing (MEC) servers assist each others to effectively select which content to store and the appropriate computation tasks to process. In this paper, we adopt a collaborative caching and transcoding model for VoD in MEC networks. However, unlike other models in the literature, different chunks of the same video are not fetched and cached in the same MEC server. Instead, neighboring servers will collaborate to store and transcode different video chunks 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 the viewers watching pattern and designing a probabilistic model where chunks popularities are evaluated. Based on this model, popularity-aware policies, namely Proactive caching policy (PcP) and Cache replacement Policy (CrP), are introduced to cache only highest probably requested chunks. In addition to PcP and CrP, an online algorithm (PCCP) is proposed to schedule the collaborative caching and processing. The evaluation results prove that our model and policies give better performance than approaches using conventional replacement policies. This improvement reaches up to 50% in some cases.

Figures

Tables

Table 1. TABLE I: Fit coefficients of PDF of the drop positions for different categories.

Category ($c{g}_y$)	${\alpha }_y$	${\beta }_y$	${\gamma }_y$	P-square	Category ($c{g}_y$)	${\alpha }_y$	${\beta }_y$	${\gamma }_y$	P-square
People	2.39	0.56	0.0023	0.999	Howto	2.74	0.52	0.0153	0.999
Gaming	1.98	0.45	0.0146	0.999	Comedy	2.89	0.65	-0.0250	0.999
Entertainment	2.41	0.56	-0.0064	0.999	Education	2.40	0.54	-0.0104	0.999
News	4.70	0.95	-0.298	0.999	Science	2.53	0.53	0.013	0.999
Music	2.45	0.51	0.0178	0.999	Autos	2.68	0.58	0.0016	0.999
Sports	4.34	0.92	-0.267	0.999	Activism	2.50	0.59	-0.0228	0.999
Film	2.32	0.62	0.0205	0.999	Pets	3.089	0.69	-0.066	0.999

Table 2. TABLE II: Simulation parameters.

Variable	Distribution/parameters value
Number of MEC servers	const, $𝒦$=3
Total number of video requests	const, $R_1=R_2=R_3=$10.000
Total number of videos	const, $𝒱$=1000 randomly chosen
	from [11]
Video popularity	zipf, $\alpha$=0.5
Number of video categories	const, $G=$14 (see Table I)
Category preference $U{P}^j$	random
Video sizes	$\le$1500s (50 chunks)
Video bitrate	Uniform, $ℳ$=4, from 200 kbps
	to 2Mbps
Watching time	Exponential, mean watch time
	from [11]
Chunk size	30s
Number of viewers	const, $\left|U_1\right|=\left|U_2\right|=\left|U_3\right|=$ 500
Activity session size	Exponential, mean 300s
Video request arrival	Poisson, $\lambda$=5, inter-arrival time=30s
Max cache size	Library size
popularity threshold	$TH$=0.001

Equations

$$p_j(c{g}_y)=\sum _{k=1}^{|U_j|}p(u_k^j)p(c{g}_y|u_k^j),$$

$$p_j(c{g}_y)=\frac{1}{|U_j|}\sum _{k=1}^{|U_j|}p(c{g}_y|u_k^j).$$

$$\displaystyle p_{j}(cg_{y},v)=\left\{\begin{array}[]{ll}\dfrac{p_{v}}{\sum_{i=1}^{V}p_{i}\times I_{i}^{cg_{y}}},&\text{if $I_{v}^{cg_{y}}=1$.}\\ 0,&\text{otherwise}.\end{array}\right.$$

$$P_{j,y,v}=p_j(c{g}_y)\times p_j(c{g}_y,v)$$

$$D{p}_y(c)=\frac{{\alpha }_y}{{\beta }_y}(\frac{c-{\gamma }_y}{{\beta }_y}{)}^{{\alpha }_y-1}{e}^{-(\frac{c-{\gamma }_y}{{\beta }_y}{)}^{{\alpha }_y}}$$

$$p_v(v_i)=\frac{1-{\int }_{c=0}^{c=v_i}D{p}_{y}dc}{{\int }_{c=0}^{c=1}D{p}_{y}dc}=\frac{{\int }_{c=v_i}^{c=1}D{p}_{y}dc}{{\int }_{c=0}^{c=1}D{p}_{y}dc}.$$

$$P_{j,y,v,v_i}=P_{j,y,v}\times p_v(v_i).$$

Full text

I Introduction

In the last decade, the video content traffic witnessed an explosive growing, especially with the upgrade of the next generation mobile networks and the advancement of smart devices. For example, authors in [1] stated that, in 2016, audio and video streaming contents presented the largest traffic category. This traffic is accounted for 60% of the overall data traffic and it is predicted to increase to 78 % by 2021 [2]. Notably, the huge multimedia traffic load is caused by the redundant delivery of the same popular videos.

In order to solve the problem of repeated video transmission and support the continuously growing content delivery, MEC networks have been introduced to complement the cloud and CDN networks. In fact, in MEC networks, the base stations (BSs) are equipped with servers having small caching and computing capacities. These resources allow the network to fetch a content from the CDN only one time, then, cache and serve it in the proximity of viewers without duplicating the transmission. Since the MEC network presents an opportunity to enhance the Quality of experience (QoE) of mobile users and alleviate the data load over the transit links, it arouses the research interest. The authors in [3] proposed a CachePro approach where they used the storage and computing capabilities of one MEC server to store videos at the edge base stations. However, since one MEC server has a limited storage and computation capacity, collaborative and intelligent caching are introduced. In CoCache [4], authors implemented video sharing to minimize the network cost while authors of JCCP approach [5] implemented the Adaptive Bitrate streaming technology (ABR) to jointly transcode and share new bitrate versions of videos. In the existing literature, authors propose to bring the requested long video from the cloud and to store it or transcode it in one of the MEC servers.

However, in real life scenarios, video content is usually partitioned into small chunks of few seconds which can be transferred independently. Also, viewers only watch small parts of a video before leaving the session as stated in [6] and [7]. This makes requesting the whole video from the CDN a waste in terms of cost and delivery latency. According to Ooyala’s Q4 2013 reports [8], the average watch time, per play, of VoD on mobiles is only 2.8 minutes. Ending a video unexpectedly without fully watching it incurs: (a) a lower cache hit ratio due to caching a number of unwatched video parts. This leads to a rapid cache storage saturation and a lower caching efficiency because of storing a long video in the same base station; (b) a lower processing efficiency and a higher transcoding cost caused by generating videos that will not be fully watched, in addition to a rapid resource consumption because of transcoding a long video in one server. In the same context, authors in [7] showed that the watching time of videos can be studied since it is impacted by the length, the popularity and the category of a video. Hence, based on these challenges, we propose to derive a study of chunks popularity based on users viewing pattern. Then, using this model, a proactive caching to load the cache with popular videos and a reactive cache replacement are introduced. We, also, propose a framework where servers can collaborate to cache or transcode chunks of the same video. This framework will be presented in a greedy heuristic.

The main contributions of this paper are summarized as follows:

• •

We present our collaborative chunks caching and processing. By proposing the possibility of caching one video in different cooperative MEC servers, resource utilization can be improved.

• •

We propose a probabilistic model where we study the popularity of different chunks of videos based on users preference.

• •

We introduce our popularity-aware caching policies (PcP and CrP) that use the probabilistic model for chunks caching and evicting.

• •

We design a PCCP greedy heuristic to schedule the chunks loading and transcoding.

• •

We evaluated our model compared to previously described caching approaches (CachePro, CoCache and JCCP).

Our paper is organized as follows: In section II, we present our proposed caching and processing collaborative system, where we study the viewing pattern of videos and we express the popularity of chunks. Then, the PcP and CrP policies are presented along with the PCCP greedy heuristic. A detailed experimental evaluation is provided in section III. Finally, in section IV, we draw the conclusions.

II Proactive caching and processing of video chunks

In this section, we will describe our caching system implemented on distributed MEC servers in RAN networks. The description of the architecture is followed by the study of viewing pattern and the presentation of the probabilistic model. This model is used, next, to introduce the popularity-aware caching policies (PcP and CrP). Finally, the greedy heuristic suggesting a collaborative caching for different chunks is described.

II-A System model

In our system, the network consists of multiple base stations (BSs), each BS is associated with a MEC server providing computation, storage and networking capacities. The area grouping communicating base stations is called cluster. In this paper, we intend to use the servers for caching and computation and we assume that these servers can share resources. Then, the shared streams can be transmitted to mobile users if requested. In addition, the transcoder embedded with the server can transcode the shared video to the required bitrate version if needed. Hence, the requested data can be received either from the cache or the transcoder. A video transcoding is the lossy compression of a higher bitrate version to a lower version. The architecture of our system is described in Figure 1.

In our system, a cluster can comprise $K$ base stations accommodating caching servers. A cluster is denoted by $\mathcal{K}=\{1,2,...K\}$. The collection of videos shared in the cluster is indexed by $\mathcal{V}=\{1,2,...V\}$. We assume that all requested videos have $\mathcal{M}$ bitrate versions. Each video can be partitioned into chunks with similar length. The set of chunks related to a video $v$ is denoted as $v=\{v_{1},v_{2},...,v_{i},...,v_{c}\}$, $c$ is the number of chunks in the video $v$. All video chunks having a bitrate version $l$ have the same size proportional to the bitrate, denoted as $s_{l}$. The set of all chunks that can be requested by a viewer is denoted as $\breve{\mathcal{V}}=\{v^{l}_{i}|\quad v_{i}\in v,\quad v\in\mathcal{V},l=1,2,...\mathcal{M}\}$. We consider that a video chunk $v_{i}^{l}$ can be obtained by transcoding the video chunk $v_{i}^{h}$, if $l\leq h$, $\forall v_{i}\in v,v\in\mathcal{V}$ and $l,h\in\{1,2,...\mathcal{M}\}$. We consider that viewers can only request and receive videos from the closer BS, denoted as home node. In addition, we consider that each server $k$ is provisioned with a cache capacity equal to $S_{k}$ bytes. We model the video content caching by introducing the variable $C^{v_{i}^{l}}_{k}\in\{0,1\},$ $\forall\quad v_{i}\in v,$ $v\in\mathcal{V},$ $\forall\quad l\in\{1...\mathcal{M}\},$ $\forall\quad k\in\mathcal{K}$, where $C^{v_{i}^{l}}_{k}=1$, if $v_{i}^{l}$ is stored at the BS $k$ and $C^{v_{i}^{l}}_{k}=0$, if not. The cache capacity of a cache server associated to a BS $k$ is expressed by $\sum\limits_{v_{i}^{l}\in\breve{\mathcal{V}}}s_{l}.C^{v_{i}^{l}}_{k}\leq S_{k}$. Since transcoding videos is a computational intensive task and because of the real-time requirements of converting videos to the requested bitrate, we consider separate instances for each transcoding task, that are large enough to transcode the highest considered representation of videos. Let $P_{k}$ represent the processing capacity (number of transcoding instances) of the $k^{th}$ caching server. The description of different chunks fetching scenarios presented in Figure 1 will be deferred to ulterior subsections.

II-B Users viewing pattern

To study the viewing pattern, we will identify first the parameters that impact the preferences of users (video categories, length, popularity, etc). Then, we will define our viewing model and identify the most likely chunks to be requested within the collaborative cluster. In fact, authors in [9] studied the characteristics of several types of videos and proved that the popularity $p_{v}$ of a video $v$ follows a Zipf distribution with a skew parameter $\alpha$. Studies in [10] showed that videos popularities depend strongly on its category. Additionally, authors stated that the popularity of different categories changes from a viewer to another. Another interesting conclusion is that the popularity of a category depends also on the location of the viewer. Other researchers studied the viewing pattern and the watching time of VoD contents, among them we can cite [6]. These studies concluded that viewers only watch small parts of a video before leaving the session and that short videos have higher probabilities to be fully watched. Other previous works (e.g. [7]) proved that in addition to its length, the popularity and the category of a video can impact its watching time. These conclusions motivate us to identify the probability that a user requests a specific chunk based on the popularity and the category of the video, and the watching time pattern.

II-B1 Probability of requesting a video

We define a set $Cg=\{cg_{1},...,cg_{G}\}$ of $G$ categories. We define, also, a set of users $U^{j}$ connected to a BS $j$ at the studied period. We define for each user $u^{j}_{k}$ a set $UP^{j}=\{p(cg_{y}|u^{j}_{k})\quad|\quad\forall y=1..G,\forall k=1..K\}$, where $p(cg_{y}|u^{j}_{k})$ is the probability of requesting videos from a category $cg_{y}$ ($y\in\{1..G\}$) by the user $u^{j}_{k}$. The probability that a video belonging to a category $cg_{y}$ is requested by users $U^{j}$ connected to a BS $j$ can be calculated by summing the probabilities that $cg_{y}$ is selected by different users:

[TABLE]

where $|U_{j}|$ is the number of users connected to the BS $j$ and $p(u^{j}_{k})$ is the probability that a user $u^{j}_{k}$ requests a video. We assume that all viewers have the same probability to request a video, $p(u^{j}_{1})=...=p(u^{j}_{|U_{j}|})=\dfrac{1}{|U_{j}|}$. Hence, the probability of requesting a video belonging to a category $cg_{y}$ within the BS $j$ can be expressed as follows:

[TABLE]

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 a category $cg_{y}$. This probability can be written as follows:

[TABLE]

where $V$ is the total number of videos, $p_{v}$ is the popularity of $v$ inside the library and $I_{v}^{cg_{y}}$ is a binary variable which indicates if $v$ belongs to $cg_{y}$ or not. The difference between the probabilities $p_{j_{1}}(cg_{y},v_{i})$ and $p_{j_{2}}(cg_{y},v_{i})$ is the popularity of videos within the BSs $j_{1}$ and $j_{2}$. The probability of requesting a video $v$ belonging to a category $cg_{y}$ from the whole library can be expressed as follows:

[TABLE]

The next step is to calculate the probabilities $p_{j,y,v,v_{i}}$ of requesting chunks $v_{i}$ of a video $v$. As we stated previously, the watching time and the behavior of viewers depend on the length, category and popularity of the requested videos and this viewing pattern has different distributions depending on the studied data [7]. Hence, without loss of generality, we will first analyze and extract the viewers behavior based on a specific dataset [11]. Any other data can be used to identify the viewing behavior. Also, we suppose that we study a population that has the same behavior of chunks viewing.

II-B2 Probability of requesting a chunk of video

To study the viewers behavior and model the video watching pattern, we will use a real-life video dataset. Specifically, we will use video logs extracted from one of the most popular video providers ”YouTube” collected by authors in [11] and named TweetedVideos. This dataset contains more than 5 Million videos published in July and August, 2016 from more than one million channels. The dataset contains also several metadata of videos including view count which gives an idea about the popularity of videos, the watch time and video duration.

In this paper, we suppose that the users request chunks of videos from the edge servers and different chunks have similar duration. Hence, we decompose each video $v$ into chunks and we attribute to each chunk a position $v_{i}$. These positions are normalized from 0 to 1. We further model the drop position distribution which means the chunk position where the viewers stopped watching the video and the drop probability in each chunk. Figure 3 presents the PDF distribution of the drop positions $Dp$ of videos from 14 different categories in the dataset. We can see that the drop position PDFs follow the same shape which is similar to a Weibull model but with different coefficients. This validates that the category of video impacts the viewing behavior. Figure 3 shows the integrity of our Weibull fit expressed as follows for a category $cg_{y}$:

[TABLE]

where $Dp_{y}(c)$ is the drop distribution of chunk position $c$ of a video belonging to a category $cg_{y}$. $\alpha_{y}$, $\beta_{y}$ and $\gamma_{y}$ are the coefficients of the Weibull distribution; $\alpha_{y}>0$, $\beta_{y}>0$ and $-\infty<\gamma_{y}<+\infty$. Different Weibull coefficients corresponding to different categories of the dataset TweetedVideos are presented in Table I. This table includes also the P-square indicators which is the goodness of fit measure. We can see that the P-square is close to 1 for all categories which proves that the Weibull fit can model the distribution of the drop positions.

Using the Weibull distribution, we can now derive the instantaneous drop probability and the watching probability of a random chunk position $v_{i}$. To simplify our model, we suppose that viewers leaving a video must have watched the last chunks completely. It means a viewer who dropped a video $v$ at a chunk $v_{i}$ must have watched this chunk. Hence, the probability of watching a chunk $v_{i}$ can be expressed as follows:

[TABLE]

where $1-\int_{c=0}^{c=v_{i}}D_{p}(v_{i})$ is the probability of watching a video from position 0 to $v_{i}$ (not leaving a video between positions 0 and $v_{i}$) and $\int_{c=0}^{c=1}Dp_{y}dc$ is the probability of watching all chunks which is equal to 1. We define, now, the popularity of a chunk $v_{i}$ of a video $v$ belonging to a category $cg_{y}$ as the probability of requesting a video $v$ and consuming its chunk $v_{i}$. From equations (2) and (5), we can estimate this popularity as:

[TABLE]

After deriving the expression of chunk popularity, we will define our popularity-aware policies in the next section.

II-C Popularity-aware caching policies

In this section, we present two caching policies based on the popularity of chunks studied in the previous subsection; Proactive caching Policy PcP for cache pre-loading and Cache replacement Policy CrP for reactive cache removal. However, we need to introduce, first, our proposed distributed and synchronized video catalogue that contains the metadata of each stored video and helps to manage the data caching. This catalogue is associated with each cache. In fact, each catalogue is 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. Such a collaborative catalogue management helps to enhance the video selection delay by making video searching local and minimizing the communication overheads. A snapshot of a synchronized catalogue is illustrated in Figure 4.

II-C1 CrP

CrP is a reactive caching replacement policy that presents two new features: The first feature is the minimum replication strategy. Indeed, in previous edge caching studies, each fetched video is cached at the local cache whether it exists in the cluster or not, which means multiple copies of the same video can be cached. Even when the cache is full, other potentially needed videos have to be deleted to provide space for the duplicated video. In our system, a second copy of the video is only stored when the cache is available and this video is marked in the catalogue as Replica=1. In case of storage unavailability, only a single copy of the video is cached in the collaborative cluster. In our system, a video chunk is called a Replica, if a similar or a higher bitrate representation exists in the cluster because it is always possible to create a lower video quality from a higher one. In this way, when the cache is unavailable, if a higher representations exists, there is no need to store lower ones. The second new feature is the popularity-aware caching and removing. Indeed, if the cache is available, the incoming chunk request is stored even if it is a replica or an unpopular content. In case the storage is unavailable, all $P_{j,y,v,v_{i}}$ in the catalogue are ranked and the Less Popular Chunk (LPC) is selected. If the requested video chunk is a replica and its popularity is less than LPC, this chunk is not cached. The above approach guarantees that the highest popular chunks are cached and the number of stored videos is maximized due to the minimum replication policy and the LPC rule. The detailed CrP policy is presented in algorithm 1.

II-C2 PcP

We, also, propose a proactive caching policy where we populate the cache with the most popular chunks that are most likely to be requested. This pre-load is done based on the preference of active users connected to the base station as studied previously in section II-B. More specifically, high popular chunks are stored with the higher bitrate one by one until filling the cache. If the cache is still available, popular chunks are 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 has an initial cost. The proposed PcP is illustrated in algorithm 2.

II-D Proactive Chunks Caching and Processing (PCCP)

To illustrate the different events that can occur when a user connected to a BS $j$ requests a chunk of video $v_{i}^{l}$, we introduce our greedy algorithm, named Proactive Chunks Caching and Processing (PCCP) and detailed in algorithm 3. At the installation of the system, different caches and catalogues are initialized with the popular video chunks. On each chunk request arriving to the BS $j$, the catalogue is checked to find the chunk with the requested bitrate. If available, the viewer is served from the home node $j$ (see Figure 1, scenario 1) and the CrP policy is called to update the access time of the video. In addition to the requested chunk, $Wd$ potentially requested chunks from the same video are fetched. In this way, when the user requests to watch the next part, the video will be streamed without stalls. If the requested bitrate is not available at home node, a higher representation is searched locally (see Figure 1, scenario 2) and the possibility of serving the video from a neighboring BS is also studied. The option that has the lower cost is adopted. If the requested bitrate does not exist in the cluster and a local transcoding is not possible, a higher representation is searched in neighbor nodes. Depending on resources availability, the chunk of video can be transcoded at the neighboring node or locally (see Figure 1, scenarios 3,4 and 5) . If these options cannot be performed, the request is served from the CDN, either by bringing the same or a higher bitrate (see Figure 1, scenario 6 and 7). The CrP 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.

III Performance evaluation

III-A Simulation Settings

In this section, we will evaluate the performance of our system under different network configurations including storage capacity, processing capacity and popularity of videos. In our simulation, we considered that our network consists of 3 neighboring BSs attached to 3 MEC servers ($\mathcal{K}=3$). Let the video library $\mathcal{V}$ consist of 1000 different videos chosen randomly from the dataset in [11] and belonging to $G=$ 14 categories described previously in Table I. All videos are divided into chunks of 30 seconds each. We selected only videos with a duration lower than 1500 s (50 chunks) to limit the size of the set $P_{j,.,.,.}$. Each video has 4 different representations ($\mathcal{M}=4$). As configured in [5], we will set the bitrate variants related to each representation to be 0.45, 0.55, 0.67, 0.82 of the original video bitrate version. In this paper, we consider that all videos have the same original bitrate which is 2 Mbps. The popularity (number of views) of the chosen videos follows a Zipf distribution having a skew parameter $\alpha=0.5$. The parameters of users arrival and requests along with the cluster parameters are summarized in Table II.

The latency of getting a chunk of video for various scenarios follows a uniform distribution in a range of (a) [5-10] ms from the cloud remote servers (b) [1-2.5] ms when fetching different versions from the neighboring BSs (c) [0.25-0.5] ms from the home server. Several parameters are evaluated to prove the performance of our system: (a) cache hit ratio: is the number of requests that can be fetched or transcoded in the edge network (home or neighbor servers). (b) Average access delay: is the average latency to receive videos from different caches or from the CDN. (d) CDN cost: is the cost of fetching the chunks of videos from the CDN. The CDN cost is calculated as 0.03$ per GB. Our system is compared to different recently proposed systems, which are CachePro[3], CoCache[4], and JCCP[5].

III-B Simulation Results

III-B1 Impact of caching and processing resources

The cache size and the processing capacity are important parameters to test the efficiency of a caching system. Figure 5 shows the performance of different cache systems achieved for the described cluster for different cache and processing sizes. The results show the performance of our system in terms of cache hit ratio, access delay and cost. It can be seen that our PCCP heuristic with its CrP and PcP policies performs significantly better than the other caching systems even for low cache sizes or processing capability. For example, when the cache size is equal to 10% of the library size, PCCP achieves a hit ratio equal to 0.79 when $Wd=0$ and 0.97 when $Wd=1$ compared to JCCP, CoCache and CachePro achieving a cache hit ratio equal to 0.56, 0,46 and 0.51 respectively. We can see that our system performs more than 20 % better than the other systems without proactively fetching the next chunks ($Wd=0$). This can be explained by: (a) The proactive caching policy (PcP) that stores the highest popular chunks, which improves the probability to find the videos inside the cluster, (b) Collaboration between BSs to store different chunks of the same videos which makes caching a video possible, even when the cache is full, (c) Avoiding to store the whole video, since it is proved that viewers rarely watch the content to the end, which provides more space to cache a higher number of chunks, (d) The reactive caching policy (CrP) that stores only high popular chunks in the cache, removes only less popular chunks and avoids the replication of videos to maximize the number of cached videos. When $Wd=1$, we can see that the hit ratio becomes very high, which is explained by the fact that the next potentially requested chunks are fetched and served beforehand. Such prediction of the incoming requests contributes to increasing the hit ratio. The system with a prediction window $Wd=1$ incurs more cost and data fetching compared to the system without prediction. This can be explained by the additional cost of the chunk that is served but not watched by the user abandoning the video. This cost waste can be accepted since the loaded content is only a small chunk with a minimal cost.

III-B2 Impact of video popularity

Varying the popularities of videos has an important impact on our system since it is based on the preference of viewers.

Figure 6 presents the impact of changing the Zipf parameter $\alpha$ on cache hit and CDN cost. Specifically, a large $\alpha$ (high skewed popularity) represents a library with a small number of videos with similar popularities. It means the library contains videos with very high popularities and videos with very low popularities. In our simulation, we created another video library from the same dataset [11] containing videos with a larger $\alpha=0.7$, which makes the library contain videos with higher difference in terms of popularity. In this way, videos with very high popularity will be highly requested. Whereas, unpopular videos will be rarely or never requested. Figures 6(a) and 6(b) show that a higher skewed library gives better results in terms of cache ratio. This is explained by the fact that only a part of videos are frequently requested which are stored in the cluster thanks to the PcP policy. Also, even if the cache is low (10% of the library size), the size is enough to cache highly popular chunks which enhances the cache hit.

IV Conclusion

In this paper, we propose that different MEC servers collaborate to cache and transcode different chunks of one video content. In order to maximize the edge caching, we studied videos viewing pattern and we proposed CrP and PcP content placement policies for estimating the placement of video chunks in the BS caches based on a probabilistic model. Then, to schedule sharing videos between MEC servers, a greedy algorithm (PCCP) is proposed. The extensive simulation of our heuristic proves the performance of PCCP compared to other caching approaches in terms of cost, cache hit ratio and access delay.

Acknowledgment

This publication was made possible by NPRP grant 8-519-1-108 from the Qatar National Research Fund (a member of Qatar Foundation). The findings achieved herein are solely the responsibility of the author(s).