移动边缘计算与计算卸载综述

移动边缘计算：架构与计算卸载综述

一、引言

用户对数据速率和服务质量（QoS）的需求呈指数级增长。此外，智能手机、笔记本电脑和平板电脑的技术演进催生了新的高需求服务和应用程序。尽管新型移动设备在中央处理器（CPU）性能方面越来越强大，但这些设备可能仍无法在短时间内处理需要大量计算的应用程序。此外，高电池消耗仍然是限制用户在其设备上充分使用高需求应用程序的重要障碍。这推动了移动云计算（MCC）概念的发展，使移动用户能够享受云计算服务[1]。在MCC中，用户设备（UE）可以利用远程强大集式云计算中心的计算和存储资源。

（CC），可通过移动运营商的核心网络（CN）和互联网进行访问。移动云计算（MCC）带来了多项优势[2]：1）通过将应用程序的耗能计算卸载到云，延长电池寿命；2）使移动用户能够使用复杂应用；3）为用户提供更高的数据存储能力。然而，由于数据需要发送到在网络拓扑上远离用户的强大服务器集群，移动云计算也给移动网络的无线接入和回传链路带来了巨大的额外负载，并引入了高延迟。

为了解决延迟较长的问题，云服务应被移至用户设备（UE）的邻近位置，即移动网络边缘，这正是新出现的边缘计算范式所考虑的方式。边缘计算可以理解为移动云计算（MCC）的一个特例。然而，在传统的移动云计算中，云服务是通过互联网连接进行访问的[3]，而在边缘计算中，计算/存储资源应位于用户设备附近（从网络拓扑意义上而言）。因此，与移动云计算相比，多接入边缘计算（MEC）能够提供显著更低的延迟和抖动。此外，移动云计算采用完全集中式架构，计算机集群通常部署在一个或少数几个位置，而边缘计算则应以完全分布式方式进行部署。另一方面，相对于移动云计算，边缘计算提供的计算和存储资源是有限的。表I概述了移动云计算与边缘计算在关键技术方面的高层次对比。

首个将计算/存储更靠近用户设备的边缘计算概念是2009年提出的云朵[4]。云朵背后的理念是在战略位置部署具有高计算能力的计算机，以便为附近的用户设备提供计算资源和存储。计算“热点”的云朵概念类似于WiFi热点场景，但云朵为移动用户提供的是云服务，而非互联网连接。事实上，云朵主要应

表I：移动云计算与边缘计算概念的高级比较

技术方面	MCC	边缘计算
部署	集中式	分布式
与用户设备的距离	High	Low
延迟	High	Low
抖动	High	Low
计算能力	充足	有限
存储容量	充足	有限

由于用户设备在利用云组服务时必须在移动网络和无线保真之间切换，因此通过无线保真连接访问移动用户设备被视为一个缺点[2]。此外，与移动云计算类似，用户设备的服务质量难以得到满足，因为云朵并非移动网络的固有部分，且无线保真的覆盖范围仅限于本地，对移动性的支持有限。

另一种实现边缘云计算的选项是通过自组织云在用户设备（UE）上直接进行计算，使得邻近的多个用户设备能够结合其计算能力，从而在本地处理高需求应用[5]‐[14]。为了实现自组织云，需要解决若干关键挑战：1）在邻近范围内找到合适的计算用户设备，同时确保处理后的数据能被交付回源用户设备；2）尽管缺乏控制信道来支持可靠的计算，仍需实现计算用户设备之间的协调；3）考虑到电池消耗和额外的数据传输限制，必须激励计算用户设备向其他设备提供其计算能力；4）安全与隐私问题。

与云朵和自组织云相比，边缘计算的一个更广泛的概念被称为雾计算。雾计算范式（在文献中常简称为Fog）由思科于2012年提出，旨在使应用程序能够在网络边缘的数十亿互联设备上进行处理[15]。因此，雾计算可被视为物联网（IoT）和大数据应用的关键推动者之一[16]，因为它提供：1）由于计算设备靠近网络边缘而实现的低延迟和位置感知；2）与云计算中心相比更广泛的地理分布；3）大量节点（例如无线传感器）的互连；以及4）对流媒体和实时应用程序的支持[15]。此外，雾计算的特性还可应用于许多其他应用和场景，如智能电网、用于智能交通系统（ITS）的联网车辆或无线传感器网络[17]‐[20]。

从移动用户的角度来看，上述所有边缘计算概念最显著的缺点是，由于计算未集成到移动网络架构中，因此很难保证用户的QoS和QoE（体验质量）。一种将云能力集成到移动网络架构中的概念是云无线接入网络（C‐RAN）[21]。C‐RAN利用了分布式协议栈[22],的思想，即将协议栈的部分层从分布式的射频远程头（RRHs）迁移到集中的基带单元（BBUs）。然后，BBU的计算能力被汇聚成虚拟化资源，能够为数十、数百甚至数千个RRHs提供服务。

尽管该虚拟化BBU池的计算能力主要用于集中控制和基带处理，但也可用于向网络边缘进行计算卸载（例如，[23]）。另一种将边缘计算集成到移动网络架构中的概念由新成立的（2014）欧洲电信标准协会（ETSI）内的行业规范组（ISG）[24]。ETSI提出的解决方案被称为多接入边缘计算（MEC）。与MEC相关的标准化工作由主要的移动运营商（例如NTT DOCOMO、沃达丰、意大利电信）和制造商（例如IBM、诺基亚、华为、英特尔）推动。ISG MEC小组的主要目的是实现云计算功能在移动网络中的高效且无缝集成，并为所有利益相关者（移动运营商、服务提供商、供应商和用户）创造有利的发展条件。

迄今为止，已发表多篇关于云计算的综述文章。在[3],中，作者综述了移动云计算应用模型，并强调了其优点和不足之处。在[25],中研究了移动云计算中的异构性问题。该异构性指的是移动设备的多样性、不同云服务提供商所提供的服务、基础设施、平台以及各种通信介质和技术的差异。该论文分析了这种异构性对移动云计算的影响，并讨论了相关挑战。在[26]中，作者综述了移动云媒体领域的现有研究成果，该技术通过互联网和移动无线网络提供丰富的多媒体服务。上述所有论文总体上关注的是移动云计算，其中云并未专门部署在移动网络边缘，而是通过互联网进行访问。由于多接入边缘计算具有广泛的应用潜力，工业界和学术界均投入大量精力专注于多接入边缘计算的研究。尽管如此，目前仅有一篇主要聚焦于多接入边缘计算的综述[27]，但该综述仅简要回顾了几项与多接入边缘计算相关的研究工作，并通过描述关键属性提出了多接入边缘计算的分类体系。此外，在[28]中，作者全面综述了各种边缘计算概念中的安全问题。另外，在[29]中，作者用一个章节专门讨论边缘计算，考虑了经济与定价模型在边缘计算资源管理中的应用。

与上述综述不同，我们描述了MEC的关键用例和场景（第二节）。然后，我们调研了文献中提出的将MEC功能集成到移动网络中的现有MEC概念，并讨论了MEC的标准化问题（第三节）。之后，本文的核心部分聚焦于关于向移动边缘计算卸载计算的技术研究。一方面，从用户角度来看，计算卸载可被视为一个关键用例，因为它能够在用户设备上运行新的复杂应用，同时降低其能耗（例如，参见[30]‐[36]，其中假设向远程云中心进行计算卸载）。另一方面，计算卸载带来了若干挑战，例如选择适当的应用与编程模型、准确估计能耗、有效管理多个用户的并发卸载，或虚拟机（VM）迁移[37]。在这方面，我们概述了与计算卸载相关的若干通用原则，如卸载分类（完全、部分卸载）、影响卸载的因素以及实际中的卸载管理（第四节）。随后，我们对

研究社区在应对将计算卸载到多接入边缘计算中的以下关键挑战方面所做的努力：

