摘要：边缘计算目前已经成为产业界和学术界的研究热点，在靠近业务的网络边缘侧部署计算处理能力能够极大地满足未来业务对低时延、大带宽、高可靠的要求，极大的支持了未来车联网、工业控制、智能制造、大视频等业务。同时边缘计算也是5G原生使能技术，未来的5G网络架构已经明确支持边缘计算的诸多特性。欧洲电信标准化组织ETSI是最早开始进行边缘计算标准化的国际组织，目前该组织已经完成第二阶段的标准化，对外公布包括MEC平台架构、业务需求、管理编排、API接口在内的20余份标准化文稿，对产业界和学术界具有极大的指导意义。本文重点分析ETSI MEC标准化组织的研究进展，同时对该组织所提出的MEC架构进行技术分析，最后提出中国联通对于MEC标准化工作的一些看法。

关键词：边缘计算；ETSI；MEC；标准化

1 ETSI MEC标准化工作综述

ETSI欧洲电信标准化组织，在2014年率先启动MEC标准项目。这一项目组旨在移动网络边缘为应用开发商与内容提供商搭建一个云化计算与IT环境的服务平台，并通过该平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。联盟的初创成员包括惠普、沃达丰、华为、诺基亚、Intel以及Viavi。目前ETSI MEC标准化组织已经吸引了国内外数百家运营商、设备商、软件开发商、内容提供商参与其中，ETSI MEC的影响力也逐渐扩大。

在2017年底，ETSI MEC标准化组织已经完成了Phase I阶段基于传统4G网络架构部署，定义边缘计算系统应用场景、参考架构、边缘计算平台应用支撑API、应用生命周期管理与运维框架、以及无线侧能力服务API（RNIS/定位/带宽管理）。目前正在进行的PhaseII阶段，则主要聚焦在包括5G/Wi-Fi/固网在内的多接入边缘计算系统，重点覆盖MECin NFV参考架构、端到端边缘应用移动性、网络切片支撑、合法监听、基于容器的应用部署、V2X支撑、Wi-Fi与固网能力开放等研究项目，从而更好地支撑MEC商业化部署与固移融合需求，第二阶段的标准化于2018年9月底之前完成，同期将开启第三阶段的标准维护和标准新增阶段。ETSI MEC标准化的内容主要包括以下内容：研究MEC需求、平台架构、编排管理、接口规范、应用场景研究等。

图1 ETSI MEC标准化的第一阶段与第二阶段工作示意图

ETSI MEC还陆续发布了多本MEC白皮书，内容涉及到C-RAN、MEC从4G到5G的演进、MEC关键技术以及MEC软件实现等，如图2所示。这些白皮书主要给出了MEC对现网和未来网络架构的融合构想，提出了切实的解决方案和演进规划，但是对于具体的技术实现细节是没有过多介绍的。

图2 ETSI MEC标准化发布行业白皮书

ETSI MEC还鼓励各会员单位和参与公司积极提交MEC PoC，PoC的内容主要是各大公司所开展的MEC实际落地的工作。ETSI MEC认为，MEC非常偏向实践和应用，需要结合具体业务场景进行落地，因此标准组织非常希望能够有更多的MEC落地方案能够提交到组织中以产生更多的示范效应和指导意义。目前PoC的总数已经达到12个，业务范畴覆盖了IoT、V2X、CDN、工业控制等。

ETSI MEC标准化组织的成立具有非常重大的意义，一方面它填补了MEC标准化领域的空白，各个成员单位围绕MEC在多个领域开展了富有成效的研究工作，内容范围非常广泛，涵盖了技术点、业务需求、业务场景和模块接口定义；另一方面，MEC的标准化工作为MEC产业链的各家单位提供了宝贵的学习和参考文献。由于MEC的相关领域技术还不够成熟，很多相关企业和研究机构都将ETSI MEC的标准化文稿作为第一手学习材料，大量的研究和开发工作都围绕ETSI MEC标准化的成果进行开展和讨论，这使得该标准化成果具有非常重要的指导意义和启发性，从这个角度来讲，ETSI MEC标准化组织的工作是非常成功的。

