6G移动通信网络^[1]将实现全新的范式转变，有望达成万物智联、支撑全社会深度数字化转型的愿景。6G将不仅仅追求传输速率和网络容量的突破，更要实现通信、计算、感知一体化，实现信息、通信和数据技术的深度融合^[2]。面对在网络边缘接入的海量设备产生的海量数据以及广泛的低时延高可靠需求，移动边缘计算是支撑6G网络建设的关键技术^[3]。移动边缘计算(mobile edge computing，MEC)将云计算能力分布式下沉至网络边缘，相比于传统的移动云计算，将极大提升数据的处理效率，降低由数据长距离路由和传输引入的时延。

MEC领域的关键问题已得到广泛研究。软件定义网络、网络功能虚拟化^[4]是支撑MEC系统与移动通信网络融合的关键技术。文献[5]着眼于MEC的移动性管理问题，为MEC的服务连续性提供了保障。MEC系统的计算资源与网络资源分配的联合优化^[6]实现了系统的低时延性能与资源负载平衡。用户设备向MEC系统计算卸载策略的设计^[7]平衡了能量消耗与时延性能。MEC的安全与隐私问题也越来越受到关注^[8]。

然而，以上研究都没有关注复杂架构下的多主机MEC系统，在实际的计算密集型、多用户应用场景下难以达成低时延高可靠的性能指标，因此多主机MEC架构仿真工作也存在空缺。对多主机MEC系统讨论的不足限制了时延的优化空间，难以实现进一步的突破。基于以上讨论，为实现复杂多主机架构下MEC系统时延优化，本文提出横向多主机架构与多连接主从多主机架构，并设计了相应的完整信令流。搭建了多主机MEC架构的仿真平台验证性能表现。使用与真实部署环境的相符合的系统级5G-MEC仿真，通过将UE端的高维矩阵乘法运算通过5G移动网络卸载至MEC主机进行计算这样一个贴近现实场景的计算卸载任务，仿真验证了所提出的多主机架构可显著降低MEC系统的端到端时延。

1 研究现状

MEC在网络边缘端提供了计算与存储能力，能够有效降低计算卸载的时延^[9]。MEC将计算资源下沉至RAN(radio access network)内，如图 1(a)所示，用户设备的计算卸载任务可以在接入的边缘节点内完成计算。

用户设备与MEC系统的交互主要有以下3个步骤：

步骤1 任务卸载   数据上行传输过程，用户设备将计算卸载任务所必要的数据上行传输至特定的MEC主机。

步骤2 服务调用与计算   MEC主机根据计算卸载任务的需要调用相应的MEC服务，计算产生用户设备所需要的结果数据。

步骤3 结果回传   数据下行传输过程，MEC系统将用户所需的计算结果下行传输至用户设备。

欧洲电信标准化协会(European Telecommunications Standards Institute，ETSI)规范化了MEC系统，为其制定了参考架构^[10]。在这套参考架构下，各个功能实体的功能与交互都得到了良好的定义。ETSI将MEC系统层次化为MEC系统层与MEC主机层。

MEC系统层   主要负责响应终端用户请求，维护MEC系统的全局信息。

MEC主机层   负责为MEC系统提供软、硬件资源并维护软、硬件资源。

ETSI MEC已经成为当下较为通行的重要MEC标准。然而如图 2(a)所示的参考架构中的单主机架构资源有限，将成为优化低时延MEC的瓶颈。

文献[11]利用ETSI MEC参考架构的标准化接口在边缘端部署了基于LoRa(long range radio)协议的IoT(internet of things)应用，相比于在中心云上的部署，减少了数据获取与处理的延迟。文献[12]提出一种基于ETSI MEC参考架构的车辆碰撞检测算法及其测试平台实现，MEC的低时延特性显著提升了算法的有效性。文献[13]提出一种在支持ETSI MEC的蜂窝网络中进行MEC流量与互联网流量识别与优先级排序算法，避免MEC流量拥塞从而进一步降低时延。文献[14]对比了在LTE(long term evolution)、5G NSA(non-standalone)、5G SA(standalone)部署环境下集成ETSI MEC系统的性能表现，仿真说明MEC系统在5G SA部署环境下拥有更加优异的时延性能表现。但是以上工作均在单主机架构下进行讨论，忽略了多主机复杂架构可能带来的时延优化潜力。

