目录
ETSI MEC 参考架构模型 架构设计原则 分层架构 系统架构 CFS portal UE app User app LCM proxy OSS MEAO MEPM MEP VIM ME Host DP VI ME APP 参考点类型 用户实例化 APP 的流程
ETSI MEC 参考架构模型存在的问题
中移动 MEC 参考架构示例
ETSI MEC 参考架构模型
ETSI 在 2014 年率先启动了 MEC 标准化参考模型项目。该项目组旨在移动网络边缘为（自己、合作伙伴或第三方）应用开发商与内容提供商构建一个云化的计算与 IT 服务平台，并通过该服务平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。
ETSI MEC 标准化的主要内容包括：研究 MEC 需求、平台架构、编排管理、接口规范、应用场景研究等。
在 2017 年底，ETSI MEC 标准化组织已经完成了第一阶段（Phase I）基于传统 4G 网络架构的部署，定义了 MEC 的应用场景、参考架构、边缘计算平台应用支撑 API、应用生命周期管理与运维框架、以及无线侧能力服务 API（e.g. RNIS、定位、带宽管理）。
在 2018 年 9 月，ETSI MEC 标准化组织完成了第二阶段（Phase II）的工作内容，主要聚焦于包括 5G、Wi-Fi、固网在内的多接入边缘计算系统，重点完成了 MEC in NFV 融合的标准化参考模型、端到端边缘应用移动性、网络切片支撑、合法监听、基于容器的应用部署、V2X 支撑、Wi-Fi 与固网能力开放等研究项目。从而更好地支撑 MEC 商业化部署与固移融合需求，同期将开启第三阶段的标准维护和标准新增阶段。
架构设计原则
网络开放：MEC 可提供平台开放能力，在服务平台上集成第三方应用或在云端部署第三方应用。
能力开放：通过开发 API 的方式为运行在 MEC 平台主机上的第三方应用程序提供包括无线网络信息、位置信息等多种服务。能力开放子系统从功能角度可以分为能力开放信息、API 和接口。API 支持的网络能力开放主要包括网络及用户信息开放、业务及资源控制功能开放。
资源开放：资源开放系统主要包括 IT 基础资源的管理（如 CPU、GPU、计算能力、存储及网络等）、能力开放控制以及路由策略控制。
管理开放：平台管理系统通过对路由控制模块进行路由策略设置，可针对不同用户、设备或者第三方应用需求，实现对移动网络数据平面的控制。
本地流量卸载：MEC 平台可以对需要本地处理的数据流进行本地转发和路由。
移动性：终端在基站之间移动，在小区之间移动，跨 MEC 平台的移动。
计费和安全。
分层架构
从宏观的视角，可以将 MEC 的技术堆栈分为 3 个层次进行讨论：
MEC 虚拟化基础设施层：基于通用的 x86 服务器，采用计算、存储、网络功能虚拟化的方式为 MEC 平台层提供计算、存储和网络资源，并且规划应用程序、服务、DNS 服务器、3GPP 网络和本地网络之间的通信路径。
MEC 平台层：是一个在 VIM（虚拟化基础设施架构）上运行 MEC 应用程序的必要功能的集合，包括 MEC 虚拟化管理和 MEC 平台功能组件。其中，MEC 虚拟化管理利用 IaaS（基础设施作为服务）的思想，实现 MEC 虚拟化资源的组织和配置，MEC 应用层提供一个资源按需分配、多个应用独立运行且灵活高效的运行环境；MEC 平台功能组件通过开放的 API 为 MEC 应用层的应用程序提供各项服务，这些服务包括无线网络信息服务、位置服务、数据平面分流规则服务、访问的持久性存储服务以及配置 DNS 代理服务等。
MEC 应用层：是以虚拟机或容器方式运行的应用程序，如：本地内容快速交付、物联网数据处理、任务迁移等。应用程序具有明确的资源要求和执行规则，如所需的计算和存储资源、最大时延、必需的服务等，这些资源要求和执行规则由 MEC 系统管理器统一管理和配置。MEC 应用层可以通过标准的接口开放给第三方业务运营商，以此促进创新型业务的研发，实现更好的用户体验。
其中，就 MEC 平台层而言，根据 ETSI 的设计可被展开为以下 3 个层次：
MEC 系统层（MEC System Level）：一般采用集中式部署，比如部署在核心网机房或者更集中的位置。负责对 MEC 平台进行全局掌控。
– OSS 让运营商可以触发 APP 运维管理和控制操作，并决定是否授权 APP 实例化请求。
– MEAO 管理 MEC 系统拓扑，负责 APP 包加载和 APP 实例部署位置编排，并触发 APP 实例化和实例终止。
MEC 主机层（MEC Host Level）：一般分布式部署，比如在基站机房或者接入、汇聚机房。负责在网络的边缘提供 “计算 + 联接” 能力。
– MEPM 则负责 APP 生命周期管理、性能统计、服务授权、以及分流策略与 DNS 配置等应用规则管理，并负责 MEC platform 基本运维管理。
– MEP 让 APP 可以发现、通知、消费其中的边缘服务，注册第三方服务，以及基于分流策略和 DNS 配置控制 Data Plane 规则。
– ME-Host 为 APP 运行提供 VIM 管理的虚拟化基础设施。
网络层（Networks Level）：包含了 3GPP 网络和 Non-3GPP 网络（本地网络和外部网络），表示了 MEC 平台所类型网络之间的接入情况。
系统架构
CFS portal
CFS Portal（Customer-Facing Service Portal，面向客户的服务门户）是运营商面向第三方客户订阅并监控边缘 APP 的门户网站，主要提供了：
应用兜售：应用开发商使用 CFS Portal 将自己开发的各种应用接入到运营商的 MEC 系统中。
应用购买：企业或用户使用 CFS Portal 选择感兴趣的应用，并指定其使用时间和地点。
UE app
UE app，即用户终端的应用程序，可以是任意形态的终端用户，包括：手机、IoT 设备或支持移动蜂窝网络通信的外部云终端。
UE app 与 User app LCM proxy 之间通过 Mx2 接口进行通信，Mx2 接口仅支持移动蜂窝网络接入方式。
User app LCM proxy
User app LCM proxy（用户应用生命周期代理）接收 UE App 在客户端侧发起的操作，例如：请求进行 APP 的实例化和终止。
User app LCM proxy 可以实现外部终端和 MEC 平台之间的应用重定位，负责对所有来自外部终端的请求进行认证，然后分别通过 Mm8、Mm9 接口发送到 OSS 或 MEAO 作进一步处理。
OSS
OSS（Operations Support System，运营支撑系统）包括操作维护中心和网络管理中心，是电信运营商的一体化、信息资源共享的支撑系统，完成跨业务、端到端、全过程的管理。
OSS 主要由网络管理、系统管理、计费、营业、账务和客户服务等部分组成，底层系统间通过统一的信息总线有机整合在一起，负责全网的通信质量及运行的检验和管理，记录和收集全网运行中的各种数据的情况。
在 MEC 场景中，OSS 作为 MEC 系统中最高级的管理实体，接收来自 CFS Portal 和 User app LCM proxy 的 APP 实例化或终止请求，同时检查请求的数据完整性和授权合法性，并负责将 APP 的镜像包上传到 MEAO。主要完成了：
应用部署指令下达到 MEAO：OSS 与 MEAO 之间通过 Mm1 接口来触发 APP 的实例化或终止。
MEP 元素配置指令下达到 MEPM：OSS 与 MEPM 之间通过 Mm2 接口与 MEPM 进行交互完成 MEP 的纳管、配置、故障告警等操作。
MEAO
MEAO（Multi-access edge application orchestrator，移动边缘编排器） 是 MEC 业务的编排中心，负责 APP 编排部署，决定 APP 部署在哪些 MEPM（ME Host）上。MEAO 通常全国只部署一个，宏观掌控 MEC 系统的总视图，包括：VIM 中的计算、存储、网络资源，应用镜像包资源，以及 MEPM、MEP 的可用服务资源。主要完成了：
应用编排部署与策略配置：MEAO 根据调度选择 MEPM，并通过 Mm3 接口下发 APP 相关的部署指令和策略配置到 MEPM。
VIM 资源管理：MEAO 与 VIM 之间通过 Mm4 接口来管理虚拟化资源和应用程序镜像仓库，同时维护可用资源的状态信息。
在实例化 APP 时，MEAO 首先加载应用程序的镜像包、检查镜像包的完整性和真实性，然后根据用户资源的需求以及各个 VIM 的资源状态，为其选择最为合适的 MEPM 进行部署。如果 APP 需要进行 ME Host 之前的迁移，也是由 MEAO 来触发切换程序。
在 OpenStack 环境中通常使用 Heat（TOSCA）组件编排。
在 Kubernetes 环境中则使用 Helm（YAML）进行编排。
MEPM
MEPM（ME platform manager，移动边缘平台管理器）负责 MEP 的运维管理、VIM 的运维管理、APP 的生命周期管理以及 APP 的应用规则和需求管理等功能。
MEP 运维管理：通过 Mm5 接口完成 MEP 的自动化推送部署或纳管，ME services 的配置。
VIM 运维管理：通过 Mm6 接口完成 VIM 的自动化推送部署或纳管，包括从 VIM 接受虚拟资源故障报告、资源统计、性能统计等数据。
APP 生命周期管理：调用 VIM 北向接口完成 APP 的实例化和终止，也包括向 MEAO 上报与 APP 相关的事件消息。
APP 的应用规则和需求管理：针对 APP 的授权认证，Traffic Rule（IP 五元组）、DNS Rule（DNS 目标域名）的下发，以及解决配置或资源占用冲突协调等。
MEP
MEP（ME platform，移动边缘平台）通过 Mp1 接口为 APP 提供 ME Services（MEC 平台能力开放），包括：服务注册、服务发现、状态监控，本地分流（Traffic Rules Control）、DNS 服务（DNS handling），Local API 网关、负载均衡器、防火墙、NAT，以及 5G 网络能力，包括：无线网络信息服务（RNIS API）、位置信息服务（Location API）、带宽管理服务（Bandwidth API）、UE 标识服务（UE Identity API）等。同时，支持从 MEPM 或 APP 接收应用规则配置，并通过 Mp2 参考点指示 DP 执行数据路由，将数据流量重定向到相应的 APP 或 ME Services。
另外，在分布式 MEC 系统的协作机制中，Mp3 接口可以作为不同 MEP 之间互联的基础，为 APP 的移动性管理提供支撑。
VIM
VIM（虚拟化基础设施管理器）虚拟化资源管理程序，提供虚拟化计算、存储和网络资源，以及管理 APP 的镜像包，还负责收集虚拟化资源的统计信息，并通过 Mm4 和 Mm6 接口分别上报给 MEAO 和 MEPM。
ME Host
ME Host（移动边缘主机）是一台通用 x86/ARM 服务器，部署在最靠近客户的网络边缘，视乎于实际情况，分部署部署在基站、4G DGW、5G UPF 机房（Network Edge）或客户现场（On-Premise）。运行着 MEP、ME APP、VI 和 DP 等软件模块。
DP
DP（Data Plane，数据转发平面软件）执行 MEP 下发的 Traffic Rule 或 DNS Rule，处理 ME APP，ME Services，DNS 服务器、代理服务器，3GPP 网络，其他访问网络，局域网和外部网络之间路由流量。
VI
VI（虚拟化基础设施），即 Hypervisor，可以是 KVM、Docker、ESXi 等一切为 ME APP 提供运行载体的虚拟化管理程序。
ME APP
ME APP（移动边缘应用）是运行在 VI 上的应用实例，可以通过 Mp1 参考点与 MEP 进行交互，以获取 MEP 平台的服务化开放能力（ME Services）。
参考点类型
Mx 参考点：代表 MEC 系统和外部组件之间的关系；
Mm 参考点：代表 MEC 系统内部管理相关；
– Mm1：OSS 和 MEAO 之间的接口。
– Mm2：OSS 和 MEPM 之间的接口。
– Mm3：MEAO 和 MEPM 之间的接口。
Mp 参考点：代表 MEC 主机内部各模块之间的接口关系。
– Mp1：MEP 与 MEC APP 之间服务和配置接口。
– Mp2：MEP 与 DP 之间的转发接口。
– Mp3：MEP 之间的控制面数据交互接口。
其中，ETSI MEC 0010-2 规范统一规范了 Mm1 和 Mm3 接口 API。Mm1 和 Mm3 将 OSS、MEAO、MEPM 这 3 个功能组件串联起来，形成完整的应用生命周期、规则与需求管理功能。目前 Mm1 和 Mm3 主要包含两大类型的服务化 API。
应用包管理服务 API：提供预定义方式管理边缘应用分流规则和 DNS 规则，加载或者卸载应用包到目标 ME-Host，查询加载后的应用包信息。
应用生命周期管理服务 API：提供目标 ME-Host 上边缘应用实例化或终止应用实例，按照业务运营需求启动目标边缘应用实例或将其阻塞。
另外，Mp1 作为 MEC APP 获取 MEP 提供的 ME Services 的参考点，运营商除了无线接入网能力服务之外，还有核心网能力服务也需要开放给 MEC APP。通过 MP1 接口向第三方应用服务提供商提供所需的网络服务能力主要包括：
用户位置信息。
无线网络信息服务。
带宽管理服务。
用户设备标识类信息等。
但目前来看，Mp1 还缺少计费、接入控制等标准定义，商用化并不完善。
用户实例化 APP 的流程
用户通过 OSS 平台申请实例化一个 MEC APP，输入 Name、资源池 Location、APP 镜像、APP 实例规格、APP 编排形态等基本信息。OSS 将用户输入的信息翻译为 MEO 可以理解的参数并输入到 MEO。
MEO 接收到 OSS 下发的 APP 实例化请求后，根据资源池 Location 信息进行 MEPM selection，并把 APP 实例化请求及参数发送到选中的 MEPM。
MEPM 接收到 MEO 的 APP 实例化请求，或管理员直接通过 MEPM 输入 APP 实例化请求及参数开始 APP 实例化的流程。MEPM 通过用户输入的 Location 信息完成 VIM（OpenStack 或 Kubernetes）selection，并完成 APP（虚拟机或容器）启动、IP 地址分配以及网络打通（完全交由边缘云化平台来完成）。
VIM 启动 APP 后，向 MEPM 返回响应。
MEPM 通过用户输入的 Location 信息完成 MEP selection，并完成 APP Traffic rule、APP DNS rule 的下发。其中，DNS rule 指示 5G 网络开放能力接口完成将 APP domain name 的重定向到边缘 DNS Server 进行本地 IP 地址解析，返回边缘云平台为 APP 配置的 IP 地址；Traffic rule 指示 MEP 通过 5G 网络开发能力接口完成对 APP 的 IP 流量进行边缘本地分流。如此的，就打通了 UE 到 UPF 再到 MEC APP IP 的整个媒体面通信路径。
完成 APP 启动和 APP 本地分流规则（Traffic rule、DNS rule）配置后，MEP 为边缘原生的 APP 进行 AK/SK token 安全认证配置，使得 APP 可以安全访问 MEP 平台上的第三方业务服务、以及 MEP 平台本身的增值业务服务。
MEP 完成 APP 边缘化配置流程后，向 MEPM 返回 APP 实例化成功响应。
MEPM 向 MEO 返回 APP 实例化成功响应。
MEO 向 OSS 返回 APP 实例化成功响应。
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 所面临的问题。
中移动 MEC 参考架构示例
注：本章节内容摘自《广东通信技术》期刊，《5G 边缘计算 MEC 节点容灾组网部署方案研究》。
各层级主要网元和功能如下：
集团：边缘计算运营平台 ECM（一级）、业务编排中心（一级）、总部 OSS。
大区中心：5G 核心网控制面网元，包括 AMF、PCF、SMF、UDM、UDR 等。
省中心：运营平台 ECM（二级）、业务编排中心（二级）、MEC 能力管理平台、运维管理域（MEO、MEPM、OMC等）、专线 UPF 等。
地市：按需分层部署共享式/入驻式 MEC 节点，包括 UPF、边缘 PaaS（ECP）、边缘应用（ECA）、边缘云基础设施层（ECI），以及边缘云设施内部管理 VIM/CIM/PIM。
关键组件说明：
ECM：边缘计算业务运营平台，统一门户，应用上架、能力管理、自服务等，实现边缘计算业务开通流程。
ECP：边缘计算 PaaS 平台，统一服务框架，为应用提供网络能力和垂直行业能力，代理开放大网能力。
ECA：边缘应用，可以是运营商自有或第三方。
ECI：边缘虚拟化基础设。
MEC 能力管理平台：北向面向商城，支持把网络产品上架到商城，面向最终企业进行产品销售和拓展；南向面向运维管理域，支持把企业的业务需求自动转换为网络需求，并构建灵活的业务敏捷开通能力，实现 ToB 产商品的商业闭环。
- END -
关于 “云物互联” ：
欢迎关注 “云物互联” ，我们专注于云计算、云原生、SDN/NFV、边缘计算及 5G 网络技术的发展及应用。热爱开源，拥抱开源！
技术即沟通
化云为雨，落地成林