但是我们也不得不指出，ETSI MEC标准化的诸多工作依然存在大量的问题，其所预期的引领MEC标准化实现商用落地的目标多少有些落空。首先，MEC标准化文稿学术气息太重，缺乏商用指导和实践部署的支持。由于这一标准化组织被欧洲的设备商和运营商所把持，他们在组织中具有较大的话语权，但是却缺乏有效的MEC实践所支持，因此，大量的标准文稿都存在着“技术浓厚，落地困难”的问题。例如，标准文稿中所涉及的MEC参考架构封闭性极强，没有过多的考虑实际部署和运营商网络架构，基本没有实现设备和虚拟化之间的解耦，这和MEC开放、开源的宗旨背道而驰。另外，由于MEC平台和架构没有对实际网络架构和业务需求进行考虑，导致业界的设备商和平台开发商基本都不采用ETSI所提出的MEC架构，实际上没有做到架构和标准的统一。目前华为、中兴、诺基亚等厂商均已经拥有自行研发的MEC平台，但是所有的接口和功能模块都是私有化的，非常封闭，长期来看这是对产业界非常不利的。最后一点要强调的是，目前MEC标准化组织尝试对相关的业务场景进行标准化，包括V2X、WLAN互通等。但是这些技术本身还处于萌芽期，技术不够成熟，因此尝试对V2X和MEC进行标准化本身就不适时宜。因此，大量的标准化文稿属于“为了标准而标准”，严重脱离发展实际和产业现状，成为了没有任何存在价值的文稿，这也是当前ETSI MEC所面临的问题。

2 ETSI NFV-MEC平台架构分析

ETSI MEC017协议于2018年2月最新发布，重点描述了MEC在NFV环境下的部署，如图3所示。MEC作为与生俱来的带有NFV属性的一套生态，MEC017协议可以认为是MEC003协议的进一步的扩展，更加面向实际部署和落地。MEC017中详细的参考架构如图所示。整个架构遵循以下原则：已有的电信网NFV架构网元部分尽可能的重用，MEC模块可调用NFV部分功能，MEC内部功能模块之间的信令不受NFV管理编排器控制，MEC同NFV之间的接口要重新定义。

整个参考架构可以看做是MEC003同ETSINFV架构（ETSI GS NFV 002）之间的一套融合方案。这一参考架构中，主要分为三个部分：重用NFV架构部分、MEC架构部分以及共用网元模块部分。

以OSS、NFVO、VNFM（ME APP LCM）、VIM、NFVI为组合，被NFV参考点所连接的网元，是NFV架构部分。这些网元都是ETSI NFV中已经定义的网元，在这里直接引入MEC架构中实现了网元功能的重用。要注意的是，NFV标准化要早于MEC。之所以考虑重用网元，是因为MEC中的各类功能模块和网元，也涉及到了虚拟化基础设施的搭建、虚拟化基础设施的管理、虚拟化管理和编排、生命周期管理等内容，因此这部分可以直接调用NFV的网元，而无需再进行重复开发。因为目前各大运营商的网元虚拟化工作早已经开展，很多的开发工作也已经完成，现网正在运行，因此根据MEC业务和NFV业务的共性对NFV的网元进行重用是非常有必要的。需要说明的是，对于NFV网元之间的接口，其功能和信令交互流程可以保持不变，而对于NFV网元和MEC功能模块之间的接口，可能需要新定义或者新开发，比如：Mv2接口。

图3 ETSI MEC017：MEC在NFV下的参考架构

以ME APP、MEP、MEPM-V、VNFM（MEPLCM）、dataplane、CFSPortal、UEAPP、UEAPPLCM proxy、OSS、MEAO为组合，被MEC参考点所连接的网元，是MEC原有架构部分，这部分已经在MEC003中定义和说明过。这些功能模块是属于MEC特有的网元，是基于NFV基础上，根据MEC业务特性和业务需求所设定的全新的功能模块架构。由于NFV的网元大多是面向电信网的网元，而MEC则更加偏向第三方APP和业务，业务种类也比NFV更加多样，如：定位、分流、IoT、视频编解码等等。所以，基于MEC业务种类繁多的特性，有必要在NFV的基础上增加若干个功能不一的模块来协助MEP实现更多的功能。这里需要说明一点，MEC需要虚拟化资源和管理，因此，MEC重用了NFVI和VIM的部分，可直接调用而无需二次开发。MEC模块同NFV网元之间的接口，也存在着重新开发和定义的问题。

以NFVI、VIM、OSS为组合，可视为MEC和NFV重用的网元部分。这些网元在进行电信网NFV开发和部署的时候就已经建设完成了，MEC相关业务在运行时也需要他们的支持，因此直接重用即可。

3 第三方APP的管理模式

APP的管理对MEC来说是重要的部分，对APP的管理方式其背后代表了未来计算平台的运维模式和管理策略。ME APP既受控于有MEC背景的MEPM-V，也受控于有NFV架构背景的VNFM（ME APP LCM），其本质在于ME APP是否与MEP有交互，是否使用了ME service或获取平台能力进行优化。

