基于5GC 关键技术的 MEC 边缘计算(中)

此系列文章作者分为上中下三部分进行阐述,本文主要分享中部分内容,大纲简述如下:

MEC 与 5G 融合
MEC 接入 5GC 的方式
MEP 的服务开发框架

上部分内容概要:

ETSI MEC 标准化参考模型
MEC 架构设计原则
ETSI MEC 存在的问题

下部分内容概要:

MEC 部署场景
MEC 在 4G 网络中的部署
MEC 在 5G 网络中的部署
MEC 应用场景

1、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 应支持如下功能:

1、在 PDU Session 建立时,5GC 为用户选择部署在用户接入侧的 UPF。

2、支持业务的本地路由,由于 5GC 支持用户通过多个 UPF 获取服务的模式,用户侧的 UPF 可以只负责本地业务, 用户发起的其他远端服务将由其他 UPF执行。

3、流量引导功能,当存在多种本地业务时,区分业务类型并将流量引导到本地应用服务器。

4、保持会话和业务的连续性,确保业务体验。

5、支持 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 相当于应用控制器的角色,提供应用与网络控制面之间的交互。

2、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。

基于5GC 关键技术的 MEC 边缘计算(中)

在 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 接口的差异性。

3、MEP 的服务开发框架

Mp1 作为 ME APP 获取 MEP 提供的 ME Services 的参考点,运营商除了无线接入网能力服务之外,还有核心网能力服务也需要开放给 ME APP。然而,随 Mp1 缺少计费、接入控制等标准定义,商用化并不完善。3GPP SA6 为了避免运营商网络能力服务开放框架的碎片化,正在 R15 阶段定义一个通用的 API 开放框架结构,即 Common API Framework for 3GPP Northbound APIs(CAPIF)。

基于5GC 关键技术的 MEC 边缘计算(中)

上图中,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 交互。

4、MEP 的南向接口

MEP 定义了 3 个与 5G 网络紧密关联的 ME Services,分别是无线网络信息服务、位置信息服务、带宽管理服务。ME APP 可以调用这些服务的 API 优化其性能或者提供新的业务。比如:位置服务可以提供用户室内定位,商业分析软件可以利用位置服务统计分析商场室内人员流动信息,进一步优化室内商铺业态。然而,MEC 目前并没有定义这些 ME Service 如何获取网络信息与能力。当 MEC in 5G 部署,并进一步扩展无线接入网络能力服务时,架构层面需要考虑这些接口。

3GPP 5G 系统架构中,核心网可以通过 NEF 向第三方 App 提供网络。NEF 对外提供 3 种能力:

1、监控网络状态
2、为外部应用提供诸如 UE 行为等信息
3、对外提供策略配置能力

对于 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 需要与基站直联,从而达到最高效的边缘性能协同。

基于5GC 关键技术的 MEC 边缘计算(中)

5G gBN 可以通过双向交互接口,直接向 MEP 开放无线接入网络信息以及基站策略控制能力。MEC Platform 通过 ME Service(或者说 Local NEF),向 ME APP 提供无线接入网络能力 API。

猜你喜欢

转载自blog.51cto.com/99cloud/2480090