MEC边缘计算提高篇（下）

MEC 边缘计算

要实现上文中提到过的 5G 的低延时需求，所以引入了边缘计算（Edge Computing）的概念，其思想类似于计算机中的 Memory 和 Cache 的概念，我们将用户常用到的数据，放在离用户比较近的边缘云（Edge-cloud）中，达到降低用户存取网络信息/服务的延迟，同时降低核心网络的流量/负担。

MEC（Mobile Edge Computing，移动边缘计算）概念最初于 2013 年出现。IBM 与 Nokia Siemens（诺基亚，PS：联通 5G 买了那么多诺基亚的设备，大概就是因为 MEC 的发起者是诺基亚了吧。）网络当时共同推出了一款计算平台，可在无线基站内部运行应用程序，向移动用户提供业务。ETSI（European Telecommunications Standards Institute，欧洲电信标准协会）于 2014 年成立移动边缘计算规范工作组（Mobile Edge Computing Industry Specification Group），正式宣布推动移动边缘计算标准化。

其基本思想是把云计算平台从移动核心网络内部迁移到移动接入网边缘，实现计算及存储资源的弹性利用。这一概念将传统电信蜂窝网络与互联网业务进行了深度融合，旨在减少移动业务交付的端到端时延，发掘无线网络的内在能力，从而提升用户体验，给电信运营商的运作模式带来全新变革，并建立新型的产业链及网络生态圈。

MEC 改变了 4G 中网络和业务分离的状态，通过对传统无线网络增加 MEC 平台网元，将业务平台（包含内容、服务、应用）下沉到移动网络边缘，为移动用户提供计算和数据存储服务。

据估计，将应用服务器部署于无线网络边缘，可在无线接入网络与现有应用服务器之间的回程线路（Backhaul）上节省高达 35% 的带宽使用。到 2018 年，来自游戏、视频和基于数据流的网页内容将占据 84% 的 IP 流量，这要求移动网络提供更好的体验质量。利用边缘云架构，可使用户体验到的网络延迟降低 50%。据 Gartner 报告，全球联网的物联网设备至 2020 年将高达 208 亿台。在图像识别方面，服务器的处理时间增加 50-100ms，能提高 10%-20% 的识别准确率，这意味着在不对现有识别算法做改进的情况下，通过引入移动边缘计算技术，就可通过降低服务器同移动终端之间的传输时延改善识别效果。

2016 年，ETSI 把 MEC 的概念扩展为多接入边缘计算（Multi-Access Edge Computing），将边缘计算从电信蜂窝网络进一步延伸至其他无线接入网络（如 WiFi）。MEC 可以看作是一个运行在移动网络边缘的、运行特定任务的云服务器。

下图是 ETSI 在 MEC 白皮书（White Paper）中列出的 MEC 相关应用，包含了远程手术（Remote surgery）、自动驾驶车（Autonomous car）、AR 等等要求低延时的应用。

针对不同延时需求的应用，将 Content/Service（内容/服务）放在距离用户/核网不同的位置，就如同 Memory Hierarchy 距离 CPU 的距离远近，如下图所示：

中国联通通信云整体架构

其实同样的概念早已经被使用了，像是 CDN（Content Delivery Network），所以 CDN 本质是一个边缘应用，属于边缘计算的子集。

其中，由于高清视频切片网络要求海量视频内容缓存（Cache）、分发和用户就近访问，所以核心网用户面功能下沉到了边缘云。同样，由于任务关键型物联网对时延要求高，比如车联网，为了降低物理距离带来的时延，核心网也下沉到了边缘云，并在边缘配置车联网应用服务器。如下图，将原本放在电信运营商核心网或数据中心中的 APPs 跟 Services 迁移到了边缘云中，而使用者或是开发者只要透过 API 就能存取/使用边缘云上的资源/服务。

再把焦点缩小到ㄧ个 MEC Server 上，如以下这张中国联通的构架图所示，电信运营商将部份服务移到 MEC Server 上，而开发者（OTT 提供者，如 Youtube 或爱奇艺）及用户，可以透过一些共同的 API 来存取电信运营商于此 MEC 上提供的服务。

通过 API 呼叫 Service 的方式提下：

Microservices architecture

MEC 还可以跟 C-RAN 等技术结合，还有将核网中的ㄧ些服务、IMS 等，拉到边缘云中，降低核网的负担、提升整个系统的 Capacity。

