科学技术的进步需要技术和商业需求的双轮驱动。在过去的4年多时间里，国内运营商以SDN/NFV/AI技术为代表持续推进网络重构转型。但是随着改革的深入，缺乏明确业务需求支撑开始让决策者变得犹豫和观望[1-2]。以5G和边缘计算为代表的多种新型业务的出现正好补足了双轮驱动中的商业需求。但是其对网络和管理的较高要求也同样为相关业务的部署落地蒙了一层阴影。
以SDN/NFV技术为代表的网络云化过程中，网络的控制器、业务的编排器以及云资源的管理器都在向集约控制的逻辑上演进。随着典型边缘计算业务对低时延、大带宽以及业务内容本地化等要求的不断具体化，为这些业务服务的网络、业务网关以及云资源都需要逐步从核心集约的部署原则向核心集约、边缘按需、云边协同的部署原则，在核心DC和边缘DC上边缘计算业务所需的各类资源的模式转变。在此原则下，对网络、业务网关以及云资源的管理提出了更高的要求。因此需要重新去考虑在边缘DC(多级)和核心DC如何部署SDN/NFV/MEC相关的管理组件。本文因为篇幅问题，在接下来的篇幅中主要讨论NFV与MEC的管理组件之间的交互与协同。
边缘技术的管理组件(MEAO、MEPM)的定位是有效管理边缘计算业务能力平台(Mutil-Access Edge Computing Platform，MEP)上的各种支撑边缘计算业务(Multi-Access Edge Application，ME-App)的原子化能力以及在边缘计算业务能力平台上部署各类边缘计算的业务。边缘计算业务中更多的是面向企业场景的业务，不同于运营网面向大众消费者业务的建设模式，这些业务按需部署在靠近企业的边缘计算节点上。虽然很多观点认为边缘计算业务不一定需要部署在边缘云基础设施上，但是运营商多接入网络的业务网关需要下沉到相应的边缘计算节点上。根据全球运营商的网络重构战略，运营商的多接入网关为了降低成本和提高对多种新型业务的灵活支撑能力，需要进行虚拟化或云化的重构然后部署在电信级云平台上，例如从CPE到vCPE、从BRAS到vBRAS，同时5G的接入网关UPF大多也是基于虚拟机来部署的。总结起来，为了满足边缘计算低时延、大带宽和低成本的业务需求，运营商提供的边缘计算方案必须包括多种接入网络和网关以及MEP。这就决定了对边缘计算业务的有效管理的前提是虚拟化的多接入网关所需的NFV MANO与边缘计算业务所需的管理组件需要深入融合和互通。
目前，针对在现有的网络功能虚拟化环境，如何对边缘计算系统架构进行部署，ETSI给出了两种方案。两种方案的主要差别在于MEC架构与NFV MANO组件的耦合程度不同：低耦合度的部署方案以MEC架构为基础，MEC管理体系与NFV管理体系分设，未进行融合，仅通过MEAO与NFVO之间的接口进行管理层面的协调[3]；高耦合度的部署方案根据文献[4]中描述，以NFV架构为基础，增加MEC组件，使在NFV上可以承载MEC业务。该方案的原则是将已有的NFV架构网元部分尽可能地重用，增加新的接口并适当调整MEC组件，使得两者能够更高效地进行管理。
本研究的主要贡献包括：介绍现有EIST标准中的NFV和MEC研究进展和系统框架；对当前基于NFV MANO的边缘计算部署方案的架构体系进行介绍；归纳各融合部署方案的NFV MEC组件部署以及组件之间的交互方式；分析各部署方案中由于系统交互融合带来的各种问题；根据多种部署方案中存在的问题，基于人工智能的算法和模型提出智能化的MEC与NFV管理面的高效协同编排方法与设计。
1 相关研究
NFV经过长时间的发展，目前已经发展部署比较完善。MEC则是近几年新发展起来的技术。如果大范围部署MEC设备，则是一项耗时耗力的方案，所以，在现有NFV设备的基础上部署MEC设备，对于运营商或厂商来说都是一种更可取的办法。且NFV技术专注于将软件硬件解耦，使网络设备不再依赖于专用硬件，资源可以灵活共享，实现业务的快速开发和部署[5]。随着5G商业化的普及，越来越多的新型业务也在快速发展，对传统业务也提出了更高的要求。将现有NFV技术与新兴MEC技术相互融合，共同发挥各自的优势已经迫在眉睫。
1.1 NFV系统框架
ETSI NFV组在2014年12月发布标准ETSI GS NFV 002[6]，该标准主要介绍了NFV参考体系结构框架。NFV实现了底层物理设备，虚拟化操作系统和虚拟化网元功能单元的解耦，NFV引入NFV管理与编排(NFV Management and Orchestration，MANO)，MANO主要包括NFV编排器(NFV Orchestrator，NFVO)、VNFM(VNF Manager)以及虚拟资源管理(Virtualised Infrastructure Manager，VIM)3个功能实体。其中，NFVO是MANO框架中的控制中心，负责NFV基础设施和软件资源的协调和管理；VNFM负责VNF生命周期管理，例如VNF的实例化、更新、查询、缩放、终止；VIM在NFV架构中主要用于实现对虚拟化基础设施的管理。MANO提供了可控、可管、可运维的服务交付环境，有利于基础资源的调度，以及网络服务的高效管理和弹性调度。
1.2 MEC系统框架
ETSI MEC组在2016年2月发布标准003[3]，该标准主要介绍了MEC框架和参考架构。MEC 架构中主要的管理组件包括移动边缘编排(Mobile Edge Orchestrator，MEO)、移动边缘平台管理(Mobile Edge Platform Manager，MEPM)以及虚拟基础设施管理器(VIM)。其中，MEO是MEC系统级管理的核心功能实体，主要负责维护MEC框架的整体视图，提供边缘计算应用程序的实例化、检查、记录、终止以及重定位；MEPM用于边缘计算应用程序的生命周期管理，为MEP提供管理功能，接收VIM的虚拟化资源性能报告；VIM在MEC架构中主要负责管理虚拟化基础设施的虚拟化资源。
1.3 MEC in NFV系统框架
ETSI MEC组在2018年2月发布标准ETSI GR MEC 017[4]，该标准主要介绍了在NFV架构中承载MEC架构的方法。该文献指出，假设移动边缘平台部署为虚拟网络功能(Virtualised Network Function，VNF)，虚拟化资源由VIM管理，ME应用程序在NFV MANO组件中被看作VNFs，则在NFV环境中部署MEC架构后，原MEC的MEPM更新为移动边缘平台管理-NFV(Mobile Edge Platform Manager-NFV，MEPM-V)，原MEPM管理应用程序生命周期，更新后的MEPM-V不再承载此功能，而是将此功能委托给VNFM；MEO转换为更适应此架构的MEAO，使用NFVO进行资源编排，并将ME应用VNFS集作为一个或多个NFV网络服务进行编排。MEPM-V将充当ME平台VNF的元素管理器。MEC和NFV由运营支持系统(Operations Support System，OSS)统一管理。该方案可以将NFV和MEC进行深度融合，但是在实际部署过程中仍存在一些问题有待解决。
2 关键技术
目前在现有的网络功能虚拟化架构中，部署边缘计算的建议方案根据NFV MANO管理框架与MEC系统框架的耦合程度，分为两种部署方案：其一是低耦合度的基于NFV MANO管理框架的MEC架构，MEC管理体系与NFV管理体系分设，两个管理系统之间不做融合，仅涉及MEO与NFVO组件之间交互；其二是高耦合度的基于NFV框架的MEC部署方案，该方案中MEC管理体系与NFV管理体系深度融合，将MEC的功能分解，业务配置部分由MEC管理体系完成，资源管理部分由NFV体系完成。以下将从部署方案的框架及组件交互方式、部署方案的特点、方案在实际部署时的适用场景三方面对两种方案进行对比分析。
2.1 部署方案的框架及组件交互方式对比
高、低耦合的都是以MEC架构和NFV架构为基础。由于MEC架构与NFV架构整体框架有一定的相似性，因此只需分析NFV与MEC交互部分的组件和管理方式。
2.1.1 低耦合方案
首先分析低耦合的基于NFV MANO的边缘计算部署方案，如图1所示。MEC部分主要由MEO、MEPM、VIM、MEP(MEC平台)、MECAPP(MEC应用)以及虚拟化基础设施组成。其中，虚拟化基础设施可以为MEC应用提供计算、存储、网络等资源，并具有数据面功能，用于执行来自MEP的流量规则，MEC应用是运行在虚拟化基础设施上的应用实例；MEP提供MEC应用程序和MEC服务，并从MEPM应用上接收流量规则等，并指示相应的数据平面[3]。NFV MANO框架包括3个主要的功能实体：NFVO、VNFM和VIM。
在低耦合的基于NFV MANO的边缘计算部署方案中，MEC管理体系与NFV管理体系分立，使用统一VIM创建所需的MAC APP和VNF，分别由MEO和NFVO进行管理，两个管理系统之间不做融合，仅通过MEO和NFVO之间的接口管理网络切片(Network Slice，NS)，协调多个MEC APP和VNF。
在低耦合的基于NFV MANO的边缘计算部署方案中，MEC管理体系和NFV管理体系是根据所管理的业务类型进行划分的，即MEC管理体系负责边缘应用的资源管理和业务管理，NFV管理体系负责虚拟网元的资源管理和业务配置。在这种模式下，两套管理体系在功能上具有一定的重复性，尤其是虚拟机形式部署的边缘应用，它们对VIM的需求和调用与虚拟网元并无本质区别。但是由于边缘应用和虚拟网元的供应商不同、标准尚未融合等原因，这种低耦合的部署方式可以实现MEC体系的快速部署上线，以管理和维护的成本换取部署时的复杂度。在实际的边缘应用部署中，先由NFV管体系准备好虚拟网元，之后再由MEC管理体系进行边缘应用的创建和配置，具体交互流程如下：
(1)MEO向NFVO发出请求，查询虚拟网元(UPF、vCPE等)是否准备就绪；
(2)如果NFVO事先已部署虚拟网元，则监测虚拟网元运行状态是否正常；
(3)如果NFVO事先没有部署虚拟网元，则触发创建网元条件，通过MEO向NFVO发送具体虚拟网元参数，进行虚拟网元部署；
(4)虚拟网元部署完成后，NFVO向MEO发送通知，并传递网元相关参数；
(5)MEO发起ME APP部署流程，将业务请求和虚拟网元信息发送给MEPM进行处理；
(6)MEPM进行ME APP资源创建和业务配置，生成虚拟网元路由规则；
(7)ME APP创建完成后，MEPM下发路由规则，通知MEO部署完成，进行业务上线。
2.1.2 高耦合方案
高耦合的基于NFV MANO的边缘计算部署方案，即在NFV中部署MEC框架，如图2所示。
在高耦合的基于NFV MANO的边缘计算部署方案中，MEC管理体系和NFV管理体系根据系统功能进行了融合，即MEC管理体系负责边缘应用的业务配置，NFV管理体系负责虚拟网元、MEP以及MEC APP的资源管理。由于MEC中的资源管理与NFV中的资源管理类似，在VIM上增强对容器的纳管和编排就能基本满足MEC资源管理的需求，因此这种部署方式可以充分利用NFV的现有系统功能。从图2中分析，这种部署方式减少了纵向系统的对接，即编排层可以使用统一的NFVO和MEAO融合系统，资源管理层复用原NFV系统中的接口，增加对容器资源的管理功能；相对地，这种部署方式增加了横向系统交互的复杂性，边缘应用的部署被拆分成资源部署和业务配置两部分，在实际的边缘应用部署中，每一步都需要两套管理体系协同进行，具体交互流程如下：
(1)MEAO向NFVO发出请求，查询虚拟网元(UPF、vCPE等)和MEP是否准备就绪；
(2)如果NFVO事先已部署虚拟网元和MEP，则监测虚拟网元和MEP运行状态是否正常；
(3)如果NFVO事先没有部署虚拟网元和MEP，则触发创建网元条件，通过MEAO向NFVO发送具体参数，进行虚拟网元和MEP的部署；
(4)虚拟网元和MEP部署完成后，由NFVO向MEAO发送通知，并传递虚拟网元和MEP相关参数，MEAO通知MEPM-V对MEP平台进行纳管；
(5)MEO发起ME APP部署流程，向NFVO发送业务资源需求，由NFVO进行ME APP资源创建；
(6)NFVO完成ME APP资源创建后，通知MEAO，并传递参数配置；
(7)MEAO将业务请求、虚拟网元信息、ME APP资源信息发送至MEPM-V，MEPM-V进行ME APP的业务配置，生成虚拟网元路由规则；
(8)ME APP创建完成后，MEPM-V下发路由规则，通知MEAO部署完成，进行业务上线。
2.2 部署方案现有问题对比
在低耦合度的基于NFV MANO管理框架的MEC架构中，由于MEC管理体系与NFV管理体系分设，MEC和NFV的管理组件(即MEO和NFVO)分别对ME APP和VNF进行管理，两种管理体系之间没有深入融合，仅涉及MEO与NFVO组件之间交互，需要考虑在MEO与NFVO之间如何通过交互接口，协调多个MEC APP和VNF，使其能够部署在同一虚拟化基础设施中执行而不相互干扰。另外，由于该方案耦合度低，导致MEC和NFV管理体系中存在大量冗余，且两个管理体系相互独立，相当于需要对两个管理系统分别进行维护，增加了运维难度。
在高耦合度的基于NFV MANO管理框架的MEC架构中，由于是在原有的NFV架构中部署MEC组件，因此，需要根据NFV的管理体系对MEC管理组件进行一定的更改，便于NFV管理体系实现对NFV组件和MEC组件的同一管理。但是该部署方案在实际部署中同样存在一些问题：(1)在NFV中部署MEC后，MEPM被分成MEC特定部分和负责管理ME app VNF实例生命周期的VNFM，MEPM-V需要能够与VNFM通信，以跟踪由NFVO发起的生命周期管理操作， VNFM与MEPM-V组件之间如何通信还有待明确；(2)在NFV架构中的VNF包中需要携带特定的MEC文件，那么如何在不干扰包内容的情况下，在VNF包中携带特定于MEC的文件，并且MEP和MEAO如何识别这些文件也是有待解决问题之一；(3)NFV定义了VNFD(Virtualised Network Function Descriptor)，其中的某些部分与MEC定义的MEC AppD(Application Descriptor)相互重合，这两者之间的映射在实际部署中同样有待解决。
2.3 部署方案适用场景对比
通过前两节对高、低耦合的基于NFV MANO管理框架的边缘计算部署方案的分析，进一步明确两种方案在实际部署时适用的场景。下面针对两种部署方案的优势和不足进行分析，并给出两者在实际部署时的建议。
低耦合的基于NFV MANO管理框架的边缘计算部署方案中，MEC管理体系与NFV管理体系分设，分别管理MEC APP和虚拟网元(VNF)，两个系统之间未进行融合，这种方案的优势在于MEC APP部署与NFV体系无关，不具备NFV能力的MEC APP厂家也可以部署；另外MEC管理系统与VNF系统交互较少，便于方案的快速部署上线。但是，由于两个管理体系分立，该部署方案需要功能复杂的MEPM，既能管理业务配置，又能对业务进行生命周期管理；同时，MEC与NFV管理体系分立，需要多维护一整套的管理系统，增加了运维管理的难度；此外，OSS与VIM都需要对接MEC和NFV两套系统，增加了大量异厂家对接的功能。因此，该部署方案适用于不具备NFV架构能力的MEC厂家，仅需要加入NFV MANO组件，就可以实现边缘计算的部署，由于两种框架之间没有过多的交互，因此架构中的各组件可以采用不同厂家的产品，实现方案的灵活部署，如图3所示。
高耦合的基于NFV MANO管理架构的边缘计算部署方案中，MEC管理体系与NFV管理体系深度融合，首先，组件角度进行分析，MEC组件在NFV环境中部署需要进行一定程度上的重构，并大量新增重构后MEC管理组件与NFV管理组件之间用于管理的交互接口，MEC组件重构且引入大量接口会导致部署难度的增加，因此，出于上述两点的考虑，倾向于采用同厂家系统，对系统进行整体部署，以避免大量异厂家在对接时工作量大幅增加的问题，如图4所示。
3 边缘计算多种智能化部署
3.1 低耦合的基于SVM深度学习算法的智能边缘计算部署方案
对于低耦合度的基于NFV MANO管理架构的边缘计算部署方案中，由于MEC管理与NFV管理体系分立，未进行融合，即MEC管理组件负责边缘应用的资源管理和业务管理，而NFV管理组件负责虚拟网元的资源管理和业务配置，这就导致二者对在管理方面复杂度增加、无法对资源进行统一的规划和部署。因此，在现有整体部署架构下，采用最优化的虚拟化资源调度策略和业务管理策略，是现阶段需要重点解决的问题。
具体方案如图5所示，MEPM对ME APP需要向VIM、MEC主机分别发送资源分配和业务配置信息，以生成应用路由规则、完成业务上线和管理；VFNM对虚拟网元同样需要向VIM和MEC主机发送虚拟网元的资源分配和业务配置信息。因此，为了降低NFV和MEC两天系统之间协同工作的复杂度，并且对虚拟资源进行统一规划和部署，提高底层资源的利用率，可以将两类资源分配和业务管理信息进行特征标记，利用支持向量机SVM的深度学习算法，生成统一的资源分配和业务配置策略，最大化利用虚拟基础设施资源并提高业务部署效率。
3.2 MEC in NFV架构
在高耦合度的NFV MANO管理架构的边缘计算部署方案中，MEC和NFV在资源管理、业务下发等多个步骤中具有紧密的联系，导致MEAO在确定业务资源规划时需要进行复杂的人工设计，并且与业务类型和业务规模相关，如人工智能相关的业务需要提供GPU加速的MEC资源、大流量业务需要FPGA加速的NFV资源等。为了解决业务部署时复杂的资源规划问题，可以引入人工智能的方法让分配的资源更加符合业务需求。
在MEAO中增加智能业务需求分析模块，根据MEC APP部署所需资源和性能表现的历史信息，进行数据关联和特征提取，然后利用基于机器学习中的决策树算法，对各类业务所需的虚拟资源进行学习推理，进而生成最优的业务资源匹配策略，最大化提升边缘计算业务的执行效率，提高底层资源的利用率，方案如图6所示。
4 结束语
边缘计算业务与运营商从技术上的网络重构战略是相辅相成的关系。边缘计算业务的快速兴起，从业务发展需求的角度对网络重构的持续深耕提供强有力的推动和牵引作用。在边缘计算业务规模化推广过程中，如何简洁高效地在NFV MANO基础之上来部署边缘计算方案，并提供更加完善的边缘计算业务的端到端管控，从而加速实现5G网络的全面云化部署，是运营商和相关产业界需要思考的一个重要课题。正如2019年7月初在可信云大会上发布的云计算与边缘计算协同九大应用场景[7]里描述的那样，未来边缘计算相关产业界需要在推动边缘计算业务部署落地的同时，体系化地思考边缘计算和云计算的有效协同将成为长远期推动边缘计算不断成熟的关键所在。
参考文献
[1] SDN/NFV产业联盟.NFV技术白皮书[Z].2018.
[2] 李子姝，谢人潮，孙礼，等.移动边缘计算综述[J].电信科学，2018，34(1)：87-101.
[3] ETSI GS MEC 003-2016.Multi-access edge computing(MEC)；framework and reference architecture[S].2016.
[4] ETSI GR MEC 017-2018.Mobile edge computing(MEC)；deployment of mobile edge computing in an NFV environment[S].2018.
[5] 宗均然.NFV编排系统的设计与实现[D].北京：北京邮电大学，2019.
[6] ETSI GS NFV 002-2014.Network functions virtualization(NFV)；architectural framework[S].2014.
[7] 云计算开源产业联盟.云计算与边缘计算协同九大应用场景[Z].2019.
作者信息:
王旭亮1，刘增义1，胡雅婕2，李童瑶2
(1.中国电信股份有限公司研究院，北京102209；
2.北京邮电大学 信息与通信工程学院 信息光子学与光通信研究院，北京100035)
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
