深度解析 3GPP TS 38.423：8.3.5 S节点发起的S节点变更 (副手的主动请辞)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.5 S-NG-RAN node initiated S-NG-RAN node Change”的核心章节。本文旨在为读者深入剖析5G双连接中一种高度智能化的移动性管理流程——由当前次节点（SN）主动发起的“禅让”式变更，揭示其背后的设计哲学与信令实现。

1. 引言：当“最佳拍档”不再“最佳”

在前面的章节中，我们见证了主节点（MN）如何为视频博主“V-Log小杰”招募并管理他的“最佳拍档”——次节点（SN），以保障其8K直播的流畅。双连接（DC）的动态调整，似乎总是由作为“总指挥”的MN一手掌控。然而，一个真正高效的团队，不仅需要领导者的英明决策，也需要前线成员的主动性和洞察力。

我们的工程师小林，在深入研究双连接日志后，又有了新的发现。他向导师陈工请教：“陈工，我看到一个有趣的案例。一个处于双连接状态的UE，其与SN的连接质量还不错，但SN却主动向MN发起了一个流程，似乎是请求‘更换自己’。这让我很困惑，SN为什么要‘主动请辞’呢？它还没到‘不堪重用’的地步啊。”

陈工赞许地点点头：“你的观察非常敏锐！这正是5G网络从‘被动响应’走向‘主动预测’的智能化体现。你看到的，就是我们今天要学习的、一个极为精巧的流程——S-NG-RAN node initiated S-NG-RAN node Change (S节点发起的S节点变更)。”

陈工继续描绘场景：“想象一下，V-Log小杰正坐在一辆自动驾驶的观光车上，在智慧园区的固定路线上游览。他当前的次节点SN1，通过UE上报的测量报告和网络侧的AI能力，预测到观光车即将在10秒后转弯，届时UE将进入SN1的信号弱区，但会进入另一个基站SN2的信号强区。

如果SN1等到信号恶化再被动地由MN释放，可能会造成短暂的速率抖动。于是，SN1决定‘先发制人’。它主动向MN发起这个‘变更’流程，相当于提交了一份附带建议的‘辞职报告’：‘报告总指挥，根据预判，我即将无法胜任副手一职，但我已经为您物色好了接替者——SN2，建议立即进行交接！’ 这就是今天要讲的故事核心——‘副手’的主动、平滑、且有预见性的‘禅让’。”

2. 8.3.5.1 General (概述) - “先见之明”的交接班

This procedure is used by the S-NG-RAN node to trigger the change of the S-NG-RAN node. The procedure uses UE-associated signalling.

这段概述看似简单，却揭示了一个颠覆性的角色转变：

• 发起方 (Initiator)：S-NG-RAN node。这是整个双连接管理流程中，首次由次节点SN扮演主动发起角色，目的是为了替换自己。
• 目的 (Purpose)：触发一次SN的变更。这不是简单的修改，而是彻底的更换，UE的SCG（次小区组）将从旧的SN切换到一个新的SN。
• 驱动力 (Driver)：SN侧的前瞻性RRM算法。它不再是基于“已发生”的链路恶化，而更多是基于“将要发生”的移动预测、负载趋势或更优路径的发现。

这个流程，将SN从一个被动的“执行者”，提升为了一个具备局部态势感知和主动优化建议能力的“智能探针”。

3. 8.3.5.2 Successful Operation (成功操作) - 一场精心策划的“禅让”大典

这是一个Class 1流程。SN的“禅让”提议必须得到MN的批准和统一调度，才能最终执行。

第一步：当前SN1的“禅让”请求 - S-NODE CHANGE REQUIRED

The S-NG-RAN node initiates the procedure by sending the S-NODE CHANGE REQUIRED message to the M-NG-RAN node including the Target S-NG-RAN node ID IE. When the S-NG-RAN node sends the S-NODE CHANGE REQUIRED message, it shall start the timer TXnDCoverall.

场景代入： 预见到UE即将移动出自己的最佳覆盖区，SN1决定发起变更。

1. 发送S-NODE CHANGE REQUIRED: SN1向MN发送此消息。
2. 包含Target S-NG-RAN node ID IE: 这是整个消息的画龙点睛之笔。SN1在“辞职报告”中，附上了它推荐的“接班人”——SN2的全局ID。这表明SN1已经通过UE的测量报告，或者网络内部的拓扑信息，做出了一个智能化的推荐。
3. 启动TXnDCoverall定时器: SN1启动一个长定时器，用于监控从提议到最终完成交接的全过程。

S-NODE CHANGE REQUIRED消息的核心内容还包括：

