51学通信

深度解析 3GPP TS 38.423：8.3.6 & 8.3.7 S节点释放 (主从发起的“分手”艺术)

19分钟阅读

深度解析 3GPP TS 38.423：8.3.6 & 8.3.7 S节点释放 (主从发起的“分手”艺术)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.6 M-NG-RAN node initiated S-NG-RAN node Release”和“8.3.7 S-NG-RAN node initiated S-NG-RAN node Release”的核心章节。本文旨在将这两种互补的次节点释放流程进行整合与对比解读，为读者深入剖析5G双连接关系是如何在不同驱动力下被优雅、可靠地终止的。

1. 引言：当“合作”走向终点

在之前的章节中，我们见证了主节点（MN）如何为视频博主“V-Log小杰”的8K直播流成功建立并动态调整了双连接（DC），次节点（SN）作为“得力副手”功不可没。然而，天下没有不散的筵席。当小杰的直播结束，或者他乘坐的观光车驶入了SN信号的盲区，这段为了极致性能而建立的“合作关系”便需要走向终点。

工程师小林在分析网络日志时发现，双连接的拆除似乎有两种截然不同的“剧本”。他向导师陈工请教：“陈工，我看到有时候是主节点MN主动发起了释放流程，就像公司裁员；而另一些时候，竟然是次节点SN自己发起了释放请求，这更像是主动请辞。这两种‘分手’方式，背后有什么不同的考量和机制吗？”

“观察得非常细致！”陈工赞许道，“你已经洞悉了双连接生命周期管理的最后，也是同样重要的一环——资源释放。一个健壮的系统，不仅要懂得如何‘建立合作’，更要懂得如何‘优雅地结束合作’，以最高效的方式回收资源，并确保用户体验的平滑。这两种由不同节点发起的释放流程，正是为了应对不同的网络场景和触发条件而设计的，它们共同构成了双连接管理的‘安全退出’机制。”

今天，我们就来深入探讨XnAP协议中的这两种“分手”艺术：

  • 8.3.6 M-NG-RAN node initiated S-NG-RAN node Release：由“总指挥”MN发起的、自顶向下的**“解散”命令**。
  • 8.3.7 S-NG-RAN node initiated S-NG-RAN node Release：由“前线副手”SN发起的、自下而上的**“请辞”报告**。

我们将通过对比分析，揭示它们各自的适用场景、信令逻辑以及对网络性能的深远影响。

2. 8.3.6 M节点发起的S节点释放 - 总指挥的裁决

这是最常见、最符合逻辑直觉的释放方式。作为双连接关系的“主导者”，MN拥有对整个连接的最终裁决权。当MN认为SN的存在不再必要或不再有益时，它便会主动发起释放流程。

2.1 8.3.6.1 General (概述) - 解散团队的四大理由

The M-NG-RAN node initiated S-NG-RAN node Release procedure is triggered by the M-NG-RAN node to initiate the release of the resources for a specific UE.

MN在什么情况下会做出“解散团队”的决定呢？

  1. 业务需求降低：小杰的8K直播结束了，切换到了普通的网页浏览。单个MN的带宽已经绰绰有余，维持一个SN不仅占用资源，还徒增UE的功耗。此时，MN会果断释放SN。
  2. 无线环境变化：UE移动到了SN信号覆盖的边缘，与SN的连接质量持续恶化，双连接带来的增益已经小于其信令开销和干扰。
  3. MN自身资源充裕：网络整体负载下降，MN发现自己的资源不再紧张，可以独立支撑UE的业务，于是释放SN以备不时之需。
  4. 网络策略调整：出于全网负载均衡、节能等更宏观的RRM策略，MN可能需要将SN资源释放出来，服务于其他更高优先级的用户。

2.2 8.3.6.2 Successful Operation (成功操作) - 一场需要回执的“解雇”通知

这是一个Class 1流程，MN需要得到SN的明确回执，以确认“解雇”指令已被接收和处理。

第一步：MN的“解散令” - S-NODE RELEASE REQUEST

MN向SN发送S-NODE RELEASE REQUEST消息，核心内容包括：

  • Cause IE: MN必须说明释放的原因。这对网络运维至关重要。例如：

    • normal-release：正常的业务结束。
    • user-inactivity：用户长时间无数据活动。
    • radio-reasons：无线原因，如链路质量差。
    • rrm-purpose：RRM策略调整。

  • UE Context Kept Indicator IE set to “True”: 这是一个非常精妙的优化设计。

    Upon reception of the S-NODE RELEASE REQUEST message containing UE Context Kept Indicator IE set to “True”, the S-NG-RAN node shall, if supported, only initiate the release of the resources related to the UE-associated signalling connection between the M-NG-RAN node and the S-NG-RAN node…

    陈工的解读：“小林，你要特别注意这个IE。通常的释放意味着SN要删除关于这个UE的所有‘记忆’（上下文）。但如果MN设置了这个标志为True，它相当于告诉SN：‘请你先暂停服务，只断开我们之间的Xn信令连接，但请保留这个UE的完整档案！’。为什么这么做？设想小杰只是暂停了直播去接个电话，几分钟后又要恢复。如果MN能让SN保留上下文，那么当直播恢复时，MN就可以通过一个更轻量级的流程快速重新激活这个SN，而无需再次走一遍完整的S-NODE ADDITION流程。这是一种为了快速响应业务潮汐变化而设计的‘冷备’机制。”

