Mobile Edge Computing学习笔记（一）从通信领域看移动边缘计算：现有的经典结构与模型

MEC最近越来越火了，inforcom，mobicom各种顶会每年都有大量产出。看了一篇 IEEE COMMUNICATIONS SURVEYS & TUTORIALS的综述：A Survey on Mobile Edge Computing: The Communication Perspective，记录一下收获。

一、前言

在物联网和5G通信的愿景驱动下，近年来，移动计算发生了从集中式移动云计算向移动边缘计算（MEC）的转变。 MEC的主要功能是将移动计算，网络控制和存储推向网络边缘（例如，基站和接入点），以便在资源受限的移动设备上启用计算密集型和延迟关键型应用程序。 MEC将显着减少延迟和移动能源消耗，应对实现5G愿景的关键挑战。 MEC的成果已激发了学术界和工业界在开发该技术方面的广泛努力。 MEC研究的主要目的是无缝融合无线通信和移动计算这两个学科，从而产生了各种各样的新设计，从计算分流技术到网络体系结构。本文提供了对最新的MEC研究的全面概述，重点是联合无线电和计算资源管理。

二、简介

传统的云计算是集中式的，也就是将数据，算力都集中在一起，从而为终端的用户提供服务。但是据估计，在不久的将来，数以百亿计的边缘设备将被部署，它们的处理器速度将按照摩尔定律呈指数增长。获取分布在网络边缘的大量空闲计算能力和存储空间，可以为移动设备执行计算密集型和延迟关键型任务提供足够的能力。这种模式被称为移动边缘计算(MEC)，也就是拜托了传统的集中式方式，反而将计算转移到边缘设备上。长时间的传播延迟是云计算的一个关键问题，相反，具有近距离访问特性的MEC被广泛认为是实现下一代Internet各种愿景的关键技术。

1：5G技术包含的移动计算

同样移动云计算本来是发展的方向，用户远程利用云端的资源进行运算，但是远距离传输延迟是硬伤。对响应时间要求很高的应用显然不合适。在5G无线系统中，包括小细胞基站(BSs)、无线接入点(APs)、笔记本电脑、平板电脑和智能手机在内的超高密度边缘设备将被部署。每台计算机的计算能力可与十年前的计算机服务器相媲美。因此，大量的设备将在任何时候都处于空闲状态。也就是说我们能从网络边缘获取大量的计算和静态资源，这将足以支持无处不在的移动计算。无线系统的主要目标，从1G到4G。是对越来越高的无线速度的追求，以支持从以语音为中心的流量到以多媒体为中心的流量的转换。随着无线速度越来越接近有线计数器部分，5G的任务变得不同，也更加复杂，即支持ICT和互联网的爆炸性发展。在功能方面，5G系统将支持通信、计算、控制和内容交付(4C)。在应用方面，5G的大量新应用和服务正在涌现，比如实时在线游戏、VR等各种东西。现在普遍认为，仅仅通过云计算是不足以支持5G所要求的毫秒级延迟的。而移动边缘计算将计算，存储都推到网络边缘，十分符合下一代物联网的特征：“信息局部产生并局部处理”。

移动边缘计算的定义来源于，用基站分流移动设备的计算任务（为移动设备完成一部分计算）。Cisco再MEC的基础上，提出了Fog Computing的概念，将终端设备扩展从单纯的手机，笔记本扩展到了机顶盒这种设备。当然二者的思想很类似，基本上属于重合的领域。

2：移动边缘计算与移动云计算比较

MEC和MCC系统在计算服务器、到最终用户的距离和典型的延迟等方面存在显著差异。与MCC相比，MEC具有实现较低延迟、为移动设备节省能源、支持上下文感知计算、增强移动应用程序的隐私和安全性等优点。