•关于计算卸载的决策，旨在确定对于用户设备而言，从能耗和/或执行延迟的角度来看，向多接入边缘计算的卸载是否有利可图（第五节）。

在多接入边缘计算中，为了最小化执行延迟并平衡计算资源和通信链路的负载，当计算被卸载时，需要对计算资源进行高效分配（第五节）。

•移动性管理针对卸载到多接入边缘计算的应用，当利用多接入边缘计算的用户设备在网络中漫游时，保证服务连续性（第七节）。

此外，我们总结了关于向移动边缘计算卸载计算的最新研究中的经验教训（第八节），并概述了若干开放挑战，这些挑战需要得到解决，以便使多接入边缘计算对所有利益相关者都有利（第九节）。最后，我们总结了总体成果并得出结论（第十节）。

II. 用例和服务场景

多接入边缘计算为所有利益相关者（如移动运营商、服务提供商或用户）带来了诸多优势。根据《[38][39],》中的建议，多接入边缘计算可分为三大主要用例类别，具体取决于其对哪些主体有利可图（见图1）。接下来的小节将讨论各个用例类别，并指出若干关键的服务场景和应用程序。

A. 面向消费者的服务

第一类用例面向消费者，因此应直接使终端用户受益。通常情况下，用户主要通过计算卸载从多接入边缘计算中获益，从而能够在用户设备上运行新兴的应用程序。其中受益于计算卸载的应用之一是网页加速浏览器，该应用将大部分浏览功能（如网页内容评估、优化传输等）卸载到多接入边缘计算；有关将网页加速浏览器卸载到多接入边缘计算的实验结果，参见[40]。此外，面部/语音识别和图像/视频编辑也适用于多接入边缘计算，因为这些应用需要大量的计算和存储资源[41]。

此外，基于增强现实、辅助或虚拟现实的应用程序可以利用向移动边缘计算卸载计算任务。这些应用程序通过分析用户周边环境来获取有关用户周边环境的附加信息（例如，游览的游客可以在其邻近区域找到兴趣点）。这可能需要快速响应和/或用户设备无法提供的大量计算资源。[42]展示了多接入边缘计算在增强现实中的适用性。作者在一个真实的多接入边缘计算测试平台上证明，通过向移动边缘计算卸载计算任务，可实现延迟降低高达88%以及用户设备能耗降低高达93%。

此外，运行低延迟应用程序（如在线游戏或远程桌面）的用户可能会从邻近的多接入边缘计算中受益。在这种情况下，特定应用的新实例将在适当的移动边缘

主机上启动，以降低用户设备上该应用的延迟和资源需求。

B. 运营商和第三方服务

第二类使用场景由运营商和第三方可以受益的服务组成。对运营商或第三方有利可图的一个使用案例是从用户或传感器收集大量数据。这些数据首先在多接入边缘计算（MEC）节点进行预处理和分析，然后将预处理后的数据发送到远程的中央服务器进行进一步分析。该场景可用于安全相关的目的，例如区域监控（如停车场监控）。

另一个用例是利用MEC（多接入边缘计算）实现物联网（Inter‐ net of Thing）目的[43]‐[45]。通常，物联网设备通过多种无线技术（例如3G、LTE、WiFi等）并使用不同的通信协议进行连接。因此，需要一个低延迟的汇聚点来处理各种协议、消息分发和数据处理。这可以通过将MEC作为物联网网关来实现，其作用是将物联网服务聚合并传递到高度分布式的移动基站，从而支持实时响应的应用程序。

多接入边缘计算也可用于智能交通系统，将联网汽车云扩展到移动网络中。因此，直接在多接入边缘计算上运行的道路侧应用程序可以直接从车辆中的应用程序和路侧传感器接收本地消息，分析这些信息，并以极低的延迟向附近车辆广播警告（例如，发生事故）。诺基亚及其合作伙伴最近在运营商的长期演进技术网络中展示了多接入边缘计算在车对车和车对基础设施通信中的应用，具体见2016[46][47]。

C. 网络性能和用户体验质量提升服务

第三类用例是优化网络性能和/或提升用户体验质量。其中一个用例是实现无线网络与回传网络之间的协调。迄今为止，如果回传链路或无线链路的容量下降，由于网络的另一部分（分别为无线或回传）无法感知到这种下降，整体网络性能也会受到负面影响。在这方面，利用多接入边缘计算的分析应用可提供无线/回传网络流量需求的实时信息。然后，运行在多接入边缘计算上的优化应用根据需要按应用重塑流量或重新路由流量。

提高网络性能的另一种方式是在移动边缘进行本地内容缓存，以缓解拥塞的回传链路。通过这种方式，MEC应用可以存储其地理区域中最受欢迎的内容。当用户请求该内容时，无需通过回传网络进行传输。

除了缓解和优化回传网络外，多接入边缘计算还能帮助实现无线网络优化。例如，收集来自用户设备的相关信息并在边缘进行处理，将实现更高效的

调度。此外，多接入边缘计算还可用于移动视频传输优化，通过为传输控制协议（TCP）提供吞吐量引导来实现。传输控制协议在无线信道上难以适应快速变化的条件，导致资源利用效率低下。为解决此问题，分析型MEC应用可向后端视频服务器提供关于估计吞吐量的实时指示，从而将应用层编码与估计吞吐量相匹配。

III. MEC架构与标准化

本节介绍并比较了集成到移动网络中的边缘计算的若干概念。首先，我们概述了文献中提出的各种MEC解决方案，这些方案能够将计算能力靠近用户设备。其次，我们描述了欧洲电信标准协会（ETSI）标准化组织在MEC方面所做的工作。最后，我们从多个角度（如MEC控制、计算/存储资源的位置等）对现有MEC概念（包括文献和ETSI中提出的概念）进行了比较。

A. MEC概念概述

近年来，文献中提出了多种旨在将云能力无缝集成到移动网络架构中的多接入边缘计算概念。本节简要介绍小区云（SCC）、移动微云（MMC）、快速移动个人云、随行云（FMC）和CONCERT的基本原理。此外，本节还展示了为实现每种多接入边缘计算概念所需的网络架构增强/修改。

1) 小小区云（SCC）

SCC的基本思想最初由2012年的欧洲项目TROPIC[48][53],提出，即通过增加计算和存储能力来增强小小区（SCeNBs），例如微蜂窝、皮基站或飞基站。类似的思想后来也在SESAME项目中被提及，其中支持云的SCeNBs实现了边缘计算[49][50]。云增强型SCeNBs可通过利用网络功能虚拟化（NFV）[51][52]范式来聚合其计算能力。由于未来移动网络预计将部署大量SCeNBs，因此SCC能够为用户设备提供充足的计算能力，特别是对延迟有严格要求的服务/应用（此类应用示例列于第二节‐IIA）。

为了将SCC概念充分且平滑地集成到移动网络架构中，引入了一个新实体，称为小区管理器（SCM），用于控制SCC[53]。SCM负责管理由小小区基站提供的计算和/或存储资源。由于小小区基站可以随时开启或关闭（特别是在用户拥有的情况下，如飞基站），因此SCM在SCC内对计算资源执行动态弹性管理。SCM掌握整体集群上下文（包括无线和云方面），并决定在哪里部署新的计算任务或何时迁移正在进行的计算，以优化终端用户的服务交付。

计算资源通过位于小小区基站（SCeNBs）处的虚拟机（VM）实现虚拟化。关于SCC架构的一个重要方面是SCM的部署（见图2）。SCM可以以集中式方式部署，作为位于无线接入网（RAN）内、靠近SCeNB簇的独立SCM，或作为移动性管理实体（MME）的扩展[53][54]。此外，SCM也可以采用分布式层级式方式进行部署，其中本地SCM（L‐SCM）或虚拟本地SCM（VL‐SCM）负责管理附近小小区基站簇的计算和存储资源，而位于核心网（CN）的远程SCM（R‐SCM）则可调用所有连接至核心网的小小区基站的资源[55]（见图2b）。