2 多主机架构与信令流

卸载至边缘端的计算任务通常是计算复杂度极高的任务，需要充足的计算资源。使用MEC的代价是要付出相应的通信时延，如果计算任务在本地设备执行的时延与计算卸载的通信时延相比处于相同的量级，那么将计算任务卸载至边缘是不合适的选择。部署在基站单元内的MEC系统是面向多用户的，一旦基站单元所服务的用户量增大，用户将对边缘端有限的资源进行竞争，会造成排队时延。根据计算卸载对计算资源的大量需求和潜在的多用户对边缘资源的竞争，部署在边缘端的单MEC主机的资源有限，单主机架构将不能满足越来越多用户设备的接入与计算密集型低时延应用需求。

然而多主机的并行计算会引入掉队者问题^[15], 这是分布式计算场景下的一个重要问题。由于计算节点的工作负载不均衡以及其本身存在不可控的异质性等问题，各计算节点完成各自任务所耗费的时间不尽相同。但是完整任务的结果依赖所有参与计算节点生成的子结果，也就导致了任务计算总时延取决于所有子节点中计算时间最长的节点。仅仅增加主机数量无法降低计算卸载的传输时延。计算卸载任务通常都会有不可忽视的数据量，因此计算卸载的过程中存在显著的通信时延，对低时延的MEC提出了巨大挑战。

2.1 横向多主机架构 2.1.1 架构设计

为降低计算卸载中的计算时延，提出一种横向多主机架构，如图 2(b)所示。单主机架构进行横向拓展，为一个基站单元配备多台平行的MEC主机，即为横向多主机架构。多台MEC主机的部署能够为基站单元带来更充足的资源为用户提供服务。而且，利用某一类卸载任务的可拆分性^[9]，这种架构可以带来更灵活的计算卸载方案，即拆分一个完整计算任务，将拆分后的子任务卸载至不同主机进行运算，从而降低用户请求MEC系统的计算时延。

2.1.2 信令流设计

对于横向多主机架构，设计了完整的端到端信令流如图 3(a)所示。从UE(user equipment) app至MEC编排器逐级传递N个MEC app实例化请求信令，MEC编排器按需选择合适的N台MEC host，N台MEC host成功实例化终端用户所需的MEC app后，逐级回传N个MEC app进程实例的IP(internet protocol)地址、端口号等信息信令。UE app获得完整的回传信息信令后，UE app会分拆计算卸载任务，直接与N个MEC app通信，向其发送待计算的分拆子任务数据。N个MEC app完成子任务计算后回传子结果，UE app接收回传子结果并根据子结果恢复整个计算卸载任务的总结果，信令流结束。

2.2 多连接主从多主机架构 2.2.1 架构设计

为进一步降低计算卸载中由掉队者问题引入的计算时延，同时优化计算卸载过程的传输时延，提出一种多连接主从多主机架构。多连接技术允许用户设备同时接入多个基站，实现向多个基站的并行传输，是一种有希望实现超高可靠超低时延通信的技术^[16]。通过编码计算方法缓解掉队者问题是一种行之有效的解决方案^[17]。编码计算的基本思想是通过增加一定量的额外计算来换取计算时延的鲁棒性。在这个过程中存在主从节点的结构，主节点负责调控整体的编码、任务分配与结果恢复工作，子节点负责计算主节点分配的计算子任务。主从多主机架构实现了编码计算所需要的主从节点结构，为编码计算技术的引入提供了可能。结合多连接与编码计算技术，多连接主从多主机架构如图 2(c)所示。多个基站单元构成一个组，组内基站可供用户设备进行多连接。同一分组内的每一个基站单元都被分配多台MEC主机，这些MEC主机形成层次化的主从关系结构，构成MEC主机集群，集群内分为主节点与工作子节点。主节点负责获取分配到该MEC主机集群的计算任务，将计算任务进行编码后，合理地将编码后任务分配给集群内的工作子节点进行计算。通过编码计算技术，不必等到每一个被分配计算任务的工作子节点都完成计算，主节点就能够获取到足够数量的子结果，得到这一集群应该产生的计算结果。因此，掉队者问题得到缓解，提高了边缘端计算的鲁棒性，能够有效降低计算时延。另一方面，用户设备多连接至多个基站单元，用户设备端进行一次计算任务拆分后能够并行传输计算卸载的数据，这将有效降低整个计算任务卸载过程中的通信时延。