• 低延迟：延迟分为三部分，传播延时，计算延时，通信延时。（i）终端设备与边缘计算节点的距离一般不超过1km，而和中心节点的距离可能超过几百公里。（ii）不仅是距离的问题，如果你的数据要发往某地，途径多个网络，网络的流量限制，拥塞程度都将会大大影响数据的传输速率和准确率。（iii）虽然集中式的云端具有超强的计算资源，但是他要把计算结果传回超多的终端应用，而边缘节点虽然算力不多，但是服务的应用也不多，而且下载算力提升很快，基本上够绝大部分5G应用。
• 能量节省：一个传感器就指甲那么大，构成了物联网的基石，他们的电量很少，而且大部分不能充电，还要承担比较多样的计算任务，此时如果我们将传感器的计算任务转移到边缘节点上，传感器只负责进行感知，那么就会大大延长它的寿命。
• 上下文感知计算：上文说了，终端和边缘节点之间的距离很近，传输很快，因此可以做很多实时的感知任务。比如再博物馆中根据用户的位置预测他们的兴趣。
• 隐私保护：云计算的数据都在一起，价值很高，很多人都想要去攻击他。但是边缘计算的数据分布十分松散，一个边缘节点存储不了多少数据，攻击它的意义不大。

三、MEC计算和通信模型

难就难在如何将各种功能和操作抽象为优化问题。

对于上图所示的MEC系统，关键组件包括移动设备(又称终端用户、客户端、服务sub scribers)和MEC服务器。MEC服务器通常是由云和电信运营商部署的小型数据中心，与终端用户距离很近，可以与无线APs一起使用。通过网关，服务器通过Internet连接到数据中心。移动设备和服务器由空中接口分隔，利用先进的无线通信和网络技术可以建立可靠的无线连接。

1：Computation Task Models

在计算任务的建模过程中，有许多重要的参数，包括延迟、带宽利用率、上下文感知、通用性和可伸缩性。虽然为任务开发精确的模型是非常复杂的，但也有一些简单的模型是合理的，下文将会介绍

（1）Task Model for Binary Offloading:

一个简单的任务不能被分割，要么在本地计算，要么传送给边缘节点帮你计算，只有两个选择。这种情况下的模型通常是这样的：
$A(L,\tau_d,X)$
$L$:任务数据量，单位bit， $\tau_d$:任务的ddl，单位秒， $X$:计算强度（CPU周期数/bit）。这三个参数的使用不仅捕获了计算，通信要求，也简化了对执行延迟和能量消耗表现的评估。

（2）Task Models for Partial Offloading:

一部分在终端计算，一部分在边缘节点计算。最简单的就是数据二进制，你随便分。然而数据之间往往不是独立的，有些任务的执行顺序必须按照要求，有些任务必须在本地（比如图像显示）。这就要求我们的任务分配能考虑数据内在的联系，其中一种是任务调用图，将任务作为节点，任务之间的关系作为边，就可以建模任务在完成顺序以及完成位置的要求。

2：Communication Models

对于集中式的云计算系统，着重于处理大规模的数据处理与核心网络的延迟，而不是无限传感的延时，因此他们经常假设无线传输像一个管道一样，速率恒定。MEC不一样，边缘节点本身的数据范围就不大，而且要满足一些对传输时间严格要求的应用，所以我们必须使用更接近现实的模型，精确化信息传输的延时。先来看一看无线信道和有限信道的差距

• 现实环境的物体会影响无线传输的质量，包括悬浮物/建筑物等等。
• 信号的互相干扰很难避免，无线传输最常用的就是广播，如果占用了同一频谱，信号就会冲突。干扰管理是无线传输很重要的一部分。
• 频谱资源短缺。

无线传输环境动态变化，有时候信号很差，我们将数据分流给边缘节点的传输率很低，还不如自己算，当然也可以增大发送频率，但这样同时也会增大能量消耗，如何在二者之间取得一个折中也是一个值得研究的问题。

3：Computation Models of Mobile Devices

在这里看看如何对移动设备进行建模

计算延迟定义如下：
$t_m=\frac{LX}{f_m}$
$L,X$都是上文说过的， $L$:任务数据量，单位bit， $X$:计算强度（CPU周期数/bit）, $f_m$是该移动设备的主频。主频越高，计算越快。