2) 移动微云(MMC)

移动微云（MMC）的概念首次在[56]中提出。与SCC类似，MMC也允许用户以低延迟即时访问云服务。在SCC中，计算/存储资源由相互协作的小小区基站（SCeNBs）簇提供，而在MMC中，用户设备（UEs）利用单个MMC的计算资源，该MMC通常直接连接到无线基站（即移动网络中的eNB），如图3所示。MMC概念不会在网络中引入任何控制实体，其控制功能被假定为

以与SCC的虚拟本地SCM方案类似的方式实现完全分布式。为此，MMC通过直接互连或通过回传链路相连，以在用户设备在网络中移动时保证服务连续性，从而实现MMC之间的平滑虚拟机迁移（有关虚拟机迁移的更多细节，请参见第七节‐B）。

3) 快速移动个人云(MobiScud)

MobiScud架构[57]通过软件定义网络（SDN）[58]和NFV技术将云服务集成到移动网络中，同时保持与现有移动网络的向后兼容性。与SCC和MMC概念相比，MobiScud中的云资源并非直接位于接入节点（如SCeNB或eNB），而是位于RAN内部或靠近RAN的运营商云中（见图4）。尽管如此，这些云仍被视为高度分布式，与SCC和MMC类似，可为附近的所有用户设备提供云服务。

与SCC类似，MobiScud引入了一个新的控制实体，即MobiScud控制（MC），该实体与移动网络、SDN交换机以及运营商的云进行交互。基本上，MC具有两种功能：1）监控控制平面信令消息交换

1）移动网络中的网元需感知用户设备的活动（例如，切换）；2）在支持SDN的传输网络内协调和路由数据流量，以支持应用卸载以及当用户设备在网络中移动时的虚拟机迁移。

4) 随行云（FMC）

FMC的核心思想是，运行在分布式数据中心（DCs）上的云服务会像MobiScud中一样，随着用户设备在网络中的移动而跟随其迁移[59][60]。与之前的多接入边缘计算概念相比，计算/存储能力被推向离用户设备更远的位置——即运营商的核心网网络中。然而，尽管之前的多接入边缘计算概念假设采用较为集式的核心网部署，FMC则利用了移动运营商为应对用户设备数量增长而必须实现网络去中心化的趋势。在这方面，当前网络部署中使用的集中式核心网预计将被分布式核心网所取代，如图5所示。为了便于移动运营商的部署，数据中心可与分布式S/P‐GW部署在同一位置。

与SCC和MobiScud类似，FMC在网络架构中引入了新的实体：DC/GW映射实体和FMC控制器（FMCC）。这些可以是与现有网络节点共址的功能实体，也可以是在任何数据中心（DC）上运行的软件（即利用NFV原则，如SCC或MobiScud概念）。DC/GW映射实体根据各种指标（例如位置或DC与分布式核心网之间的跳数）以静态或动态方式将数据中心映射到分布式S/P‐GW。FMCC管理DC的计算/存储资源、在其上运行的云服务，并决定应将哪个DC与使用云服务的用户设备（UE）相关联。FMCC可以集中部署（如图5所示），也可以分层部署[61]（包含全局FMC控制器（G‐FMCC）和本地FMC控制器（L‐FMCC）），以实现更好的可扩展性（其控制方式类似于第三节‐A1中所述的SCC）。需要注意的是，FMC本身也可以通过完全省略FMCC来实现去中心化控制。在这种情况下，数据中心将以自组织方式进行协调。

5) CONCERT

一种融合云和蜂窝系统的概念被提出，简称为CONCERT[62]。CONCERT假设采用上述解决方案类似的NFV原则和SDN技术。因此，由传统移动通信和云计算服务共同使用的计算/存储资源被呈现为虚拟资源。控制平面主要由一个称为导控器的控制实体组成，该实体负责管理CONCERT架构中的通信、计算和存储资源。导控器可以像SCC或FMC一样集中部署，或以分层方式部署，以提高可扩展性。数据平面由物理上表示eNB的无线接口设备（RIEs）、SDN交换机以及计算资源组成（见图6）。这些计算资源既用于基带处理（类似于C‐RAN），也用于应用层处理（例如，用于应用卸载）。在所有已描述的多接入边缘计算概念中，计算/存储资源都是完全分布式的。而CONCERT则提出在网络内对资源进行分层部署，以便灵活且弹性地管理网络和云服务。在这方面，假设在物理基站处直接部署具有低计算能力的本地服务器（例如，类似于SCC或MMC），当本地资源不足时，则利用区域甚至中央服务器，如图6所示。

B. 欧洲电信标准协会多接入边缘计算

除了上述所有解决方案外，欧洲电信标准协会（ETSI）目前也正深入参与标准化活动，以将多接入边缘计算（MEC）集成到移动网络中。在这方面，我们简要总结了ETSI在MEC方面的标准化工作，描述了ETSI定义的参考架构，并探讨了迄今为止所考虑的MEC部署的各种选项。

1) 欧洲电信标准协会多接入边缘计算的标准化

多接入边缘计算的标准化仍处于初期阶段，但ISGMEC已发布了规范草案。各规范中涉及的概念性、架构的术语

功能元素在[63]中进行了描述。本文档的主要目的是确保所有与多接入边缘计算（MEC）相关的欧洲电信标准协会（ETSI）规范使用相同的术语。ISG MEC用于协调和推广MEC的框架在概念验证（PoC）规范[64]中进行了定义。该文档的基本目标是描述PoC活动流程，以促进MEC的发展，阐明MEC的关键方面，并建立对MEC技术可行性的信心。此外，在[65]中提出了若干可从MEC及云服务邻近性中受益的服务场景（详见第II节）。此外，为保证互操作性并促进MEC部署，[38]中引入了针对MEC的技术要求。这些技术要求分为通用要求、服务要求、运行和管理要求，以及安全、法规和计费要求。

2) ETSI MEC参考架构

欧洲电信标准协会在[66],中描述的参考架构由功能元素和参考点组成，以实现它们之间的交互（见图7）。基本上，这些功能模块不一定代表移动网络中的物理节点，而是运行在虚拟化基础设施之上的软件实体。虚拟化基础设施被理解为运行虚拟机的物理数据中心，而虚拟机则代表各个功能元素。在这方面，假设将重用来自与欧洲电信标准协会多接入边缘计算并行运行的ETSI NFV小组的一些架构特性，因为网络功能虚拟化的基本思想是将所有网络节点功能虚拟化。

如图7所示，多接入边缘计算（MEC）可由直接位于用户设备中的用户设备应用，或通过面向客户的业务（CFS）门户的第三方客户（如商业企业）来使用。用户设备和CFS门户均通过MEC系统级管理与MEC系统进行交互。MEC系统级管理包含用户应用生命周期管理（LCM）代理，用于协调在MEC系统内用户设备应用的启动、终止或迁移等请求。

移动运营商的运营支持系统（OSS）。然后，OSS决定是否批准请求。被批准的请求将被转发给移动边缘编排器。移动边缘编排器是MEC系统级管理中的核心功能，因为它掌握着可用的计算/存储/网络资源以及MEC服务的整体视图。在这方面，移动边缘编排器会根据应用程序的需求（例如延迟）将虚拟化的MEC资源分配给即将启动的应用程序。此外，编排器还可以灵活地对已运行应用程序的可用资源进行扩展或缩减。

MEC系统级管理与MEC服务器级管理相互连接，构成移动边缘平台和虚拟化平台管理器。前者负责管理应用程序生命周期、应用程序规则和服务授权、流量规则等；后者负责管理位于MEC服务器内的虚拟化基础设施所提供的虚拟化计算/存储资源的分配、管理和释放。MEC服务器是参考架构的重要组成部分，因为它代表了虚拟化资源，并承载在虚拟化基础设施之上以虚拟机形式运行的MEC应用程序。

3) ETSI MEC部署选项