在未来，MEC 将构成一个庞大的生态圈，包含了用户、电信商、内容分发、设备商以及服务开发商等等。

Edge-Cloud产业链格局

 

MEC 应用场景举例

MEC 应用于 VR

基于 5G 的 MEC 解决方案，该方案适用于 VR 这一典型应用场景。MEC 部署在 RAN 或 C-RAN（Cloud RAN）侧以获取利于统计分析的关键信息，提供低时延的本地化业务服务。运营商不仅可以有效减少核心网的网络负载，还能通过本地化的部署，提供实时性高、低时延的 VR 体验，增强 VR 实时互动。

系统结构

MEC 应用于在线视频系统

下述为英特尔中国研究院与英特尔网络平台事业部、中国移动及爱奇艺合作开发的一款在线视频系统。该系统利用 MEC 进行视频加速，视频提供商利用 MEC 的计算、存储和网络功能，通过对用户视频请求数据分组进行分析，为特定的高清付费用户提供充足带宽，以保证其观看体验。OTT（互联网应用服务） 在使用上述系统时，无需对自己的应用网络进行架构性变动，由此可以大幅降低使用成本，加速业务创新。该系统目前已在业界知名的世界移动通信大会（Mobile World Congress，MWC）上现身，并引起广泛关注，并被 ETSI MEC ISG 采纳为典型业务场景之一。

基于MEC的在线视频系统

 

MEC PoC12

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

ETSI MEC PoC12:面向OTT业务的MEC参考架构

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

MEC 服务器部署场景

设计 MEC 解决方案时，还必须考虑 MEC 服务器在网络中的部署位置。MEC 服务器可以被部署在网络的多个位置，例如可以位于 LTE 宏基站（eNode B）侧、3G 无线网络控制器（radio network controller，RNC）侧、多无线接入技术（multi-radio access technology，multi-RAN）蜂窝汇聚点侧或者核心网边缘。本节旨在介绍 MEC 服务器的几个主要的部署场景，并且对不同部署方式的优势和存在问题加以简要分析。

4G EPC 架构下的 MEC 部署

MEC 服务器部署在无线接入网（RAN）侧 ：MEC 部署在 RAN 侧的多个 eNode B 汇聚节点之后，这是目前比较常见的部署方式。MEC 服务器也可以部署在单个 eNode B 节点之后。这种方式适合学校、大型购物中心、体育场馆等热点区域下 MEC 的部署。将 MEC 服务器部署在 RAN 侧的优势在于可以更方便地通过监听、解析 S1 接口的信令来获取基站侧无线相关信息，但是该方案需要进一步解决计费和合法监听等安全性问题。

MEC服务器部署在基站汇聚节点之后

MEC 服务器部署在核心网（CN）侧：MEC 服务器部署在核心网边缘。在 PGW 之后（或与 PGW 集成在一起），从而解决 RAN 部署方案下的计费和安全问题。但部署在核心网侧会存在距离用户较远、时延较大和占用核心网资源的问题。该方案是不改变现有的 EPC 架构，将 MEC 服务器与 PGW 部署在一起。UE 发起的数据业务经过 eNode B、汇聚节点、SGW、PGW+MEC 服务器，然后到互联网。

MEC服务器与PGW部署在一起

下图所示方案需要改变现有的 EPC 架构，将原 PGW 拆分成 P1GW 和 P2GW（即 DGW），其中，P1GW 驻留在原位置，DGW 下移到 RAN 侧或者核心网边缘，DGW 负责计费、监听、鉴权等功能，MEC 服务器和 DGW 部署在一起。在此方案下，P1GW 和 DGW之间为私有接口，需由同一设备厂商提供。

MEC服务器与DGW部署在一起

MEC 在 5G 网络中的部署架构

而针对 MEC 的部署，不管是 ETSI 还是中国联通，都希望使用 x86 通用架构，利用网络虚拟化技术（NFV），增加未来扩充服务、动态配置资源的弹性，像是中国联通就建议使用 OpenStack 当作管理平台，以及利用 Container（如 Docker）取代 VM，其优势是为边缘运算提供更快更有弹性的反应速度、资源利用率等等。

