ETSI ISG视角：MEC – 电信数字化转型的推动者

过去10年，全球电信运营商的数据流量几乎每年都翻了两番，但这10年里电信公司还没有能够将价值增长货币化。这使得电信运营商只能充当Pipe Line，对OTT的服务和产品的可见度较低。为了让电信业务和盈利像软件公司一样，2012年，许多T1运营商领导的电信业开始向虚拟化/NFVI转变，将传统业务转变为SaaS公司。整个电信行业最初是通过建立他们的中央电信数据中心并将其核心网络发展到云来启动NFV，然而运营商发现五年后仍然无法解决这些问题，在云中托管中央服务的理念似乎直到今天还不能提供期望的业务成果。

为什么MEC如此重要

ETSI于2014年9月成立了ETSI MEC小组，寻求另一种方式将电信运营商转变为软件公司，充分利用他们与用户和服务的紧密联系，进一步开放他们网络的公共云托管以及通过第三方应用开发来满足企业和行业的纵向需求。

过去，电信运营商在其网络上的所有应用程序都难以启动专门针对延迟、高带宽、实时、接近感知的应用程序/服务，MEC将解决所有这些挑战，将边缘服务从网络中分离。

在本文中，笔者想与大家分享在ETSI的MEC架构方面的工作经验，它可以帮助电信运营商摆脱网络边缘服务的痛点。

如何规划边缘数据中心

答案各不相同，因为它应该主要与PE-AGG或Access传输设施保持一致。笔者的理解是，每个聚合站点都是一个Edge DC，作为Operator开始部署MEC应用程序，但随着需要部署的用例越来越复杂如远程工厂，视频分析，这意味着部署边缘更接近用户。我们综合ETSI的理解是，对于这样的情况，企业一定会比普通用户要求更多，因此对于复杂的情况，Edge DC可以是校园设施中的企业。

因此，要回答有关如何部署Edge DC的问题，请重点关注Edge DC 以及之后的Access CO或Enterprise。

如何为MEC开发具有成本效益的解决方案

这一点很复杂，主要是因为传统厂商不愿意为Agile MEC站点优化成本指标。举个例子，运营商有两种选择。首先，选择Silow解决方案，其中包括Complete Openstack在内的所有功能都可以绑定在一个大约2~10台服务器的机架中，但是这种方法部署和后续操作的成本使得它很难被广泛采用。

笔者认为，如果想建立一个标量解决方案，最好是基于Akraio和StarlingX。我们的方向很明确。如果MEC Site是一个Edge DC，那么MEC可以在4-100台服务器上部署多个机架，如果MEC Site是一个Access CO它应该是2-10台服务器，对于企业案例来说，它可以是1-2台服务器，这在接入网中是最可能的。

同样，笔者认为Open Stack Remote计算项目不可能满足Edge MEC的要求，特别是考虑到Rabbit MQ总线和代理扩展的限制，因此StarlingX似乎是最佳解决方案。 StarlingX的典型控制器/计算架构如下所示。

如何解决MEC的集成和自动化需求

对于一个典型的中等规模的国家来说，MEC大约有1000个站点的分布，需要对整个系统和基于ZOOM的操作进行集成管理，这些操作简单、可扩展且自动化，能够快速集成和创新以及优化成本。Akraino项目能够基本解决所有这些挑战，那么什么是Akraino？它主要涉及以下几点

• 为Edge VNF开发API
• Middle Ware SDK向第三方开放云服务
• 跨平台测试
• MEC的完整CI/CD

让我们尝试了解Akraino高级架构，如下所示。

笔者认为在MEC的当前阶段必须基于部署和集成，而不是集成和自动化，因此StarlingX仍然很重要，但是随着2020年初基于ONAP的产品上市，Akraino将被重点关注。

如何定义独立测试框架

笔者认为这一点很复杂，主要是因为在标准和开放的定义之间仍然没有作出妥协。在NFV时代，E2E测试已经面临很多问题，在NFV环境中使用第三方工具进行端到端测试是不可能的。我们知道一个成熟的商业E2E测试公司不能提供这种服务，除非VNF或VIM/NFVO层来自他们或他们的首选合作伙伴。针对各种MEC应用的E2E测试更为复杂，因为应用多样性和预期的生态系统将更加复杂。这是一个热门话题，MEC0025正在讨论中，将于2019年3月发布。

简单地说，除了涵盖MEC测试的FR情况的UE接口之外，最相关的测试接口是Mp1、Mp2、Mm5、Mm6，如下所示。

MEC E2E测试的最大问题是API的标准化，特别是对于互操作性案例（几乎就是这样）和包标准化（仍然存在争议），因为Akraino Agile集成的大多数工作都需要在E2E测试平台上具备以上两种功能。第二个主要问题是商业产品，因为测试和它的一致性需要对厂商的所有组件进行彻底的了解，因此我没有看到供应商强烈希望构建这种不可知的工具，而让电信公司使用开源方法。这个领域仍然值得商榷，我们正在继续与ETSI和其他同行合作，通过在我们的网络中引入MEC来实现这一目标。

MEC如何利用虚拟化和编排的力量

为了获得这个常见查询的响应，笔者建议读者参考GR MEC 0017所谈到的在NFV环境中引入MEC，因为MEC可以在NFV平台上或类似第三方云的独立平台上进行，因此开发一个与平台无关的解决方案是非常关键的。因此，正确的策略是，将MEC应用/MEC平台/MEC平台管理器作为VNF部署在一个共同的NFVI之上将是最有效的。然而，很显然一个普通的NFVO不能满足MEC的所有要求，因此它必须与MEC应用程序编排器（MEAO）合作才能完成MEC特定的任务。但对于由NFVO负责的任务，我们通过Mv1接口对MEC和NFV有一个共同的NFVO。我认为，早期的ETSI架构不会使用MEAO部署Mv1，而是使用E2E SO，主要是因为它对数字OSS转换以及在网络中部署单层跨域编排更有意义。

利用公共云提供MEC应用程序

根据我们的理解，MEC作为平台支持边缘云中的APP与包括公共云在内的远程云之间的通信。此外，它支持将应用程序从公共云迁移到边缘，前提是它们满足MEC系统所要求和定义的描述符和打包要求。这对电信公司来说是一个令人兴奋的时代，因为我们可以在Edge或Access CO的DC上托管边缘应用，并且可以在公共云上使用现在更成熟的应用，它意味着明确的SAP、财务、地理位置并猜测每项服务都可以在3〜5年内到达电信公司。

总结一下，笔者在本文中提出了5~6个问题，这些问题将帮助架构师如何顺利地将网络发展到MEC，最后将网络提供给第三方应用程序和开发人员，以便通过边缘获得更好的业务收益。

不过，笔者认为，至少从商业的角度来看，MEC行业仍处于起步阶段。讨论如何构建正确的用例是一个需要深入分析宏观形势和技术整合的重大课题。

安全也是MEC的一个大问题，就像它迫使电信公司放缓向云的发展一样，它会试图放慢MEC的速度。 最重要的是由于MEC固有的设计，考虑到MEC应用需要私有云和公共云之间的协作，因此MEC应用需要对架构（网络、VNF等方面）和API和终端安全进行更详细的分析，以开发安全可靠的解决方案。 最后，由于MEC的定义确实涉及Access CO或Radio Site，因此MEC还需要解决来自物联网、传感器和一系列网络的安全问题。

原文链接：https://www.netmanias.com/en/?m=view&id=blog&no=13934