5GC 关键技术之 MEC 边缘计算
5GC 关键技术之 MEC 边缘计算
原文链接：5GC 关键技术之 MEC 边缘计算 (uml.org.cn)
作者： 范桂飓
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 将构成一个庞大的生态圈，包含了用户、电信商、内容分发、设备商以及服务开发商等等。
ETSI MEC 标准化参考模型
ETSI 在 2014 年率先启动了 MEC 标准化参考模型项目。该项目组旨在移动网络边缘为（自己、合作伙伴或第三方）应用开发商与内容提供商构建一个云化的计算与 IT 服务平台，并通过该服务平台开放无线侧网络信息，实现高带宽、低时延业务支撑与本地管理。ETSI
MEC 标准化的主要内容包括：研究 MEC 需求、平台架构、编排管理、接口规范、应用场景研究等。
在 2017 年底，ETSI MEC 标准化组织已经完成了第一阶段（Phase I）基于传统 4G 网络架构的部署，定义了 MEC 的应用场景、参考架构、边缘计算平台应用支撑 API、应用生命周期管理与运维框架、以及无线侧能力服务 API（RNIS/定位/带宽管理）。
MEC 架构设计原则
网络开放：MEC 可提供平台开放能力，在服务平台上集成第三方应用或在云端部署第三方应用。
能力开放：通过开发 API 的方式为运行在 MEC 平台主机上的第三方应用程序提供包括无线网络信息、位置信息等多种服务。能力开放子系统从功能角度可以分为能力开放信息、API 和接口。API 支持的网络能力开放主要包括网络及用户信息开放、业务及资源控制功能开放。
资源开放：资源开放系统主要包括 IT 基础资源的管理（如 CPU、GPU、计算能力、存储及网络等）、能力开放控制以及路由策略控制。
管理开放：平台管理系统通过对路由控制模块进行路由策略设置，可针对不同用户、设备或者第三方应用需求，实现对移动网络数据平面的控制。
本地流量卸载：MEC 平台可以对需要本地处理的数据流进行本地转发和路由。
移动性：终端在基站之间移动，在小区之间移动，跨 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 平台与局域网、蜂窝移动网或者外部网络的接入情况。 MEC 系统架构
MEC 虚拟化基础设施层：基于通用的 x86 服务器，采用计算、存储、网络功能虚拟化的方式为 MEC 平台层提供计算、存储和网络资源，并且规划应用程序、服务、DNS 服务器、3GPP 网络和本地网络之间的通信路径。
MEC 平台层：是一个在 VIM（虚拟化基础设施架构）上运行 MEC 应用程序的必要功能的集合，包括 MEC 虚拟化管理和 MEC 平台功能组件。其中，MEC 虚拟化管理利用 IaaS（基础设施作为服务）的思想，实现 MEC 虚拟化资源的组织和配置，MEC 应用层提供一个资源按需分配、多个应用独立运行且灵活高效的运行环境；MEC 平台功能组件通过开放的 API 为 MEC 应用层的应用程序提供各项服务，这些服务包括无线网络信息服务、位置服务、数据平面分流规则服务、访问的持久性存储服务以及配置 DNS 代理服务等。
MEC 应用层：是以虚拟机或容器方式运行的应用程序，如：本地内容快速交付、物联网数据处理、任务迁移等。应用程序具有明确的资源要求和执行规则，如所需的计算和存储资源、最大时延、必需的服务等，这些资源要求和执行规则由 MEC 系统管理器统一管理和配置。MEC 应用层可以通过标准的接口开放给第三方业务运营商，以此促进创新型业务的研发，实现更好的用户体验。
从 MEC 的框架可以看出，移动网络基于 MEC 可以为用户提供诸如内容缓存、超高带宽内容交付、本地业务分流、任务迁移等能力。需要注意的是，任务迁移能够使得终端突破硬件限制，获得强大的计算和数据存取能力，在此基础上实现用户内容感知和资源的按需分配，极大的增强用户体验。任务迁移技术对移动设备的计算能力的强化和移动应用的计算模式的改变，必然会对未来移动应用和移动终端的设计产生深远的影响。 任务迁移的流程，如下所示：
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 的配置、故障和性能管理。
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 标准化参考模型：
MEC in 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 作为一种边缘数据中心的资源设施服务还是作为业务平台来经营，二者策略、定价是完全不同的。
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 融合
注：该章节主要参考 《5G边缘计算演进》。
据估计，将应用服务器部署于无线网络边缘，可在无线接入网络与现有应用服务器之间的回程线路（Backhaul）上节省高达 35% 的带宽使用。2018 年，来自游戏、视频和基于数据流的网页内容将占据 84% 的 IP 流量，这要求移动网络提供更好的体验质量。利用边缘云架构，可使用户体验到的网络延迟降低 50%。
据 Gartner 报告，全球联网的物联网设备至 2020 年将高达 208 亿台。在图像识别方面，服务器的处理时间增加 50-100ms，能提高 10%-20% 的识别准确率，这意味着在不对现有识别算法做改进的情况下，通过引入移动边缘计算技术，就可通过降低服务器同移动终端之间的传输时延改善识别效果。
为了满足业务的低时延需求同时节省不必要的网络传送需求，5G 也引入了 MEC 的概念。其核心是将部分核心网功能和业务功能以及内容资源部署在靠近用户的一侧。其基本思想是把云计算平台从移动核心网络内部迁移到移动接入网边缘，实现计算及存储资源的弹性利用。这一概念将传统电信蜂窝网络与互联网业务进行了深度融合，旨在减少移动业务交付的端到端时延，发掘无线网络的内在能力，从而提升用户体验，给电信运营商的运作模式带来全新变革，并建立新型的产业链及网络生态圈。
然而，MEC 在与 5G 融合的演进中，却遇到了挑战，主要有以下几个方面：
本地分流：MEC 直接实现了本地分分流，但没有制定数据计费以及合法监听的完备标准，这是 5G 商用化必须面对的。
服务开放框架：MEP 通过 Mp1 向 ME APP 开放无线网络能力服务，Mp1 是一个独立的服务开放框架。但运营商 5G 网络还有其他能力也需要开放，比如核心网的策略配置能力。MEC 需要考虑如何将边缘无线网络能力服务与整个运营商的能力开放框架有机结合起来。
服务南向接口：MEC 定义了面向 ME APP 的无线网络能力服务，即 ME Service。但 MEC 并没有定义这些服务到底如何获取 5G 无线接入网络信息和能力。
容器化演进：MEC 目前基于虚拟机部署第三方应用程序，而越来越多的垂直行业应用正在以 Container 方式部署，因此 5G 时代，MEC 需要满足这些应用部署需求。
MEC in 5G 部署：5G RAN 既有 Central Unit 和 Distributed Unit分离架构，也有单基站模式，MEC 在 5G 系统部署时需要考虑 5G RAN 架构演进。
为了支持 MEC，3GPP 标准规定 5GC 应支持如下功能：
在 PDU Session 建立时，5GC 为用户选择部署在用户接入侧的 UPF。
支持业务的本地路由，由于 5GC 支持用户通过多个 UPF 获取服务的模式，用户侧的 UPF 可以只负责本地业务， 用户发起的其他远端服务将由其他 UPF执行。
流量引导功能，当存在多种本地业务时，区分业务类型并将流量引导到本地应用服务器。
保持会话和业务的连续性，确保业务体验。
支持 QoS 和计费功能，MEC 包含了用户平面的功能，5GC 可以对其进行计费和 QoS 控制。
以上功能要求将通过会话管理、策略控制机制、QoS 和计费等技术方案具体实现。当 5G 网络支撑边缘计算时，MEC 作为 AF（Application Function）向非授信域（NEF）或者向授信域（PCF）发送 AF Request，其中包含 Target DNN 和 S-NSSAI、Application ID、N6 路由需求、应用位置（DNAI 信息集）、UE 信息、应用移动性指示、空间和时间有效条件等一系列参数。
PCF 根据 AF提供的这些信息参数，结合自身策略控制，为目标 PDU Session 业务流生成 PCC 规则，通过 SMF 为其选择一个合适的 UPF（如靠近用户附件的位置），并配置 UPF 把目标业务流通过 N6 接口传输到目标应用实例。同时，5G 核心网通过用户面管理事件消息通知 AF 有关 UPF 位置改变信息，这样 AF 可以对应改变应用的部署位置。此时，AF 相当于应用控制器的角色，提供应用与网络控制面之间的交互。
MEC 接入 5GC 的方式
从 MEC 角度，UPF 可以作为 MEC Host 中 Data Plane 的具体实现，MEP 可以通过 Mp2 接口来配置 UPF 的策略和行为。然而，UPF 也会从 N4 接口受到 SMF/PCF 控制，为了消除 N4 接口和 Mp2 接口的分歧与冲突，2018 年 3 月 ETSI MEC 通过了 5G CoreConnect Feature，将 MEC 作为 AF 影响 5G 核心网的特性进一步标准化。
5G CoreConnect Feature 的具体内容包括：
MEC 系统可以代表应用向 5G NEF 发送业务路由以及策略控制请求。
MEC 系统可以从 5G NEF 或者其他 5GC NF 接收通知（UP path management event 通知），根据通知消息信息（如 DNAI 标识的 UPF 位置），MEC 可以选择一个 ME Host 并在其上实例化的一个 ME APP。
MEC 系统可以从 5G NEF 或者其他 5GC NF 接收通知（UP path management event 通知），MEC 可以利用通知内容支持 ME APP 重定位到一个特定 ME Host。
在 MEC System level：加入 5G Core connect proxy 作为 System level 管理域与 5G 核心网交互的代理模块，实现与 5G 核心网控制面消息交互与流程处理。这是因为，MEC 作为一个多接入系统，还需要处理与 WiFi、固定接入网络等其他系统的交互消息，而 OSS 负责运维，MEAO 编排，从功能设计角度，将 5G CoreConnect 特性用一个代理模块单独实现，可以让 MEC 针对 5G 系统的交互独立升级演进，以减少对 OSS 与 MEAO 的技术影响。当 MEC 系统在一定区域内的 ME Host 集群上实例化 ME APP 之后，5G CoreConnect proxy 可以将该 ME APP 及其实例分布信息（如一组 DNAI 信息）通过 AF Request 发送给 5G 核心网，当 UE 向移动网络发起该 ME APP 的业务请求时，5G 核心网就能选择合适边缘位置的 UPF，该 UPF 连接的 ME Host 上部署了相应的 ME APP 实例。同时，当 UE 移动导致 UPF 位置改变时，5G CoreConnect proxy 可以接收从 5G 核心网发送过来的 UP path management event 消息，该消息指示了目标 UPF 位置信息，MEC 根据该信息判断是否需要在相应的 Target ME Host 上新建该 ME APP 或者重定位该 ME APP。
在 MEC Host level：加入 5G CoreConnect Service，MEP 管控的 ME APP 通过该服务可以动态触发 MEC 对 5G 核心网的 AF Request。比如针对当前正在进行边缘业务的某个 UE 使用业务情况，ME APP 通过 5G CoreConnect Service 直接调整该 UE 的 5G 核心网路由策略。
通过上述在 MEC System level 和 MEC Host level 引入的 5G CoreConnect 特性实现功能，MEC 将以 AF 的身份无缝部署到 5G 系统中。
5G Core Connect Proxy
作为 OSS、MEAO、MEPM 提供以 5GC 交互的代理模块。当 OSS、MEAO 或 MEPM 在指定的 ME Host 上实例化 ME APP 后，通过 5G Core Connect Proxy 将会 ME APP 的特征属性以及位置信息告知 5GC NF。当 UE 访问该 ME APP 时，5GC 就可以根据这些信息选择接入指定的 Edge UPF 并进行分流分流。当 UE 移动离开 Edge UPF 的覆盖范围时，5GC 就会将 UP path management event 通过 5G Core Connect Proxy 上报到 MEAO、MEPM，再由 MEAP、MEPM 统筹是否在新的区域中实例化 ME APP 并完成 ME APP 的重定位。
5G Core Connect Service
通过稳定开放的北向 API，为 MEP、ME APP 提供 5GC 交互服务，作为 MEP 本地分流和服务开发框架的底层支撑，屏蔽各厂商 5GC 接口的差异性。
MEP 的服务开发框架
Mp1 作为 ME APP 获取 MEP 提供的 ME Services 的参考点，运营商除了无线接入网能力服务之外，还有核心网能力服务也需要开放给 ME APP。然而，随 Mp1 缺少计费、接入控制等标准定义，商用化并不完善。3GPP SA6 为了避免运营商网络能力服务开放框架的碎片化，正在 R15 阶段定义一个通用的 API 开放框架结构，即 Common API Framework for 3GPP Northbound APIs（CAPIF）。
上图中，API Invoker 是第三方 APP。APP 提供商和运营商之间有相应的服务协议，并且 API Invoker 可以部署在运营商的可信域内。如果 API Invoker 部署在运营商的可信域内，则通过 CAPIF-1 和 CAPIF-2 与 CAPIF 交互。如果 API Invoker 部署在非可信域内，则通过 CAPIF-1e 和 CAPIF-2e 与 CAPIF 交互。对于可信域内 API provider domain 中的 API exposing function、API publishing function 以及 API management function，则 各 自 通 过 CAPIF-3、CAPIF - 4 和 CAPIF-5 与 CAPIF core function 交互。对于非可信域内的 API provider domain function，则使用 CAPIF-3e、CAPIF-4e 和 CAPIF-5e 与可信域内的 CAPIF core function 交互。
MEP 的南向接口
MEP 定义了 3 个与 5G 网络紧密关联的 ME Services，分别是无线网络信息服务、位置信息服务、带宽管理服务。ME APP 可以调用这些服务的 API 优化其性能或者提供新的业务。比如：位置服务可以提供用户室内定位，商业分析软件可以利用位置服务统计分析商场室内人员流动信息，进一步优化室内商铺业态。然而，MEC 目前并没有定义这些 ME Service 如何获取网络信息与能力。当 MEC in 5G 部署，并进一步扩展无线接入网络能力服务时，架构层面需要考虑这些接口。
3GPP 5G 系统架构中，核心网可以通过 NEF 向第三方 App 提供网络。NEF 对外提供 3 种能力：
监控网络状态
为外部应用提供诸如 UE 行为等信息
对外提供策略配置能力
对于 MEC 而言，ME Service 就像无线接入网络（RAN）的 NEF，即一个属于 RAN 的 Local NEF。MEC in 5G时，将挖掘更多 RAN 能力服务支持 5G 业务，尤其是低时延高可靠的业务。以 V2X 为例，由于 V2X 业务涉及大量道路辅助安全应用，其部署会下沉到无线接入网的 MEC 边缘云，并对无线接入网络链路性能指标有非常严格的要求。对于 MEC 而言，可以基于 ME Service 将无线网络信息状态暴露给边缘 V2X App，让 V2X App 可以实时监控无线接入网络运行状态并调整业务策略。同时 ME Service 可以将边缘 V2X App 的实时业务需求转换为对 RAN 的网络优化操作（比如根据 App 业务实时质量进行实时多 RAT 传输增强等）。如此，MEC 提供从基站到应用之间的协同优化，为 5G 业务提供完整的性能保障。由于这些基于 RAN 的 ME Service 对于无线信息和控制时延具有极其严苛的指标要求，因此在架构层面，ME Service 需要与基站直联，从而达到最高效的边缘性能协同。
5G gBN 可以通过双向交互接口，直接向 MEP 开放无线接入网络信息以及基站策略控制能力。MEC Platform 通过 ME Service（或者说 Local NEF），向 ME APP 提供无线接入网络能力 API。
MEC 与 5G 融合架构示例
NOTE：该章节摘自《中兴通讯技术（简讯）》。
我们可以简单的使用 MEC =（连接+计算）x 能力 这一公式来描述 MEC 边缘计算：
连接：MEC 支持 4G、5G、IoT、Wi-Fi、Ethernet 等多种有线/无线网络接入技术，解决了多接入的问题，使不同的网络都能够访问部署在边缘的同一业务，获得相同的用户感知。
计算：MEC 的边缘云模块，提供了部署边缘业务所需的算力资源，包括 CPU、GPU、FPGA 等异构计算能力。
能力：MEC 作为边缘业务的赋能平台，提供了边缘云资源能力、无线网络能力、业务使能能力等，服务于边缘应用。
对于运营商而言，需要考虑 MEC 怎么能够发挥移动通信网络优势，以 CT 能力作为抓手，提供 ICT 融合的统一 MEC 平台为最终目标。MEC 可提供 CT 特有的无线网络能力，如本地分流、NAT/ VFW/DNS/LB、无线室内定位等。
本地分流能力：本地分流能力是 MEC 的核心能力。对于本地计算或企业园区之类的应用场景，首先需要解决业务数据流如何灵活高效地进行本地卸载、就近接入的问题。根据不同组网条件，可选的方案有面向 4G 网络的 TOF+ 方案、CUPS 方案。面向 5G 的 UPF 方案，可以采用 LADN（Local Area Data Network）、UL CL（Uplink Classifier）分流、基于 IPv6 的 Multi-homing 分流方案。
分流规则：MEC 平台提供了业务规则配置及管理功能，ME APP 可以通过相关的业务规则配置接口动态地改变本地分流规则，实现按域名、IP 五元组、用户位置、基站位置等多种方式来对本地业务进行灵活控制。
NAT/VFW/DNS/LB：业务数据流量通过本地分流卸载后，走隧道方式到 MEP 平台，MEP 平台提供 NAT、VFW、DNS、LB 等网络服务，完成业务数据流从运营商网络分发到各个 ME APP。
无线室内定位：MEC 通过融合室内基站、蓝牙等多种定位技术，提供 3~5m 的室内定位能力，同时还可以通过基于 MEC 的物联网管理平台与地磁、消防喷头、火灾报警器等无线传感器等进行联动管理。这种室内定位能力，可以通过 API 方式开放给第三方应用及商场大数据平台，为用户提供室内导航、智能停车等业务应用，从而在现有通信能力的网络基础上叠加提供位置服务能力。中兴通讯基于室内覆盖的 QCell 设备，外加 MEC 定位服务，已经和应用合作伙伴进行了智慧商场、智慧楼宇、智慧园区等多个项目的合作。
DPI/TCP 优化：这类功能以优化网络性能以及提升用户 QoE 为主要目标。基于 MEC 的 DPI 功能通过在 MEC 平台实现深度报文识别，把识别结果通过随路报文通知基站，基站按照设定的策略实现对特定业务类型的差异化调度算法保障，从而获得更好的业务体验。基于 MEC 的 TCP 优化方案主要采用无线网络特有的 TCP 空口优化与有线侧的 TCP 拥塞优化结合，通过 HTTP 分片代理、TCP 透明代理、TCP 拥塞控制、无线资源调度优化等功能来提升 TCP 业务的性能。中兴通讯在深圳联通现网试点测试的效果表明，部署基于 MEC 的 TCP 优化功能后，典型的 HTTP 业务、视频业务等可以获得上行约 15%，下行约 30% 的性能提升。
RNIS（Radio Network Information Services，无线网络信息服务）：是向 MEC 平台和 ME APP 提供无线网络相关信息（e.g. Cell ID、无线信道质量、小区负荷和吞吐量等）的服务，这些信息可以用于优化现有服务。比如：随着人工智能分析推理能力的引入，可以实现业务 QoS 从用户级 => 流级 => 报文级的更细粒度保障，提供位置感知、链路质量预测等新的网络能力。
MEC 部署场景
设计 MEC 解决方案时，还必须考虑 MEC 服务器在网络中的位置。例如：可以位于 4G LTE eNB（宏基站）侧、3G RNC（Radio Network Controller，无线网络控制器）侧、multi-RAN（multi-Radio Access Technology，多无线接入技术）蜂窝汇聚点侧以及核心网侧。
MEC 在 4G 网络中的部署
MEC 的概念早在 4G 建设的前期就已经被提出，所以 MEC 在 4G 和 5G 网络中均可部署。但是在 4G 网络中因为 MEC 提出时 LTE 网络标准已完成制定，所以 4G 网络下的 MEC 部署目前大多采用非标的串联部署或者厂家私有标准部署模式，在计费、监听、业务移动性支持方面并不完善。
MEC 部署在 RAN（无线接入网）侧 ：MEC 可以部署在单个 eNB 节点之后，也可以部署在多个 eNB 的汇聚节点之后，这是 4G 中比较常见的部署方式。称为无线侧 TOF（Traffic Offload）。这种部署方式适合用于学校、大型购物中心、体育场馆等热点区域下。将 MEC 部署在 RAN 侧的优势在于可以更方便地通过监听、解析 S1-C 接口的信令来获取基站侧无线相关信息，也可以通过解析 S1-U 接口的 GTP-U 报文将业务数据流量卸载到边缘进行处理，以此降低网络时延到毫秒级。但是该方案需要进一步解决计费和合法监听等安全性问题。
MEC 服务器部署在 CN（核心网）侧：MEC 部署在 PGW 之后（或与 PGW 集成在一起）。这种方式可以解决 RAN 侧部署方案下的计费和安全问题，但在 C/U 没有分离 4G EPS 架构中，MEC 部署的位置通常与用户距离较远，存在时延较大和占用核心网资源的问题。好处就是该方案不需要改变现有的 EPC 架构，而且 SGi 接口出来的是 IP 报文，也就不需要 MEC 去处理 GTP 报文解析了。
而在 4G EPC CUPS 架构中，PGW 被拆分成了 PGW-C 和 PGW-U（即 DGW）。其中，PGW-C 驻留在原位置，DGW 下沉到 RAN 侧或者核心网边缘，DGW 负责计费、监听、鉴权等功能，也解决了网络时延大的问题。缺点在于，4G C/U 分离技术并不完全，PGW-C 和 DGW 之间为私有接口，需要由同一设备厂商提供。
MEC 在 5G 网络中的部署
3GPP 的 5G 核心网在标准上天然支持用户数据面的下沉及边缘计算的部署，解决了 4G 网络中 MEC 部署存在的计费监听等问题。ETSI MEC 规范包括了用户数据平面功能以及边缘计算平台功能，而 3GPP 的 5G 标准里面主要定义了 UPF 网元，UPF 作为 5GC 的用户面下沉网元，关注的是网络功能。两大组织一直在合作推进将 UPF 作为 MEC 系统中的一个组成网元，充当 DP 模块，UPF 负责将边缘网络的流量卸载到 MEC 平台。逻辑上 UPF 与 MEC 平台是松耦合的，一般认为 5G 场景中 MEC 与 UPF 的关系如下图所示：
实际建设时对于 MEC 与 UPF 是否合设集成部署与统一承载存在以下多种方案：
MEC 与 UPF 集成部署，基于 ICT 综合边缘云统一承载：建设包括 UPF 在内的统一 MEC 系统， MEC 系统的建设也通常被锁定在提供 UPF 的核心网厂家，MEC 业务系统与 UPF 共享 NFV 电信边缘云基础设施以及统一纳管，节约部分投资，另外靠近基站的边缘接入点资源比较紧张，集成部署有利于资源的充分利用。但是该方案需要既可以满足 UPF 等 NFV 高性能网络转发处理需求，还需要支持 IT 类业务应用的容器化部署与编排管理、边缘 AI 类以及视频类业务应用的 GPU/FPGA 等加速及异构计算处理，之前主要面向网络通信处理的 NFV 电信云需要扩展成为 ICT 综合边缘云，包括 MANO 也需要相应的扩展。
MEC 与 UPF 分离部署，基于不同的边缘云各自承载：MEC 业务系统与 UPF 分离部署，支持分厂家建设，支持引入 IT 厂家或者自研提供 MEC 业务系统，并且 UPF 作为 5G 核心网元，与承载自有及第三方业务应用的 MEC 业务系统物理隔离也有利于 5G 网络的安全保障。但是该方案下 MEC 业务系统如果提供网络流量业务链处理类服务，不能与 UPF 共享网络处理，有一定的重复投资，并且部分资源受限的边缘点也很难建设提供两朵边缘云，两朵云的利用率不如集成部署的统一边缘承载方案。
MEC 与 UPF 部分共享部署：MEC 业务系统分为 CT 类 VNF 与 IT 类 APP 两大类业务服务，其中 CT 类 VNF 与 UPF 统一承载集成部署，IT 类 APP 独立部署。对于 CT 类业务服务共享 NFV 边缘云，仍然由运营商网络运维部门负责统一运营管理。同时独立建设 IT 边缘云，满足 IT 类边缘业务灵活性，这部分 IT 边缘云可以考虑由运营商负责公有云的部门统一集约运营。这种模式的问题在于增加了边缘业务的统一管理复杂度，同时部分融合业务也很难简单的是化为 IT 类还是 CT 类业务，比如远程驾驶控制等。
ME Host 的部署方案
5G 网络原生采用云化建设，更加轻盈和灵活，以中心 DC（大区中心机房）、区域 DC（省层面机房）、核心 DC（本地网核心机房）、边缘 DC（本地网汇聚机房）、接入局所 DC、基站机房为基础架构的分层 DC 化机房布局模式成为各运营商传统机房改造演进的共同路线。
其中，MEC 系统级网管（包括 MEPM、MEAO）需要协调不同 ME Host（包括 MEP、UPF、ME APP）之间以及 ME Host 与 5GC 之间的操作（e.g. 选择主机、应用迁移、策略交互等），一般部署在区域 DC（省层面）或者中心 DC（大区中心）；而 ME Host 部署方面应以业务为导向按需部署，并与 UPF 的下沉和分布式部署相互协同，在实际组网中，根据对操作性、性能或安全的相关需求，ME Host 可以灵活地部署在从基站附近到中央数据网络的不同位置。但是不管如何部署，都需要由 UPF 来控制流量指向 ME APP 或是指向网络。下图概述了 ME Host 物理位置的一般可行选项
ME Host 在接入局所 DC：此种模式一般采用 ME Host 和基站 CU 共机房，部署在基站后面，数据业务离用户更近，终端发起的业务经过基站、ME Host 到互联网/第三方内容服务，主要针对新型超低时延业务在边缘才能满足需求的场景，时延可控制在 1ms-10ms 之内，例如：无人机投递业务（10ms，15Mbit/s）、智慧场馆（10ms，1Gbit/s）、自动驾驶（1ms，50Mbit/s以上）、远程医疗诊断（10ms，50Mbit/s）、机器人协作（1ms，110Mbit/s）、远程手术（1ms10ms，300Mbit/s）等。
ME Host 部署在边缘 DC：此种模式 ME Host 一般部署在本地网汇聚机房，逻辑位置在 UPF/PGW-U 之后，会增加一部分回传网络的时延，可以为用户提供低时延、高带宽服务，例如：AR/VR业务（20ms，1Gbit/s）、移动视频监控（20ms，50Mbit/s）、移动广播（小于100ms，10Mbit/s）、公共安全（20ms，10Mbit/s）、高清视频（20ms，10Mbit/s）等。
MEC 应用场景
MEC 应用于 VR
基于 5G 的 MEC 解决方案，该方案适用于 VR 这一典型应用场景。MEC 部署在 RAN 或 C-RAN 侧以获取利于统计分析的关键信息，提供低时延的本地化业务服务。运营商不仅可以有效减少核心网的网络负载，还能通过本地化的部署，提供实时性高、低时延的 VR 体验，增强 VR 实时互动。
MEC 应用于在线视频系统
下述为英特尔中国研究院与英特尔网络平台事业部、中国移动及爱奇艺合作开发的一款在线视频系统。该系统利用 MEC 进行视频加速，视频提供商利用 MEC 的计算、存储和网络功能，通过对用户视频请求数据分组进行分析，为特定的高清付费用户提供充足带宽，以保证其观看体验。OTT（互联网应用服务） 在使用上述系统时，无需对自己的应用网络进行架构性变动，由此可以大幅降低使用成本，加速业务创新。该系统目前已在业界知名的世界移动通信大会（Mobile World Congress，MWC）上现身，并引起广泛关注，并被 ETSI MEC ISG 采纳为典型业务场景之一。
MEC 应用于支持 OTT 业务
中国联通在 2018 年 3 月首次参与 ETSI MEC 标准化工作。在 MEC#13 次会议中，中国联通主导的《PoC12：MEC Platform to Enable OTT Business》国际标准项目成功立项，获得审核委员会全票通过。这是 ETSI 在边缘计算领域首个实现 ICT（IT&CT）融合的立项，填补了 MEC 应用研究方面的空白。自此，中国联通牵头开启了 ETSI MEC 标准化组织与 OTT（互联网应用服务）的应用合作，具有里程碑式的重要意义。
如下这张中国联通的构架图所示，电信运营商将部份服务移到 MEC 上，而开发者（OTT 提供者，如 Youtube 或爱奇艺）及用户，可以透过一些服务化的 API 来存取电信运营商于此 MEC 上提供的服务。
该立项建议由中国联通联合中兴通讯、INTEL 共同向 ETSI MEC#13 提交，并由中国联通网络研究院标准专家进行立项申请陈述和答辩。该标准项目将基于业界最大的天津边缘云测试床，依托轻量化 OpenStack、Kubernetes 等虚拟化技术，以商用化部署为目标，研究 vCDN、VR/AR 等 OTT 应用对 MEC 边缘云业务平台能力及 API 的需求，并为 ETSI GS MEC 003 系统架构的进一步完善提供强有力的参考依据。
PoC12 中所展示的 APP 部署在边缘主机上，经过 Mp1 同 MEP 对接，获取 MEP 上的平台能力，平台能力的好坏直接决定了 APP 是否部署在边缘主机并接受 MEP 管控。目前 MEP 平台的最大的问题就是平台封闭性严重，不同厂家平台制式不同很难互通，接口私有化定义。造成的后果就是一旦规模部署，每款 APP 都要分别部署在各方开发的 MEP 上，因此就都要针对各家平台进行定制化的开发和业务对接，这种不友好的方式是不会被第三方 APP 所接收，因为这种方式极大地增大了第三方的业务重复开发和维护工作。目前的解决方法是，由运营商主导 MEP 平台，同时由运营商统一开展平台接口标准化和平台架构标准化，集合设备商的各类平台能力和资源，这样第三方 APP 只需要一次开发和对接即可实现快速业务部署，对第三方 APP 非常友好，平台也更为开放。