能量消耗定义如下：
$E_m=\kappa LXf_m^2$
$\kappa$是一个与硬件架构有关的参数，从上面的定义来看，如果移动设备在规定时间内难以完成任务，或者能量消耗太大，那不如将任务分流到边缘节点。

除此之外ROM,flash都会造成能量消耗，但是考虑他们就比较复杂了。

4：Computation Models of MEC Servers

计算延迟和能量消耗依然是需要注意的两大块，但是对于边缘节点而言，通信时长远远大于计算延迟，因为计算负载一般都不大，反而是通信的时间更长。因此计算时间一般可以忽略，当然如果节点计算能力很差，那肯定不能忽略。

（1）延迟建模

边缘节点对移动设备 $k$分流的数据的计算时间定义如下
$t_{s,k}=\frac{w_k}{f_{s,k}}$
$w_k$是计算 $k$设备分流数据总共需要的CPU周期数， $f_{s,k}$是分配给 $k$设备分配的服务器的主频。这个模型被广泛用于计算资源分配策略的制定。

边缘节点根据各移动设备传入数据的比例来分配算力，以使得终端设备的计算延迟相同，如果算力不足，可能还要处理排队的情况。因此，总共的服务器计算延迟定义如下：
$T_{s,k}=\sum_{i\leq k}t_{s,i}$
$k$在这里表示一个处理顺序，处理的是设备 $k$的数据。

对于可以容忍延迟的应用而言，平均的服务器计算时间可以根据随机的分布得出，比如任务的到达时间和服务时间可以根据Poisson和exponential分布建模。排队时间可以根据排队论建模，服务器的计算往往依赖于VM技术（虚拟机），但是多个虚拟机使用同一个物理设备往往会造成I/O冲突，造成一定的干扰和延迟，这个延迟可以这样建模：
$T_{s,k}'=T_{s,k}(1+\epsilon)^n$
$\epsilon$是性能下降因子，也是延迟增加的百分比。

（2）能量消耗建模

CPU的能量消耗是大头，也是研究的重点。其中一种模型基于DVFS技术。考虑一个MEC服务器，处理 $K$个计算任务，第 $k$个计算任务分配了 $w_k$个CPU周期和 $f_k$的CPU频率。因此总共的能量消耗为：
$E_s=\sum_{k=1}^K\kappa w_kf_{s,k}^2$
参数和终端的能量消耗类似。另一种模型是基于一个观察：即服务器能耗与CPU利用率成线性关系，CPU利用率取决于计算负载。即使对于一些空闲的服务器，当CPU全速计算时，仍然会有高达70%的能耗，相对于满负载。
$E_s=\alpha E_{max}+(1-\alpha)E_{max}u$
其中 $E_{max}$是完全使用的服务器的能耗，α是闲置能耗的一部分（例如70％），u表示CPU利用率。 该模型表明，高能效的MEC服务器应该适时的允许服务器切换到睡眠状态，将计算负载合并到较少的活动服务器上。

四、 MEC系统的资源管理

无线资源和计算资源的管理是实现节省能耗的关键，下图展示了目前常见的一些管理方法

1：Single-User MEC Systems

（1）Deterministic Task Model With Binary Offloading:

二进制的决策是这里的关键，对某个任务而言，我们到底应该分流还是本地计算？设 $B$为数据传输速率, $d$是数据量， $w$是数据计算需要的CPU周期数目， $f_m$是本地计算的CPU主频， $f_s$是云端的主频，分流可以带来较小的延迟当且仅当
$\frac{w}{f_m}>\frac{d}{B}+\frac{w}{f_s}$
在数据量较小但是计算量很大，云端计算很快或者数据传输速率特别高的情况下比较适合分流。让 $p_m$代表终端的计算功耗， $p_t$是数据传输功耗， $p_i$是分流到服务器的部分数据的功耗，那么分流可以帮助节省能量当且仅当
$p_m*\frac{w}{f_m}>p_t*\frac{d}{B}+p_i*\frac{w}{f_s}$
然饿，无线信道的传输频率是会随时间变化的，也会受到传输功率的影响。因此我们必须设计足够好的优化模型来选择适当的传输功率和计算功率。