2.2.2 信令流设计

针对多连接主从多主机架构，设计了多连接的任意一条连接链路上完整的端到端信令流，如图 3(b)所示。从UE app至MEC编排器逐级传递MEC app实例化请求信令，MEC编排器首先选择该条接入链路上的主MEC host，并向这台主MEC host发送实例化终端用户所需主MEC app信令，主MEC app将负责接收UE发送的数据信息并对数据进行拆分、编码与分发。主MEC app紧接着会向从属于主MEC host的各个子MEC host发送实例化子MEC app请求信令，子MEC app将负责计算主MEC app下发的计算任务。最终主MEC host向UE app逐级回传主MEC app实例的IP地址、端口号等信息信令。因此，UE app的交互主体为主MEC app，并不会与子MEC host与子MEC app产生直接交互，减轻了用户设备端的复杂度。UE app获得完整的回传信令后，根据链路数拆分完整的任务卸载数据，再向每条链路上的主MEC app发送待计算的数据，每条链路上的MEC主机在计算完成后立即回传子结果，UE app接收回传子结果，并汇总子结果恢复整个计算任务的结果，信令流结束。

3 仿真与分析

本节介绍搭建系统级仿真平台的开源组件库，给出仿真中的重要参数，验证仿真平台的有效性，并分析仿真结果。具体地，用户设备通过5G网络向MEC卸载1 200维矩阵-向量乘积计算任务，边缘端完成计算后向用户设备回传结果向量。这个任务包含上行计算卸载数据传输、边缘端计算与下行结果传输过程，可以对MEC系统端到端时延进行精确评估。

3.1 仿真平台搭建

OMNeT++^[18]是一个可扩展的、模块化的、基于组件的C++仿真库和仿真框架，主要用于构建网络仿真。INET^[19]是基于OMNeT++的开源模型库，提供计算机网络协议、无线和有线网络链路层协议等，以符合OMNeT++的形式将协议封装为各种module组件。Simu5G^[20]是一个基于OMNeT++的5G仿真组件库，提供了符合3GPP标准的链路层和物理层协议模型。Simu5G拥有定义良好的接口，能够与INET库兼容，允许用户实现任意复杂度的端到端、全链路、基于5G蜂窝网络接口的TCP/IP网络仿真。更重要的是，Simu5G提供了符合ETSI标准的MEC相关组件和功能，为仿真5G-MEC系统提供了支持。本文基于以上所介绍的开源组件库搭建了仿真平台，并在仿真平台上构建了所提出的多主机架构仿真。

3.2 计算任务选取

选取高维矩阵乘法作为计算任务进行仿真与分析。图像、视频渲染计算是边缘计算的典型应用场景之一。渲染管线^[21]的逐步推进主要包括以下几个流程：顶点变换和属性构建、图元处理、光栅化、片元计算。顶点变换和属性构建阶段涉及大量模型的平移、旋转、缩放、空间映射操作，这些操作都是通过矩阵乘法描述与实现的，在渲染计算的计算复杂度中占据主要部分^[22]。分布式机器学习是边缘计算的另一个典型应用场景，其中矩阵乘法是机器学习算法的关键^[17]。矩阵乘法是众多边缘计算典型应用场景下的基础运算，而且矩阵乘法的计算复杂度极高，因此选取高维度矩阵乘法运算作为仿真的计算任务具有普适性与代表性。

3.3 仿真参数

在5G NR的Sub 6G场景下，最大可选带宽为100 MHz。当前5G组网最常见的子载波间隔为30 kHz。更大的带宽和更大的子载波间隔能够带来更高的数据传输速率，因此选定传输带宽为100 MHz，子载波间隔为30 kHz。横向多主机架构选用2台MEC主机，多连接主从多主机架构选用双连接，每一条链路内拥有1个主节点和3个工作子节点，采用(3, 2)MDS(maximum distance separable)编码。其余主要仿真参数^[20]如表 1所示。

3.4 仿真结果分析

1) 仿真平台有效性分析