（1）ME APP受控于MEPM-V。这种方式表明了ME APP部署在NFVI上，同时经由Mp1接口，连接到MEP平台，并可能使用ME service，遵从MEPM-V的管理。由于MEPM-V中包含了ME APP规则和需求管理，因此这种方式就默认了ME APP要受到MEP平台的管理。通常MEP可以是运营商自建也可以是设备商的集成设备，总之，这种管理方式就意味着第三方APP部署在MEP上时必须受到平台的管理，这种管理方式的好处显而易见，有利用边缘生态中APP的管理和调度，但是未来可能存在一个问题，如果ME APP只是想用这些NFVI的资源，而对MEP上的ME service不敢兴趣，那么这种管理就使得第三方APP难以接受，因为目前Mp1接口定义的还不够充分，第三方也需要围绕MEP进行定制化开发，这些都加重了第三方的工作量，需要考虑第三方的需求和想法。但是作为MEC构建生态的想法，我们更倾向于提供第三方APP足够的PaaS能力。

（2）ME APP受控于VNFM（ME APP LCM）。这种管理方式，即ME APP仅受到NFV网元的管理，也就是只是对ME APP的生存周期进行管理。这种方式表明第三方的APP仅仅是租用了边缘数据中心的NFVI，进行部署，但是不使用任何MEP中的service和平台能力，因此ME APP仅仅从资源层面受到管理。这种商业模式其实就是租赁机房资源、租赁机架、租赁硬件资源、租赁虚拟机的商业模式，从实现来讲受益更加直接，第三方直接获取资源自行开发相应服务，运营商也无需在MEC平台层面做过多的开发。但是这种方式并不是在营造MEC生态，因为这一管理方式彻底抛弃了APP同MEP之间的关联， Mp1接口完全废弃，那么MEP也没有了存在的价值，因此这种方式只可在早期不成熟的时候采用，长期发展对MEC生态和建设非常不利。

（3）ME APP同时受控于MEPM-V和VNFM（MEAPP LCM）。这种方式结合了MEC中APP管理和NFV中的APP管理。NFV仅对APP的生存周期和虚拟化资源进行管理，而MEC则对ME APP规则和需求进行管理，分工明确职责不同。同时定义好Mp1接口，提供ME APP使用MEP中ME service的途径，借助边缘云平台能力可以进行APP的定制优化。这种方式一方面迎合了APP和MEC平台搭建方的各方需求，同时也是未来比较合适的管理方式。

4 中国联通对边缘计算标准化工作的思考

中国联通与2018年3月首次参与ETSI MEC标准化工作。在MEC#13次会议中，中国联通主导的PoC12：MEC Platform to Enable OTT Business国际标准项目成功立项，获得审核委员会全票通过。这是ETSI在边缘计算领域首个实现ICT融合的立项，填补了MEC应用研究方面的空白。自此，中国联通牵头开启了ETSI MEC标准化组织与OTT的应用合作，具有里程碑式的重要意义。该立项建议由中国联通联合中兴通讯、INTEL共同向ETSI MEC #13提交，并由中国联通网络研究院标准专家进行立项申请陈述和答辩。该标准项目将基于业界最大的天津Edge-Cloud测试床，依托轻量化OpenStack、Kubernetes等虚拟化技术，以商用化部署为目标，研究vCDN、VR/AR等OTT应用对MEC边缘云业务平台能力及API的需求，并为ETSI GS MEC 003系统架构的进一步完善提供强有力的参考依据，如图4所示。

图4 ETSI MEC PoC12：面向OTT业务的MEC参考架构

PoC12中所展示的APP部署在边缘主机上，经过Mp1同MEP对接，获取MEP上的平台能力，平台能力的好坏直接决定了APP是否部署在边缘主机并接受MEP管控。目前MEP平台的最大的问题就是平台封闭性严重，不同厂家平台制式不同很难互通，接口私有化定义。造成的后果就是一旦规模部署，每款APP都要分别部署在各方开发的MEP上，因此就都要针对各家平台进行定制化的开发和业务对接，这种不友好的方式是不会被第三方APP所接收，因为这种方式极大地增大了第三方的业务重复开发和维护工作。目前的解决方法是，由运营商主导MEP平台，同时由运营商统一开展平台接口标准化和平台架构标准化，集合设备商的各类平台能力和资源，这样第三方APP只需要一次开发和对接即可实现快速业务部署，对第三方APP非常友好，平台也更为开放。

