MEC – 我们越来越近了吗？！
多接入边缘计算(MEC)或之前的移动边缘计算在过去几年中一直是很流行的术语，尤其是去年5G技术进入了商业阶段。MEC通常用于描述将服务推向网络边缘的概念，与雾计算等其他术语存在冲突，随着这项技术与5G、容器等基础设施技术联系在一起，其中各种混淆也越来越多。本文从电信公司的角度揭开这一技术的神秘面纱。
MEC的定义和框架来自ETSI，欧洲电信标准化协会，作为MEC行业规范小组(ISG)的一部分，于2014年12月开始工作。以下是ETSI的定义。
多接入边缘计算(MEC)为应用程序开发人员和内容提供商提供了云计算功能，以及在网络边缘的IT服务环境。这种环境的特点是超低延迟和高带宽以及对应用程序可以利用的无线网络信息的实时访问。
这个定义为电信运营商绘制了一张路线图，以便通过IaaS/PaaS模型在边缘提供云计算功能。所以让我们在这里停住并指出，MEC的概念没有与5G结合，尽管它可以在满足5G的超延迟和千兆体验需求方面发挥重要作用。 ETSI MEC最初提供了一个框架和一个有趣的参考架构，如下所示。
该规范于2016年3月发布，在移动运营商中引发了许多问号。下面列出了一些常见的问题，并附上了作者观点。
网络中的MEC主机位置是什么?它可以存在于BTS吗?区域DC?它可以驻留在终端用户场所吗?
MEC被认为距离终端用户只有一步之遥，但是没有明确表示它应该驻留在BTS或Edge DC中。因此，我们可以认为它不会触及终端设备或物联网设备，它只是网络的一跳，可以匹配BTS和Edge DC。
在边缘放置网络功能的数据平面的机制是什么?
有了CUPS，现在就可以在边缘分别部署用户平面功能了。我认为5G UPF和SGW/PGW-U完全吻合。此外，通过适当的服务/资源编排，可以在边缘部署一些VNF，例如Gi-LAN功能和增值服务(缓存、FW、Parental Control等)。
MEC主机上可以运行哪些服务(MEC App)，它们是否需要特殊的基础设施需求?
这些可以是由第三方开发人员开发的第三方应用程序。因此，运营商基本上可以为那些公司或者开发商提供IaaS/PaaS，以开发需要MEC特性(如超延迟)的特殊用途应用程序。 VR / AR、IoT和V2I应用程序就是一个例子。
对于基础设施来说，这些应用程序很可能基于容器。因此，运营商必须利用可托管和“管理”容器的环境。
VIM(例如Openstack)如何管理有数百或数千个DC的远程基础设施环境?
不是很清楚，目前有一些开源计划、小组和论坛，但到目前为止还没有什么实体。两种趋势：
- 集中管理 - 所有OpenStack控制组件仅部署在主DC中，而代理和消息总线跨越所有DC。
- 分布式管理 - 每个DC都部署了整个OpenStack控制组件
应该在边缘部署什么样的基础设施?
应该是轻便的、占地面积小，并且具有低功耗和相对良好的计算能力的廉价基础设施。白盒似乎是一个合适的解决方案。
工作负载是否会在VM上运行?容器?裸机?
出于某些原因，容器总是在MEC工作负载上下的表中。但是，工作负载可以在任何东西上运行。上图是SDx Central 2017年边缘计算和MEC报告调查结果，其中问题是“什么将被用来管理边缘平台”，受访者来自厂商和运营商团队。
MEC是5G的组成部分之一吗?
它可以是，但是这是强制性的吗?我不这么认为。5G国际电联的要求非常明确，如果运营商设法向终端用户提供5G服务/特性，可以不必部署ETSI MEC概念。它们之间没有紧密的联系。
MEC如何与ETSI NFV参考架构相关或匹配?
最近发布的ETSI MEC规范之一GR MEC 017 Mobile Edge Computing(MEC);在NFV环境中部署移动边缘计算。有趣的是，新的网络元素已经被引入，例如MEAO，多接入边缘应用编排，这引发了许多关于这种编排的功能以及它如何与NFVO集成的疑问。
MEAO应该管理移动边缘应用程序包的上载、跨边缘DC的资源编排、为应用程序实例化选择适当的移动边缘主机，以及使用以下参考点触发应用程序实例化、终止和重定位。
- 移动边缘编排器和OSS之间的Mm1参考点用于触发移动边缘系统中的移动边缘应用的实例化和终止。
- 用户应用程序生命周期管理代理与移动边缘系统的移动边缘编排器之间的Mm9参考点用于管理UE应用程序请求的移动边缘应用程序。
- 移动边缘编排器和移动边缘平台管理器之间的Mm3参考点用于管理应用程序生命周期、应用程序规则和需求以及跟踪可用的移动边缘服务。
- Mv1参考点连接MEAO和NFVO。它与Os-Ma-nfvo参考点有关，如ETSI NFV中所定义的，仍在评估中。