ETSI MEC — 面向边缘计算的 5G 增强技术探讨
Posted 范桂飓
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ETSI MEC — 面向边缘计算的 5G 增强技术探讨相关的知识,希望对你有一定的参考价值。
目录
文章目录
面向边缘计算的 5G 增强技术探讨
结合 ETSI MEC 定义的内容,3GPP 标准从 5G 网络架构设计之初就考虑了对边缘计算的支持,同时在后续演进版本中不断增强。
- Rel15 版本定义了支持业务连续性的 3 种模式,支持边缘计算的会话管理架构,支持本地分流(UL/CL、BP 和 LADN);
- Rel16 版本针对业务场景对边缘计算的技术点进行改进,如支持 URLLC 业务;
- Rel17 版本建立了边缘计算特性增强项目,重点研究边缘业务发现、应用迁移以及如何高质量地为边缘应用平台提供所需的网络信息等内容,目前诸多解决方案还在持续讨论之中。
边缘应用服务器(EAS)
TR 23.748 中给出了 5GC 与多个 EAS(边缘应用服务器)的网络架构假设,根据网络中是否存在分流 ULCL/BP,5GC 提供三种保持业务连续性的模式来支持多边缘计算环境:
-
分布式锚点:PSA 在网络中移动到很远的地方,即本地站点。对于所有的用户 PDU Session 的流量都是一样的。重新锚定(ssc# 2、ssc# 3)在移动长距离时优化所有应用程序的流量路由。
-
会话分流。PDU Sesson 在中心站点中有一个 PSA,在本地站点中也有一个 Local PSA。其中只有一个提供 IP 锚点。利用 ULCL/BP 技术,将边缘计算应用流量选择性地转移到 Local PSA。重新锚定 Local PSA 锚点在用户移动时为本地分流的流量优化流量路由。
-
多 PDU 会话。边缘计算应用程序使用本地站点中带有 PDU 会话锚点的特定 PDU 会话。其余的应用程序使用带有中心 PDU 会话锚的 PDU 会话。应用程序和 PDU 会话之间的映射由 URSP 规则控制。
5GC 网络架构支持多边缘应用平台存在四种情况:
- UE 对 MEC 无感知。
- UE 感知 MEC。
- UE APP 无感知 MEC。
- UE APP 感知 MEC。
UE APP 可以同时使用多个边缘计算平台提供的差异化业务,而无需感知特定的边缘计算环境。多边缘计算环境可以由网络运营商建设管理,也可以由第三方控制,可以连接到多个 PLMN,可以与中心网络没有任何连接。
针对这种多种不同边缘应用平台的场景,5G 边缘计算增强项目提出了以下关键问题。
边缘应用服务器(EAS)的发现机制
在边缘计算部署中,UE 的数据业务可能由部署在不同站点的多个 EAS 提供服务。承载相同业务的这些 EAS 实例可以使用单个 IP 地址或不同的 IP 地址。UE 开始连接到服务之前,需要发现一个合适的边缘服务器 IP 地址,这样 UE 的业务流量可以通过 ULCL/BP 分流到边缘应用服务器。业务时延、路由线路以及用户体验都可以得到优化。此外,当 UE 移动到很远的地方时,边缘应用程序服务器将不再是最优化的,可以使用新的边缘应用程序服务器代替旧的边缘应用程序服务器来为 UE APP 服务。
边缘应用服务器的重新选择可以由 5GS 或应用层中的事件触发。在第一种情况下,它可以由网络发起的用户平面变化如移动事件切换、或者一次失败事件触发;第二种情况下,可以由于 EAS 可能变得拥塞或不可用触发。这取决于 UE 上的业务是否能够容忍 EAS 的更改。为了更好地支持有效地发现 EAS,5G 网络还需要研究以下几个方面的内容:
- UE如何发现合适的边缘应用服务器;
- 考虑 UE 需要感知或者不感知边缘主机环境中有应用服务器的场景;
- 使用什么信息可以辅助这样的发现机制;
- 通过这样的发现机制可以发现有关 EAS 的哪些额外信息。
当 EAS 变得非最优或不可用时,如何支持 UE 重新发现边缘应用服务器,是否需要确保边缘应用服务器的发现与 PSA UPF 的选择和重新选择共同进行,如果需要,如何实现都是本文将要探讨的问题。所有的解决方案都是基于现有的机制如:DNS、SFC 技术或者行业实践,以避免或至少最小化对业务的影响。EAS 发现机制不会将网络运营商限制在特定的边缘平台上,这样可以更好地适用于任何边缘主机模型,所有的解决方案中如果使用 DNS,要考虑业务同时使用不同 PSA 的场景。
应用迁移,EAS 重定向,业务连续性保障
随着边缘计算在 5G 系统中的部署,需要考虑 UE 移动性和应用服务器的重定向。例如,当 UE 在跨 5G 系统中移动时,UE 位置会发生变化,需要网络和边缘来处理 UE 位置的变化。UE 移动性和应用服务器重定向的主要场景如下:
-
业务边缘应用服务器的改变,例如:由于服务边缘应用服务器变得拥塞或处于停机状态。假设 EAS 的 IP 地址改变了。业务边缘应用服务器的改变,例如:由于服务边缘应用服务器变得拥塞或处于停机状态。假设 EAS 的 IP 地址改变了。根据 UE 的位置改变 DNAI 以便更好地服务于 UE。这可能意味着 EAS 的 IP 地址发生了变化,但在某些情况下,只要 UE 事务没有结束,就可以保留旧的 EAS。
-
上述情况下,如何保证用户业务的连续性是网络需要考虑解决的问题。实际的解决方案需要考虑触发机制,EAS 的重新寻址,EAS 的无缝切换等关键过程。
网络向本地边缘应用平台快速提供网络信息
EAS 需要与 5GS 进行交互才能访问网络信息或者向 5GS 提供信息以保证业务的连续性,5GS 与边缘计算功能之间需要公开交互的信息一直都是研究的焦点。作为研究的一部分,需要考虑网络开放的时延。目前 5GS 网络开放机制基于 NEF 以及 AMF、SMF、PCF 等控制网元,对于部署在边缘主机环境中的应用程序,边缘应用程序服务器或应用程序功能可以在本地部署,而一些控制网元例如:NEF/PCF 可能集中部署,这导致了较长的网络信息开放时延。对于一些需要开放的网络信息,较长的开放时延是不能容忍的,但是一些实时网络信息,如网络拥塞或者实时的用户路径时延频繁变更,如果需要及时将这些信息传递给应用服务器或应用程序功能,不希望出现的延迟可能会使这些信息过时,从而导致 UE 会根据过时的网络信息调整其行为,例如:调整视频流的分辨率或驱动自动化的切换级别。需要在网络和 AF 之间快速交换的 QoS 信息主要包括以下两点:
- 可以订阅接收 QoS 拥塞条件的通知;
- AF 可以请求 5GS 来监视 QoS 状态,例如:空口或端到端数据路径,并接收 QoS 测量报告。
网络还需要研究以下几点,来确定 5GS 向边缘平台的应用传递信息:
- 5GS 如何确定是否需要以低延迟公开网络信息;
- 如何向部署在边缘中的应用程序公开网络信息且延迟较低;
- 当 UE 移出支持开放的网元覆盖范围时,是否维持开放以及如何维持开放。
关于 EAS 发现机制的解决方案
针对多个边缘服务器发现机制,目前有多种方案在探讨中。
将 URSP 配置给 UE,为边缘应用业务建立 PDU 会话
在当前的研究架构中,UE 需要与应用业务建立有特定特征的连接,例如:到特定的切片或专用数据网(DN)或 SSC#2、SSC#3,5GC 在 PDU 会话建立过程中需要根据 UE 的位置以及相应的业务需求为 UE 提供合适的 EAS 接入。为了使 EAS 的发现机制更准确,使得合适的 PDU 会话与选定的 EAS 通信,5GC 可以提供包含 URSP 规则组成的策略配置,URSP 规则可以由 UE 本地配置,也可以在配置更新过程中提供,在初试注册或者移动更新注册时,UE 可以包含相应的策略容器,以便从 5GC 接收 URSP 规则。此外,为了更新由于 UE 迁移而产生的 URSP 规则,应用程序功能(AF)需要从 5GC 订阅 UE 位置信息。
此种方案需要对 AF 功能进行相应的增强,以便 AF 能够根据 URSP 规则在会话基础上配置边缘业务参数,如:在 AF 请求中包括 FQDN 或者 EAS 的 IP 地址列表。而 PCF 需要基于 AF 请求的信息决策 URSP 规则,如 EAS IP 地址或者 FQDN 以及标准的位置。
URSP 配置流程如下,基本的注册流程参照 TS23.502 执行。
首先,AF 的应用层通过 NEF/PCF 提供边缘应用流量的策略需求,在策略适用的地方可以指示位置信息。当 UE 执行注册时,UE 在注册请求中应包含 UE 策略容器。AMF 根据 UE 策略容器决定与 PCF 建立 UE 策略关联。PCF 依据 UE 的位置信息以及策略签约信息执行 UE 配置更新流程来为 UE 提供 URSP 规则。
PCF 基于 AF 请求的策略来决定 URSP 规则。URSP 规则包含 DNN、S-NSSAI 以及相关的用来匹配边缘应用流量的网络参数,例如:从安装在 UE 上的边缘应用程序客户端到边缘应用程序服务器的流量。如果 AF 在策略请求中携带一个或多个位置信息,PCF 在 URSP 规则的 RSD 部分中也会包含相应的位置信息。PCF 可以为特定边缘 DN 使用 URSP 规则中的特定的策略子句,灵活配置,使得 UE 更准确地接收 EAS 相关信息,及时准确地执行 EAS 发现。另外,网络运营者还可以在 UE 本地配置 URSP。当 UE 需要发送业务到边缘应用时,UE 通过发送针对边缘服务 FQDN 的 DNS 查询来触发 EAS 发现。URSP 规则还可以根据位置做多种不同的配置,使得 UE 在不同位置可以应用不同的规则。
基于本地 DNS 的边缘服务器地址
边缘计算服务的业务区域包括本地业务区域列表下图所示的本地业务区域 1 和本地业务区域 2。由于边缘计算服务是由不同的边缘服务器在不同的本地业务区域提供的,DNS 可以在本地进行授权部署,为本地业务区域的边缘服务器提供地址查询服务。在 PDU 会话建立过程中,通过 ePCO 将本地 DNS 提供给 UE。
此种方式分三种场景,执行 EAS 发现:
首先在 UE 需要使用边缘应用业务,而 UE 又恰好在 EC 服务的本地区域时,UE 将触发 PDU 会话建立过程,SMF 将根据 UE 的位置,为 UE 配置一个本地 DNS 地址,DNS 地址可以通过 PDU 建立过程中 ePCO 提供给 UE。如果所请求的 FQDN 没有存储 IP 地址,则应用客户端调用 UE 内核来触发一个 DNS 请求,此请求使用 FQDN 从网络获取 DNS 地址。本地 DNS 发送 DNS 地址响应,包含与请求的 FQDN 对应的边缘服务器地址给 UE,UE 存储 DNS 查询记录,包括 FQDN 和相关的 IP 地址。
另外两种场景分别是在 ULCL/BP 场景下提供本地 DNS 服务器地址以及在 SSC#2 或者 SCC#3 场景下提供本地 DNS 服务器地址,流程上都是通过 PDU 会话建立或者修改过程,从 SMF 获得相应的边缘服务器地址信息。此种方式需要 SMF 能够基于 UE 的位置信息为 UE 配置本地 DNS 地址。
DNS AF
此方案以支持 “会话分流” 连续性模型以及为边缘计算动态插入本地 PSA 技术点为前提。运营商将部署一个新的 DNS 组件,这个组件被称为 DNS AF,它被部署在 NAT 之前的移动网络中。DNS AF 拥有一个转换表,它将给定的用户位置和应用程序 FQDN 映射到首选的 PDU 会话锚点中,包括 DNAI 和完整 IP 地址的信息,它还具有 IP 地址范围,UE 可以与 AF(s) 通信时使用这些 IP 地址。
DNS AF 参与边缘服务认证 UEs 的 DNS 通信,例如,在 PDU 会话建立时,SMF 将 DNS AF 地址发送给 UE。DNS AF 接收与 EAS 相关的 UE DNS 请求,授权 UE,获取 UE 位置信息,并优先为该 UE 确定至少一个合适的本地 PSA。5GC 通过向 DNS 请求添加相应的 N6 访问位置或将 DNS 请求转发到服务于 UE 位置的 DNS 来帮助发现最适合 PSA 的应用服务器。在此阶段,由业务提供者选择与给定位置匹配的合适 EAS。业务提供者可以使用 ECS 选项将信息反馈给移动网络,以确定选择是否根据所提供的信息进行了调整。然后核心网插入 ULCL 并相应地设置业务流量控制。
基于 DNAI 的 SMF/I-SMF 插入
此解决方案既适用于会话分流连接模型,也适用于多个 PDU 会话连接模型。在这个解决方案中,假设 DNS 服务器部署在边缘主机环境中。DNS 服务器用于在边缘主机环境中发现EAS。利用 AF 影响流量机制来激活面向边缘主机环境的流量路由。AF 请求信息作为数据集存储在 UDR 中,通过 UDR->PCF->AMF->SMF(I-SMF)过程,传递给 AMF,AMF 可以根据请求的 DNAI(s) 选择 SMF 或 I-SMF。SMF 最后将 I-UPF 配置为 DNS 查询消息路由到边缘主机环境。AF 流量影响请求信息包括 FQDN 或 DNS 服务器地址。SMF 配置 I-UPF,因此当 UE 使用目标 FQDN 或目标 DNS 服务器地址发送 DNS 查询时,I-UPF 可以将 DNS 查询消息路由到边缘主机环境中的 DNS 服务器,以发现 EAS IP 地址。
除了上述几种解决方案,还有诸如 DNS 认证服务器提供关于 UE 位置的 IP 寻址信息、使用 DNS 和 IP 路由的服务器发现、基于 DNS 的 EAS 发现等多种 EAS 发现机制也在 Rel17 中给出了探讨,这里将不做更多的讨论。
以上是关于ETSI MEC — 面向边缘计算的 5G 增强技术探讨的主要内容,如果未能解决你的问题,请参考以下文章
LTE-5G学习笔记23--5G及移动边缘计算(MEC)学习笔记