计算卸载关键技术及其卸载决策问题
计算卸载决策
通过将计算和存储资源广泛地分布到更接近用户或数据源的网络边缘，移动
边缘计算（Mobile Edge Computing, MEC）支持在无线接入网内完成移动应用的计
算卸载过程，大幅降低了网络的端到端时延，并有效减轻了核心网和数据中心的
处理压力。计算卸载决策，包括用户侧卸载决策（如任务是否卸载、如何卸载以
及何时卸载）和运营商侧卸载决策（如是否允许用户卸载、分配多少资源进行卸
载），是MEC能否提升用户体验的关键。由于MEC环境的复杂性，影响卸载决策
的因素众多，如何设计最优的卸载决策策略，以充分挖掘MEC在时延、能耗上的
性能增益，是非常具有挑战性的科学问题。
任务调度与资源管理是MEC卸载决策过程中需要考虑的两个重要因素。一方
面，MEC环境本质上是一个分布式异构并行计算环境，只有对任务进行合理调度，
才能充分发挥该计算环境的性能优势。若考虑网络环境的动态变化，则还需要对
任务卸载的时机进行调度决策。另一方面，由于网络边缘的资源有限，必须对这
些资源进行合理分配以充分发挥它们的效用。在用户较多的情况下，还需要对是
否允许用户卸载进行决策（即准入决策），避免资源的过度竞争。在此背景下，本
文分别针对用户视角下的面向图依赖关系的任务卸载调度和面向复杂任务队列的
动态任务卸载调度，以及运营商视角下的考虑用户移动性的准入决策与资源分配
三个场景，考虑静态环境与动态环境中不同应用卸载模型的影响，探索MEC计算
卸载调度与资源管理的最优策略。
移动边缘计算的由来
早在2000年左右，学术界就开始针对MD的这两个问题（以及当时还普遍存
在的无线通信带宽不足、流量昂贵等问题）进行研究，并提出了一种在当时看
来较为超前的解决方案——网络觅食（cyber foraging）
[3, 6–8]。根据该解决方案，
MD每当进入到一个新的区域时，就会主动寻找该区域内潜在的代理（surrogate）。
1电子科技大学博士学位论文
MD通过近距离无线点对点技术与代理进行交互，并接受代理提供的计算和缓存
服务。当需要执行计算密集型任务时，MD首先将该任务发送到代理，随后，代
理将代表该MD对任务进行远程执行。这个将任务发送出去进行远程执行的过程
被称为计算卸载。通过计算卸载，网络觅食可以显著提升移动应用的执行性
能并有效降低MD的能耗，从而大幅提高MD的用户体验。这一解决方案在当时受
到了学术界的广泛追捧，但最终并没有被产业界所采用。这主要包括以下原因
[8]
。
首先是运营管理方面的问题，如：代理应该部署在网络的什么位置？由谁进行部
署及管理？商业模式是怎样的？其次是技术实现方面的问题，如：代理上的多个
应用之间应采用何种隔离方案？移动应用程序应该怎样进行分割？如何保证MD和
代理之间的状态一致？在移动计算（Mobile Computing, MC）时代
[4–6]，这些问题都还没有较为令人满意的答案。
2006年，亚马逊（Amazon）推出了两款划时代的互联网产品——弹性云主
机EC2（Elastic Cloud Computer）和简单存储服务S3（Simple Storage Service）。次
年，云计算（Cloud Computing, CC）的概念正式被谷歌（Google）提出。其基于
日益成熟的虚拟化和分布式技术，将计算和存储资源在网络核心进行集中部署和
统一管理，并封装为各种能力对用户提供按需服务，具有很高的灵活性、可靠性、
可扩展性和性价比[9–11]
。在短短的十几年中，云计算迅速从萌芽阶段发展到空前
繁荣，深刻改变了当今的信息技术产业格局。在云计算出现之后不久，移动计算
便开始与之融合，移动云计算（Mobile Cloud Computing, MCC）的概念随之被提
出[12–14]。基于云数据中心提供的强大计算和存储能力，以及3G/4G移动网络提供
的大带宽数据传输能力，计算卸载得以在MD和云之间实现，很好地解决了MD所
面临的计算能力弱和续航时间短的问题。各类移动应用不再受到MD能力的限制，
得以大规模部署，真正促成了移动互联网的繁荣。
然而，随着近年来移动互联网的进一步发展以及物联网（Internet of Things,
IoT）[15, 16]
的逐步普及，云解决方案的局限性也逐渐暴露出来。首先，其无法满
足新兴应用场景对网络时延更加苛刻的需求。由于云数据中心位于网络核心，远
离终端用户，导致应用数据需要远距离传输。即使在不考虑网络拥塞的情况下，
云解决方案的端到端网络时延也在数十甚至数百毫秒级
[17]。但是，增强/虚拟现
实（Augmented/Virtual Reality, AR/VR），数字医疗（eHealth），自动驾驶，工业智
能控制等新兴的强实时应用均要求网络的传输时延在毫秒级甚至次毫秒级[18–20]
。
这样的网络时延需求是云解决方案无法达到的。其次，联网设备数量的急剧增
加导致网络数据传输量呈爆炸性增长，而采用云解决方案汇聚所有网络流量将让核心网不堪重负。根据思科（Cisco）在2017年发布的视觉网络指数白皮书[21]，到2022年，全球联网设备数量将达到人口总数的三倍以上，预计为285亿台；而全球年网络流量更将达到4.8泽字节（ZB）。将上述海量数据通过核心网传输到云数
据中心会消耗巨大的能量，同时也可能导致严重的网络拥塞。
云解决方案的这些局限性均是由资源集中部署在网络核心所导致。因此，将
云计算资源下沉，在靠近用户或数据源的“网络边缘”提供计算和存储能力进行
“就近服务”，已经成为了学术界和产业界的共识。早在2009年，学术界便已经
开始了针对云计算资源下沉的早期研究。随后，微云（Cloudlet）、雾计算（Fog Computing, FC）[23]以及国内的海计算[24]等概念相继出现。2014年，移动边缘计算（Mobile Edge Computing, MEC）[25–29]被欧洲电信标准化协会（EuropeanTelecommunications Standards Institute, ETSI）正式提出，旨在在移动网络边缘提供IT服务环境和云计算能力，为移动用户提供更低时延、更高带宽、更大规模连接的移动通信服务，并进一步打造开放、弹性、协作的生态系统。2017年，ETSI将MEC的概念进一步延伸至其它接入网络（如WiFi，车辆网络，甚至固定
网络），将其更名为多接入边缘计算（Multi-access Edge Computing）[34]。承载各类云计算能力并为用户提供就近服务的网络实体也从原来的移动基站或者其附属服务器扩充为网络边缘具有处理能力的所有设备，如无线接入点（Access Point,AP）、路边单元（Road Side Unit, RSU）、交换机、路由器、甚至是其它的MD。这些具有处理能力的网络实体在本文中被统称为“MEC服务器”（MEC Server,MS）。
计算卸载关键技术及其卸载决策问题
在MEC中，计算卸载的具体过程如下：
- 任务数据上传：将需要卸载的任务的相关数据（如任务的输入数据、环境
上下文数据、任务的执行代码等）通过无线网络上传至MS。这些数据可
以通过程序分析器（program profiler）来获取
[13, 27, 47]
。 - 任务远程执行： MS保证所上传任务的执行环境与MD一致并对该任务进
行远程执行。这是由MS上的计算卸载代理（surrogate/proxy，以下简称代
理）实现的
[13, 27, 47]
。代理的具体实现方式是多样的：可以被实现为虚拟
机（Virtual Machine, VM），也可以被实现为网络服务；可以由单用户独
占，也可以由多用户共享
[35, 48–50]
。 - 任务结果反馈：当任务远程执行完成之后，MS通过无线网络将任务的运
行结果反馈给MD。
可以看出，计算和通信在整个卸载过程中紧密结合。从计算的角度出发，通
过卸载可以大幅缩短任务的执行时延，也节省了任务的本地执行能耗；但从通信
的角度出发，计算卸载过程中数据的上传和结果的反馈又引入了额外的时间和能
量开销。因此，计算卸载实质上是一个用通信开销换取计算开销的过程。如何进
行合理的卸载决策，以更好地折中计算开销和通信开销，从而达到令人满意的移
动应用体验，是计算卸载技术的关键所在。
对移动用户而言，其需要
解决是否卸载任务、卸载什么任务、何时卸载任务、何处卸载任务等问题；对运
7电子科技大学博士学位论文
营商而言，其需要解决是否允许用户卸载任务、分配多少资源执行卸载任务、如
何解决用户间的资源竞争等问题。由于MEC场景的复杂性，影响卸载决策的因素
众多。以下分别站在移动用户和运营商的视角对一些重要的影响因素进行说明。
站在移动用户视角，卸载决策需要考虑以下因素。首先，待卸载的任务属性
不同：有的任务不可分割，仅能作为整体进行卸载；有的任务可以划分为多个子
任务，从而进行细粒度卸载。若进行细粒度卸载，则还需要考虑子任务的划分方
式和子任务之间的依赖关系等问题。其次，用户进行计算卸载的目的各异：可能
是为了加速程序运行，也可能是为了降低MD的能耗，还有可能是为了两者兼顾。
这直接影响到卸载决策的最终优化目标。如果再将系统的动态因素考虑进来，如
任务的动态到达、用户的移动性、无线信道质量的动态变化等，卸载决策问题将
变得非常复杂。
站在运营商视角，卸载决策需要考虑以下因素。首先，运营商需要服务于多
个用户，而网络边缘的计算和通信资源均是有限的。这就涉及到用户之间的资源
竞争和分配问题。其次，运营商进行卸载决策的目的也同样是多样的：可能是为
了让系统的资源利用率更高；也可能是为了服务更多数量的用户；还有可能是为
了经济收益更大。而不同的目的会得到不同的卸载决策问题。另外，为了解决网
络边缘资源有限的问题，运营商还可能引入“边与云”或者“边与边”之间的协
作机制，这使得卸载决策问题进一步复杂化。
本文地址：https://blog.csdn.net/qq_19132935/article/details/110917529