如前一小节所述，MEC服务由多接入边缘计算服务器提供，这些服务器可使用其可用的计算和存储资源。在移动网络中，MEC服务器有多种部署位置选项。第一种选项是将MEC服务器直接部署在基站处，类似于SCC或MCC的情况（参见第三节‐A1和第三节‐A2）。需要注意的是，在传统网络部署情况下，例如3G网络，MEC服务器也可以部署在3G无线网络控制器上[38]。第二种选项是将MEC服务器放置在小区汇聚站点或多RAT汇聚点，这些位置可以位于企业场景（例如公司）或公共覆盖场景（例如购物中心、体育场、机场等）内。第三种选项是将MEC服务器远离用户设备，并将其部署在核心网边缘，类似于FMC（第三节‐A4）。

当然，MEC服务器的部署选择取决于许多因素，例如可扩展性、物理部署约束和/或性能指标（如延迟）。例如，采用完全分布式MEC服务器部署的第一个选项将实现非常低的延迟，因为用户设备靠近演进型节点B，因此也靠近多接入边缘计算服务器。相反，利用位于核心网中的MEC服务器的用户设备不可避免地会经历更长的延迟，这可能会阻碍实时应用的使用。一项初步研究在[67]中提出，并在[68]中进一步阐述，该研究旨在确定在移动网络中如何最优地安装MEC服务器，主要目标是在安装成本和以延迟衡量的服务质量之间找到权衡。基于这些研究，预计与CONCERT框架（见第III‐A5节）类似，具有不同计算能力/存储容量的MEC服务器将分散在整个网络中。因此，需要

表II：现有多接入边缘计算概念的比较。

多接入边缘计算 concept	控制实体	控制方式	控制放置	计算/存储放置
SCC	SCM	集中式、去中心化分层‐ 结构（取决于SCM类型和放置位置）	在无线接入网（例如，在eNB）或在核心网（例如，与MME共址的SCM）	小小区基站，SCeNB集群
MMC	-	去中心化	-	移动微云（演进型节点B）
MobiScud	MC	去中心化	RAN 和 核心网 之间	RAN 内或靠近 RAN 的 分布式云
FMC	FMCC	集中式, 去中心化 层级式 选项 with 层级式 FMCC），去中心化 （无FMC控制器的选项）	与现有节点共址（例如 核心网中的节点）或作为软件运行在 DC	与分布式数据中心靠近或共址的DC 分布式核心网
CONCERT	导控器	集中式、去中心化层级 结构	不适用（可以在相同的 与FMC概念中的方式相同）	eNB（RIE）、区域和中央服务器
欧洲电信标准协会多接入边缘计算	移动边缘编排器	集中式	不适用（最可行的选项是 将控制放入核心网	eNB、汇聚点、 CN

只有低计算能力需求的应用将由与eNB共址的本地MEC服务器提供服务，而高需求的应用程序将被移交到距离用户设备更远但更强大的MEC服务器上。

C. 总结

本节将文献中提出的MEC概念与ETSI所制定的MEC愿景进行相互比较。当前各类MEC解决方案普遍遵循两种共同趋势，即将云引入移动网络边缘。第一种趋势基于利用NFV原则的虚拟化技术，网络虚拟化对于灵活管理MEC提供的虚拟化资源而言是必要的。第二种趋势是通过利用SDN范式实现控制面与数据面分离，从而能够根据变化的流量模式和用户需求对网络进行动态适应。在MEC中使用SDN也符合当前移动网络的发展趋势[69]‐[71]。

在控制/信令方面，MMC和MobiScud采用完全去中心化方法，而SCC、FMC和CONCERT则采用完全集中式控制或分层控制，以实现更好的可扩展性和灵活性。

如果从计算/存储资源部署的角度比较各个多接入边缘计算概念，显然的努力方向是将这些资源在网络内完全分布式地部署。然而，每种多接入边缘计算概念在计算/存储资源的物理位置方面有所不同。SCC、MMC和MobiScud假设将计算置于无线接入网内的用户设备附近，而FMC方案则考虑将数据中心集成到更远的位置，例如分布式核心网中。此外，CONCERT以分层方式在整个网络中分布计算/存储资源，使得低需求计算应用在本地处理，而高需求应用则被转移到区域或中央服务器。关于欧洲电信标准协会多接入边缘计算，也存在多种可选方案来确定向用户设备提供计算/存储资源的MEC服务器的部署位置。最可能的做法是在网络各处部署MEC服务器，以确保计算/存储资源的高可扩展性。所有现有MEC概念的比较见表II。

IV. 计算卸载导论

从用户的角度来看，关于多接入边缘计算的一个关键用例是计算卸载，因为这可以节省能量和/或加速计算过程。一般来说，计算卸载的关键部分是决定是否卸载。在前一种情况下，还需要考虑卸载多少以及卸载什么[41]。基本上，计算卸载决策可能产生以下结果：

•本地执行 — 整个计算在用户设备上本地完成（见图8）。

此时不执行向移动边缘计算卸载，例如由于移动边缘计算计算资源不可用，或者卸载本身并不划算。

•完全卸载—整个计算被卸载并由多接入边缘计算处理。

•部分卸载—一部分计算在本地处理，其余部分卸载到多接入边缘计算。

计算卸载，尤其是部分卸载，是一个受多种因素影响的非常复杂的过程，例如用户偏好、无线和回传连接质量、用户设备能力或云能力和可用性[3]。在计算卸载中，一个重要的方面是应用程序模型/类型，因为它决定了完全或部分卸载是否适用、哪些内容可以卸载以及如何卸载。在这方面，我们可以根据多个标准对应用程序进行分类：

•应用的可卸载性 ——支持代码或数据分割以及并行化的应用（即可部分卸载的应用）可分为两种类型。第一种类型的应用是可以被划分为N可卸载部分，且所有这些部分均可卸载（见图9a）。由于每个可卸载部分在数据量和所需计算量上可能不同，因此需要决定哪些部分应卸载到多接入边缘计算。如图9a所示，第1个、第2个、第3个、第6个和第9个部分在本地处理，其余部分则卸载到多接入边缘计算。需要注意的是，在极端情况下，如果用户设备不处理任何部分，则此类应用可完全卸载到多接入边缘计算。第二种类型的应用始终包含一些不可卸载的部分（例如用户输入、摄像头或需要在用户设备上执行的位置获取[72]），以及M可卸载部分。在图9b中，用户设备处理整个不可卸载部分以及第2个、第6th和第7个部分，而应用的其余部分则卸载到多接入边缘计算。

•待处理数据量的已知程度 ‐ 可以根据对待处理数据量的已知程度对应用进行分类。第一类应用（例如人脸检测、病毒扫描等）在执行前已知待处理的数据量。对于第二类应用，由于它们是连续执行应用，无法估计待处理的数据量，也无法预测其运行时间（例如在线交互游戏）[95]。显然，对于连续执行应用，计算卸载决策可能相当复杂。

•可卸载部分的依赖性 ‐ 对需卸载应用进行分类的最后一个标准是待处理各部分之间的相互依赖性。应用的各部分可以彼此独立，也可以相互依赖。在前一种情况下，所有部分都可以同时卸载并并行处理。然而在后一种情况下，应用由需要来自其他部分输入的部分（组件）构成，因此可能无法进行并行卸载。请注意，各组件之间的关系可以通过组件依赖图（CDG）或调用图（CG）表示（参见例如[34][41][72][73]）。图10展示了组件之间的关系，其中整个应用被划分为M个不可卸载部分（图10中的第1st、第4th和第6th部分）和N个可卸载部分（图10中的第2nd、第3rd和第5th部分）。在给定的例子中，只有在第1st部分执行完成后，才能卸载第2nd和第3rd部分；而第5th部分则必须在第1st至第4th部分执行完成后才能卸载。

