论文阅读[20ICME]A MOBILE EDGE CACHE REPLACEMENT SCHEME FOR ADAPTIVE VIDEO STREAMING IN MULTI-MEC SERVERS

A MORE REFINED MOBILE EDGE CACHE REPLACEMENT SCHEME FOR ADAPTIVE VIDEO STREAMING WITH MUTUAL COOPERATION IN MULTI-MEC SERVERS

Published in: 2020 IEEE International Conference on Multimedia and Expo (ICME)

1介绍

在MEC服务器上预缓存部分视频，可以避免视频内容的重复传输，减少回程网络的负担，从而实现更快的业务响应。当前的研究工作中，MEC视频缓存更新策略还存在一些问题需要解决:(1)没有考虑视频前几段的重要性，可能导致初始延迟较大。(2)客户端的回放状态和通道状态被忽略，导致频繁的重缓冲事件。(3) MEC服务器之间的协作没有被充分利用，视频信息没有被共享。

2贡献

在上述工作的启发下，我们提出了一种更精细的MEC缓存更新策略，以提高系统吞吐量和段命中率，并减少回程流量、客户端回放冻结时间。我们的工作在以下几个方面是新颖的。
•基于每个片段的内容特性和流行程度，细化MEC缓存分区：根据每个片段的特性，将MEC缓存分为高流行和高重要缓存、高流行但低重要缓存和低流行缓存，以避免频繁更新时增加回程流量。
•结合段请求数和客户端传输状态计算段删除优先级:为了避免缓存的段无法匹配客户端传输能力的情况，我们将当前更新周期内的段请求数与客户端传输能力结合计算段删除优先级。
•缓存效用函数及最优解:综合考虑客户端的回放状态、通道状态以及MEC服务器间的协作机制，得到缓存效用函数。为了降低计算复杂度，我们将客户端缓存问题转化为分段缓存问题，并利用品牌和分支brand and branch method方法实现最优解。

3系统建模

3.1场景模型

在本文中，考虑这样一种场景，即多个客户端可以向本地MEC服务器请求视频流，合作的MEC服务器将共享视频流，如图1所示。**MEC系统主要由云服务器、MEC服务器、客户端和eNodeB构成。**首先，eNodeB根据客户端的视频请求向本地MEC服务器发送视频请求。如果视频流已经缓存在本地MEC服务器中，则会直接传输到eNodeB，然后再发送给请求的客户端。否则，本地MEC服务器将请求信息发送给合作MEC服务器共享视频流或从云服务器下载视频流。

我们用Q={1,…q,…, Q}表示MEC服务器的集合。每个具有Kq客户端的MEC服务区域由一个MEC服务器和多个enodeb提供服务。

3.2 Mec缓存更新策略

3.2.1 MEC Cache分区

如果所有存储的片段都是实时更新的，那么在当前时间段删除的网段可能需要在下一个时间段缓存，这会增加回程流量。因此，我们将MEC缓存分为三类，并采用∆1;∆2;∆3表示:(1)20%热门视频的前15%片段(视频的前15%的视频内容更为重要[9])构成缓存的第一部分∆1，(2)20%热门视频的剩余片段构成∆2，(3)其他视频片段构成∆3。缓存∆1每长周期更新一次，缓存∆2和∆3每短周期更新一次。

3.2.2 段更新策略

首先，我们利用请求数、客户端传输容量和段速率来获得MEC服务器q在γ期间不同版本段的删除优先级，其可以描述为

其中ζ和α是正变量。示客户端k是否在γ时间段内请求段i的版本l。如果要求，则，否则，。反映了平均传输容量与分段速率的匹配关系。

但是，仅根据当前时间段γ的删除优先级执行删除策略是不准确的，这可能会删除之前时间段的低删除优先级段。因此，我们采用前一期的删除策略对本期进行更新，如下:

在不同的缓存中，段更新策略是不同的。对于缓存∆1，由于前15%的段对客户端更重要，我们将根据每个周期J的最新段流行度进行更新。对于缓存∆2和∆3，由于回程的传输容量有限，我们需要决定应该缓存哪一段。为了使删除和缓存的效益最大化，我们共同优化了缓存∆2和缓存∆3的缓存更新策略。
缓存策略:为了根据每个客户端对应的回放缓存状态更好地区分客户端的紧急程度，使用分段指数函数表示请求版本l段i的客户k的缓存优先级，如下所示:

客户端k在周期γ结束时接收版本l的段i−1时的剩余缓冲时间。表示视频f的第l个版本的第i段的大小。w是正常数。
删除策略:在每个缓存更新周期γ中，将∆2和∆3中存储的段按照除正在传输的段外的段的整体删除优先级依次删除，直到缓存的大小足以存储待下载的段为止。

3.2.3 MEC缓存空间传输

为了充分利用每个缓存空间，我们在每个更新周期前后比较∆1的大小，释放或增加∆2和∆3的部分空间。在每个时期J开始时，∆1的变化大小由

表示流行视频的集合。为J−1周期∆1的大小。则可以根据更新∆2和∆3的和大小

3.2.4MEC服务器之间的协作机制

如果相邻MEC服务器存储请求的段，则本地MEC服务器将从剩余传输容量最大的相邻MEC服务器p下载请求的段。下载的段大小之和不能超过本地MEC服务器q和相邻MEC服务器p之间的传输容量。

4 问题的表述和最优解

4.1.客户端缓存优先级效用函数

由于来自云服务器和相邻MEC服务器的段时间不同，当从云服务器下载请求的段时，需要提高客户端k的缓存优先级，否则保持不变。则可将客户端缓存优先级的效用函数定义为

4.2问题公式化

在缓存∆1中，缓存更新策略是每J周期更新热门视频的前15%片段，这是相对固定的。在缓存∆2和∆3中，目标是缓存尽可能多的高缓存优先级客户端请求的段，这可以转换为最大化客户端的总缓存效用，如下所示:

约束(c1)意味着要缓存的段不应大于∆2和∆3的大小。约束(c2)保证段不能被重复缓存。约束(c3)和约束(c4)表示从相邻MEC服务器和云服务器下载的段的大小不应分别超过相应的传输容量。
为了解决的问题，我们采用brand and branch method来获得最优解。算法1描述了我们提出的算法的详细过程。

5实验结果

5.1 比较算法

本节比较的算法有:
Proposed:本文提出的缓存更新算法。
LRU: Least Recently Used。该算法的思想是:前一段时间请求的数据越多，后一段时间请求的数据越多。
LFU:最少使用。该算法的思想是:如果数据被频繁请求，那么它在未来被请求的概率也会更高。
WGDSF:加权贪婪双大小频率。该算法是对贪婪双大小频率算法的改进，增加了基于频率的加权时间和加权文档类型的因素。
RBCC:考虑视频速率、初始延迟、中断时间、版本切换和公平性的缓存替换策略。

5.2 实验结果

在图4 (a)、(b)和©中，我们给出了MEC服务器1、2和3初始缓存空间分别为650MB、500MB和550MB时客户端的吞吐量对比。可以看出，与其他四种比较算法相比，本文算法的客户端吞吐量总体上是最高的，因为它综合考虑了请求段的大小和客户端的当前剩余缓冲时间，并动态调整段缓存更新策略，以确保客户端的吞吐量能够满足流畅播放的要求。
图4 (d)给出了不同MEC总缓存大小下的平均吞吐量。在初始阶段，该算法的平均吞吐量最高，其次是WGDSF和RBCC算法，LRU算法的平均吞吐量最低。随着MEC缓存空间的增加，WGDSF和RBCC算法的平均吞吐量相对接近，交替导致不同的MEC缓存大小，但始终高于LFU和LRU算法。当MEC总缓存空间为2.4 GB时，各算法的平均吞吐量达到最大值，与LRU、LFU、WGDSF和RBCC相比，本文算法的平均吞吐量分别提高了60:7%、23:3%、9:8%和5:9%。

在图5 (a)、(b)和©中，我们给出了MEC服务器1、2和3初始缓存分别为650MB、500MB和550MB时的回程流量对比。总体而言，与其他算法相比，虽然本文算法的部分客户端回程流量较高，但我们仍然可以保证大多数客户端的回程流量较低。由于该算法考虑了在每个缓存更新周期中缓存或删除整个段的好处，因此它可以为大多数客户端缓存更合适的版本段。图5 (d)为不同MEC总缓存大小下的平均回程流量。随着MEC缓存空间的增大，各算法的平均回程流量逐渐减小，所提算法的平均回程流量始终保持最低。

图6 (a)和(b)分别为不同MEC总缓存大小的段的平均冻结时间和命中率。禁用MEC缓存时，平均冻结时间为4.2s。这是因为客户端需要通过eNodeB向云服务器请求该段，这会导致传输延迟较大。随着MEC总缓存大小的增大，各算法的平均冻结时间减小，段命中率增大。