2. 北京邮电大学 网络体系构建与融合北京市重点实验室, 北京 100876
提出了多接入边缘计算（MEC）在接入侧和核心网中的联合部署架构.利用容器和微服务模式设计MEC的敏捷部署方案，通过修改基站的数据面协议栈，完成MEC流量高效地分辨和调度，并基于智能域名解析，实现接入网、核心网中MEC业务的智能联合调度.实验测试结果表明，该架构能够根据业务特性合理地分配分布式的MEC处理节点，降低了完成任务的时延，提升了可扩展性.相较于独立部署架构和传统的业务分配方式，本架构在第5代移动通信系统（5G）的网络低时延场景下具有更好的性能.
2. Beijing Key Laboratory of Network System Architecture and Convergence, Beijing University of Posts and Telecommunications, Beijing 100876, China
A novel architecture of cooperated deployment for multi-access edge computing (MEC) was proposed to integrate the radio access networks and core networks. It makes full use of container technology and micro-service to implement the agile deployment scheme. MEC traffic flow is recognized and forwarded efficiently with a modified the protocol stack of data plane in base stations. Moreover, the intelligent domain name system was introduced to handle cooperated task allocation of MEC among multiple network elements. According to the results of practical experiments, the proposed architecture may allocate appropriate MEC processing nodes to specific tasks in line with their characteristics to reduce the delay and enhance the scalability. It provides better performance for low-latency scenarios in the fifth generation of mobile communications system(5G) compared with standalone deployment and traditional task allocation approaches.
为了提升网络的处理能力，移动/多接入边缘计算(MEC, mobile/multi-access edge computing)由欧洲电信标准化协会于2014年提出，以此为无线接入网(RAN, radio access network)提供IT和云计算能力.部署在接入侧的边缘服务器具备了本地处理应用层业务的能力，并结合RAN提供的无线侧相关信息，能够实现低延时、高带宽和网络上下文感知的业务特性[1].在第5代移动通信系统(5G，the fifth generation of mobile communications system)网络中，由于需要对多种业务场景提供特定的服务质量(QoS, quality of service)支持，例如高带宽需求的超密集网络、大规模接入场景下的窄带物联网(IoT, internet of things)网络以及无线局域网网络，移动边缘计算将其目标拓展为多接入边缘计算.与此同时，根据5G新型网络架构设计，MEC的部署位置亦从原先的宏基站和基带处理单元池拓展至核心网的用户面功能(UPF, user plane function)[2].在现有的MEC部署架构基础上，本文提出了MEC在基站和核心网的联合部署架构，改进了基站侧的协议处理流程，实现基于IP地址的业务类型识别，并通过智能域名解析系统(DNS, domain name system)进行MEC业务的协同分配.最后本文通过实验给出了联合部署架构的性能测试和影响性能的参数.
1 多接入边缘计算联合部署架构5G中对业务要求的100 Gbps吞吐量，端到端毫秒级时延给移动通信技术带来的巨大挑战.但是随着软件定义网络(SDN, software defined network)、网络功能虚拟化(NFV, network function virtualization)、轻量级容器以及与分布式计算的发展，信息技术和通信技术的融合能够将上层功能下沉到网络边缘，提供更靠近用户的数据处理能力，从而降低网络传输的整体压力，缩短端到端传输距离，并简化通信流程[3].这使得MEC成为达到5G网络性能的关键技术之一.
1.1 MEC部署主要模式最初提出实用的边缘计算系统框架的是基于OpenStack和虚拟机的Cloudlet系统，其设计了可信且计算资源丰富的边缘集群[4]，但受限于Cloudlet简单的网络功能，该系统只适用于WiFi网络，并且基于中间层的虚拟化方式消耗资源较大，性能降低明显.随着基于命名空间的隔离技术的成熟，剑桥大学的Adisorn等使用Docker和树莓派设计了PiCasso系统，并通过本地镜像库提供应用服务，但是该系统受限于硬件条件，只适用于物联网场景，无法支持多媒体和高计算量业务[5].
Eurecom的Navid等基于OpenAirInterface系统和SDN重新改造了4G基站，使其能够通过OpenFlow流表分离通用分组无线服务隧道协议(GTP, GPRS tunnelling protocol)封装内的本地和核心网流量，将本地流量通过OpenvSwitch路由到目标MEC服务器[6]，然而OpenvSwitch主要利用CPU进行软路由，对于高并发大数据量的流量无法做到高效处理.在此基础上，Intel公司通过DPDK和NFV技术提出了NEV边缘计算平台[7]，提升了网络转发效率，但是NEV局限于Intel硬件，而GTP重新拆解数据包的方式增加额外的处理负担和单点故障率.
1.2 MEC联合部署架构设计欧洲电信标准化协会提出的MEC方案主要应用在RAN中，而3GPP则倾向于将其部署到核心网的UPF和应用功能(AF, application function).为了充分利用二者的优势，需要借鉴双方优势的实现联合部署架构研究和设计.由于部署虚拟机需要额外花费大量的资源配置运行环境，同时为了降低将5G网元开放给第三方所带来的不安全性，MEC的联合部署架构拟采用容器的方式部署新MEC应用，其架构如图 1所示.
|
图 1 多接入边缘计算联合部署架构图 |
在5G网络架构中，基于微服务的核心网是网络功能实体演进的重要方向，微服务之间目前比较成熟的接口主要为表征性状态转移(RESTful, representational state transfer)接口[8].用户侧(UE, user equipment)通过RESTful接口，辅以IP地址加端口号的方式确定具体的参考点，与MEC平台进行交互. MEC网元作为接受用户请求的参考点，位于基站本身或移动核心网内部，因此外部的DNS服务器无法解析MEC服务的具体地址.为了解决内部地址解析问题，需要在架构中引入内网DNS处理MEC的RESTful请求.内网DNS根据收集的底层资源数据和用户位置情况决定将用户请求解析到特定的MEC网元地址.为了降低GTP解包封包的额外工作，联合架构在基站内部进行业务的分流. MEC业务和一般业务经由两个不同的协议栈处理，MEC业务以基站为网关，直接转发至目标地址.
考虑到在5G初步部署场景下还大量存在4G基站(eNodeB)，4G基站和5G基站(gNodeB)共存将是5G初始阶段不可避免的问题，因此eNodeB也需要对基站数据面协议栈结构进行改进.由于双协议栈模式并不影响原有LTE业务流程，4G核心网和用户无需做出额外更新.在MEC场景下，由于业务种类和需求量差异性较大，冗余和低频应用会占据并不宽裕的物理层资源；同时需要在新业务突发到来时，能够实现业务的敏捷部署，所以在MEC平台中，所有的应用都需要打包成对库无依赖性的独立应用，并以服务镜像的方式提供给容器调用.此外，服务镜像需要存储在MEC平台可高速获取的磁盘阵列服务器中，降低获取镜像所带来的初始化时延.
2 基于RAN的高效流量调控设计流量调控(TS, traffic steering)是分辨MEC业务和一般业务的关键环节，然而由于GTP隧道协议的存在，在核心网中通用协议处理流程无法区分GTP包中的应用数据类别，而基于GTP解包的处理方式增加了处理复杂度和故障率，因此需要研究RAN侧流量调控.
2.1 基站数据面协议栈优化为了实现MEC业务流量的区分，需要在数据流中添加特征信息作为流量调控的依据.从MEC平台的分布式特点来看，MEC各个功能单元可以被认为是独立的AF.而在5G服务化核心网中，每一个功能实体可以通过(IP地址，应用端口号)的二元组来唯一定位，所以网络层是实现用户流量分载的首要选择.
在移动通信网络中，基站和核心网之间使用GTP协议封装用户面数据，并将GTP数据包作为应用层数据，重新加上UDP和IP报头，在传输网中传输.传输网不需要了解应用层的内容，只负责将数据包可靠地交付到数据交换网络，GTP在数据交换网络之前的网关(P-GW或UPF)解封装. MEC应用在移动通信网络内部处理用户数据，因此不仅需要端到端传输，还需要对内部数据进行处理，更重要的是MEC网元在移动网内是可见的，这使得MEC业务在传输中不必使用GTP-U协议.
|
图 2 联合部署架构协议处理流程 |
改进后的基站数据面协议栈主要由两个部分组成，底层的接入协议被用来处理无线侧相关业务，属于通用的无线通信处理协议，只对RAN有效，不影响后续的流量调度.所有流量在GTP封装之前需要进行流量类型的判别，如果是属于MEC业务，则不需要进行GTP封装操作，直接通过IP转发到指定的MEC参考点.原数据包不需要再次添加UDP和IP的数据报头，其处理流程和QoS指标按照标准的TCP/IP报文处理即可，MEC平台可以像处理以太网流量一样处理传输网中的业务.需要指出的是，MEC平台可能位于基站和核心网两处，当MEC业务直接由基站本身处理时，将直接转发至基站的内部容器地址，不再经过传输网.
2.2 流量调控功能设计流量调控作为MEC处理的核心功能之一，关系到系统的整体性能和稳定性.基站是无线到有线传输的分水岭，相当于是有线传输的起点，在基站中实现流量调控，避免了核心网中使用包检测和重定向功能.流量的区分主要通过IP来识别，所有的基于MEC的服务都使用限定的IP.为了实现IP的分流，需要利用Linux的内核转发功能.
无线侧和有线侧帧的处理使用不同的协议栈，数据包必然会进行IP层的处理.在GTP-U协议处理数据面流量之前，流量调控功能需要对目标IP进行以此检测.如果目标IP地址属于MEC的地址范围(包括本地容器地址)，则中断3GPP规定的处理流程，并将该IP包交付给内核，而内核通过使用路由策略数据库(RPDB，routing policy database)包含的一些规则和多张路由表来选定合适的IP路由.
在联合MEC部署架构中，基站本身的MEC功能被作为容器打包运行在系统中，而UPF的MEC参考点也有特定的地址，因此可以通过配置内核路由表实现流量调度.同时非MEC流量则不会直接进入路由表，而是GTP封装后，再由内核路由表转发. 表 1展示了内核路由表在处理流量调度时的配置示例.其中，默认路由是经过GTP封装之后所使用的路由表项，通常指向S-GW或UPF网关.第二、三行是AF中的边缘计算平台，以主机路由的方式出现，代表了目前服务该基站的核心网侧MEC网元.需要指出的是，移动网络允许多个MEC网元同时服务一个基站，因此可以存在多个MEC平台的主机路由表项.最后一行表示的是基站本地MEC的路由表项，当业务归基站侧MEC应用处理时，流量会转发给本地的docker网桥，从而保障更低的时延，尤其适用于超低延时高可靠场景.
|
表 1 MEC联合部署基站路由表 |
在第2节中，基站通过匹配指定的IP地址来进行流量的分辨和调度.但是对于用户而言，并不知道每一个MEC网元的地址，用户只是通过统一的域名访问RESTful接口，因此需要智能DNS来实现同一域名到不同IP地址的映射.
3.1 基于RESTful的任务传输API对于MEC平台而言，服务以容器的形式存在于MEC网元中，IP与端口号确定了目标MEC服务单元的位置.然而，对于同一个服务而言，需要不同的操作内容和用户相关的特定参数.因此，需要扩展基于RESTful的任务接口，其具体主要由4部分组成：
ACTION/serviceURI=〈v1〉/action=〈v2〉?usertoken=〈v3〉 & 〈jsonEncodedParameters〉
首先为了明确服务类型serviceURI，需要匹配正确的服务名称，处理同一类型服务的容器拥有相同的服务名称，如果用户上传的业务类型与容器能够处理的业务类型不一致，将会造成无法找到serviceURI的错误.其次，需要显式的表达出操作的类型，一方面便于客户端开发，由于MEC的服务范围不仅包括正常智能终端业务，也包括IoT终端，然后受限于硬件成本，许多IoT设备缺乏完整的应用层协议支持；另一方面，因为基于RESTful的请求一般为无状态请求，在出现网络故障时，客户端发送一个请求后不能立即得到响应，由于不能确定请求是否被成功提交，所以客户端有可能会再次发送另一个相同的请求，幂等性决定了第2个请求是否有效.在HTTP协议中，只有GET、HEAD、OPTIONS和PUT方法是幂等的，因此出于一致性与安全性考虑，系统中应限定只使用这4种方法(目前设计中只使用了GET方法)，而具体的增加、读取查询、更新和删除操作由RESTful接口中的action字符内容确定.此外，用户的身份信息应包含在请求的URL中，用以检测是否拥有操作的权限.
由于MEC业务类型差异大，需要有统一的参数传递方式，但是受限于RESTful的URL表述机制，需要采用额外的数据结构传输来自用户的多媒体数据. JS对象简谱(JSON, JavaScript object notation)作为一种轻量级的数据交换格式，采用完全独立于编程语言的文本格式来存储和表示数据，被广泛地应用于数据交换. JSON不仅可以用户传输文本数据，还可以用来传输图片，对象等复杂数据结构，同时因为其轻量级和对机器友好的特性，在IoT中也得到了大规模应用，因此在架构设计中，客户端需要将用户参数进行JSON编码再进行base64编码，从而增强MEC架构的兼容性.相对应地，服务端需要进行结构化的JSON解码，从而获取实际的用户参数.
3.2 DNS解析目标选择的任务调度机制智能DNS部署在5G数据面网关和数据交换网络的交汇处，作为内网DNS服务基于RESTful的MEC业务请求，此外，还通过将RESTful请求解析成不同的IP地址实现MEC业务的分配.通常，该智能DNS作为P-GW或者UPF的默认DNS网关.
智能DNS需要在配置项中需要预设一个MEC专用域名，当接收到专用域名的解析请求时，则将其解析到RAN或者核心网侧对应的MEC平台地址.为了保证目前MEC平台的可用性，所有可处理用户请求的MEC平台需要通过注册机制，向网络暴露功能(NEF, network exposure function)登记自身的服务和性能，并周期性地向NEF发送心跳包，维持在线的状态.智能DNS通过获取NEF上登记的MEC平台状态，更新IP解析地址库.
与一般DNS的负载均衡机制不同的是，负责智能DNS的AF还需要通过RESTful接口周期性地向MEC负责联合编排和管理(CO & M, coalition orchestration and management)的AF发送资源监控请求, 包括基站请求的流量、MEC节点可用的物理资源、核心网的传输时延等.根据收集来的网络上下文，智能DNS将会建立任务分载模型.
在本文架构中，使用Dnsmasq作为DNS服务器，通过配置其轮询机制实现任务分配.但是Dnsmasq轮询只是将多个服务器IP映射到同一个主机名URL，并没有更多的分配机制.因此，将根据一定条件设置每一个URL的解析项数量，实现任务调度机制.对于可用的MEC服务节点k，其占用的DNS解析条目数ρk如
| $ {\rho _k} = N\left\lceil {\frac{1}{{{D_k}}}{R_k}{f_k}{p_k}{\eta _k}{{\left( {\sum\limits_I {\frac{1}{{{D_i}}}} {R_i}{f_i}{p_i}{\eta _i}} \right)}^{ - 1}}} \right\rceil $ | (1) |
其中：N表示设置的解析项总条目数；Dk表示客户端到节点k的平均时延，本文中使用ping程序的时延作为基准，需要注意的是Dk对大传输量或大计算量业务的影响小，而对小数据量且小计算量业务有巨大影响；Rk表示客户端到节点k的传输速率；fk和pk分别表示节点的CPU频率和核数；ηk表示目前CPU的使用率.
需要注意的是，通常情况下DNS在发现域名本地无法解析时会采用递归或者迭代的方式，希望从其他DNS服务器上获取域名的解析结果.但是，MEC应用只作用于移动网络内部，递归或者迭代并不会得到正确的结果，还会浪费大量的查询时间，所以需要将MEC的特定域名配置为仅在本地查询.此外，由于UE在一次请求DNS后会将结果暂存在本机的host文件中，其后不再受到智能DNS任务分配机制的影响，且不同系统的DNS缓存时延差别很大，因此需要研究在一定流量下任务分配的平均情况.除此之外，MEC联合部署架构中，DNS本地缓存统一地采用30 s，这样可以根据网络负载状况，周期性地改变任务分配策略.
4 测试实验与结果 4.1 测试实验参数设置为了体现联合部署架构中网络的差异性，测试中使用MEC网元设备如表 2所示.其中，两台性能较差的服务器作为部署在基站侧的MEC网元，CPU性能最好的阿里云主机作为核心网侧MEC单元，在容器资源分配时，实验中限制每个容器最多只可以使用一个CPU，从而避免多核CPU对处理时延的影响.在无线网络方面，采用基于OpenAirInterface的4G FDD-LTE软基站系统，无线射频模块为USRP B210，只使用单天线，基带处理单元为GIGABYTE BSi7HT，50PRB，接入网位于本地机房，核心网3个主要组件归属签约用户服务器、移动性管理实体与服务/公用数据网网关部署在阿里云上.在实际系统中，接入网侧MEC网元传输速率大于核心网侧，但是由于无线接入系统的限制，其上行吞吐量最大可达8 Mbit/s，因此，在实验中使用wondershaper限制核心网侧MEC的带宽为5 Mbit/s.经过Ping程序的实验可得客户端与边缘、核心网侧MEC服务单元的平均往返时延为20.1 ms和79.4 ms，由此亦可以发现现有的4G网络中，数据面空口往返时延是整体时延的重要组成部分.需要指出的是，测试中使用的传输量和计算量较大，因此在实现任务分配机制时并未考虑往返时延的参数.
|
|
表 2 MEC联合部署服务节点参数 |
为了衡量不同传输量和计算量的业务对MEC架构性能的影响，实验中拟采用3种类型业务进行测试，其业务性质如表 3所示.
|
|
表 3 MEC业务属性 |
实验从3个方面来阐释联合部署架构对MEC业务的影响.
图 3描述了在3种部署场景下，不同请求数量对任务完成时间的影响.从实验中，对于低数据量、高计算量的业务A，接入网边缘计算部署方案的时延反而比核心网侧方案高至少30%.这与边缘计算最开始的理念完全相悖，这是由于核心网侧的节点计算能力大于边缘侧计算能力，所以在核心网侧边缘计算节点所需的额外传输时延可以通过降低计算时延来弥补.而对于传输量大，计算量小的业务B，边缘计算节点能够充分利用瓶颈链路少的特点，大大提升任务完成率.联合部署方案通过平衡数据传输和任务处理所需的时延，能够根据业务特性选择合适MEC节点，因此在高数据量、高计算量的业务中，联合部署方案的整体时延可以减少40%.需要注意的是，在请求数量大于15时，传输时延的增长速度迅速上升，这是由于MEC节点链接数量受限，多余的请求会被拒绝，需要等到一部分请求传输完成后才能重新建立连接.而联合部署方案，将请求分散到接入网和核心网两侧MEC节点，一定程度上降低了请求被拒绝的概率.
|
图 3 在不同部署方案下用户请求数量对时延的影响 |
图 4主要说明了不同任务分配机制对架构性能的影响.基于RESTful与智能DNS的任务调度机制考虑了吞吐量和计算能力对任务完成速率的影响.相对于轮询机制，本架构中的分配机制避免了将业务分配给与其业务特性不符合的MEC节点，例如对于A类型业务，轮询机制会将任务等概率的下发给树莓派节点，这大大拖延了任务完成时间.而对于本架构提出的任务分配机制，在计算量较高的场景下能够降低大约10%的时间，但是对于计算量很低的业务类型，并不会比轮询的效果好.
|
图 4 不同任务分配机制对时延的影响 |
图 5中一组数据分别为接入网MEC节点拥有镜像、接入网MEC节点从局域网镜像库下载镜像、接入网MEC节点从云端镜像库下载镜像、核心网MEC节点从云端镜像库下载镜像、核心网MEC节点拥有镜像这5个场景下，完成业务A所需要的平均时延. 图 5表明，任务首次在节点上运行时，还有一个重要的参数需要考虑，即镜像问题.每一个容器都是有镜像从本地生成的，如果节点缺乏所需的镜像，必须先下载该业务的镜像.镜像的大小和镜像库位置对初次执行的任务具有决定性影响，可以占到任务整体完成时间的85%以上.
|
图 5 镜像尺寸与位置对时延的影响 |
MEC在5G系统中部署受到基站、核心网物理资源以及实时流量参数的限制，同时如何实现MEC和一般流量的分辨与调度以及任务的实时分配都是系统实现的实际问题.笔者提出的MEC联合部署架构可以充分利用网络中的设备资源，以智能DNS和RESTful接口实现基于服务的架构，从而满足5G场景下苛刻的性能指标和拓展性要求.通过实验测试表明，联合部署架构能够在同样的资源配置下，能够根据业务特性分配合理的MEC节点，一定程度上减少用户请求的响应时间.
| [1] |
Hu Y C, Patel M, Sabella D, et al. Mobile edge computing-a key technology towards 5G[EB/OL]. Sophia Antipolis: ETSI, 2015[2018-08-08]. https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp11_mec_a_key_technology_towards_5g.pdf.
|
| [2] |
3GPP. 3GPP TS 23. 501—2018, System architecture for the 5g system (Release 15)[S]. Sophia Antipolis: 3rd Generation Partnership Project, 2018: 127.
|
| [3] |
Markakis E K, Karras K, Sideris A, et al. Computing, caching, and communication at the edge: the cornerstone for building a versatile 5G ecosystem[J]. IEEE Communications Magazine, 2017, 55(11): 152-157. DOI:10.1109/MCOM.2017.1700105 |
| [4] |
Satyanarayanan M, Bahl V, Caceres R, et al. The case for vm-based cloudlets in mobile computing[J]. IEEE Pervasive Computing, 2009, 8(4): 14-23. DOI:10.1109/MPRV.2009.82 |
| [5] |
Lertsinsrubtavee A, Ali A, Molina-Jimenez C, et al. PiCasso: a lightweight edge computing platform[C]//2017 IEEE 6th International Conference on Cloud Networking (CloudNet). Prague: IEEE Press, 2017: 1-7. https://www.researchgate.net/publication/320649213_PiCasso_A_lightweight_edge_computing_platform
|
| [6] |
Huang A, Nikaein N, Stenbock T, et al. Low latency MEC framework for SDN-based LTE/LTE-A networks[C]//2017 IEEE International Conference on Communications (ICC). Paris: IEEE Press, 2017: 1-6.
|
| [7] |
Lee S Q, Kim J. Local breakout of mobile access network traffic by mobile edge computing[C]//2016 International Conference on Information and Communication Technology Convergence (ICTC). Jeju: IEEE Press, 2016: 741-743. https://www.researchgate.net/publication/311461294_Local_breakout_of_mobile_access_network_traffic_by_mobile_edge_computing
|
| [8] |
Fielding, Thomas R. Architectural styles and the design of network-based software architectures [D]. Irvine: University of California, 2000. https://www.researchgate.net/publication/245476991_Architectural_Styles_and_the_Design_of_Network-based_Software_Architectures_D
|