51学通信

深度解析 3GPP TS 23.548：6.3 高级边缘重定位 (Part 5 - IP替换、无损缓冲与并发连接)

22分钟阅读

好的，遵从指令。我们继续深入剖析3GPP TS 23.548。在前几篇文章中，我们已经掌握了5G边缘计算的架构、核心发现机制以及基本的移动性管理。现在，我们将进入更高级、更精妙的领域，探索5G网络为了实现“零中断”的业务体验，所祭出的三大“黑科技”。

深度解析 3GPP TS 23.548：6.3 高级边缘重定位 (Part 5 - IP替换、无损缓冲与并发连接)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“6.3 Edge Relocation”章节下的多个高级主题，包括“6.3.3 Edge Relocation Using EAS IP Replacement”、“6.3.5 Packet Buffering for Low Packet Loss”以及“6.3.4 AF Request for Simultaneous Connectivity”。本文旨在为读者揭示5G系统为应对超低时延、高可靠（URLLC）等严苛边缘场景，所设计的三种高级重定位机制，它们共同的目标是——让业务在边缘节点间的切换，达到极致的平滑与无感。

我们已经知道，当“智行一号”在城市中穿梭时，5G网络可以通过发送EAS rediscovery indication来“建议”它重新寻找一个更近的边缘服务器。这个基于DNS的重发现机制虽然有效，但它仍然存在一些固有的“不完美”：

  • 应用层的参与： 它需要UE/应用清空DNS缓存并发起新的查询，这会引入额外的DNS解析时延。

  • 连接的中断： 对于TCP等有状态的连接，更换服务器IP地址意味着必须中断旧连接，再建立新连接。

  • 短暂的“真空期”： 在网络路径切换和应用寻找到新服务器之间，可能存在一个短暂的“真空期”，此时发出的数据包可能会丢失。

对于一般的边缘应用（如视频点播），这些影响可能微不足道。但现在，让我们升级“智行一号”的任务：它不再是简单的物流配送，而是正在通过一个机械臂，远程为城市管道系统执行一次精密的微创修复手术。此时，任何一次连接中断、任何一个数据包的丢失，都可能导致手术刀的抖动，造成不可估量的损失。

面对如此严苛的要求，基于DNS的重发现机制显得力不从心。5G网络必须拿出更强大的“杀手锏”。本篇文章，我们将聚焦于6.3节定义的三大高级重定位技术，看它们如何联手，为“智行一号”的远程手术保驾护航。

1. 终极障眼法：6.3.3 EAS IP地址替换 (EAS IP Replacement)

这是三种技术中最具颠覆性的一种，它试图从根本上让应用层对服务器的切换“完全无知”。

EAS IP replacement enables the Local PSA UPF to replace the source/old Target EAS IP address and port number with the target/new target EAS IP address and port number for the Destination IP address… and replace the target/new target EAS IP address… with the source/old Target EAS IP address… for the Source IP address… of the downlink traffic…

  • 深度解析： 这段话描述了一个令人惊叹的机制。它的本质，就是在L-PSA UPF上执行一次有状态的网络地址转换（NAT）。

    • 上行方向： 当UPF收到一个UE发往旧EAS（EAS_A）IP地址的数据包时，它会在数据包离开核心网之前，神不知鬼不觉地将目的IP地址修改为新EAS（EAS_B）的IP地址。

    • 下行方向： 当UPF收到一个从新EAS（EAS_B）发回给UE的数据包时，它会再次施展“魔法”，将源IP地址从EAS_B修改回旧EAS（EAS_A）的IP地址。

  • 对应用的影响： 在“智行一号”的远程手术应用看来，它的TCP连接自始至终都是与EAS_A建立的。它完全不知道自己的数据包在中途被“掉包”，飞向了另一台服务器。因此，TCP连接不会中断，应用层状态得以维持，实现了真正的网络层无感切换。

IP替换的触发与执行

