此系列文章作者分为上中下三部分进行阐述，本文主要分享上部分内容，大纲简述如下：
ETSI MEC 标准化参考模型
MEC 架构设计原则
ETSI MEC 存在的问题
中部分内容概要：
MEC 与 5G 融合
MEC 接入 5GC 的方式
MEP 的服务开发框架
MEC 与 5G 融合架构示
下部分内容概要：
MEC 部署场景
MEC 在 4G 网络中的部署
MEC 在 5G 网络中的部署
MEC 应用场景
1、MEC 边缘计算
MEC（Mobile Edge Computing，移动边缘计算）概念最初于 2013 年出现。IBM 与 Nokia Siemens 当时共同推出了一款计算平台，可在无线基站内部运行应用程序，并向移动用户提供业务。ETSI（European Telecommunications Standards Institute，欧洲电信标准协会）于 2014 年成立移动边缘计算规范工作组（Mobile Edge Computing Industry Specification Group），正式宣布推动移动边缘计算标准化。2016 年，ETSI 把 MEC 的概念扩展为多接入边缘计算（Multi-Access Edge Computing），将边缘计算从电信蜂窝网络进一步延伸至其他无线接入网络（如 WiFi）。
下图是 ETSI 在 MEC 白皮书中列出的 MEC 相关应用，包含了远程手术（Remote surgery）、自动驾驶车（Autonomous car）、AR 等等要求低延时的应用。
在未来，MEC 将构成一个庞大的生态圈，包含了用户、电信商、内容分发、设备商以及服务开发商等等。
2、ETSI MEC 标准化参考模型
ETSI 在 2014 年率先启动了 MEC 标准化参考模型项目。该项目组旨在移动网络边缘为（自己、合作伙伴或第三方）应用开发商与内容提供商构建一个云化的计算与 IT 服务平台，并通过该服务平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。ETSI
MEC 标准化的主要内容包括：研究 MEC 需求、平台架构、编排管理、接口规范、应用场景研究等。
在 2017 年底，ETSI MEC 标准化组织已经完成了第一阶段（Phase I）基于传统 4G 网络架构的部署，定义了 MEC 的应用场景、参考架构、边缘计算平台应用支撑 API、应用生命周期管理与运维框架、以及无线侧能力服务 API（RNIS/定位/带宽管理）。
3、MEC 架构设计原则
网络开放：MEC 可提供平台开放能力，在服务平台上集成第三方应用或在云端部署第三方应用。
能力开放：通过开发 API 的方式为运行在 MEC 平台主机上的第三方应用程序提供包括无线网络信息、位置信息等多种服务。能力开放子系统从功能角度可以分为能力开放信息、API 和接口。API 支持的网络能力开放主要包括网络及用户信息开放、业务及资源控制功能开放
资源开放：资源开放系统主要包括 IT 基础资源的管理（如 CPU、GPU、计算能力、存储及网络等）、能力开放控制以及路由策略控制。
管理开放：平台管理系统通过对路由控制模块进行路由策略设置，可针对不同用户、设备或者第三方应用需求，实现对移动网络数据平面的控制。
本地流量卸载：MEC 平台可以对需要本地处理的数据流进行本地转发和路由。
移动性：终端在基站之间移动，在小区之间移动，跨 MEC 平台的移动。
计费和安全。
4、MEC 分层架构
移动边缘系统层（Mobile Edge System Level）：负责对 MEC ；平台进行全局掌控。集中式部署在核心网或中央机房。
移动边缘主机层（Mobile Edge Host Level）：包含了移动边缘主机（ME host）和移动边缘主机层管理实体（ME host-level management entity）。其中，移动边缘主机又可以进一步划分为移动边缘平台（ME platform）、移动边缘应用（ME application）和虚拟化基础设施（IaaS）。分布式部署在基站机房或接入/汇聚机房。
网络层（Networks Level）：包含了 3GPP 网络、本地网络和外部网络，该层主要表示了 MEC 平台与局域网、蜂窝移动网或者外部网络的接入情况。
5、MEC 系统架构
MEC 虚拟化基础设施层：基于通用的 x86 服务器，采用计算、存储、网络功能虚拟化的方式为 MEC 平台层提供计算、存储和网络资源，并且规划应用程序、服务、DNS 服务器、3GPP 网络和本地网络之间的通信路径。
MEC 平台层：是一个在 VIM（虚拟化基础设施架构）上运行 MEC 应用程序的必要功能的集合，包括 MEC 虚拟化管理和 MEC 平台功能组件。其中，MEC 虚拟化管理利用 IaaS（基础设施作为服务）的思想，实现 MEC 虚拟化资源的组织和配置，MEC 应用层提供一个资源按需分配、多个应用独立运行且灵活高效的运行环境；MEC 平台功能组件通过开放的 API 为 MEC 应用层的应用程序提供各项服务，这些服务包括无线网络信息服务、位置服务、数据平面分流规则服务、访问的持久性存储服务以及配置 DNS 代理服务等。
MEC 应用层：是以虚拟机或容器方式运行的应用程序，如：本地内容快速交付、物联网数据处理、任务迁移等。应用程序具有明确的资源要求和执行规则，如所需的计算和存储资源、最大时延、必需的服务等，这些资源要求和执行规则由 MEC 系统管理器统一管理和配置。MEC 应用层可以通过标准的接口开放给第三方业务运营商，以此促进创新型业务的研发，实现更好的用户体验。
从 MEC 的框架可以看出，移动网络基于 MEC 可以为用户提供诸如内容缓存、超高带宽内容交付、本地业务分流、任务迁移等能力。需要注意的是，任务迁移能够使得终端突破硬件限制，获得强大的计算和数据存取能力，在此基础上实现用户内容感知和资源的按需分配，极大的增强用户体验。任务迁移技术对移动设备的计算能力的强化和移动应用的计算模式的改变，必然会对未来移动应用和移动终端的设计产生深远的影响。任务迁移的流程，如下所示：
6、MEC 软件架构
ME APP（移动边缘应用）：是运行在 VI 上的应用实例，可以通过 Mp1 参考点与 MEP 进行交互，以获取 MEP 平台的服务化开放能力（ME Services）。
MEP（移动边缘平台）：为 ME APP 提供 ME Services，包括：服务注册、服务发现、状态监控，本地分流（Traffic Rules Control）、DNS 服务（DNS handling），Local API 网关、负载均衡器、防火墙，以及无线网络信息服务、位置信息服务、带宽管理服务等一系列无线网络能力服务。从 MEPM 或 ME APP 接收应用规则配置，并通过 Mp2 参考点指示 DP 执行数据路由，将数据流量重定向到相应的 ME APP 或 ME Services。在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 MEP 之间互联的基础。
DP（数据转发平面软件)：执行 MEP 下发的流量规则，处理 ME APP，ME Services，DNS 服务器、代理服务器，3GPP 网络，其他访问网络，局域网和外部网络之间路由流量。
VI（虚拟化基础设施）：即 Hypervisor，可以是 KVM、Docker、ESXi 等一切为 ME APP 提供运行载体的虚拟化管理程序。
ME Host（移动边缘主机）：是一台通用 x86 服务器，通常部署在局所 DC 或边缘 DC。运行着 MEP、ME APP 和 VI 等软件模块。
VIM（虚拟化基础设施管理器）：虚拟化资源管理程序，例如 OpenStack、Kubernetes。用于管理虚拟计算、存储和网络资源的分配和释放，以及管理 ME APP 的镜像文件，还负责收集虚拟化资源的信息，并通过 Mm4 参考点和 Mm6 参考点分别上报给 MEAO 和 MEPM 等上层管理实体。
MEPM（ME platform manager，移动边缘平台管理器）：负责 MEP 的基本运维、ME Services 的配置、ME APP 的生命周期管理以及 ME APP 的应用规则和需求管理等功能。其中，ME APP 的应用规则和需求管理包括：授权认证、分流规则、DNS 规则和冲突协调等。MEPM 和 MEP 之间通过 Mm5 参考点进行交互。
MEAO（Multi-access edge application orchestrator，移动边缘编排器）：是 MEC 业务的编排中心，通常全国只部署一个。MEAO 宏观掌控 MEC 平台所有的资源和容量，主要包括 VIM 中的计算、存储、网络资源、应用程序镜像资源，以及 MEPM、MEP 资源。在实例化 ME APP 时，MEAO 首先加载应用程序的镜像（软件包）、检查软件包的完整性和真实性，然后还需要衡量用户资源需求以及各个 ME Host 的可用资源，为其选择最为合适的 ME Host 进行部署。如果用户需要进行 ME Host 切换，则由 MEAO 来触发切换程序。MEAO 和 MEPM 之间通过 Mm3 参考点，为 ME APP 相关的策略提供支持。MEAO 与 VIM 之间通过 Mm4 参考点来管理虚拟化资源和应用程序的镜像，同时维持可用资源的状态信息。
UE APP：用户终端应用。
UE APP LCM proxy（用户终端应用生命周期代理）：接收 UE APP 发起的操作请求。
CFS Portal（Customer-Facing Service Portal，面向客户的服务门户）：是运营商面向第三方客户订阅并监控 ME APP 的门户。通过 CFS Portal，客户可以选择订购一套满足其特殊需求的 ME APP，或者将自己的应用程序接入到 MEC 平台中，并指定其使用的时间和地点。
OSS（Operations Support System，操作支持系统）：是提供给运营商内部使用的 MEC 部署运维中心，作为 MEC 平台的最高级别的管理实体。OSS 从 CFS 或 UE APP LCM proxy 接收到 ME APP 的生命周期管理请求并决定是否授权，请求通过 OSS 认证授权后，OSS 与 MEAO 之间通过 Mm1 参考点来触发 ME 应用程序的实例化或终止实例。也通过 Mm2 参考点，与 MEPM 进行交互完成 MEP 的配置、故障和性能管理。
7、MEC in NFV 融合架构
ETSI 在 2018 年 9 月完成了第二阶段（Phase II）的工作内容，主要聚焦于包括 5G、Wi-Fi、固网在内的多接入边缘计算系统，重点完成了 MEC in NFV 融合的标准化参考模型、端到端边缘应用移动性、网络切片支撑、合法监听、基于容器的应用部署、V2X 支撑、Wi-Fi 与固网能力开放等研究项目。从而更好地支撑 MEC 商业化部署与固移融合需求，同期将开启第三阶段的标准维护和标准新增阶段。
ETSI MEC 017 规范于 2018 年 2 月发布，重点描述了 MEC 在 NFV（网络功能虚拟化）环境下的部署。MEC 是与生俱来就内含了 NFV 属性的一套生态，MEC 017 规范可以认为是 MEC 003 规范的进一步的扩展，更加面向实际部署和落地。整个融合架构遵循以下原则：
已有的电信网 NFV 架构网元尽可能的被重用
MEC 可调用 NFV 部分功能
MEC 内部功能模块之间的信令不受 NFVO 控制
MEC 同 NFV 之间的接口要重新定义
NFV 标准化参考模型：
由于 NFV 的网元大多是面向电信网的网元，而 MEC 则更加偏向第三方 APP 和业务，业务种类也比 NFV 更加多样，比如：定位、分流、IoT、视频编解码等等。基于 MEC 业务种类繁多的特性，有必要在 NFV 的基础上根据 MEC 业务特性和业务需求，增加若干个全新的功能模块，比如：MEPM-V、VNFM（MEP LCM），来协助 MEP 实现更多的功能。另外，MEC 需要的虚拟化资源和管理重用了 NFVI 和 VIM 的部分，MEC 需要的运维部署中心重用了 OSS 部分，这些网元在进行电信网 NFV 开发和部署的时候就已经建设完成了，可直接调用而无需二次开发。
在标准构架上，MEC 和 NFV 看起来别无二致，但它们是有区别的，例如：MEC 模块同 NFV 网元之间的接口存在着重新开发和定义的问题。核心的区别在应用服务平台和相关服务上，MEC 根据 RAN 环境对 NFV 进行了优化，它将移动接入网与互联网业务深度融合，并将云计算和云存储下沉到边缘数据中心，加速内容分发和下载，且向第三方提供开放接口以驱动创新。通过 MEC，PGW-U/SGW-U/UPF 等核心网用户面的网元就可以下沉到了移动边缘节点，且由 NFV VIM（虚拟基础设施管理）、SDN 和 Orchestrator（编排器）控制管理。
需要注意的是，ME APP 的管理对 MEC 来说是非常重要的部分，对 ME APP 的管理方式代表了未来计算平台的运维模式和管理策略。ME APP 既受控于有 MEC 背景的 MEPM-V，也受控于有 NFV 背景的 VNFM（ME APP LCM），其本质在于 ME APP 是否与 MEP 有交互，是否使用了 ME Service 或获取 MEP 的能力进行优化。
ME APP 受控于 MEPM-V 模式：ME APP 部署在 NFVI 上，同时经由 Mp1 参考点与 MEP 交互，并可能使用 ME Service，统一遵从 MEPM-V 的管理。由于 MEPM-V 中包含了应用规则和需求管理，因此这种方式就默认了 ME APP 要与 MEP 进行交互。通常 MEP 可以是运营商自建也可以是设备商的集成设备。这种方式的好处是有利用到 MEC 生态开放性服务化能力，但是未来可能存在一个问题，如果第三方 APP 只是想用这些 NFVI 的资源，而对 MEP 及其上的 ME Service 不感兴趣，那么这种管理就使得第三方 APP 难以接受，因为目前 Mp1 接口定义的还不够充分，第三方很难围绕 MEP 的服务化接口进行 APP 的定制化开发，无疑是加重了第三方软件开发商的工作量。但是从构建 MEC 生态的角度出发，电信运营商肯定更倾向于向第三方软件开发者提供足够的 PaaS 赋能。
ME APP 受控于 VNFM（ME APP LCM）模式：这种管理方式中，ME APP 仅受到 NFV 的管理，即平台只是对 ME APP 的生存周期进行管理。第三方 APP 仅仅是租用了边缘数据中心的 NFVI 进行部署，让自己的 APP 更加靠近用户，对 MEP 的服务化能力并不感到兴趣。因此 ME APP 仅仅从 NFVI 资源层面受到管理。这种商业模式其实就是租赁机房资源、租赁机架、租赁硬件资源、租赁虚拟机的商业模式，从实现来讲受益更加直接，第三方软件开发商直接获取 APP 的部署资源，运营商也无需在 MEC 层面做过多的适配性开发。但这种方式并不利于营造 MEC 生态，因为这一管理方式彻底抛弃了 APP 同 MEP 之间的关联， Mp1 接口完全废弃，那么 MEP 也没有了存在的价值。因此这种方式只应该在早期 MEC 不成熟的时候采用，长期发展对 MEC 生态建设非常不利。
ME APP 同时受控于 MEPM-V 和 VNFM（ME APP LCM）模式。这种方式结合了 MEC 中的 APP 管理和 NFV 中的 APP 管理。NFV 仅对 APP 的生存周期和虚拟化资源进行管理，而 MEC 则对 ME APP 规则和需求进行管理，分工明确，职责不同。同时定义好 Mp1 接口，为 ME APP 提供 MEP 中 ME service，借助边缘云平台能力可以进行 APP 的定制优化。这种方式一方面迎合了 APP 和 MEC 平台搭建方的各方需求，同时也是未来比较合适的管理方式。
总的来说，MEC 是云网融合型的平台，其基础是提供边缘本地分流这样的基础网络服务，而其核心价值则是边缘云服务，包括：
提供边缘虚机、存储等资源型边缘 IaaS 服务；
提供边缘网络能力开放 API、容器以及边缘应用框架在内的平台型边缘 PaaS 服务；
提供自有以及第三方业务应用在内的边缘 ICT 业务服务。
目前总体来说，BAT 等在内的互联网公司主要需求是资源型边缘 IaaS 服务，而政企等行业客户则三种服务需求都有。单纯从 MEC 业务需求角度来说，边缘 IaaS 服务、边缘 PaaS 以及边缘 ICT 业务服务都是 MEC 可以提供的主要业务和获取收益，但是 MEC 的就近处理会减少中心云及 IDC 的处理，对运营商已有的云及 IDC 收入有影响，并且运营商一直以来对于手握 IDC 资源却没能占据 CDN 市场主要份额心有不甘，不希望在边缘计算上面重蹈覆辙，所以运营商需要综合考虑边缘云的建设成本、中心云及 IDC 的定价、客户的需求、市场发展态势等进行综合的分析以确定 MEC 边缘云的业务提供重点及经营策略，将 MEC 作为一种边缘数据中心的资源设施服务还是作为业务平台来经营，二者策略、定价是完全不同的。
8、ETSI MEC 存在的问题
注：该章节摘自《自动化博览》2018年增刊《边缘计算2018专辑》。
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 所面临的问题。