在 5G 架构下，MEC 服务器也有两种部署方式。MEC 服务器可以部署在一个或多个 Node B 之后，使数据业务更靠近用户侧，如图中粗实线所示，UE 发起的数据业务经过 Node B、MEC 服务器 1，然后到达互联网。在该方式下计费和合法监听问题需进一步解决。MEC 服务器也可以部署在用户平面网关 GW-UP 后，如图中粗虚线所示，UE 发起的数据业务经过 Node B、GW-UP、MEC 服务器 2，最后到达互联网。此部署方法将以牺牲一部分时延为代价。

MEC在5G架构下的部署

MEC 系统设计原则

网络开放：MEC 可提供平台开放能力，在服务平台上集成第三方应用或在云端部署第三方应用。

能力开放（APIs 经济）：通过公开 API 的方式为运行在 MEC 平台主机上的第三方 MEC 应用提供包括无线网络信息、位置信息等多种服务。能力开放子系统从功能角度可以分为能力开放信息、API 和接口。API 支持的网络能力开放主要包括网络及用户信息开放、业务及资源控制功能开放。

资源开放：资源开放系统主要包括 IT 基础资源的管理（如 CPU、GPU、计算能力、存储及网络等），能力开放控制以及路由策略控制。

管理开放：平台管理系统通过对路由控制模块进行路由策略设置，可针对不同用户、设备或者第三方应用需求，实现对移动网络数据平面的控制。

本地转发：MEC 可以对需要本地处理的数据流进行本地转发和路由。

移动性：终端在基站之间移动，在小区之间移动，跨 MEC 平台的移动。

计费和安全。

MEC 框架设计

MEC 框架所涉及的实体如下图所示，这些实体可以分为外部相关层、MEC 主层和 MEC系统管理层。核心是 MEC 主层，它是包含 MEC 平台和虚拟化基础设施的实体，并且可以更具体的分为 MEC 虚拟基础设施层、MEC 平台层、MEC 应用层。

MEC架构设计图

 

MEC 虚拟化基础设施层 基于通用服务器，采用计算、存储、网络功能虚拟化的方式为 MEC 平台层提供计算、存储和网络资源，并且规划应用程序、服务、DNS 服务器、3GPP 网络和本地网络之间的通信路径。

MEC 平台层 是一个在虚拟化基础设施架构上运行 MEC 应用程序的必要功能的集合，包括虚拟化管理和 MEC 平台功能组件。虚拟化管理利用基础设施作为服务（IaaS）的思想，实现 MEC 虚拟化资源的组织和配置，应用层提供一个资源按需分配、多个应用独立运行且灵活高效的运行环境。MEC 平台功能组件主要是为应用程序提供各项服务，通过开放的 API 向应用层的具体应用开放，这些功能包括无线网络信息服务、位置服务、数据平面分流规则服务、访问的持久性存储服务以及配置 DNS 代理服务等。

MEC 应用层 是基于虚拟化基础设施架构，将 MEC 平台功能组件组合封装后，以虚拟机方式运行的应用程序，如本地内容快速交付、物联网数据处理、任务迁移等。MEC 应用拥有确定数量的资源要求和执行规则，如所需的计算和存储资源、最大时延、必需的服务，这些资源要求和执行规则由 MEC 系统管理层统一管理和配置。MEC 应用可以通过标准的接口开放给第三方业务运营商，促进创新型业务的研发，实现更好的用户体验。

由上述的 MEC 框架可以看出，移动网络基于 MEC 可以为用户提供诸如内容缓存、超高带宽内容交付、本地业务分流、任务迁移等应用。需要注意的是，任务迁移能够使得终端突破硬件限制，获得强大的计算和数据存取能力，在此基础上实现用户内容感知和资源的按需分配，极大的增强用户体验。任务迁移技术对移动设备的计算能力的强化和移动应用的计算模式的改变，必然会对未来移动应用和移动终端的设计产生深远的影响。MEC 的任务迁移流程，如下：

移动边缘计算环境下的任务迁移流程

ETSI MEC 架构参考模型

ETSI（欧洲电信标准化组织）在 2014 年率先启动 MEC 标准化参考模型项目。这一项目组旨在移动网络边缘为 （自己、合作伙伴或第三方）应用开发商与内容提供商 搭建一个云化计算与 IT 环境的服务平台，并通过该平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。MEC 标准化的内容主要包括以下内容：研究 MEC 需求、平台架构、编排管理、接口规范、应用场景研究等。

