1. 引入
云计算愿景是将计算、存储和网络管理集中到云中，指的是数据中心、骨干IP网络和蜂窝核心网络。云中大量的计算和存储资源可以被利用来解决终端用户的计算和存储需求。云计算主要缺点：长传播延迟。
云的功能逐渐向网络边缘转移（云端向边缘端）。收集分布在网络边缘的大量空闲计算能力和存储空间可以产生足够的容量，以便在移动设备上执行计算密集型和延迟关键型任务。这种范例被称为移动边缘计算(MEC)。从云到网络边缘的转移可以减少传播延迟，使得触觉互联网，物联网和Internet of Me。
1.1 5G 移动计算：从云端到边缘
高速率、高可靠性的空中接口允许在远程云数据中心运行移动设备的计算服务，因此被称为移动云计算(Mobile Cloud Computing，MCC)的研究领域。但是，移动计算依旧继承了云计算的缺点——长传播延迟，因此急需一种新的网络体系结构。
网络边缘部署了超密集的高性能边缘设备——小型蜂窝基站(BSs)、无线接入点(AP)、笔记本电脑、平板电脑和智能手机。每个时刻都会有空闲的设备，累加起来是一股很大的计算和存储资源，以满足无处不在的移动计算需求。如果说1G到4G的任务是增加无线通信速度，那么5G的任务更加复杂，即支持ICT和互联网的爆炸性发展。就功能来说，5G将支持通信，计算，控制和内容分发(4C)。未来，各种物联网设备的接入，非常依赖云或边缘计算。而云计算不足以支持5G要实现的各种功能，而且大量设备与云端进行数据交换，会造成网络的崩溃，MEC作为云计算的补充显得非常重要。MEC在本地即完成生成与消费。
云计算最初的定义是：在无线接入网（RAN）下，使用BSs设备将计算任务从移动设备上卸载。
最近，Cisco提出了雾计算的概念，MEC和雾计算的领域是重合的，讨论关于MEC的内容也适用于雾计算。
MEC 基于虚拟化平台实现，该平台利用了网络功能虚拟化(NFV)，以信息为中心的网络(ICN)和软件定义网络(SDN)方面的最新进展。具体来说，NFV通过创建用于同时执行不同任务或操作不同网络功能的多个虚拟机(VM)，使得单个边缘设备能够向多个移动设备提供计算服务。另一方面，ICN为MEC提供了另一种端到端的服务识别范例，从以主机为中心转变为以信息为中心，以实现内容感知计算。最后，SDN允许MEC网络管理员通过功能抽象管理服务，实现可扩展和动态计算。MEC研究的一个主要焦点是开发这些通用的网络技术，以便它们能够在网络边缘实施。
1.2 MEC与MCC对比
低延迟：
移动服务的延迟是传播、计算和通信延迟三个组件的聚合，分别取决于传播距离、计算能力和数据速率。
- MEC（小蜂窝网络或者设备到设备）相比于MCC（核心网到用户）传播距离更短，在几十米，因此传播延迟更低。
- MCC通过无线接入网、回程网络、互联网，在这些网络中流量控制、路由和其他网络管理操作导致延迟。而对于网络边缘，通信受到限制，没有这样的限制。
- MCC虽然计算能力比MEC强很多，但是MCC的计算要被更多的多的用户共享，相反，现代BS足以运行高度复杂的计算程序，所以实际每个用户的计算延迟和MEC的计算延迟不会差距很大。
- MCC的总时延一般在30ms-100ms之间，这对很多延迟关键型应用来说是不可接受的，这些应用需要触觉速度，延迟接近1ms。
移动能量储存：
为数以亿计的物联网设备频繁更换电池是不现实的。之前看到的解决方法是无电池EH-IoTs，通过能量感知的方式收集包括太阳能，动能，热能和电磁能。而MEC也是另外一个有前途的方向，MEC通过计算卸载技术，将计算密集型任务从物联网设备卸载到边缘，以降低设备能耗，延长电池使用寿命。
环境感知：
区分MEC和MCC的另一个关键特征是MEC服务器能够利用边缘设备与最终用户的接近度来跟踪他们的实时信息，如行为，位置和环境。基于这些信息的推理允许向最终用户提供环境感知服务。例如，根据用户的位置来预测用户的兴趣，以自动提供相关的目的地指引。
隐私/安全增强：
- MCC用户信息资源高度集中，容易受到攻击;MCC将用户数据的所有权和管理权分离，这将导致私有数据泄露和丢失的问题
- 由于MEC服务器的分布式部署、小规模特性，以及有价值的信息不太集中，MEC服务器成为安全攻击目标的可能性要小得多。许多MEC服务器可能是私有的Cloudlet，这将缓解信息泄露的担忧
1.3 主要动机
已经发表了几篇调查文章，以不同的侧重点概述MEC领域，包括系统模型、架构、使能技术、应用、边缘缓存、边缘计算卸载以及与物联网和5G的连接。鉴于以往的工作，还缺乏一篇系统的综述文章，对移动计算和无线通信深度融合的具体MEC研究成果进行全面而具体的讨论。
2. MEC的计算和通信模型
2.1 计算任务模型
-
二进制卸载的任务模型：二进制卸载：高度集成或者相对简单的任务不能被区分，作为一个整体来执行，所以不是完全在本地执行，就是完全卸载到MEC服务器上执行。这样的任务可以用 $A\left(L, \tau _{d}, X\right)$ 来表示，$L$ 表示任务输入数据的大小（单位bits），$\tau _{d}$ 表示完成截止时间（单位s），$X$ 表示计算强度（单位每bit所需CPU循环周期）。这些参数与任务本身有关，可以用任务分析器获知。
$A\left(L, \tau _{d}, X\right)$ 任务被要求在硬截止时间 $\tau _{d}$ 前完成，这也可以被推广到处理软截至时间约束，即允许一小部分任务在 $\tau _d$ 之后执行。在这种情况下，执行1bit任务输入数据所需的CPU周期数被建模为随机变量X。具体来说，定义 $x _0$ 作为一个正整数，使得 $Pr(X>x _0) \leq \rho$，其中 $0 <\rho \ll 1$。而且，$\operatorname{Pr}\left(L X>W _{\rho}\right) \leq \rho$，其中 $W _{\rho}=L x _{0}$。那么，给定 $L$ 位任务输入数据，$W _{\rho}$ 给出了所需CPU周期的上界。 -
部分卸载的任务模型：在实践中，许多应用程序由多个过程/组件组成，这使得实现细粒度的计算卸载成为可能。程序一部分在本地设备上执行，一部分被卸载用于边缘执行。
最简单的一种部分卸载的任务模型就是数据分割模型，每个比特是独立的，并且可以被任意划分为不同的组并由MEC系统中的不同实体执行，例如，在移动站和MEC服务器处并行执行。
但是，对于许多应用来说，不同过程之间的依赖关系是不可忽视的，会严重影响执行过程和计算卸载。
任务调用图（Task-call graph）可以建模这种具有依赖关系的任务执行。具体来说，他是一个有向无环图（DAG），将其表示为 $G(\mathcal{V}, \mathcal{E})$，其中顶点集合 $V$ 表示任务的不同过程，边集合 $\mathcal{E}$ 指定调用依赖性。子任务有三种典型的依赖关系模型，即顺序依赖关系，并行依赖关系和一般依赖关系。
对于移动设备发起的任务，通常第一步和最后一步都要在本地执行，例如收集I/O数据并将结果显示在屏幕上。因此节点1和N必须在本地执行。此外，还可以在任务调用图的顶点中指定每个过程所需的计算工作量和资源，例如所需的CPU周期数和所需的存储器量。而每个过程的输入/输出数据量可以通过在边缘上施加权重来表征。
2.2 通信模型
MCC通信信道：抽象为具有恒定速率或具有给定分布的随机速率的比特管。原因：解决核心网络中的延迟和大规模云的管理 MEC通信信道：考虑到小规模的边缘云和针对延迟关键型应用，通过设计高效的空中接口来减少通信延迟是主要的设计重点。所以与过于简化的MCC信道不同。
无线信道和有限信道区别：
- 码间串扰：多径衰落使得信道时变，带来严重的码间串扰（ISI），所以需要码间干扰抑制技术（如均衡和扩频）来实现可靠的传输。
- 干扰管理：无线传输的广播特性导致信号受到占用相同频谱的其他信号的干扰，为降低SINR下降的影响，干扰管理是一个研究重点。
- 频谱短缺：提高频谱效率。
卸载和无线传输进行联合设计：无线信道在时间、频率和空间上的随机变化使得无缝集成计算卸载控制和无线资源管理对于设计高效的MEC系统具有重要意义。例如，当无线信道处于深度衰落时，通过远程执行减少的计算延迟可能不足以补偿由于传输数据速率的急剧下降而导致的传输延迟的增加。对于这样的情况，希望推迟卸载，直到信道增益有利，或者切换到具有更好质量的替代频率/空间信道进行卸载。此外，增加发射功率可以增加数据速率，但也会导致更大的发射能量消耗。基于上述考虑，有必要对卸载和无线传输进行联合设计，基于准确的信道状态信息(CSI)来适应时变的信道。
MEC通信：在MEC系统中，通信通常在AP和移动设备之间进行，可以直接进行D2D通信。MEC服务器是云计算/电信运营商部署的小型数据中心，可以与公共WiFi路由器、BS等无线AP共存，以降低资本支出(CAPEX)(如站点租赁)。如图3所示，无线AP不仅为MEC服务器提供无线接口，而且能够通过回程链路访问远程数据中心，这有助于MEC服务器进一步将一些计算任务分流到其他MEC服务器或大型云数据中心。对于由于无线接口不足而无法直接与MEC服务器通信的移动设备，与相邻设备的D2D通信提供了将计算任务转发到MEC服务器的机会。此外，D2D通信还支持在移动设备群集内的资源共享和计算负载平衡方面的点对点协作。
对于手机和MEC服务器之间的远程通信，WiFi和LTE(或未来的5G)是实现MEC系统接入的两种主要技术，这些技术可以根据链路的可靠性进行自适应切换。
2.3 移动设备的计算模型
对于移动设备来说，CPU主频为 $f_m$，这是一个可变的数，允许升降 $f_m$ 以提高和降低能耗（DVFS技术）。对于计算任务 $A(L, \tau, X)$：
\[\tag{1} t_{m}=\frac{L X}{f_{m}}\]这表明需要较高的CPU时钟速度以降低执行等待时间，代价是较高的CPU能量消耗。
又因为一个CPU周期的能源消耗由 $\kappa f _{m}^{2}$ 给定，其中 $\kappa$ 是与硬件架构有关的一个常量。$A(L, \tau, X)$ 任务的能源消耗由下式给出：
\[\tag{2} E _{m}=\kappa L X f_{m}^{2}\]从(1)和(2)可以看出，移动设备可能无法在要求的期限内完成计算密集型任务，或者移动执行所产生的能量消耗过高，以至于车载电池将很快耗尽。在这种情况下，需要将任务执行过程卸载到MEC服务器。
2.4 MEC服务器的计算模型
确定性服务器计算延迟：
确定性模型是为了考虑延迟敏感型应用的确切服务器计算延迟而提出的，该模型是使用VM和DVFS等技术实现的。具体地，假设MEC服务器为不同的移动设备分配不同的VM，从而允许独立计算。令 $f _{s,k}$ 表示给移动设备 $k$ 分配的CPU周期频率，服务器的执行时间可以计算：
\[t _{s,k}=w _k / f _{s,k}\]其中，$w _k$ 表示完成被卸下的负载所需的CPU周期数。
另一个相似的模型是：
假设MEC服务器对所有负载进行负载均衡，即MEC的CPU周期按比例分配给各设备，保证处理延迟相同。
此外，除了CPU处理时间外，计算能力相对较小的MEC服务器还应考虑服务器调度排队延迟，其中通过虚拟化技术进行并行计算是不可行的，因此需要按顺序处理计算工作量。不失一般性，k表示处理顺序，因此包括k本身的处理时间和等待时间的总服务器计算延迟可以表示为：
\[\tag{3} T_{s,k}=\sum _{i\leq k} t _{s,i}\]随机模型计算延迟：
对于延迟有较大容忍度的应用，平均服务器计算时间可以基于随机模型来推导。例如，在[87]中任务到达时间和服务时间分别由泊松过程和指数过程建模。因此，可以使用排队论中的技术来推导平均服务器计算时间。
共享同一物理设施的虚拟机之间彼此也会有I/O干扰，导致延迟增加。新的虚拟机的延迟可以表示为 $T _{s, k}^{\prime}=T _{s, k}(1+\epsilon)^{n}$，其中 $\epsilon$ 是随着延迟百分比的增加而导致性能下降的因素。
MEC的能耗由CPU、存储、内存和网络接口的使用情况而定，但是CPU是主要因素。
MEC服务器能耗：
基于DVFS技术：
考虑处理K个计算任务的MEC服务器，第 $k$ 个任务被分配了 $w_k$ 个CPU周期（对应$f _{s,k}$）。因此，MEC 服务器上消耗的CPU总能量，用 $E _s$ 表示：
\[\tag{4} E _{s}=\sum _{k=1}^{K} \kappa w _{k} f _{s, k}^{2}\]这与移动设备的情况类似。
另一种模型是基于观察：服务器能耗与CPU利用率呈线性关系，CPU利用率依赖于计算负载。此外，即使对于空闲的服务器，它的平均能耗仍高达CPU全速运行的70%。因此，可以根据以下公式计算MEC服务器处的能耗。
\[\tag{5} E _{s}=\alpha E _{\max }+(1-\alpha) E _{\max } u\]其中，$E _{max}$ 是完全利用的服务器的能耗，$\alpha$ 是空闲能耗的分数（70%），$u$ 表示CPU的利用率。该模型建议，节能的MEC应该允许服务器在负载较轻的情况下切换到休眠模式，并将计算负载合并到较少的活动服务器中。