第二步：SN的“交接工作”与回复 - S-NODE RELEASE REQUEST ACKNOWLEDGE

SN收到释放请求后，立即停止向UE提供服务，并开始清理相关资源。然后，它会回复S-NODE RELEASE REQUEST ACKNOWLEDGE消息，这封“离职交接报告”内容丰富：

  • SCG UE History Information IE: SN将UE在自己这里活动的“最后一份历史档案”（如驻留小区、时长等）上交给MN，供MN后续的移动性决策参考。

  • 数据转发信息：

    If the S-NG-RAN node provides data forwarding related information … the M-NG-RAN node may decide to provide data forwarding addresses to the S-NG-RAN node and trigger the Xn-U Address Indication procedure… 如果SN的缓冲中还有未发送给UE的下行数据，它可以在ACK中提议进行数据转发。MN收到后，可以决定是否通过XN-U ADDRESS INDICATION流程向SN提供MN侧的“收货地址”，让SN将这些“遗留”数据包转发给MN，再由MN发送给UE，从而最大化地保证数据零丢失。

  • SN状态传递触发:

    If the UE Context Kept Indicator IE set to “True” and the DRBs transferred to MN IE are included in the S-NODE RELEASE REQUEST message, the S-NG-RAN node shall, if supported, provide the uplink/downlink PDCP SN and HFN status for the listed DRBs… 如果释放的原因是将分离承载（Split Bearer）的SN部分转移回MN，那么MN就需要知道SN侧的PDCP序列号状态。这个ACK就是触发SN向MN发送SN STATUS TRANSFER消息的信号，确保承载路径的平滑切换。

3. 8.3.7 S节点发起的S节点释放 - 副手的“无奈”请辞

在某些情况下，SN比MN更早、更准确地感知到自己已不再适合继续服务UE。此时，等待MN的决策可能会错失最佳时机，甚至导致业务中断。因此，协议赋予了SN主动发起释放的权力。

3.1 8.3.7.1 General (概述) - “请辞”的驱动力

This procedure is triggered by the S-NG-RAN node to initiate the release of the resources for a specific UE.

SN在什么情况下会“主动请辞”？

  1. 无线链路失败 (RLF)：SN侧检测到其与UE之间的无线链路彻底中断，并且在一定时间内无法恢复。这是最常见的触发原因。
  2. RRM决策：SN的本地RRM算法判断，继续为该UE服务弊大于利。例如，UE处于SN覆盖的极弱边缘，维持连接需要消耗大量功率且效果不佳。
  3. 内部资源抢占：SN需要将资源分配给一个更高优先级的紧急业务（如急救通信），不得不“牺牲”小杰的直播业务。
  4. O&M操作：运维人员需要对该SN进行维护或关站。

3.2 8.3.7.2 Successful Operation (成功操作) - 需要“总指挥”批准的“辞呈”

这也是一个Class 1流程。SN的“请辞”必须得到MN的批准和后续处理，否则UE的配置状态将会混乱。

第一步：SN的“辞职报告” - S-NODE RELEASE REQUIRED

The S-NG-RAN node initiates the procedure by sending the S-NODE RELEASE REQUIRED message to the M-NG-RAN node.

SN向MN发送S-NODE RELEASE REQUIRED消息。消息名称中的REQUIRED再次强调了这次请求的必要性和紧迫性。

  • Cause IE: 这是SN“请辞”的核心。它必须向MN解释原因，例如radio-connection-with-ue-lost（无线连接丢失）、tXnDCoverall-expiry（SN侧的流程监控定时器超时）等。
  • SCG UE History Information: 主动附上自己的“工作总结”。

第二步：MN的“批准与善后” - S-NODE RELEASE CONFIRM

MN收到SN的“辞呈”后，不能拒绝。它必须接受这个事实，并立即开始“善后”工作：

  1. 向UE下发指令：MN会立即构建一个RRCReconfiguration消息，指令UE释放SCG配置，将所有业务收回到MN上。
  2. 回复S-NODE RELEASE CONFIRM: MN向SN回复此消息，表示“申请已批准，我正在处理后续事宜。”
  3. 数据转发协商: MN同样可以在CONFIRM消息中请求SN进行数据转发，以回收SN缓存中的数据。