在 2017 年底，ETSI MEC 标准化组织已经完成了 Phase I 第一阶段基于传统 4G 网络架构部署，定义边缘计算系统应用场景、参考架构、边缘计算平台应用支撑 API、应用生命周期管理与运维框架、以及无线侧能力服务 API（RNIS/定位/带宽管理）。

ETSI MEC 架构抽象模型

Muti-access Edge Computing framework

MEC的基本框架

 

宏观来讲，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 工作系统与局域网、蜂窝移动网或者外部网络的接入情况。

ETSI MEC 架构参考模型

更为详细的MEC参考架构

1.ME 主机（移动边缘主机） 由 ME 平台、ME 应用和虚拟化基础设施组成。虚拟化基础设施可以为 ME 应用提供计算、存储和网络资源，并且可以为 ME 应用提供持续的存储和时间相关的信息，它包含一个数据转发平面来为从 ME 平台接收到的数据执行转发规则，并在各种应用、服务和网络之间进行流量的路由。

2.ME 平台（移动边缘平台，MEP） 从 ME 平台管理器、ME 应用或 ME 服务处接收流量转发规则，并且基于转发规则向转发平面下发指令。另外，ME 平台还支持本地域名系统（DNS）、代理服务器的配置，可以将数据流量重定向到对应的应用和服务。ME 平台还可以通过 Mp3 参考点与其他的 ME 平台进行通信，在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 ME 平台互联的基础。

3.ME 应用（移动边缘应用，ME APP） 是运行在 ME 虚拟化基础设施上的虚拟机实例，这些应用通过 Mp1 参考点与 ME 平台相互通信。Mp1 参考点还可提供标识应用可用性、发生 ME 切换时为用户准备或重定位应用状态等额外功能。

4.ME 平台管理器（ME platform manager，移动边缘平台管理器，MEPM） 具有 ME 平台元素管理、ME 应用生命周期管理以及 ME 应用规则和需求管理等功能。ME 平台和 MEPM 之间使用 Mm5 参考点，该参考点实现平台和流量过滤规则的配置，并且负责管理应用的重定位和支持应用的生命周期程序。Mm2 是操作支持系统（OSS）和 MEPM 之间的参考点，负责 ME 平台的配置和性能管理。Mm3 是 MEO 和 MEPM 之间的参考点，负责为应用的生命周期管理和应用相关的策略提供支持，同时为 ME 的可用服务提供时间相关的信息。

ME 应用生命周期管理包括 ME 应用程序的创建和终止，并且为 ME 编排器（ME orchestrator，MEO，移动边缘编排器）提供应用相关事件的指示消息。
ME 应用规则和需求管理包括认证、流量规则、DNS 配置和冲突协调等。

1.ME 编排器（ME orchestrator，MEO，移动边缘编排器） 是 ME 提供的核心功能，MEO 宏观掌控 ME 网络的资源和容量，包括所有已经部署好的 ME 主机和服务、每个主机中的可用资源、已经被实例化的应用以及网络的拓扑等。在为用户选择接入的目标 ME 主机时，MEO 衡量用户需求和每个主机的可用资源，为其选择最为合适的 ME 主机，如果用户需要进行 ME 主机的切换，则由 MEO 来触发切换程序。MEO 与OSS 之间通过 Mm1 参考点来触发 ME 应用的实例化和终止。MEO 与虚拟化基础设施管理器（VIM）之间通过 Mm4 参考点来管理虚拟化资源和应用的虚拟机映像，同时维持可用资源的状态信息。

2.从 ME 系统的角度来看，OSS（Operations Support System 操作支持系统） 是支持系统运行的最高水平的管理实体。OSS 从面向用户服务（Customer-Facing Service，CFS）门户和用户终端（UE）接收实例化或终止 ME 应用的请求，检查应用数据分组和请求的完整性和授权信息。经过 OSS 认证授权的请求数据分组会通过 Mm1 参考点被转发到 MEO 进行进一步处理。

3.面向用户服务门户（Customer-Facing Service Portal，CFS Portal） 实体相当于第三方接入点，开发商使用该接口将自己开发的各种应用接入运营商的 ME 系统中，企业或者个人用户也可以通过该接口选择其感兴趣的应用，并指定其使用的时间和地点。CFS 通过 Mx1 参考点与 OSS 实现通信。

4.用户终端应用（User app，UEAPP）