这个“魔法”是如何施展的呢？我们通过Figure 6.3.3.1.1-1: Enabling EAS IP replacement procedure by AF来解读。

  1. 初始状态 (Step 1-3): “智行一号”与EAS_A（源EAS）正常通信，执行手术任务。

  2. 触发 (Step 4a/4b): 重定位被触发（可以由AF主动发起，也可以由5GC因UE移动而发起）。最关键的是，在这次AF influence请求中，AF会同时提供源EAS IP和目标EAS IP给SMF。

  3. 施法 (Step 5): SMF收到了这对“替换IP”后，它会向L-PSA UPF下发一条特殊的N4规则。这条规则的核心是一个包含了“IP Address and Port Number Replacement”信息单元的转发动作规则（FAR）。这条规则明确指示UPF执行上述的IP地址替换操作。

不可或缺的前提：应用层上下文传输

EAS IP replacement requires support of TCP/TLS/QUIC context transfer between EASs.

NOTE: The feasibility of this requirement… depends on whether third party platforms support an individual real time TCP/TLS/QUIC context transfer between EASs.

  • 深度解析： 5G网络只能替换数据包的“信封”（IP地址），但无法改变“信”里的内容（应用数据）和“信”的上下文（TCP会话状态、安全密钥、手术进度等）。

  • 因此，要使IP替换成功，一个绝对必要的前提是：在网络层切换发生之前，EAS_A必须已经将所有与“智行一号”手术相关的实时上下文，完整地、实时地同步给了EAS_B。

  • 当EAS_B开始收到被UPF重定向过来的数据包时，它必须能够像EAS_A一样，无缝地接续处理这些数据。这个应用层的上下文同步，是应用平台自身的责任，3GPP规范不定义其实现，但明确指出了其必要性。

  • 场景总结： 运营中心（AF）检测到“智行一号”即将移动，决定将其手术业务从EAS_A迁移到EAS_B。

    1. AF触发EAS_A和EAS_B之间进行实时的会话镜像。

    2. AF向SMF发起请求，提供EAS_A和EAS_B的IP。

    3. SMF指令L-PSA UPF启动IP地址替换。

    4. “智行一号”的TCP连接毫无波澜，远程手术刀的控制信号平滑地从由EAS_A处理，过渡到由EAS_B处理。一次“零中断”的完美切换完成。

2. 无忧的守护：6.3.5 低丢包的报文缓冲 (Packet Buffering for Low Packet Loss)

IP地址替换虽好，但它要求应用平台具备高级的上下文同步能力。对于更常见的、基于DNS重发现的切换场景，如何避免在切换窗口期的数据包丢失？报文缓冲机制应运而生。

This procedure aims at synchronizing between EAS relocation and UL traffic from the UE, ensuring that UL traffic from the UE is sent to the new EAS only when EAS context transfer has been carried out. It consists of buffering uplink packets in the target PSA…

  • 深度解析： 报文缓冲的核心思想是，在目标路径上的新L-PSA UPF（目标PSA）处，建立一个**“临时蓄水池”**。

  • 在应用层完成从旧EAS到新EAS的上下文迁移之前，如果UE已经通过DNS重发现拿到了新EAS的IP并开始发送数据，这些“心急”的数据包不会被直接丢弃，而是被新L-PSA暂时缓冲起来。

  • 直到新EAS向网络确认“我已准备就绪”，新L-PSA才会打开“闸门”，将缓冲的数据包按序发往新EAS，从而保证了数据的零丢失。

缓冲的协同流程