以横向多主机架构在仿真平台运行结果为例，整理了仿真平台运行生成的日志，总结仿真运行过程中关键步骤发生的时间节点如图 4(a)所示。根据该架构下设计的信令流，仿真平台能够准确输出所需的观测数据，从而有效地完成相应任务对多主机MEC架构进行仿真。由于仿真过程中的关键步骤信息大多以文字日志的形式输出，无法在仿真界面框内进行可视化，图 4(b)展示了一个能够可视化展示的步骤，UE正在向其中一台MEC host下发子任务数据。

2) 多连接主从多主机架构对掉队者问题的优化

掉队者问题存在于多主机架构之下^[15]。多连接主从多主机架构为引入编码计算技术优化掉队者问题提供了架构支持。2种多主机架构下1 200维矩阵-向量乘法任务的主机节点计算时延如图 5所示。在仿真中，多连接主从多主机架构选用双连接，1个MEC主机集群拥有3个工作子节点，因此引入(3，2)MDS编码^[23]，将集群的计算任务拆分为2部分，由这2部分编码生成第3部分，分配给3个工作子节点进行并行计算。因此在一个集群内，只要有任意2个工作节点完成计算任务，这一集群的计算结果就可以恢复。图 5(a)给出多连接主从多主机架构在仿真中参与计算的2个MEC主机集群内各个工作节点的计算时延。MEC主机集群1内计算时延最短的节点耗费3.82 ms，完成计算任务的计算时延为4.97 ms；MEC主机集群2内计算时延最短的节点耗费3.82 ms，完成计算任务的计算时延为4.63 ms。因此多连接主从多主机架构下总计算时延为4.97 ms，落后者效应使计算时延性能下降30.1%。横向多主机架构无法缓解掉队者问题。在仿真中，横向多主机架构选用2台MEC主机。图 5(b)给出2台平行MEC主机的计算时延，分别为9.28与13.15 ms，因此横向多架构下总计算时延为13.15 ms。落后者效应使计算时延性能下降41.7%。多连接主从多主机架构优化了并行计算中掉队者问题带来的计算时延性能下降问题，在实际部署中使用冗余度更高的MDS码将带来更大的性能增益。

3) 上行传输时延对比

在不同架构下仿真测得的上行传输1 200维方阵的传输时延如图 6(a)所示。单主机架构和横向多主机架构在用户设备与基站间的无线传输阶段都是单链路传输，因此2种方案的上行传输时延是一致的。多连接主从多主机架构在无线传输阶段为双链路并行传输，明显降低了上行数据传输时延。但由于存在主从架构，主节点收到数据后还要对数据进行拆分、编码等工作，接着分配给所属的工作节点，因此最终的上行传输时延并非前2种方案的一半。

4) 计算卸载时延架构间横向对比

在不同架构下通过5G网络向MEC卸载1 200维矩阵-向量乘法任务的完成总时延如图 6(b)所示。单主机架构花费了最长的时间完成整个任务。横向多主机架构在一定程度上降低了计算时延，但是由于主机间的异质性问题，导致计算时延没有下降至单主机架构的1/2。由于卸载任务数据量不变，横向多主机架构仍然是单链路上行传输，传输时延没有得到优化。在多连接主从多架构下，传输时延和计算时延同时得到了优化。多连接使得上行数据可以在多条链路上并行传输，有效降低了数据的传输时延。MEC主机主从关系结构的加入让编码计算策略得以实施，有效缓解了多节点并行计算中的掉队者问题。性能最好的多连接主从多主机架构成功将千维矩阵乘法计算卸载任务的时延控制在20 ms以内。

4 结论

本文针对低时延MEC系统架构设计，提出2种多主机架构，设计了2种架构下完整的信令流，搭建了多主机MEC架构仿真平台以评估架构的关键性能指标。针对计算时延的优化问题，提出横向多主机架构，设计了该架构下完整信令流。针对传输时延和掉队者问题的优化，提出多连接主从多主机架构，设计了该架构下完整的信令流。实验与仿真表明，横向多主机架构降低了计算卸载的计算时延；多连接主从多主机架构进一步优化了计算卸载的传输时延和并行计算的掉队者问题；搭建的仿真平台能够有效评估多主机MEC架构的时延性能。仿真平台的代码已在GitHub平台(https://github.com/eva-ding/simu5G-for-MEC)开源。下一步将继续探索性能更优的MEC系统复杂架构设计，扩充多主机MEC架构仿真平台的功能。