关于计算卸载的另一个重要方面是如何在实践中利用和管理卸载过程。基本上，用户设备需要由代码分析器、系统分析器和决策引擎[36]组成。代码分析器负责确定哪些内容可以被卸载（取决于应用类型以及如上所述的代码/数据划分）。然后，系统分析器负责监控各种参数，例如可用带宽、待卸载的数据大小或应用程序在本地执行所消耗的能量。最后，决策引擎决定是否进行卸载。

接下来的章节将综述当前聚焦于以下关键研究主题的研究工作：1）关于向移动边缘计算卸载的决策；2）移动边缘计算内计算资源的有效分配；3）利用MEC服务的移动用户的移动性管理。请注意，从现在起，我们将明确使用欧洲电信标准协会标准化活动所定义的术语。因此，我们使用“多接入边缘计算服务器”这一术语来表示为用户设备提供计算/存储资源的节点，而不是云计算中心、移动微云等。

V. 计算卸载决策到多接入边缘计算

本节调研了与向移动边缘计算卸载的计算卸载决策相关的当前研究。这些论文被分为两类：一类仅考虑完全卸载（第五节‐A），另一类还考虑了部分卸载的可能性（第五节‐B）。

A. 完全卸载

专注于完整卸载决策的研究的主要目标是最小化执行延迟（第五节‐A1部分），在满足预定义延迟约束的同时最小化用户设备的能耗（第五节‐A2部分），或在能耗与执行延迟之间找到适当的权衡（第五节‐A3部分）。

1) 执行延迟最小化

通过向移动边缘计算卸载计算任务所带来的优势之一是有可能减少执行延迟（D）。当用户设备自行完成所有计算任务时（即，无卸载），执行延迟（Dl）仅代表在用户设备本地执行所花费的时间。而在向移动边缘计算进行计算卸载的情况下，执行延迟（Do）包含以下三个部分：1）将卸载数据传输至移动边缘计算的传输时长（Dot）；2）在移动边缘计算中的计算/处理时间（Dop）；3）从移动边缘计算接收已处理数据的时间（Dor）。图11展示了仅基于执行延迟做出计算卸载决策的简单示例。可以看出，用户设备1选择全部本地计算，因为其本地执行延迟明显低于向移动边缘计算卸载计算任务的预期执行延迟（即，Dl< Do）。相反，对用户设备2而言，更优的选择是将数据完整卸载到移动边缘计算，因为本地执行将导致显著更高的执行延迟（即，Dl> Do）。

作者在[74]中追求最小化执行延迟的目标。这是通过一维搜索算法实现的，该算法根据应用缓冲区排队状态、用户设备和多接入边缘计算服务器的可用处理能力以及用户设备与多接入边缘计算服务器之间信道的特性，找到最优的卸载决策策略。计算卸载决策本身由用户设备上的计算卸载策略模块完成。（见图12）。该模块在每个时隙决定缓冲区中等待的应用是在本地处理还是在多接入边缘计算服务器上处理，同时最小化执行延迟。所提出的算法的性能与本地执行策略（始终在本地进行计算）、云执行策略（始终由多接入边缘计算服务器执行计算）以及贪婪卸载策略（当本地CPU或传输单元空闲时，用户设备调度缓冲区中等待的数据）进行了比较。仿真结果表明，所提出的最优策略能够将执行延迟最多降低80%（相比本地执行策略）和大约44%（相比云执行策略），因为它能够应对高密度的应用到达。所提出方法的缺点是用户设备需要从多接入边缘计算服务器获得反馈以做出卸载决策，但论文未讨论由此产生的信令开销。

另一种旨在最小化执行延迟的方法在[75]中被提出。与之前的研究相比，[75]中的作者还减少了卸载应用的应用失败情况。该论文考虑用户设备在本地执行期间采用动态电压和频率调节（DVS）[76]以及能量收集技术[77]以最小化能耗，并通过功率控制优化计算卸载时的数据传输。为此，作者提出了一种基于李雅普诺夫优化的低复杂度动态计算卸载（LODCO）算法。LODCO在每个时隙做出卸载决策，随后为用户设备分配CPU周期（如果进行本地执行）或分配传输功率（如果进行计算卸载）。所提出的LODCO能够通过向移动边缘计算卸载将执行时间最多减少64%。此外，该提案能够完全防止卸载应用被丢弃的情况发生。

上述两篇论文的缺点是，卸载决策未考虑用户设备端的能耗问题，因为电池快速耗尽可能在当代网络中造成重大障碍。在[75],中，决策过程忽略了用户设备的能量因素，因为该论文假设用户设备采用能量收集技术。然而，这种收集技术本身无法完全解决能耗问题。

2) 在满足执行延迟约束的同时最小化能耗

本节综述的论文主要目标是在满足应用执行延迟约束的前提下，最小化用户设备上的能耗。一方面，将计算任务卸载到多接入边缘计算可以节省用户设备的电池能量，因为计算无需在本地进行。另一方面，用户设备需要消耗一定的能量用于：1) 将卸载数据传输至多接入边缘计算以进行计算（Eot）；2) 从多接入边缘计算接收计算结果（Eor）。图13展示了主要基于能耗的计算卸载决策的简单示例。在该示例中，UE1决定在本地执行计算，因为本地执行所消耗的能量（El）明显低于卸载数据传输/接收所需的能量（E0）。相反，

用户设备2将数据卸载到多接入边缘计算，因为计算卸载所需的能量明显低于本地计算所消耗的能量。尽管如果用户设备1将计算卸载到多接入边缘计算，同时用户设备2进行本地执行时总体执行延迟会更低，但延迟仍然低于最大允许执行延迟约束（即 Dl< Dmax）。请注意，如果仅考虑执行延迟来进行卸载决策（如第五节‐A3中所述），两个用户设备将不必要地消耗更多能量。

在[78]中提出了一种计算卸载决策，旨在满足应用执行延迟的同时最小化用户设备的能耗。该优化问题被建模为一个约束马尔可夫决策过程（CMDP）。为解决该优化问题，引入了两种资源分配策略。第一种策略基于在线学习，网络根据用户设备上运行的应用动态自适应。第二种策略是预计算离线策略，其利用了关于应用的一定程度的信息（如每时隙数据包数的到达率、无线信道状况等）。数值实验表明，在低和中等到达率（负载）下，预计算离线策略的性能比在线策略最多可提升50%。由于在[78]中提出的离线资源分配策略显示出其优势，作者进一步设计了两种额外的针对卸载[79]的动态离线策略：确定性离线策略和随机化离线策略。结果表明，与仅在用户设备上计算（节能高达78%）或仅在多接入边缘计算端计算（节能高达15%）的情况相比，这两种离线卸载策略均可实现显著的节能效果。

在[80]中，考虑了将[79]从单用户设备扩展到多用户设备场景的情况。主要目标是联合优化每个用户设备的调度和计算卸载策略，以保证用户体验质量、用户设备之间的公平性、低能耗以及平均排队/延迟约束。不允许进行计算卸载的用户设备将执行本地计算或保持空闲。结果表明，离线策略在节能方面显著优于在线策略（节能约50%）。此外，各个用户设备的能耗在很大程度上取决于其他用户设备应用的需求。

另一种针对多用户设备场景的卸载决策策略，在最小化用户设备能耗的同时

在[81]中提出了一种满足最大允许执行延迟的方案。计算卸载决策在每个时隙内周期性地进行，在此期间所有用户设备被分为两组。第一组中的用户设备被允许将计算任务卸载到多接入边缘计算节点，而第二组中的用户设备由于多接入边缘计算节点处计算资源不可用而必须在本地执行计算（注意：在该论文中，计算是在服务的小小区基站上完成的）。用户设备根据队列长度（即其需要处理的数据量）被划分到不同组中。在用户设备被允许进行计算卸载后，通过寻找用户设备的最佳传输功率以及小小区基站计算资源对各个用户设备的分配，实现通信与计算资源的联合分配。该提案的性能通过平均队列长度进行评估，评估参数包括数据到达强度以及用户设备和小小区基站所使用的天线数量。结果表明，使用的天线数量越多，用户设备所需的传输功率越低，同时仍能保证卸载计算的延迟约束。