（2）Deterministic Task Model With Partial Offloading

任务分解成子任务进行部分分流，也就是之前说的图模型或者任务随便分流， 通过将耗时或耗能的子任务分流到MEC服务器，与二进制分流相比，部分分流可以实现更大的节能效果和更小的计算延迟。 图论是根据任务依赖图设计卸载调度的强大工具。

（3） Stochastic Task Model:

随机任务模型:针对随机任务到达的MEC系统，已经制定了资源管理策略，随机任务模型以随机任务到达为特征，到达但尚未执行的任务加入任务缓冲区的队列。对于这样的系统，长期的性能，例如长期的平均能耗和执行延迟，与确定性的任务到达更相关，并且最佳系统操作的时间相关性使设计更具挑战性。因此，与具有确定性任务模型的简单情况相比，具有随机任务到达的MEC系统的设计是一个较少被开发的领域。MDP时常应用与这个方向。可以利用任务到达时间和通道的时间相关性来设计自适应动态计算分流策略。 此外，至关重要的是通过卸载速率控制来维护用户和MEC服务器上的任务缓冲区稳定性。

2：Multiuser MEC Systems

这一部分有多个终端设备共享一个边缘节点，这种情况下就会出现很多的问题：包括多用户联合无线和计算资源分配、MEC服务器调度和多用户协作边缘计算

1) 无限以及计算资源的联合分配

和中心化的云计算相比，边缘节点的计算能力本来就弱，因此如何合理的分配无线传输和计算的资源尤为重要。考虑具有有限无线电和计算资源的多用户MEC系统。对于系统级目标，例如，为了最小化移动总能耗，具有较大的通道增益和较低的本地计算能耗的用户具有较高的分流计算的优先级，因为他们可以做出较大的节能贡献。然而，过多的分流用户会导致严重的用户间通信干扰，这又会减小系统收益。

2）MEC服务器调度

为了有效地减少多个用户的计算延迟，MEC服务器的调度设计应该将更高的优先级分配给延迟要求更严格、计算负载更重的用户。此外，并行计算还可以进一步提高服务器的计算速度。

3）多用户协同计算

多用户协作计算被认为是一种很有前途的技术，可以通过提供两个优势来提高MEC的性能。首先，当MEC服务器必须为大量移动用户提供服务时，计算资源有限，可能会超载。在这种情况下，服务器的负担可以通过点对点移动协作计算来减轻。其次，在用户之间共享计算资源可以平衡计算工作负载和计算能力在用户之间的不均匀分布。

3、MEC Systems With Heterogeneous Servers

一个中心云，多个服务器，多级中心/边缘云的协调和交互引入了许多新的研究挑战，并且最近在服务器选择、协作和计算迁移方面吸引了广泛的相关研究。

1) 服务器选取

对每一个使用者，一个关键的问题是将计算分流到哪一个服务器？既可以是中心节点，也可以是边缘节点。考虑具有多个计算任务和异构服务器的MEC系统。为了减少总和计算延迟，最好将延迟不敏感但计算密集型的任务转移到远程中央云服务器，而将延迟敏感的任务转移到边缘服务器。

2) 服务器合作

通过服务器合作实现资源共享，不仅可以提高资源利用率，增加计算服务提供商的收入，还可以为移动用户提供更多的资源，增强用户体验。此外，服务器协作设计还应考虑时空计算任务到达和服务器的计算能力、时变信道和服务器的个人收益。

3）计算迁移

MEC服务器上的计算迁移是由分流用户的移动性驱动的。当用户移动到新的MEC服务器时，网络控制器可以选择将计算迁移到这个服务器，或者在原来的服务器中计算任务，然后通过新服务器将结果转发给用户。最经典的是基于随机行走迁移模型的MDP问题。结果表明，最优策略具有一个基于阈值的结构，即，只有当两个服务器的距离被两个给定的阈值限制时，才应该选择迁移。