面向边缘微服务迁移的5G核心网协议定制研究.pdf

技术热点Technical Focus2023 年第 9 期http:/751 引言MEC(Mobile Edge Computing)是 一 种 基 于 移动通信网络的分布式计算方式，是 5G uRLLC(ultra Reliable Low Latency Communication，uRLLC)场景中的重要设施1。在 5G 边缘计算场景中，UE 可以向部署在不同节点的边缘应用服务器(Edge Application Server，EAS)发起服务请求，不同节点的边缘应用服务器 EAS IP 可能不同。当 UE 快速移动到较远的地方时，用户与提供服务的边缘计算节点之间的距离变大，通信成本会逐渐增加，当前的 EAS 可能不再是最佳选择。本文采用服务迁移的方法，将服务从原有 EAS节点迁移至最近的 EAS 节点。但迁移完成后，如何在服务迁移到新 EAS 后，核心网能够将 UE 目标地址仍为原 EAS 的 UE 访问流透明转发到新 EAS 的服务，实现 UE 无感情况下的服务访问连续性以及 UE请求的就近低时延服务将是新的难点。本文在总体满足现有协议规范和不改造终端的基础上，提出了一种面向边缘微服务迁移的 5G 核心网协议定制方案(以下简称“定制方案”)，着重关注以下方面：在尽可能兼容 3GPP 5G R17 标准规范基础上，通过对用户面功能(User Plane Function，UPF)、会话管理功能(Session Management Function，SMF)等网元功能及其服务接口进行适当扩充，实现了微服务迁移后 UE 仍可利用原有服务地址透明访问编辑：贾静宇E-mail:中山大学系统科学与工程学院 崔俊浪 周传凯 蔡艺培 范文扬 李 刚 张 涛Research on Customization of 5G Core Network Protocols for Edge Microservice Migration摘 要 针对现有 5G 核心网协议对边缘微服务实时热迁移支持能力的不足，提出一种面向边缘微服务迁移的5G 核心网协议定制方案。指出了现有 5GUE 移动场景下的连续性保持研究在应用普及、5G 标准协议提供支持以及方案完整性等方面的不足之处，着重介绍了面向边缘微服务迁移的 5G 核心网协议定制方案的流程及系统架构，并对方案进行测试验证。结果证明本方案可使用原微服务 IP 地址对迁移后的微服务进行正常访问，在保证服务连续性的情况下支持边缘微服务迁移。关键词 5G 网络 边缘服务 服务迁移 协议定制Abstract:In response to the shortcomings of existing 5G core network protocols in supporting real-time hot migration of edge microservices,this paper proposes a customized 5G core network protocol solution for edge microservice migration.This article points out the shortcomings of the existing research on continuity maintenance in 5G UE mobile scenarios in terms of application popularization,5G standard protocol support,and scheme integrity.It focuses on introducing the process and system architecture of the 5G core network protocol customization scheme for edge microservice migration,and tests and verifies the scheme.The results show that this scheme can use the original microservice IP address to access the migrated microservices normally,and support edge microservice migration while ensuring service continuity.Keywords:5G network;edge services;service migration;protocol customization面向边缘微服务迁移的 5G 核心网协议定制研究技术热点Technical Focus信息技术与标准化http:/76微服务的功能。基于 Free5GC 和 UERANSIM 等开源软件2-3，验证了定制方案的可行性。2 5GUE 移动场景连续性保持现有研究不足2.1 MEC 计算卸载不足计算卸载是 MEC 的关键技术之一，ETSI 规定：MEC 计算卸载是将应用部署在终端，由 UE 主动发起4，使用合理的卸载决策和资源分配策略，将计算任务从终端卸载到边缘网络的关键技术。但该方法仍是 UE 侧主动发起卸载需求，无论是改进后的卸载策略还是资源分配方案，都对 UE 性能提出了新的要求，这对于类型众多、处理能力各异的 UE 而言，技术难度和改造成本都很大，离正式普及还有很长一段距离。2.2 5G 标准协议提供支持不足为确保在 UE 移动时能及时获取 UE 位置信息并保持数据传输的不中断，5G 核心网络需要对 UE实施移动性管理。在移动性管理功能(Access and Mobility Management Function，AMF)的跟踪下，核心网络根据 UE 订阅信息、位置信息和本地策略来决定对 UE 的服务策略。此外，在 5G 上行分流场景(Uplink Classifier，ULCL)中，中间 UPF(Intermediate UPF，I-UPF)支持基于 SMF 提供的流量检测和流量转发规则，并向不同 PDU 会话锚点 UPF(Protocol Data Unit Session Anchor UPF，PSA)转发上行数据流，从而将业务流分流至不同 MEC 节点5。针对 UE 在多个小区之间快速切换的情况，TS 23501 System architecture for the 5G System 对 UE 的路由寻址6，事件管理和如何支持 ULCL 分流场景做出了简要说明；TS 23502 Procedures for the 5G System 详细说明了由于用户移动带来的 PSA 重定位、用户平面变更管理步骤7；TS 23725 Study on enhancement of uRLLC support in the 5GC 简要阐述了移动场景下 5G网络如何进行用户平面管理8，以保持用户平面服务不中断；TS 22937 Requirements for service continuity between mobile and WLAN 规定了移动网络之间的服 务 连 续 性 要 求9；TS 22831 Study on Support for Minimization of Service Interruption 和 TS 24811 Study on the support for minimization of service interruption 则探讨了如何减少用户移动带来的服务中断时延10-11。尽管以上规范均规定了 5G 网络如何维持移动用户的服务连续性，但并没有充分结合 MEC 场景进行深入讨论。2.3 5GMEC 移动场景服务迁移方案不足为进一步探讨 5G MEC 移动场景，TS 23748 Study on enhancement of support for Edge Computing in 5GC针对边缘服务器(Edge Application Server，EAS)的发现以及终端移动性导致的边缘服务器重定位，提出了两种粗略的方案建议12。如图 1 所示，一种方案是通过 UPF 中继，将数据流转发至原始边缘服务器上，但此方案需要不断进行转发操作，导致较大通信时延和路由成本。另一种方案则提出了一种边缘服务迁移方案，但该方案没有形成具体的端到端解决方案，对实际 5G 边缘服务迁移场景下的工程应用所提供支持还不够。ETSI 在报告中详细说明了 MEC 系统参考架 构13，并在相关标准中指出：服务迁移是解决 UE移动引起的 QoS 下降问题的重要方法之一14，然而该方法的实现仍存在一些技术挑战，例如现有 MEC平台仍不具备服务动态迁移能力。3 面向边缘微服务迁移的 5G核心网协议定制方案本文在基于现有标准协议不足的基础上，提出了一种面向边缘微服务迁移的 5G 核心网协议定制方案，从而解决了由于用户快速移动带来的时延增加问题，实现了在 5G 系统侧支持 UE 无感情况下的边缘服务迁移，并保持了 UE 与边缘微服务之间的TCP 连接。3.1 移动场景下 UE 移动信息更新UE 的移动限制和服务区限制是由核心网和 PCF技术热点Technical Focus2023 年第 9 期http:/77共同决定的。为满足 UE 需求，移动限制和服务区限制都可以基于订阅信息、位置信息和网络策略等因素进行调整，以提供更符合 UE 需求的高质量网络服务。5G 核心网中 AMF 网元支持跟踪和上报 UE 移动事件，其他网元可以向 AMF 申请订阅 UE 的位置服务，并进行策略更新和信令交互。如满足订阅要求，AMF 会向订阅的其他网元发送 UE 位置事件消息。3.2 面向边缘微服务迁移的 5G 核心网协议定制方案流程当用户服务未迁移时，用户平面通过 ULCL 和PSA 之间的 N9 隧道路由中继，将用户访问流转发到原 EAS，用户可以访问旧 EAS1 上的服务，以支持会话连续性。假设用户已经完成了边缘服务访问和 PDU 会话建立，用户移动时，首先利用 UPF 之间的路由中继进行服务访问连接保持，以保持会话连续。当用户继续移动，且 AF 判决服务迁移有效时，具体边缘服务迁移方案流程如图 2 所示，其中红色标识部分是本节为支持服务迁移时扩展的接口：(1)AMF 将 UE 位置信息，发送给所订阅的 AF。(2)SMF 通过调用 Nsmf_EventExposure_Notify 服务操作，向 NEF 发送 T-PSA、用户永久标识符、UE IP、T-PSA 的 DNAI 等信息，指示用户平面路径更改完成，并指示 5GC 支持 EAS IP 替换能力。(3)NEF 收到 Nsmf_EventExposure_Notify 后，根据UE 通用公共用户标识、T-PSA 的 DNAI 查找 UE PDU会话的应用状态信息，并通过 Nnef_EventExposure_ Notify 将应用状态信息发送给 AF。(4)AF 根据新的 DNAI 选择新的 T-EAS2，并从接收到的应用状态信息中检索对应应用。此后，AF将考虑基于设定的迁移策略，进行服务迁移，并通知 S-EAS1 和目标 T-EAS2 做好迁移准备。(5)AF 指示 S-EAS1 和 T-EAS2 节点利用 CRIU进行服务迁移，迁移完成后，T-EAS2 将响应 AF 迁移完成，此后 AF 通知 NEF 迁移完成。(6)AF 向 SMF 发 送 Nnef_TrafficInfluence_App RelocationInfo，此消息通过 NEF 发送，包括 N6 接口对 T-EAS2 的流量路由信息、所选择的目标 DNAI、图 1 TS23748 服务迁移方案技术热点Technical Focus信息技术与标准化http:/78S-EAS1 IP 和 T-EAS2 IP。(7)基于目标 DNAI 和步骤(6)中接收到的信息，SMF 在 T-ULCL 上通过 N4 接口，配置新的流量转发规则，引导应用流量进出目标应用服务器。目标地址为 T-EAS2 IP 的上行数据流将被直接转发到T-PSA2，若目标地址仍为 S-EAS1 IP，则进行目标地址替换。(8)T-ULCL 开始更新并执行步骤(7)中的规则。由于迁移过程对用户是透明的，终端仍使用 S-EAS1 IP 作为目标地址，T-ULCL 利用 DNAT 将目标地址替换为 T-EAS2 IP。T-EAS2 对服务访问做出应答后，使用 T-EAS2 IP 作为源地址发送下行数据，下行数据流到达 T-ULCL 后，将源地址替换为 S-EAS1 IP 地址。(9)T-ULCL 对以上规则更新进行回复，更新后的用户平面可支持用户顺利访问 T-EAS2 节点的服务，具体用户平面访问流程如图 2 黄色箭头所示。(10)最后，SMF 释放旧的 S-ULCL 和 S-UPF。基于以上内容，本节对网元定制内容如下：首先通过定义原有 UPF 网元，使其支持 N9Session EstablishmentRequest 构建 UPF 之间的 N9 转发通道，从而构建 5G ULCL 分流场景。然后 SMF 和 AF 基于 Namf_EventExposure_Subscribe Request 向 AMF 订阅用户移动信息，当检测到用户移动到 MEC2 服务范 围 后，SMF 通 过 N4 Session Establishment Request与 PSA2 建立 N4 会话，利用 N4 Session Modification Request 更改 ULCL-UPF 上的路由转发策略。用户目的地址为 EAS1 的访问流，通过 UPF 之间的 N9 路由中继对 Docker1 进行访问。当 AF 判决服务迁移且迁移完成后，通过 Nsmf_EventExposure_AppRelocation Info 将迁移完成信息告知 SMF，SMF 通知 ULCL-UPF 进行地址转换，改造后的 ULCL-UPF 具备地址转换能力，最后 UE 目标地址为 MEC1 的信息流能够顺利访问迁移后 MEC2 上的服务。3.3 面向边缘微服务迁移的协议定制系统架构基于 3.2 节中的协议定制方案，本节设计了基于边缘微服务迁移的协议定制系统架构，可将定制方案应用于 5G MEC 系统架构中，如图 3 所示，红色标注为方案中所要扩充的网元。首先默认用户在 MEC1 服务区间内创建 PDU 会话，SMF 会为 UE分配 IP 地址。UE 通过该地址，建立 RAN-ULCL-图 2 面向边缘微服务迁移的 5G 核心网协议定制方案流程图技术热点Technical Focus2023 年第 9 期http:/79PSA1-MEC1 用户平面会话通道，访问 MEC1 上的Docker1 容器服务。当用户跨小区移动后，AMF 将用户位置信息发送给订阅的 SMF 和 AF，SMF 会与PSA2 建立 N4 会话通信，以提前打通用户平面 UE-RAN-ULCL-PSA2-MEC2 通信链路。AF 决定服务迁移后，容器服务从 MEC1 迁移至 MEC2 节点，原MEC1 停止服务，此时 ULCL 收到 SMF 指示，开始进行目标地址转换。图 3 面向边缘微服务迁移的协议定制系统架构图图 4 5G 边缘服务迁移系统原型架构图4 测试验证4.1 环境构建由于 5G 新架构具有更大的灵活性和开放性，在本节的实践框架中，使用开源平台 Free5GC v3.2.1 搭建 5G 核心网。UERANSIM 是开源 5G UE 和 RAN 模拟器。图 4 为本文所构建的 5G 边缘微服务原型系统架构，整个系统原型运行在 8 台 4 G 内存、20 G 硬盘容量的 VMware 虚拟机当中，操作系统为 Ubuntu 20.04。本文将 UE 用户的用户平面从 PSA1 切换到PSA2，来模拟用户移动场景。用户移动后，AF 将对服务迁移进行决策，将容器迁移至 MEC2 节点。SMF 将进行 N4 会话修改，ULCL 进行地址替换，使得用户目的地址为源 MEC1 节点的访问流能顺利转发到 PSA2 节点并访问 MEC2 上的服务。技术热点Technical Focus信息技术与标准化http:/804.2 协议改造兼容性测试当 用 户 在 PSA1 服 务 范 围 内 时，UE 首 先 向Free5GC 核 心 网 发 起 注 册，SMF 与 ULCL-UPF、PSA1 建立 N4 会话，用户成功建立 PDU 会话，并将用户平面数据通道打通，系统日志如图 5 所示。由于 SMF 向 AMF 订阅了用户位置信息，当 UE图 5 UE 建立 PDU 会话图 6 ULCL 上 N4 规则更新图 7 ULCL-UPF 完成地址转换移动至 PSA2 节点服务范围，图 6 中 SMF 通过 N4 会话更新相关策略为服务迁移提供支持。当 UE 访问的容器服务迁移到新节点后，在ULCL 上进行地址转换，将包的目的地址改为 MEC2 IP 地址，使得用户能成功访问到 PSA2 节点的 MEC2上的容器服务，实现 UE 无感情况下的访问保持，图 7 为在 ULCL 上的抓包结果。结果表明，定制方案能够兼容 3GPP 现有标准规范，与标准网元进行对接，实现 UE 的正常通信，并通过网元配合和地址转换，在保持 UE 与边缘微服务之间的 TCP 连接基础上，支持 UE 跨节点移动时的服务迁移。4.3 微服务迁移能力测试本节的测试内容是通过用户客户端访问 Cluster1集群内的视频服务，当用户从 Cluster1-Node1 服务范围移动至 Cluster1-Node2 服务范围时，将用户正在访问的服务迁移到 Cluster1-Node2 节点上，并继续为用户提供服务。图 8 和图 9 结果表明，本文所提协议定制方案能够在符合 3GPP 现有规范前提下，通过 5G 核心网元配合，当用户跨小区快速移动时，将微服务迁移至最合适节点，具有一定的工程应用性。技术热点Technical Focus2023 年第 9 期http:/81图 8 源 videoPod 部署信息图 9 源端清理时 Pod 状态5 结语本文针对现有 5G 核心网协议对边缘微服务实时热迁移支持能力的不足的问题，提出了一种面向边缘微服务迁移的 5G 核心网协议定制方案，在对3GPP 标准规范进行少量扩充的基础上，对 SMF、UPF 等标准网元进行少量定制，实现了在保证服务连续性的情况下进行边缘微服务迁移，用户仍可使用原微服务地址对迁移后的微服务进行正常访问。对于未来工作，本文所定制的标准协议虽然可支持有状态服务动态迁移，但还需接入更完善的MEC 平台进行系统测试验证，并在后续研究中考虑如何缩短迁移时延。参考文献1 JIANGK,ZHOUH,CHENX,etal.Mobileedgecomputingforultra-reliableandlow-latencycommunicationsJ.IEEECommunicationsStandardsMagazine,2021,5(2):68-75.2 NYCU.Free5GCEB/OL.2023-08-15.https:/www.free5gc.org/.3 Aligungr.UERANSIMGitHubrepositoryEB/OL.2023-08-15.https:/ ETSI.Multi-accessEdgeComputing(MEC):Phase2UseCasesandRequirements:ETSIGSMEC022V221S.Nice:ETSI,2022.5 3GPP.Architecture for enabling EdgeApplications:3GPPTS23558S/OL.2023-08-15.https:/www.3gpp.org.6 3GPP.Systemarchitectureforthe5GSystem(5GS):3GPPTS23501S/OL.2023-08-15.https:/www.3gpp.org.7 3GPP.Proceduresforthe5GSystem(5GS):Stage2:3GPPTS23502S/OL.2023-08-15.https:/www.3gpp.org.8 3GPP.StudyonenhancementofUltra-ReliableLow-LatencyCommunication(URLLC)supportinthe5GCorenetwork(5GC):3GPPTR23725S/OL.2023-08-15.https:/www.3gpp.org.9 3GPP.RequirementsforservicecontinuitybetweenmobileandWirelessLocalAreaNetwork(WLAN)networks:3GPPTR22937S/OL.2023-08-15.https:/www.3gpp.org.103GPP.TechnicalSpecificationGroupServicesandSystemAspects:StudyonSupportforMinimizationofServiceInterruption:3GPPTR22831S/OL.2023-08-15.https:/www.3gpp.org.113GPP.Studyonthesupportforminimizationofserviceinterruption:3GPPTR24811S/OL.2023-08-15.https:/www.3gpp.org.123GPP.StudyonenhancementofsupportforEdgeComputingin5GCorenetwork(5GC):3GPPTR23748S/OL.2023-08-15https:/www.3gpp.org.13ETSI.ETSIWhitePaperMECin5GnetworksEB/OL.2023-08-15.https:/www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf.14ETSI.Multi-accessEdgeComputing(MEC):ApplicationMobilityServiceAPI:ETSIGSMEC021V221S.Nice:ETSI,2022.(收稿日期：2023-08-16)