[81]的主要弱点在于其假设仅存在一个SCeNB，因此连接到不同SCeNB的UE之间不存在干扰。因此，[81]中的工作在[82]中被扩展至包含N个SCeNB的多小区场景，以反映实际网络部署情况。由于[81]中建立的优化问题不再具有凸性，作者提出了一种利用逐次凸逼近（SCA）的分布式迭代算法，该算法收敛于局部最优解。数值结果表明，无线资源与计算资源的联合优化方法显著优于分别优化无线和计算资源的方法。此外，研究还表明，那些需要卸载的数据量较少但处理时需要大量CPU周期的应用程序更适合进行计算卸载。原因是传输/接收卸载数据所消耗的能量远低于用户设备因计算卸载而实现的能耗节省。[82]中的工作在[83]中进一步扩展，考虑了与各个SCeNB相关联的多云架构。结果表明，随着SCeNB数量的增加（即云数量的增加），用户设备的能耗成比例下降。

通过高效能计算卸载（EECO），在[84]中实现了与之前论文相同的目标

算法。EECO分为三个阶段。在第一阶段，根据用户设备计算的时间和能量成本特征将其分类为：1）应将计算卸载到多接入边缘计算的用户设备，因为这些用户设备无法满足执行延迟约束；2）应在本地进行计算的用户设备，因为它们能够自行处理且能耗低于预定义阈值；3）可选择是否卸载计算的用户设备。在第二阶段，根据通信信道和计算需求，为第一类和第三类中的用户设备确定卸载优先级。在第三阶段，宏基站/小小区基站根据给定的优先级向用户设备分配无线资源。EECO的计算复杂度为O(max(I2+ N, IK+ N))，其中I是迭代次数，N表示用户设备数量，K代表可用信道的数量。根据所给出的数值结果，与不进行卸载的计算相比，EECO最多可使能耗降低15%。此外，还证明了随着多接入边缘计算计算能力的提升，决定卸载计算的用户设备数量也随之增加。

3) 能耗与执行延迟之间的权衡

在多用户多信道环境下，考虑用户设备的能耗与执行延迟之间权衡的计算卸载决策在[85]中被提出。卸载决策是更倾向于最小化能耗还是执行延迟，由一个权重参数决定。本文的主要目标有两个：1）根据权重参数决定用户设备是否应向移动边缘计算卸载；2）在进行计算卸载的情况下，选择最合适的数据传输无线信道。为此，作者提出了一个最优集中式解决方案，但在多用户多信道环境中该方案是NP难的。因此，作者还提出了一种达到纳什均衡的分布式计算卸载算法。最优集中式解决方案和分布式算法在两个性能指标方面进行了比较：1）从向移动边缘计算卸载中受益的用户设备数量；2）通过能耗和执行延迟加权表示的计算开销。在上述两个性能指标上，分布式算法的表现仅略逊于集中式方案。此外，与所有用户设备均在本地计算所有应用程序以及所有用户设备均优先在移动边缘计算节点上计算的情况相比，分布式算法显著更优（对于50个用户设备大约最多降低40%）。

在[86]中提出了一种用于计算卸载决策的算法，该算法权衡了用户设备的能耗和执行延迟。与[85]的主要区别在于，[86]中的作者假设当多接入边缘计算的计算资源不足时，计算任务也可以卸载到远程集中云（CC）。计算卸载决策以顺序方式进行：在第一步中，用户设备决定是否将应用卸载到多接入边缘计算；如果应用被卸载到多接入边缘计算，则在第二步中，多接入边缘计算评估其是否能够承担

以满足请求，或是否应将计算进一步中继到CC。该问题被建模为一个非凸二次约束二次规划（QCQP），然而这是NP难问题。因此，提出了一种基于半定松弛并结合新型随机化方法的启发式算法。与计算始终仅在UE上执行的情况相比，所提出的启发式算法能够显著降低总系统成本（即总能耗、执行延迟以及卸载和处理所有应用程序的成本的加权和）（约降低70%）；与始终在MEC/CC上执行的情况相比，总系统成本也显著降低（约降低58%）。

[86]从单用户设备扩展到多用户设备场景的方案在[87]中提出。由于假设多个用户设备连接到同一个计算节点（例如，eNB），卸载决策需联合进行所有用户设备的计算与通信资源分配。类似于[86],该提案在[87]中表现优于计算始终由用户设备完成的情况（系统成本最多降低45%）以及计算始终卸载到多接入边缘计算/云计算中心的策略（系统成本最多降低50%）。然而，展示在具有多个计算eNB的更现实场景下的结果仍然很有意义，其中连接到不同eNB的用户设备之间的干扰将在卸载决策中起到重要作用。此外，提出的解决方案的总体复杂度为O（N6）每迭代一次，对于连接到eNB的大量用户设备（N）而言可能过高。

B. 部分卸载

本小节重点关注涉及部分卸载的研究工作。我们将相关研究分为两类：一类是专注于在满足预定义延迟约束的同时最小化用户设备的能耗（第五节‐B1部分）；另一类是寻求能耗与执行延迟之间的合理权衡（第五节‐B2部分）。

1) 满足执行延迟约束下的能耗最小化

本节重点讨论在满足最大允许延迟的前提下实现能耗最小化的相关研究，与第V‐A2节类似。[88],作者考虑了应用被划分为不可卸载部分和N可卸载部分的情况，如图9b所示。该论文的主要目标是决定哪些可卸载部分应被卸载到多接入边缘计算。作者提出了一种基于组合优化方法的最优自适应算法，其复杂度高达O(2N)。为了降低最优算法的复杂度，还提出了一种次优算法，将复杂度降低至O(N)。最优算法最多可实现48%的节能，而次优算法性能略低，但也能实现最高达47%的节能。此外，结果表明，用户设备与服务演进型节点B之间的信号与干扰加噪声比提升，能够带来更显著的节能效果。

在满足整个应用的延迟约束的同时实现能耗最小化也是[72]的主要目标。与[88]不同，[72]中的应用被认为由多个原子部分组成

相互依赖，即某些部分只有在其他部分执行后才能处理，如第四节中的图10所示。作者将卸载问题建模为0−1规划模型，其中0表示应用卸载，1表示用户设备上的本地计算。然而，由于该问题存在2N种可能的解决方案（即O(2NN2)），最优解具有高复杂度。因此，提出了一种利用二进制粒子群优化器(BPSO)的启发式算法[89]，以将复杂度降低至O(G.K.N2)，其中G为迭代次数，K为粒子数量。BPSO算法在能耗方面能够实现与高复杂度的最优解几乎相同的结果。此外，与完全卸载相比，部分卸载在节能方面效果更显著（在用户设备上最多可实现25%节能）。

上述两篇论文在详细研究部分计算卸载时的一个缺点是假设系统中仅存在单用户设备。因此，在[90],中，作者针对多用户设备场景解决了部分卸载决策问题。关于[72][88],，待卸载的应用不包含任何不可卸载部分，在某些极端情况下，如果有利可图，整个应用都可以被卸载（即，该应用如图9a所示的结构）。假设用户设备能够决定是否划分应用以及应将多少部分卸载到多接入边缘计算。该问题被建模为一个高复杂度的非线性约束问题。因此，它被简化为可通过线性规划求解的问题，其复杂度为O(N)（其中N是执行卸载的用户设备数量）。若采用穷尽搜索的最优解，则与无卸载场景相比可实现40%节能。当使用启发式低复杂度算法时，用户设备可观察到30%节能。该提案的缺点在于假设系统中的用户设备具有相同的信道质量和相同的计算能力。然而，这些假设在实际网络中并不现实。