• S-NG-RAN node to M-NG-RAN node Container: 一个透明容器，SN1可以把自己当前的配置信息，或者它认为有助于MN决策的其他信息打包在里面。
• SCG UE History Information: UE在SN1上的移动历史，帮助MN和新的SN2更好地了解UE的行为模式。

第二步：MN的“运筹帷幄”

MN收到SN1的“禅让”请求后，作为“总指挥”，它需要进行一系列的后台操作：

1. 评估提议：MN会评估SN1的提议是否合理。它可能会采纳SN1推荐的SN2，也可能会根据自己的全局视图（例如，知道SN3的负载更低）另选他人。
2. 联系新SN：假设MN同意了SN2。它会向SN2发起一个我们已经学过的S-NODE ADDITION PREPARATION流程（8.3.1节），为UE在SN2上准备资源。
3. 获取转发地址：SN2在S-NODE ADDITION REQUEST ACKNOWLEDGE中，会向MN提供用于数据转发的用户面隧道地址。

第三步：MN向旧SN1下达“交接令” - S-NODE CHANGE CONFIRM

当MN已经为UE在SN2处准备好一切后，它就会向发起者SN1回复S-NODE CHANGE CONFIRM消息。

If the M-NG-RAN node is able to perform the change requested by the S-NG-RAN node, the M-NG-RAN node shall send the S-NODE CHANGE CONFIRM message to the S-NG-RAN node. For DRBs configured with the PDCP entity in the S-NG-RAN node, the M-NG-RAN node may include data forwarding related information in the Data Forwarding Info from target NG-RAN node IE.

S-NODE CHANGE CONFIRM消息的核心内容：

• Data Forwarding Info from target NG-RAN node IE: 这是最重要的信息。MN将从新SN2处获得的数据转发地址（GTP-U隧道信息）放在这个IE中，传递给旧SN1。这相当于告诉SN1：“你的接班人SN2已经准备就绪，这是他的‘收货地址’，准备交接数据吧。”
• MN to SN Container: MN也可能通过容器，向SN1下达一些最终的指令。

第四步：执行交接与善后

1. SN1的动作:

   The S-NG-RAN node may start data forwarding and stop providing user data to the UE and shall stop the timer TXnDCoverall upon reception of the S-NODE CHANGE CONFIRM message. SN1收到CONFIRM后，立即停止TXnDCoverall定时器，表示其提议已被批准，流程进入执行阶段。它会开始将本地缓存的、尚未发送给UE的下行数据包，通过刚刚获得的地址，转发给SN2。同时，它会停止向UE发送任何新的数据。

2. MN的动作: MN向UE发送RRCReconfiguration消息，指令UE将其SCG（次小区组）的配置从SN1切换到SN2。

3. 最终清理: 当UE成功在SN2上激活后，MN会向旧SN1发送UE Context Release（8.2.7节）消息，通知其可以彻底清理所有与该UE相关的上下文，完成“退休”。

至此，一场由SN主动发起的、平滑无感知的“禅让”式变更圆满完成。

4. 8.3.5.3 & 8.3.5.4 - 当“禅让”被驳回或出现异常

4.3.5.3 Unsuccessful Operation (失败操作)

In case the request modification cannot accept the request to change the S-NG-RAN node the M-NG-RAN node shall respond with the S-NODE CHANGE REFUSE message to the S-NG-RAN node with an appropriate cause value in the Cause IE.

如果MN不同意SN1的提议（例如，MN认为没有必要更换SN，或者它选择的SN2拒绝了资源请求），它会回复S-NODE CHANGE REFUSE。SN1收到后，就知道自己的“辞职报告”被驳回，将继续为UE提供服务。

4.3.5.4 Abnormal Conditions (异常条件)

• SN侧定时器超时:

  If the timer TXnDCoverall expires before the S-NG-RAN node has received the S-NODE CHANGE CONFIRM or the S-NODE CHANGE REFUSE message, the S-NG-RAN node shall regard the requested change as failed and may take further actions like triggering the S-NG-RAN node initiated S-NG-RAN node Release procedure… 如果SN1的定时器超时，它会认为MN没有响应或处理失败。此时，SN1可能会采取更主动的措施，比如直接发起一个SN Initiated SN Release流程（8.3.7节），即“既然你不批准我换岗，那我就直接辞职不干了”，以避免自身成为网络的瓶颈。