5.用户应用生命周期代理（user app LCM proxy，UEAPPLCM proxy） 是供 ME 用户使用来请求应用相关的实例化和终止等服务的实体。该实体可以实现外部云和 ME 系统之间的应用重定位，负责对所有来自外部云的请求进行认证，然后分别通过 Mm8 和 Mm9 参考点发送给 OSS 和 MEO 做进一步处理。值得注意的是，LCM 只能通过移动网络接入，Mx2 参考点提供了 UE 与 LCM 相互通信的基础。

6.虚拟化基础设施管理器（VIM） 用于管理 ME 应用的虚拟资源，管理任务包括虚拟计算、存储和网络资源的分配和释放，软件映像也可以存储在 VIM 上以供应用的快速实例化。同时，VIM 还负责收集虚拟资源的信息，并通过 Mm4 参考点和 Mm6 参考点分别上报给MEO 和 MEPM 等上层管理实体。

MEC 与 UPF

MEC 在 ETSI 的定义里面包括了用户数据平面功能（UPF）以及边缘计算平台功能，而 3GPP 的 5G 架构里面主要是定义了 UPF 网元，UPF 作为核心网的用户面下沉网元，更多是网络功能。目前两大组织也在考虑 MEC 与 UPF 的融合，一般认为 5G 网络下 MEC 与 UPF 的关系如下图所示：

Integrated MEC deployment in 5G network

UPF 是 MEC 系统的一个组成网元，MEC 系统还包括 ME C平台、MEC 平台管理、MEC 服务、MEC 应用、边缘云基础设施以及 MEC 编排（其中 MEC 平台、MEC 服务和 MEC 应用均是面向 MEC 业务服务提供，我们统称为 MEC 业务系统)，UPF 负责将边缘网络的流量分发导流到 MEC 业务系统，逻辑上 UPF 与 MEC 业务系统是分离、松耦合的，实际建设时对于 MEC 与 UPF 是否合设集成部署与统一承载存在以下多种方案：

1.MEC 与 UPF 集成部署，基于 ICT 综合边缘云统一承载。

2.MEC 与 UPF 分离部署，基于不同的边缘云各自承载。

4.MEC 与 UPF 部分共享部署。

Capabilities exposure（MEC deployed in Local DN）

ETSI MEC & NFV 架构参考模型

Phase II 第二阶段的标准化于 2018 年 9 月底完成，主要聚焦在包括 5G/Wi-Fi/固网在内的多接入边缘计算系统，重点覆盖 MEC in NFV 参考架构、端到端边缘应用移动性、网络切片支撑、合法监听、基于容器的应用部署、V2X 支撑、Wi-Fi 与固网能力开放等研究项目，从而更好地支撑 MEC 商业化部署与固移融合需求，之前完成，同期将开启第三阶段的标准维护和标准新增阶段。

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

NFV 参考架构

MEC 在 NFV 中的参考架构

MEC referance architecture in a NFV anviroment

以 ME APP、MEP、MEPM-V、VNFM（MEPLCM）、DataPlane、CFSPortal、UEAPP、UEAPPLCM proxy、OSS、MEAO 为组合，被 MEC 参考点（MEC reference points）所连接的网元，是 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 相关业务在运行时也需要他们的支持，因此直接重用即可。

我们知道 NFV（网络功能虚拟化）指的是解耦传统电信设备的软硬件，并将软件功能运行于 x86 通用服务器硬件上，以降低成本，缩短部署周期和激发服务创新。与 NFV 一样，MEC 也强调功能软件化和平台开放化，以提升网络敏捷性，灵活性，加快部署和创新。

在标准构架上，MEC 和 NFV 看起来不无二致，但它们是有区别的。区别主要在应用服务平台和相关服务上，MEC 根据 RAN 环境对 NFV 进行了优化，它将移动接入网与互联网业务深度融合，并将云计算和云存储下沉到边缘数据中心，加速内容分发和下载，且向第三方提供开放接口以驱动创新。有了 MEC，PGW-U/SGW-U 的用户面就下沉到了移动边缘节点，且由 NFV VIM（虚拟基础设施管理）、SDN 和 Orchestrator（编排器）控制管理。

第三方 APP 的管理模式

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

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 能力。

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

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 平台搭建方的各方需求，同时也是未来比较合适的管理方式。

本文转载自：JmilkFan_范桂飓的博客 ，如果侵权，请联系我们删除。