在[91],中也假设了多用户设备场景，其中作者假设了一个基于时分多址的系统，时间被划分为持续时间为T秒的时隙。在每个时隙期间，用户设备可根据其信道质量、本地计算能耗以及用户设备之间的公平性，将部分数据卸载到多接入边缘计算。在此基础上，定义了一种最优资源分配策略，该策略优先考虑那些如果在本地进行计算则无法满足应用延迟约束的用户设备。随后，提出了一种具有基于阈值结构的最优资源分配策略。换句话说，该最优策略为每个用户设备做出二元卸载决策。如果某用户设备的优先级高于给定阈值，则该用户设备执行完全计算卸载到多接入边缘计算；相反，如果其优先级低于阈值，则仅卸载最小计算量以满足应用延迟约束。由于通信与计算资源的联合最优分配具有高复杂度，作者还提出了一种次优分配算法，该算法解耦了通信与计算资源

分配。仿真结果表明，与最优分配相比，这种简化导致用户设备的总能耗略微增加。该论文在[92],中进一步扩展，作者指出，由于无线资源的粒度更高，正交频分多址接入使用户设备实现的节能效果相比时分多址系统大约提高了十倍。

在上述所有关于部分卸载的论文中，用户设备能耗的最小化取决于无线通信信道的质量和用户设备的传输功率。相反，在[93],中，通过动态电压频率调节技术实现了在满足应用执行延迟的同时最小化能耗。在这方面，作者提出了一种能量最优的部分卸载方案，该方案迫使用户设备根据应用的最大允许延迟(LMAX)调整其计算能力。换句话说，所提方案的目标是确保应用的实际延迟始终等于LMAX。因此，在不影响用户感知的服务质量的前提下，实现了能耗的最小化。

2) 能耗与执行延迟之间的权衡

针对部分卸载决策的能耗与执行延迟之间的权衡分析在[94]中给出。类似于[90],，待卸载的应用仅包含可卸载部分，在极端情况下可能发生完全卸载（如第五节‐B所述）。卸载决策考虑了以下参数：1) 需处理的总比特数，2) 用户设备和多接入边缘计算的计算能力，3) 用户设备与提供对多接入边缘计算访问的服务中小区基站之间的信道状态，以及4) 用户设备的能耗。计算卸载决策被建模为通信与计算资源分配的联合优化问题。仿真结果表明，用户设备的能耗随着总执行时间的增加而减少。然而，这种减少仅在执行时间较短时较为显著。对于较长的执行时间，节能增益微乎其微。此外，作者指出，如果通信信道质量较低，则卸载并不有利可图，因为卸载应用会消耗大量能量。在这种情况下，更倾向于在用户设备本地处理整个应用。当信道质量处于中等水平时，部分计算任务被卸载到多接入边缘计算，从而实现节能。最后，如果信道质量高，则优先选择完全卸载，因为此时数据传输的能耗较低，而通过计算卸载所获得的节能效果显著。

文献[95]对在[94]中初步处理的卸载应用的能耗与延迟之间的权衡进行了更深入的理论分析。此外，作者进一步证明，信道质量较好时，计算卸载的概率更高。当天线数量较多时（假设为4x2 MIMO和4x4 MIMO），相比SISO或MISO，卸载更为频繁，用户设备的节能效果也更显著（能耗最多可降低97%）。

[94][95]的主要缺点是这些论文仅考虑了单用户设备场景。针对多用户设备场景，用户设备的能耗与执行延迟之间的权衡分析在[96]中被交付。在多用户设备场景下，由于多接入边缘计算提供的通信与计算资源是共享的，因此[95]中提出的整个联合优化过程需要进一步修改

在多个用户设备之间。论文证明，随着系统中用户设备数量的增加，卸载应用所需的时间更长，且在多接入边缘计算中处理应用的时间也更长。这一现象的原因非常明显，因为每个用户设备可获得的无线与计算资源减少。然而，在多用户设备场景下，仍可实现高达90%的节能效果。

在多用户设备场景中，[97] 也解决了功耗与执行延迟之间的权衡问题。

作者提出了一个在应用缓冲区稳定性约束下的功耗最小化问题。为此，提出了一种基于李雅普诺夫优化的在线算法，用于决定执行本地执行的用户设备的最优CPU频率，并为将应用卸载到多接入边缘计算的用户设备分配传输功率和带宽。该提出的算法能够根据所选优先级控制功耗和执行延迟。论文还表明，利用多接入边缘计算进行计算卸载可使功耗最多降低约90%，同时执行延迟大约减少98%。

C. 计算卸载决策相关工作的总结

表III：针对计算卸载决策的单篇论文比较 .

	卸载 type	目标	评估方法	降低 D/EUE相对于本地计算	所提算法复杂度	提出的解决方案	用户设备数量
[74]	Full	1) 最小化 D	仿真	高达 80%减少‐ D的计算卸载	N/A	一维搜索算法 找到最优的卸载策略 icy	单用户设备
[75]	Full	1) 最小化 D, 2) 最小化应用失败	仿真	最高达64%的降低 of D	N/A	基于李雅普诺夫优化的动态计算卸载 动态计算卸载	单用户设备
[78]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	最高达78%的降低 的 EUE	N/A	在线学习分配策略， 离线预计算策略	单用户设备
[79]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	最高达78%的降低 EUE的	N/A	确定性和随机离线 策略	单用户设备
[80]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	N/A	N/A	确定性离线策略，de‐ 基于确定性在线策略的 决策后学习框架	多用户设备
[81]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	N/A	N/A	通信的联合分配 和计算资源	多用户设备
[82]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	N/A	N/A	分布式迭代算法 ex‐ ploiting连续凸 Ap-近似 (SCA)	多用户设备
[83]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	N/A	N/A	分布式迭代算法 ex‐ ploiting连续凸 Ap-proximation (SCA)	多用户设备
[84]	Full	1) 最小化 EUE，2) 满足 D约束	仿真	最高可达15%的降低 EUE 的	O(max(I2+ N, IK+N)	能量高效的计算卸载 floading（EECO）算法	多用户设备
[85]	Full	1) 权衡 EUE和 D	仿真	最高可达40%的降低 EUE的	N/A	计算卸载博弈	多用户设备
[86]	Full	1) 权衡 EUE和 D	仿真	最高可达70%的降低 总成本的	N/A	启发式算法基于 on 半定 松弛 and 随机化映射方法	单用户设备
[87]	Full	1) 权衡 EUE和 D	仿真	最高可达45%的降低 总成本的	O(N6) per 迭代次数	启发式算法基于 on 半定 松弛 and 随机化映射方法	多用户设备
[88]	部分	1) 最小化 EUE，2) 满足 D约束	仿真	最高可达47%的降低 EUE的	O(N)	基于组合优化方法的自适应算法 组合优化方法	单用户设备
[72]	部分	1) 最小化 EUE，2) 满足 D约束	仿真	最高25%降低 EUE的	O(G.K.N2)	利用二进制分割的算法‐ 粒子群优化器	单用户设备
[90]	部分	1) 最小化 EUE，2) 满足 D约束	仿真	最高可达40%的降低 E UE 的	O(N)	基于应用和延迟的重新 资源分配方案	多用户设备
[91]	部分	1) 最小化 E UE，2) 满足 D约束	仿真	N/A	N/A	最优资源分配策略 基于阈值的结构用于 TDMA系统	多用户设备
[92]	部分	1) 最小化 E UE，2) 满足 D约束	仿真	N/A	O(K+ N)	最优资源分配策略 具有基于阈值的结构，用于时分多址和正交频分多址系统	多用户设备
[93]	部分	1) 最小化 E UE，2) 满足 D约束	仿真	N/A	N/A	调整计算能力 通过DVS实现用户设备 最大允许延迟	单用户设备
[94]	部分	1) 权衡 E UE和 D	仿真	N/A	N/A	通信的联合分配 和计算资源	单用户设备
[95]	部分	1) 权衡 E UE 和 D	仿真	最高达97%降低 的 E U E(SINR 45 分贝，4x4 MIMO)	N/A	迭代算法寻找最优解 比特数的最优值 上行链路发送	单用户设备
[96]	部分	1) 权衡 E U E 和 D	仿真	最高达90%的降低 的 E U E	N/A	通信的联合分配 和计算资源	多用户设备
[97]	部分	1) 权衡 E U E 和 D	仿真	最高 90%降低 的 EU E ，最高98% D 的降低	N/A	基于李雅普诺夫优化的动态计算卸载 动态计算卸载	多用户设备