在MEC#15次会议上，中国联通提出了基于NAPT的vCDN的方案。该方案最大的特点是，CDN提供方无需进行大量开发工作，只需要将OTT的CDN域名写入中国联通的域名服务器即可。同时，基于NAPT的方案可以节约大量的公网IP出口，区域内用户也可以快速的从本地服务器上获取已经缓存好的视频资源。对于HTTPS代理的方法，本次PoC中没有采用，由于当前MEC服务器对数据包的拆解和分析能力有限，如果采用代理的方式，将加重对MEC服务器的工作量。整体的NAPT方案分为NAPT规则建立部分和本地分流实现部分，详细的流程规则如图5所示。

图5 基于NAPT的vCDN实现方案

从系统实现的角度来看，基于NAPT的vCDN方案主要是将NAPT规则写入MEC的data plane中，让整个MEP平台具备数据包截获、建立NAPT规则、完成CDN缓存等一系列流程。而这一架构上的变化，从功能角度来看，就是让MEC系统具备packet sniffer的功能。详细的功能模块变化如图6所示。

图6 基于NAPT的vCDN方案对MEC架构的映射

5 总结

未来边缘计算标准化工作将主要面向三个方面进行：首先是MEC同5G的结合。5G商用势不可挡，全新的5G网络架构如何更好地支持边缘计算将是最为重要的研究方向。尽管3GPP已经明确5G网络将支持边缘计算的诸多特性，但是具体如何支持这些特性并没有在标准中指明，后续的工作需要运营商、设备商和第三方业务提供方共同努力协作完成。其次，是各类垂直行业同MEC的结合。MEC被认为是可以和各类垂直行业如V2X、工业互联网、CDN、安防监控等紧密相关，MEC的大带宽、低时延、海量连接、就近计算等特性似乎可以很好地解决垂直行业中的技术难题。但是具体到每一个行业，如何让MEC真正的使能业务，却是一个非常重要的任务。以车联网举例，MEC的就近计算到底要解决车联网中的什么问题？MEC真正为车联网的哪些业务能够带来质变的优化？MEC又是如何在车联网业务中扮演了不可缺少的角色？这些问题都是MEC标准化工作所需要面对的。最后，MEC同开源的结合。目前在Linux基金会和OpenStack组织所分别成立的Akraino项目和Starlingx项目，都是着眼于边缘计算中虚拟化层的架构。未来在边缘侧，照搬照抄原有繁重的虚拟化部署方案已经显得不够可取，尤其是边缘侧各类资源紧缺的现状。因此，如何在MEC中更好的加入开源，也是未来标准化工作的重要方面，中国联通也将致力于MEC标准化工作，携手产业界推动MEC商用与落地部署。

作者简介：

吕华章，硕士，2017年获得中国传媒大学电路与系统硕士学位。现任职于中国联通网络技术研究院无线技术部边缘计算团队，主要负责边缘云架构、边缘云平台研究、边缘计算标准化、多天线译码算法等技术研究工作。目前已发表SCI/EI检索期刊、会议20余篇。

陈　丹，博士，2012年获得北京邮电大学信息与通信工程博士学位，2010-2011年加拿大不列颠哥伦比亚大学（UBC）访问学者&博士联合培养。现任中国联通网络研究院5G创新中心边缘计算项目经理，负责5G网络架构、边缘计算、C/U分离、网络能力开放平台等技术研究工作。目前已在JSAC、IEEE Transaction on TVT、ICC、GLOBECOM等国际顶级期刊/会议发表20余篇SCI/EI论文，并已申请专利30余项，授权6项，被北京邮电大学聘为硕士研究生企业导师，荣获中国联通2017年度“5G技术研究及标准化”一等奖。

王友祥，毕业于韩国岭南大学信息与通信专业，工学博士。中国联通网络技术研究院高级工程师， 5G技术经理，主要从事无线通信新技术、标准化和无线组网方案等方面的研究工作。先后牵头、参加了工信部和中国联通4G、5G移动通信关键技术多项研究课题，研究成果获得部级科技进步二等奖1次、三等奖1次，中国联通科技创新一等奖2次、二等奖3次；牵头完成中国联通承担的国家重大科技专项课题三项，在研三项；先后在国际及国内期刊、会议发表论文40余篇，其中SCI索引论文4篇，EI索引论文30余篇。申请专利30余项，完成专著一本。

摘自《自动化博览》2018年增刊《边缘计算2018专辑》