我们通过Figure 6.3.5-1: Packet buffering for low packet loss来理解这场精妙的时间协同。

  1. 申请缓冲 (Step 1 & 2): SMF决定将PSA从PSA1切换到PSA2。它会向AF发送一个**“早期通知(Early Notification)”**。AF收到通知后，回复一个“积极响应”，其中可以明确指示“我需要为目标DNAI的流量启动上行缓冲”。

  2. 建立蓄水池 (Step 3): SMF在向新的PSA2下发N4会话建立规则时，会附带一条指令：“请为来自该UE的上行流量启动缓冲”。

  3. 路径切换 & 流量入池 (Step 4 & 6a): SMF更新UL CL，将流量导向PSA2。同时，UE可能通过EAS rediscovery indication完成了重发现，并开始向新的EAS发送数据。这些数据包到达PSA2后，并不会被转发，而是被存入缓冲区。

  4. 应用层迁移 (Step 6b): 在网络路径切换的同时，应用层正在进行自己的上下文迁移（例如，EAS1将手术状态同步给EAS2）。这个过程独立于网络。

  5. 开闸放水 (Step 7 & 8): 当EAS2准备就绪后，AF会向SMF发送一个**“晚期通知(Late Notification)”的响应，告知“迁移完成，可以放行流量了”。SMF收到后，立即向PSA2发送N4修改指令，停止缓冲，并发送所有已缓冲的数据包**。

  • 场景总结： 在一次常规的DNS重发现切换中，“智行一号”很快拿到了EAS_B的IP并开始发送手术控制信号。这些信号首先到达了PSA2的“蓄水池”。几百毫秒后，EAS_B完成了状态同步，通知了网络。PSA2立刻“开闸”，将缓冲的信号按序发给EAS_B。对于EAS_B来说，它收到的信号流是完整且连续的，手术的平稳性得到了保障。

3. 应用的掌控：6.3.4 源与目标PSA的并发连接

IP替换让应用“无知无觉”，报文缓冲让网络“默默守护”。但还有第三种模式：赋予应用最高的**“知情权”和“控制权”**。

AF may issue a request to the network on whether to provide simultaneous connectivity over the source and the target PSA at edge relocation. This may trigger the SMF to use a re-anchoring procedure that provides simultaneous connectivity…

  • 深度解析： 这个机制允许AF向网络提出一个“高级请求”：在边缘重定位时，请不要立即拆除通往旧L-PSA的路径。我希望在一段时间内，同时拥有通往源L-PSA和目标L-PSA的可用数据路径。

  • 如何实现？ AF在请求中包含一个**"Keep existing PSA" indication**。SMF收到后，会采用特殊的重锚定流程（如TS 23.502中定义的Simultaneous change of Branching Point...），在建立新路径（通往目标L-PSA）的同时，通过定时器等机制，维持旧路径（通往源L-PSA）在一段时间内的可用性。

并发连接的价值

…if connectivity over the former PSA is maintained for some time, each application can schedule EAS relocation to suit the application specific needs without interfering with the other applications.

  • 深度解析： 拥有两条并发路径，为应用层带来了极大的灵活性：

    • 应用自主决定切换时机： “智行一号”上的手术应用，可以先通过新路径与EAS_B建立连接、完成所有上下文同步和健康检查。然后，它可以等待一个最佳的切换时机（例如，一个手术动作的间歇期），再主动将数据流从旧连接切换到新连接，最后优雅地断开与EAS_A的连接。

    • 多应用独立迁移： 如果“智行一号”上同时运行着远程手术和高清视频监控两个应用，并发连接允许手术应用先完成自己的“高精度”切换，而视频监控应用可以稍后再进行切换，两者互不干扰。

  • 场景总结： 网络为“智行一号”同时开通了通往A区和B区的路径。手术应用软件通过B区路径与EAS_B“悄悄”建立联系，并将会话状态迁移过去。在机械臂完成一次切割、即将开始下一次缝合的0.5秒间歇里，应用层逻辑果断地将主数据流切换到B区路径，并断开了A区连接。整个切换时机由应用精准掌控，实现了业务层面的“自定义无缝切换”。

4. 总结：为极致体验而生的“组合拳”