SN收到CONFIRM后，就可以认为自己的“请辞”已被接受，并开始释放资源。整个流程的最终结束，仍然要等到MN在UE RRC重配成功后，向SN发送UE Context Release消息。

4. 主从发起的释放流程对比

为了让小林更清晰地理解这两种流程，陈工在白板上画了一张对比表格：

特性/维度8.3.6 MN-initiated Release (MN发起)8.3.7 SN-initiated Release (SN发起)
发起方M-NG-RAN node (主节点)S-NG-RAN node (次节点)
驱动力全局性/策略性：业务结束、负载均衡、移动性决策局部性/事件驱动：无线链路失败、本地RRM判断、资源抢占
发起消息S-NODE RELEASE REQUEST (请求)S-NODE RELEASE REQUIRED (必要)
核心目的MN执行一个主动的管理决策SN报告一个被动发生的事实或一个紧急的本地决策
关键特性支持UE Context Kept，实现“冷备”优化强调Cause值的报告作用，是网络故障诊断的重要输入
流程关系MN是绝对的决策者和发起者SN是建议者和报告者，MN是最终的执行者
场景比喻公司老板决定裁撤一个项目组项目组长发现项目无法继续，向老板提交解散申请

5. 总结：双连接管理的健壮闭环

M-NG-RAN node initiated S-NG-RAN node Release和S-NG-RAN node initiated S-NG-RAN node Release这两个流程，如同一枚硬币的两面，共同构成了5G双连接生命周期管理的完整闭环。

  • MN发起的释放，是常规的、计划内的资源回收手段，体现了MN作为“总指挥”的集中控制能力和对网络资源的宏观调配。
  • SN发起的释放，则是应对突发状况和进行精细化局部优化的重要补充，体现了5G网络架构中分布式智能和快速响应的设计思想。

正是这种“集中指挥”与“前线自主”相结合的机制，确保了双连接在各种复杂的网络场景下，既能高效地建立和调整，也能在需要时安全、可靠地拆除，始终将保障用户业务的连续性和稳定性放在首位。

FAQ

Q1：在SN发起的释放流程中，如果MN迟迟不回复S-NODE RELEASE CONFIRM会怎么样？ A1：SN在发送S-NODE RELEASE REQUIRED后会启动一个定时器（通常也是TXnDCoverall）。如果定时器超时，SN会认为MN无响应或出现故障。此时，SN可能会采取更激进的措施，比如单方面释放所有资源并记录一次严重的协议异常。这种情况会影响UE的业务，但协议的设计是为了避免出现不确定的“僵尸”状态，保证最终状态的一致性。

Q2：UE Context Kept这个“冷备”功能，在实际网络中有什么应用场景？ A2：一个典型的场景是“潮汐”业务。例如，一个用户每天中午午休时都喜欢在工位上看一小时的超高清视频。网络可以通过学习用户的行为模式，在午休时间为他启用双连接。视频结束后，MN可以发起带有UE Context Kept的释放流程，让SN保留上下文。第二天中午，当用户再次打开视频APP时，MN就可以通过一个快速的SN Reconfiguration流程重新激活双连接，整个过程的信令开销和时延远低于重新走一遍完整的SN Addition流程。

Q3：S-NODE RELEASE REJECT（在8.3.6中定义）和S-NODE MODIFICATION REFUSE（在8.3.4中定义）都是拒绝消息，有什么不同？ A3：S-NODE MODIFICATION REFUSE是MN拒绝SN发起的修改请求。而S-NODE RELEASE REJECT是SN拒绝MN发起的释放请求。后者在实际中非常罕见，因为MN作为主节点，其释放指令通常具有最高优先级。SN拒绝释放请求可能只在一些极端的、未定义的异常状态下发生。

Q4：为什么在SN释放流程中，数据转发通常是SN→MN，而不是SN→New SN？ A4：因为SN释放意味着UE的所有业务将完全回归到MN上，由MN独立提供服务。因此，SN只需要将自己缓存中未发送的数据交给MN即可。这与SN变更（SN Change）流程不同，SN变更流程中，数据需要从旧SN转发到新SN，因为UE的SCG业务将由新SN接管。

Q5：Handover Cancel和S-NODE RELEASE都涉及资源的释放，它们会一起使用吗？ A5：不会。Handover Cancel用于取消尚未建立的连接（在切换准备阶段）。而S-NODE RELEASE用于拆除一个已经建立并正在运行的双连接。一个是“订婚宴”取消了，一个是“离婚”。它们作用于UE移动性管理的不同阶段，不会混用。

关系图谱