提出的解决方案用户设备数量

of

用于 4x4 MIMO 天线配置的功耗）。请注意，相同的结论也在 [81][82] 中得出。

[94][95]的主要缺点是这些论文仅考虑了单用户设备场景。针对多用户设备场景，用户设备的能耗与执行延迟之间的权衡分析在[96]中被交付。在多用户设备场景下，由于多接入边缘计算提供的通信与计算资源是共享的，因此[95]中提出的整个联合优化过程需要进一步修改

在多个用户设备之间。论文证明，随着系统中用户设备数量的增加，卸载应用所需的时间更长，且在多接入边缘计算中处理应用的时间也更长。这一现象的原因非常明显，因为每个用户设备可获得的无线与计算资源减少。然而，在多用户设备场景下，仍可实现高达90%的节能效果。

在多用户设备场景中，[97] 也解决了功耗与执行延迟之间的权衡问题。

作者提出了一个在应用缓冲区稳定性约束下的功耗最小化问题。为此，提出了一种基于李雅普诺夫优化的在线算法，用于决定执行本地执行的用户设备的最优CPU频率，并为将应用卸载到多接入边缘计算的用户设备分配传输功率和带宽。该提出的算法能够根据所选优先级控制功耗和执行延迟。论文还表明，利用多接入边缘计算进行计算卸载可使功耗最多降低约90%，同时执行延迟大约减少98%。

VI. 计算资源分配

如果决定将应用完全或部分卸载到多接入边缘计算（MEC）（如前一节所述），则需要对计算资源进行合理分配。与计算卸载决策类似，计算放置的选择受到卸载应用能否进行并行化/分割的影响。如果应用无法进行并行化/分割，则只能分配一个物理节点进行计算，因为该应用无法被分割成多个部分（如图14所示，用户设备1将整个应用卸载到演进型节点B，因为该应用不可分割）。相反，如果可以进行分割，则卸载的应用可由分布在多个计算节点上的资源共同处理（如图14所示，用户设备2卸载的应用被分割，并由全部三个演进型节点B处理）。

本节综述了针对将应用程序卸载到多接入边缘计算（或在多接入边缘计算资源不足时卸载到云计算中心）时如何合理分配计算资源这一问题的相关论文。我们将该领域的研究分为两类：一类是关注单个计算节点上的计算资源分配（第六节‐A），另一类是关注多个计算节点上的计算资源分配（第六节‐B）。

A. 单节点计算资源分配

在满足卸载的应用延迟要求的同时，最大化多接入边缘计算服务的应用数量是[98]中的主要目标。

决策时，各个应用程序的放置位置取决于应用程序的优先级（由应用的延迟要求决定，即延迟要求低的应用具有更高的优先级）以及多接入边缘计算中的计算资源可用性。计算资源分配的基本原理如图15所示。卸载的应用程序首先被交付到多接入边缘计算内的本地调度器。调度器检查是否存在具有足够计算资源的计算节点。如果存在具备充足可用资源的计算节点，则在该节点上分配虚拟机。随后，应用程序在此多接入边缘计算节点上进行处理，并最终返回用户设备（见图15）。然而，如果多接入边缘计算服务器提供的计算能力不足，调度器会将应用程序委托给远程云中心。为了在满足延迟要求的同时最大化在多接入边缘计算中处理的应用程序数量，作者提出了一种基于优先级的协作策略，该策略为每个优先级级别定义了若干缓冲区阈值。因此，当缓冲区满时，应用程序将被发送至云计算中心。通过低复杂度递归算法确定缓冲区阈值的最佳大小。所提出的协作策略能够将应用程序在允许延迟内完成的概率提高25%。

与之前的研究相比，[99]的总体目标不仅是最小化执行延迟，还最小化MEC的功耗。该论文考虑了一个用户设备密集的热点区域，这些用户设备能够通过附近的演进型节点B访问多个多接入边缘计算服务器。为此

最后，提出了一种基于等效离散MDP框架的最优策略。然而，随着MEC服务器数量的增加，该方法导致较高的通信开销和计算复杂度。因此，通过开发一种应用分配索引策略来克服这一问题。在此方面，每个eNB根据其计算资源的状态计算自身的索引策略，然后所有eNB广播该索引策略，用户设备能够选择最合适的MEC服务器，以最小化执行延迟和功耗。根据结果，在最坏情况下，该索引策略在系统成本方面比最优策略高出7%（注意：系统成本表示MEC的加权执行延迟和功耗）。

最小化卸载应用的执行延迟也是[100]中的主要目标。然而，与[98][99],相比，其他目标是最小化通信和计算资源的过载以及虚拟机迁移成本（注意在[100],中，计算节点由小小区基站表示，且虚拟机迁移可能由于小小区基站关闭而触发）。整个问题被建模为小小区基站上的虚拟机分配问题，并通过马尔可夫决策过程进行求解。图16展示了根据[100]进行虚拟机分配的一个示例，其中用户设备1的虚拟机被分配在服务中小区基站SCeNB1上，而用户设备2的虚拟机被分配在邻近的小小区基站SCeNB3上。选择SCeNB3是因为其具有高质量的回传链路，从而使得卸载数据的传输延迟较低。仿真结果表明，当虚拟机迁移成本较高时，如果该小小区基站具备充足的计算能力，则更倾向于将虚拟机分配在服务中小区基站（即距离用户设备最近的小小区基站）上。

上述所有方法的主要缺点是，它们未考虑在多接入边缘计算中为单个应用引入更多计算节点，以进一步降低其执行延迟。

B. 多个节点上的计算资源分配（联邦云）

与前一节相比，此处考虑了在多个计算节点上的计算资源分配。论文被分为若干子章节

主要目标：1）最小化计算节点的执行延迟和/或功耗（第VI‐B1节）；以及 2）平衡通信和计算负载（第VI‐B1节）。

1) 计算节点执行延迟和/或功耗的最小化

文献[101]提出了一种通过SCeNB集群提供的计算资源分配来最小化执行延迟的方法，同时避免使用云计算中心。该集群形成采用合作博弈方法，当SCeNB为连接到其他SCeNB的用户设备执行计算任务时，将获得经济激励。SCeNB之间的联盟在多个时隙内保持，并可随后重新组建新的联盟。计算资源分配过程如图17所示。首先，服务中小区基站尝试自行服务其用户设备，因为这可以实现最短的通信延迟（例如，在图17中，SCeNB1为其UE1和UE2分配计算资源等）。只有当SCeNB自身无法处理应用程序时，才将任务转发给同一集群中的所有SCeNB（在图17中，UE3的计算由SCeNB2和SCeNB3完成）。数值结果表明，与仅在服务中小区基站进行计算相比，所提出的方案最多可将执行延迟降低50%；与系统中所有SCeNB均参与计算的场景相比，最多可降低25%。然而，该方法未解决新联盟形成及其对当前正在处理的应用程序影响的问题。

计算节点的选择不仅会显著影响[101],中考虑的执行延迟，还会影响计算节点的功耗。因此，[102]的主要目标是分析集群规模（即执行计算的小小区基站数量）对卸载应用的执行延迟以及小小区基站功耗的影响。该分析针对不同的回传拓扑（环形、树形、全网状）和回传技术（光纤、微波、长期演进技术）进行。作者表明，全网状拓扑结合光纤或微波连接在执行延迟方面最具优势（最多可实现90%的执行延迟减少）。相反，环形拓扑中采用光纤回传链路时功耗最低。

此外，论文表明，计算用小小区基站数量的增加并不总是缩短执行延迟。恰恰