通过对这三大高级重定位机制的剖析，我们看到了5G网络为满足严苛边缘场景所做的深度思考和精妙设计。它们不再是单一的解决方案，而是一套可以组合使用的“工具箱”：

  • EAS IP地址替换，追求的是网络层的极致透明。它将移动性问题在网络内部完全消化，对上层应用屏蔽了所有复杂性，但对应用平台提出了最高的协同要求（实时上下文同步）。

  • 报文缓冲，追求的是数据平面的极致可靠。它作为切换过程的“安全垫”，确保了在任何情况下都不会因为时序问题而丢失宝贵的用户数据，是实现“无损切换”的基础保障。

  • 并发连接，追求的是应用层的极致灵活。它将切换的最终决定权交还给应用，让应用能够结合自身的业务逻辑，选择最佳的迁移时机和策略。

这套“组合拳”的出现，标志着5G边缘计算已经从单纯地提供“连接”，进化到了能够提供可保障、可控制、无中断的高级移动性服务。正是这些深藏在规范中的技术细节，才使得远程手术、车辆编队、工业精准控制等一系列激动人心的未来应用，从梦想照进现实。

FAQ环节

Q1：EAS IP地址替换和DNS重发现是互斥的吗？

A1：是的，在一次重定位事件中，它们通常是互斥的两种选择。IP地址替换是一种网络层方案，UE的DNS缓存和IP地址认知都保持不变。而DNS重发现则是一种应用层协同方案，其核心就是通过网络信令触发UE去更新DNS缓存和IP地址认知。SMF会根据AF的请求内容（是否提供了源/目标IP对）、网络能力、UE能力等，来决定采用哪一种机制。

Q2：应用上下文（Context）同步的具体技术是什么？3GPP为什么不标准化它？

A2：应用上下文同步是应用平台内部的技术，可以采用多种方式实现，例如数据库实时复制、分布式内存网格（如Redis）、自定义的会话状态同步协议等。3GPP不标准化它，是因为这完全属于应用领域的范畴，与通信协议无关。不同的应用（游戏、视频、工业控制）其上下文的结构和同步要求天差地别，强行标准化既不可能也无必要。3GPP的原则是定义好“网”与“业”的边界和接口，网络负责提供可靠的连接和触发信号，而应用则负责管理好自己的内部状态。

Q3：报文缓冲机制会不会导致时延增加？

A3：会，但这种时延是可控的、有益的。缓冲本身确实会为第一批数据包引入额外的存储转发时延。但是，这个时延是为了“等待”新EAS准备就绪，避免了因数据包过早到达而被丢弃，从而引发应用层TCP重传。应用层的重传会导致更长、更不可控的时延。因此，报文缓冲是用一次性的、可预期的网络层缓冲时延，换取了端到端数据流的完整性和更平稳的应用层表现。

Q4：同时拥有两条连接路径，UE如何区分和使用它们？

A4：这取决于具体的实现。在SSC Mode 3下，UE可能会获得一个新的IPv6前缀，应用可以通过绑定不同的源地址来区分两条路径。在会话分离模型下，网络可能会为两条路径分配不同的QoS流，应用可以通过QoS流ID来区分。更上层地，应用可以与两个不同的EAS IP（旧的和新的）建立两个独立的TCP/UDP连接。应用层逻辑需要知道哪个连接是通往旧服务器，哪个是通往新服务器，并自主管理在这两条连接上的数据收发。

Q5：这些高级功能听起来很复杂，普通的边缘应用开发者需要关心这些吗？

A5：对于大多数普通开发者可能不需要。他们可能直接使用云服务商或运营商提供的边缘平台，这些平台会将这些复杂的网络能力封装成更易于使用的服务。例如，平台可能会提供一个“无中断迁移”的API，开发者只需调用这个API，平台后台会自动与5G核心网进行交互，完成IP替换、缓冲等一系列复杂操作。但是，对于需要进行底层优化、追求极致性能的头部应用开发者，以及网络设备和终端的开发者来说，深入理解这些机制的原理和信令流程，则是至关重要的。

关系图谱