黄 强，李 宁（中兴通讯股份有限公司，上海 201203）
本文版权为《邮电设计技术》所有，如需转载请联系《邮电设计技术》编辑部
摘要：边缘计算是5G应用下沉的关键技术支撑，ETSIMEC以LTE网络为原型，提出边缘计算参考架构、基本功能与特性。但MEC目前依然存在商用化问题，尤其MEC面向5G部署时。提出MECin5G演进时面临的挑战以及5个关键技术点：MEC作为ApplicationFunction、MEC服务开放框架、MEC服务南向接口、MEC容器化演进、MECin5G部署，并进一步提出了相应的解决方案。
关键词：边缘计算； 5G；CAPIF
doi：10.12045/j.issn.1007-3043.2018.11.013
前言
2014年，ETSI启动基于LTE的边缘计算标准项目 MEC（Mobile Edge Computing），并于 2017 年升级为 Mult-access Edge Computing以满足5G、Wi-Fi、固网多接入需求。其目的是为了降低传输时延、缓解网络拥塞，让运营商能够在移动网络内部引入MEC，以无线接入网边缘位置融合计算、存储、网络以及无线网络服务API能力，就近提供边缘智能业务。MEC可利用无线接入网边缘云提供本地化云服务，并能连接非运营商网络（如企业网）私有云从而形成混合云。MEC 主机基于NFV提供虚拟化软件环境，管理第三方应用资源。第三方应用以虚拟机（VM）形式部署于边缘云，通过统一的服务开放框架获取无线网络能力。
在LTE网络中，MEC部署在基站后，包括接入环、汇聚环等位置，通过解析基站与核心网之间的S1接口消息，实现业务分流至MEC主机上的第三方应用。目前，MEC正在往5G、Wi-Fi、固网等多接入边缘系统方向演进。
1、MEC参考架构解析
MEC 系统架构分为 Mobile edge host level 和 Mobile edge system level 2个不同层次的level。其中Host level一般分布式部署，比如在 eNodeB 机房或者接入/ 汇聚机房。而System level一般集中式部署，比如核心网或者更集中的位置。第三方 App 部署在 Mobile edge host提供的虚拟化资源之上。
System level中，CFS Portal是运营商面向第三方客户订阅并监控边缘 App 的门户。User app LCM proxy 接收App在UE侧客户端发起的操作。Operations Support System 接收来自CFS Portal和User app LCM proxy 的App实例化或实例终止请求，决定是否授权请求，并负责将 App 镜像加载到 ME Orchestrator。ME Orchestrator 负责应用编排部署，决定 App 部署在哪些 MEHost上。
Host level 中，ME Host 通过 Virtualization Infrastructure 给 App 提供虚拟化计算、存储和网络资源。 ME Platform Manager负责App生命周期管理、ME Service 配置以及 ME Platform 基本运维。ME Platform 的 Traffic Rules Control 和 DNS handling 通过 Mp2 接口实现Data Plane的业务分流控制。ME Platform通过应用使能接口（Mp1）让 App 发现、通知、消费 ME Service。其中ME Service包括无线网络信息服务、位置信息服务、带宽管理服务等一系列无线网络能力服务。
综上所述，MEC系统通过参考NFV框架提供MEC 管理，通过 ME Host上虚拟化基础设施向 App提供实例化资源，通过Data plane加载App分流规则进行业务分流，通过ME Platform上的ME Service开放无线网络能力服务，并通过 Mp1接口将 ME Service 开放给 App 消费。
2、MEC面向5G的挑战
ETSI MEC 2014年刚开始定义参考架构时，运营商网络正处于4G建设阶段。其独立的部署架构特性很好地满足了4G网络本地分流需求，并在预商用测试中通过室内定位等无线网络能力服务满足了边缘业务性能优化与增强。然而，MEC在面向商用和 5G演进中，却遇到了挑战，主要有以下几个方面：
a） 本地分流：MEC直接实现了本地分流，但没有制定数据计费以及合法监听的完备标准，这是5G商用化必须面对的。
b） 服务开放框架：MEC通过Mp1向App开放无线网络能力服务，Mp1是一个独立的服务开放框架。但运营商5G网络还有其他能力也需要开放，比如核心网的策略配置能力。MEC需要考虑如何将边缘无线网络能力服务与整个运营商的能力开放框架有机结合起来。
c） 服务南向接口：MEC定义了面向App的无线网络能力服务，即ME Service。但MEC并没有定义这些服务到底如何获取5G无线接入网络信息和能力。
d） 容器化演进：MEC目前基于虚拟机部署第三方 App，而越来越多的垂直行业应用正在以Container方式部署，因此5G时代，MEC需要满足这些应用部署需求。
e） MEC in 5G 部署：5G RAN 既有 Central Unit 和 Distributed Unit分离架构，也有单基站模式，MEC在5G 系统部署时需要考虑5G RAN架构演进。
上述5点是MEC面向5G演进时需要思考并解决的问题，这些问题有些需要在3GPP 5G系统架构演进中找到方向，有些需要与开源社区紧密结合，整个 MEC产业界正在通过各个标准与工业组织协作中寻找突破。
3、MEC in 5G演进
3.1 MEC作为Application Function
3GPP SA2在R15中定义了5G系统架构（见图1）。该架构有以下几个特点。
图1 5G系统架构
a） 通过5G核心网控制面与用户面分离，用户面网元UPF可以灵活地下沉部署到网络边缘，而策略控制 PCF以及会话管理 SMF等控制面功能可以集中部署。通过 UPF可以解决边缘业务分流的计费以及合法监听问题。
b） 定义了Service Based的服务化接口，网络功能既能产生服务，也能消费服务。这些服务化接口大大降低了系统接口交互成本。
c） 对于授信域Application Function直接开放网络功能的服务接口，对于外部非授信域Application Function，则通过 NEF开放网络功能能力，让 AF可以影响5G核心网的业务路由与策略规则。
当5G 网络支撑边缘计算时，Application Function 向非授信域（NEF）或者向授信域（PCF）发送 AF Request，其中包含目标 DNN 和 S-NSSAI、应用 ID、N6 路由需求、应用位置（DNAI信息集）、UE信息、应用移动性指示、空间和时间有效条件等一系列参数。PCF根据AF提供的这些信息参数，结合自身策略控制，为目标PDU Session业务流生成PCC规则，通过SMF为其选择一个合适的UPF（如靠近用户附件的位置），并配置 UPF把目标业务流通过N6接口传输到目标应用实例。同时，5G核心网通过用户面管理事件消息通知AF有关 UPF位置改变信息，这样 AF可以对应改变应用的部署位置。此时，Application Function相当于应用控制器的角色，提供应用与网络控制面之间的交互。
MEC提供应用基础设施资源编排、应用实例化、应用规则配置等功能，其功能相当于应用控制器。因此，当 MEC 部署在 5G 系统中时，MEC 自然可以充当 Application Function 角色，代表部署在 MEC 上的应用与 5G系统控制面交互。从 MEC角度，UPF可以作为 MEC Host 中Data plane 的具体实现。然而，UPF 受到 SMF/PCF控制，为了消除其中的分歧，2018年3月ETSI MEC 通过了 5G CoreConnect Feature，将 MEC 作为AF影响5G核心网的特性进一步标准化。
5G CoreConnect Feature具体内容包括：
a） MEC系统可以代表应用向5G NEF发送业务路由以及策略控制请求。
b） MEC系统可以从5G NEF或者其他核心网网络功能接收通知（UP path management event通知），根据通知消息信息（如DNAI标识的UPF位置），MEC可以选择一个MEC Host并在其上实例化的一个应用。
c） MEC系统可以从5G NEF或者其他核心网网络功能接收通知（UP path management event 通知），MEC 可以利用通知内容支持应用实例重定位到一个特定MEC Host。
然而，目前MEC系统还没有针对5G CoreConnect 特性设计具体的功能块。从系统设计角度System level域可以有 5G CoreConnect 特性的配置及交互能力，同时也要在Host level域开放能力让应用可以直接提供5G CoreConnect特性交互信息。图2展示了未来一种可能的MEC在5G系统中的功能与交互架构。
在MEC System level加入5G Core connect proxy作为 System level管理域与 5G 核心网交互的代理模块，实现与5G核心网控制面消息交互与流程处理。这是因为，MEC作为一个多接入系统，还需要处理与 WiFi、固定接入网络等其他系统的交互消息，而OSS负责运维，ME Orchestrator负责编排，从功能设计角度，将 5G CoreConnect 特性用一个代理模块单独实现，可以让MEC针对5G系统的交互独立升级演进，以减少对 OSS与ME Orchestrator的技术影响。当MEC系统在一定区域内的 ME Host 集上实例化 App 之后，5G CoreConnect proxy 可以将该 App 以及 App 实例分布信息（如一组 DNAI 信息）通过 AF Request 发送给 5G 核心网，当UE向移动网络发起该App的业务请求时，5G核心网就能选择合适边缘位置的 UPF，该 UPF 连接的 ME Host上部署了相应的App实例。同时，当UE移动导致UPF位置改变时，5G CoreConnect proxy可以接收从5G核心网发送过来的UP path management event消息，该消息指示了目标UPF位置信息，MEC根据该信息判断是否需要在相应的目标MEC Host上新建该应用实例或者重定位该应用实例。
图2 MEC in 5G功能与交互架构
在 MEC Host level：MEC 平台上加入 5G CoreConnect Service，ME Platform上的应用通过该服务可以动态触发MEC对5G核心网的AF Request。比如针对当前正在进行边缘业务的某个 UE使用业务情况，应用通过5G CoreConnect Service直接调整该UE的5G核心网路由策略。
通过上述在MEC System level和MEC Host level引入的5G CoreConnect特性实现功能，MEC将以Application Function的身份无缝部署到5G系统中。
3.2 MEC服务开放框架
在 MEC 系统中，ME Platform 位于 ME Host 之中，为运行在MEC Host虚拟化基础设施之上的App提供边缘网络服务ME Service。ME Platform和App之间定义Mp1接口实现了MEC服务开放。
在目前预商用试点中，Mp1接口为边缘应用提供简洁独立的ME Service访问机制，效果良好。然而，随着MEC未来在5G系统中商用，其缺点也进一步体现。首先，运营商除了无线接入网能力服务之外，还有核心网能力服务也需要开放给App。其次，Mp1接口中缺少计费、接入控制等标准定义，商用化并不完善。面对这些问题，MEC需要从3GPP寻找方向。
3GPP SA6为了避免运营商网络能力服务开放框架的碎片化，正在R15阶段定义一个通用的API开放框架结构，即 Common API Framework for 3GPP Northbound APIs（CAPIF）。其基本功能模型架构如图3 所示。
图3 CAPIF功能模型
图3中，API Invoker是第三方App。App提供商和运营商之间有相应的服务协议，并且API Invoker可以部署在运营商的可信域内。
如果API Invoker部署在运营商的可信域内，则通过 CAPIF-1 和 CAPIF-2 与 CAPIF 交互。如果 API Invoker部署在非可信域内，则通过CAPIF-1e和CAPIF2e与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交互。
CAPIF本身份为CAPIF core function和API provider domain 2个域。 CAPIF core function提供如下功能。 a）对API Invoker进行鉴权。 b）支持API Invoker的双向鉴权。 c）对API Invoker访问Service API进行授权。 d）发布、存储以及支持发现Service API信息。 e）基于运营商策略配置控制Service API接入。 f）存储Service API调用日志，并提供给授权实体。 g）基于Service API调用日志计费。 h）监控Service API调用。 i）加载与卸载API Invoker。j）存储CAPIF以及Service API相关的策略配置。
API exposing functio(k）支持日志审计。)n提供如下功能。
a）与 CAPF core function 协同对 API Invoker 进行鉴权。
b）通过CAPIF core function验证授权。
c）记录 Service API 调用日志，并提供给 CAPIF core function。
API publishing function提供如下功能。通过CAPIF core function发布Service API信息。
API management function提供如下功能。
a）审计从CAPIFcorefunction过来的ServiceAPI 调用日志。
b）监控CAPIF core function相关事件报告。
c）向CAPIF core function配置API供应商策略。
d）监控Service API状态。
可以看到，同样作为服务开放框架的CAPIF，面向商用化的功能相对完备。同时，CAPIF core function和 API provider domain 可以分离，其中 API provider domain的3个功能可以下沉到网络边缘分布式部署。
对于MEC 而言，其 ME Service 通过 API exposing function开放给App，ME Platform同时也会实现相应的 API publishing function 和 API management function，形成完整的边缘API provider domain，并通过CAPIF-3/4/ 5标准化接口与运营商集中的CAPIF core function连接交互形成完整的边缘能力开放框架。
3.3 MEC服务南向接口
MEC Platform上目前定义了3个ME Service，分别是无线网络信息服务、位置信息服务、带宽管理服务。 App可以调用这些服务的API优化其性能或者提供新的业务。比如位置服务可以提供用户室内定位，商业分析软件可以利用位置服务统计分析商场室内人员流动信息，进一步优化室内商铺业态。然而，MEC目前并没有定义这些 ME Service 如何获取网络信息与能力。当MEC in 5G部署，并进一步扩展无线接入网络能力服务时，架构层面需要考虑这些接口。
3GPP 5G 系统架构中，核心网可以通过 Network Exposure Function向第三方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需要与基站直联，从而达到最高效的边缘性能协同。
在图4所示的架构中，5G gNodeB可以通过双向交互接口，直接向MEC Platform开放无线接入网络信息以及基站策略控制能力。MEC Platform 通过 ME Service（或者说Local NEF），向边缘App提供无线接入网络能力API。
图4 ME in 5G边缘服务南向接口架构
3.4 MEC容器化演进
目前MEC依托于NFV架构以及OpenStack开源技术，已经构建出一套相对成熟的虚拟机资源编排管理平台。第三方App以虚拟机承载的虚拟化网络功能形式（VNF）部署在MEC Host之上。然而，随着越来越多的第三方应用以容器化而不是虚拟机方式部署，MEC 正在面临容器化演进的挑战，尤其是在垂直行业领域。容器是一种操作系统级别的虚拟化技术，通过操作系统隔离技术如 Linux 下的 CGroup 和 NameSpace，将不同的进程隔离开。容器技术不同于硬件虚拟化（Hypervisor）技术，并没有虚拟硬件，容器内部也没有操作系统，只有进程。正是由于容器技术的这个重要特点，使得容器比虚拟机更轻量，管理也更方便。
容器技术具有以下优势。
a） 启动和卸载速度快：容器的启动和卸载速度比虚拟机快得多。
b） 镜像小：容器镜像在磁盘上占用的空间比虚拟机镜像要小很多。
c） 自包含：容器镜像包含业务实现逻辑以及运行依赖，使容器在跨平台迁移过程中，具有更好的一致性。
d） 资源利用动态变化：容器的资源利用是动态变化的；然而，基于虚拟硬件的规格，虚拟机的资源配置是静态的。
e） 部署密度大：容器的部署密度要比虚拟机大很多。
基于容器的应用一般会采用微服务架构。在这种架构下，应用被划分为不同的组件，并以服务的形式运行在各自的容器中，通过 API 对外提供服务。为了保证应用的高可用，每个组件都可能会运行多个相同的容器。这些容器会组成集群，集群中的容器会根据业务需要被动态地创建和销毁。所谓编排，通常包括容器管理、调度、集群定义和服务发现等。通过容器编排引擎，容器被有机地组合成微服务应用，实现业务需求。
Kubernetes是 Google 公司领导开发的开源容器编排引擎，目前已经成为容器编排领域的事实标准。Kubernetes可以用于容器集群的自动化部署、扩容以及运维。通过Kubernetes，可以快速而有预期地部署应用、扩展应用。对于MEC系统，使用Kubernetes来进行容器编排将是容器化演进的最佳选择。
当MEC利用容器进行部署App时，比较常见的部署方式如下：
a） 裸机容器部署：容器运行在裸机上，这种部署方式的优点为性能和物理机相近、资源利用率高、内核直接处理硬件差异；其缺点为共享内核导致的隔离性较差。
b） 虚拟机容器部署：其优点为虚拟机层屏蔽硬件差异，虚拟机标准化程度高，可以利用虚拟机的能力实现容器热迁移等高级功能，通过虚拟机隔离，以更灵活的方式实现租户间的安全隔离。其缺点为性能和虚拟机相近，但比物理机差。
当MEC引入容器部署后，其管理框架也需要进一步演进。新的管理架构需要与现有的ETSI NFV管理架构兼容，不破坏现有管理架构。充分吸纳现有容器技术的优点，例如轻量、敏捷、性能优势等。不局限于单一的容器技术，支持多种容器化VNF部署方式，即虚拟机容器、裸机容器等。MEC容器化管理架构需具有通用性，能适应各种容器部署场景。
3.5 MEC in 5G部署
从协议逻辑看，5G边缘计算部署时，UPF相当于 MEC Host的Data Plane功能。UPF和MEC Host的位置取决于运营商与第三方应用基于虚拟化基础设施、业务时延及带宽、管理和商业模式等各方面因素的综合考虑。
从物理位置角度，有下列几种可能场景。
a） MEC与gNodeB共址部署。
b） MEC与Central Unit共址部署。
c） MEC部署在传输/汇聚点。
4、结束语
MEC最初基于LTE网络实现边缘计算，如今已向5G、WLAN、固网等多接入边缘计算系统演进。5G作为2020年商用移动网络的最大期待，承载了运营商多元化业务的关键使命。而MEC作为5G业务边缘部署的最佳载体，是运营商基于5G网络进一步扩展IT业务的必然选择。本文分析 MEC 参考架构，阐述了 MEC in 5G的关键问题，并提出了相应的解决方案，为 5G边缘业务商用添砖加瓦。参考文献：
［1］ 中国联通 . 中国联通 Edge-Cloud 平台架构及产业生态白皮书［EB/OL］［. 2018-06-12］. https：//www.sdnlab.com/20563.html.
［2］ ETSI. Multi-access Edge Computing［EB / OL］.［2018-06-12］. https：//www. etsi. org / technologies-clusters / technologies / multi-access-edge-computing.
［3］ Mobile Edge Computing（MEC）；Radio Network Information API：ETSI GS MEC 012［S / OL］.［2018-06 -12］. https：//docplayer. net / 54282826-Etsi-gs-mec-012-v1-1-1.html.
［4］ Mobile Edge Computing（MEC）；Location API：ETSI GS MEC 013［S/ OL］［. 2018-06-12］. https：//docplayer.net/54282826-Etsi-gs-mec013-v1-1-1.html.
［5］ Mobile Edge Computing（MEC）；Bandwidth Management API：ETSI GS MEC 015［S / OL］.［2018-06-12］. https：//docplayer. net / 54282826-Etsi-gs-mec-015-v1-1-1.html.
［6］ System Architecture for the 5G System；Stage 2：3GPP TS 23.501［S/ OL］.［2018-06-12］. http：//www.3gpp.org/DynaReport/ 23-series.htm.
［7］ Procedures for the 5G System；Stage 2：3GPP TS 23.502［S / OL］.［2018-06-12］. http：//www.3gpp.org/DynaReport/23-series.htm.
［8］ Policy and Charging Control Framework for the 5G System；Stage 2： 3GPP TS 23.503［S/OL］.［2018-06-12］. http：//www.3gpp.org/DynaReport/23-series.htm.
［9］ Common API Framework for 3GPP Northbound APIs；Stage 2：3GPP TS 23.222［S/OL］［. 2018-06-12］. http：//www.3gpp.org/DynaReport/ 23-series.htm.
［10］ Multi-access Edge Computing（MEC）；Phase 2：Use Cases and Requirements：Draft GS MEC 002［S/OL］［. 2018-06-12］. https：//www.artesyn.com/computing/products/mec-multi-access-edge-computing.
［11］ Cloud Native Computing Foundation. Kubernetes［EB/OL］.［2018-06-12］. https：//kubernetes.io/.