• 流程冲突:

  Interaction with the M-NG-RAN node initiated Handover Preparation procedure: If the M-NG-RAN node, after having initiated the Handover Preparation procedure, receives the S-NODE MODIFICATION REQUIRED message, the M-NG-RAN node shall refuse the S-NG-RAN node modification procedure with an appropriate cause value in the Cause IE. 规范在这里的描述虽然指向了MODIFICATION REQUIRED，但其原则同样适用于CHANGE REQUIRED。如果MN正在忙于一个更高级别的操作，比如为UE准备整网切换（Handover），那么它会拒绝来自SN的任何修改或变更请求，因为Handover的优先级更高。

5. 总结：从被动执行到主动优化的飞跃

S-NG-RAN node initiated S-NG-RAN node Change流程，是5G双连接智能化水平的一次重要跃迁。它将SN的角色从一个纯粹的资源提供者，提升为了一个具备局部态势感知和前瞻性优化能力的“智能体”。

• 它实现了主动的、预测性的移动性管理：变“亡羊补牢”为“未雨绸缪”，在链路质量恶化之前就完成切换，最大程度地保证了用户体验的平滑。
• 它体现了分布式的网络智能：将部分RRM决策能力下沉到更靠近UE的SN节点，使得网络能够更快、更精准地响应局部无线环境的变化。
• 它优化了信令交互效率：通过“提议-仲裁-执行”的模型，SN的智能推荐与MN的全局控制相结合，避免了MN需要周期性地轮询所有潜在SN来寻找最优切换目标的开销。

对于小林这样的开发者来说，这个流程的实现，意味着需要为SN赋予更强大的RRM算法和预测能力。而对于网络运维人员，分析这个流程的触发频率和成功率，可以反向评估网络中双连接配置的合理性和无线环境的稳定性。这不再是简单的“连接”，而是真正的“智能协同”。

FAQ

Q1：SN是如何知道应该向哪个Target SN“禅让”的？ A1：这是SN侧RRM算法智能性的体现。通常，SN会利用UE上报的测量报告（Measurement Report）。这份报告中不仅包含UE与当前SN的连接质量，也包含UE测量到的邻近小区（包括其他SN下的小区）的信号质量。SN可以分析这份报告，发现“哦，小区S2的信号强度正在快速上升，并且已经超过了我，它将是一个很好的接替者”，从而在S-NODE CHANGE REQUIRED消息中推荐SN2。

Q2：S-NODE CHANGE REQUIRED（本章）和S-NODE MODIFICATION REQUIRED（8.3.4节）有什么区别？ A2：两者都是由SN发起，但目的是根本不同的。

• S-NODE MODIFICATION REQUIRED：目的是修改当前SN自身的配置，例如调整QoS、激活一个辅载波等。SN本身不发生改变，只是“调整工作方式”。
• S-NODE CHANGE REQUIRED：目的是替换当前SN。SN请求MN将UE的SCG从自己切换到另一个新的SN。这是一个“换人”的操作。

Q3：如果MN不同意SN推荐的SN2，而是选择了SN3，流程会怎样？ A3：流程依然可以成功。MN收到SN1的请求后，自己决策选择了SN3。它会向SN3发起S-NODE ADDITION PREPARATION。SN3准备成功后，MN在回复给SN1的S-NODE CHANGE CONFIRM消息中，携带的数据转发地址将是SN3的地址。SN1只需按照指令将数据转发给SN3即可。整个流程中，SN1是“提议者”，而MN是“决策者”。

Q4：为什么SN发起变更流程后启动的是TXnDCoverall这个长定时器？ A4：因为SN作为发起者，它关心的是这次“禅让”的整个过程是否成功闭环。这个过程非常长，包括：1. 等待MN的仲裁和与新SN的协商；2. 等待MN向UE下发RRC重配；3. 等待UE成功接入新SN；4. 等待MN最终通知自己可以释放。只有收到MN发来的UE Context Release（或在某些实现中是S-NODE RECONFIGURATION COMPLETE作为中间确认点），SN才能确认交接完成。TXnDCoverall这个长定时器正是为了监控这个端到端的完整流程，避免因为中间某个环节的失败而导致自身资源被无限期占用。

Q5：这个SN主动发起的变更流程，对于提升网络性能有什么实际意义？ A5：实际意义巨大。1. 提升用户体验：通过预测性切换，避免了因链路质量突然恶化导致的瞬时速率下降或卡顿，尤其对于时延敏感的业务（如云游戏、高清直播）至关重要。2. 降低信令开销：变MN的“轮询式”发现为SN的“事件触发式”报告，减少了不必要的探测和信令交互。3. 增强网络自愈和自优化能力：使得网络具备了更强的局部自适应能力，能够更快地应对无线环境的变化，是SON（自组织网络）理念在双连接场景下的具体体现。