深度解析 3GPP TS 38.423：9.1.2 双连接消息 (Part 2 - S节点变更与释放)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.2 Messages for Dual Connectivity Procedures”的核心章节，特别聚焦于双连接关系演变的终章：
S-NODE CHANGE(9.1.2.11-13) 和S-NODE RELEASE(9.1.2.14-18) 系列消息。本文将深入剖析SN“换岗”与“离职”的信令细节，揭示5G网络如何通过这些流程实现更智能的移动性管理和更可靠的资源回收。
1. 引言：双连接的“交接班”与“散伙饭”
在上一篇中，我们探讨了主从节点（MN/SN）之间如何通过MODIFICATION流程，对已建立的双连接进行“内部装修”。然而，双连接的世界并非一成不变。随着用户在网络中的移动，一个曾经的“最佳拍档”（SN）可能会因为距离变远而不再胜任。此时，网络需要的不是“装修”，而是“换人”。
我们的工程师小林在他的导师陈工的指导下，继续深入研究双连接的生命周期。他问道：“陈工，我们知道SN可以主动‘建言献策’（MODIFICATION），甚至可以主动‘请辞’（RELEASE）。那它能不能更进一步，主动为自己找好‘下家’，实现一次平滑的‘交接班’呢？”
“你的思考非常敏锐，这正是5G移动性智能化的高级体现！”陈工赞许道，“SN不仅可以‘请辞’，更可以发起一场精心策划的‘禅让’。这就是我们今天要学习的第一个流程——S节点变更 (S-NODE CHANGE)。它是由当前SN主动发起的，目的是将UE的SCG（次小区组）平滑地切换到一个新的SN。”
“当然，”陈工继续说，“有聚就有散。当双连接的使命完成，或者因为各种原因无法再维持时，就需要‘散伙’。我们之前已经从流程（第8章）的角度学习了释放，今天我们将从消息（第9章）的角度，深入剖析S-NODE RELEASE系列消息的每一个字段，看看这场‘散伙饭’的‘账单’和‘交接清单’上都写了些什么。”
今天，我们将聚焦于双连接关系的最后两个阶段，解构其背后的信令“语言”：
S-NODE CHANGE系列消息: SN主动发起的“禅让”仪式，涉及REQUIRED,CONFIRM,REFUSE三封核心信函。S-NODE RELEASE系列消息: MN或SN发起的“分手”流程，涉及REQUEST,REQUIRED,ACKNOWLEDGE,REJECT,CONFIRM等一系列“交接文书”。
2. 9.1.2.11 - 9.1.2.13 S-NODE CHANGE - “副手”的“禅让”大典
这是一个由当前SN（源SN）主动发起的，旨在将UE的SCG切换到一个新SN（目标SN）的Class 1流程。
2.1 S-NODE CHANGE REQUIRED (9.1.2.11) - 附带推荐的“让位”请求
这是源SN向MN发出的“禅让”请求，其核心是“推荐信”。
S-NODE CHANGE REQUIRED 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| … | |||
| Target S-NG-RAN node ID | M | Global NG-RAN Node ID 9.2.2.3 | 关键！ 推荐的“接班人”（目标SN）的ID |
| PDU Session SN Change Required List | 0..1 | 需要进行路径切换的PDU会话列表 | |
| S-NG-RAN node to M-NG-RAN node Container | M | OCTET STRING | 透明容器，包含源SN的当前配置信息 |
| … (其他可选IE) | O | 如SCG UE历史信息等 |
陈工的解读：“CHANGE REQUIRED的精髓在于Target S-NG-RAN node ID。源SN1不仅仅是说‘我不干了’，而是明确告诉MN：‘我推荐SN2来接替我’。这个推荐是基于它从UE的测量报告中获得的实时无线环境洞察。同时，Container中会附上自己当前的SCG配置，这为MN与新SN2的协商提供了重要的参考基线。”
2.2 S-NODE CHANGE CONFIRM (9.1.2.12) - “总指挥”的批准令
MN在收到请求，并成功与目标SN2完成S-NODE ADDITION PREPARATION后，会向源SN1回复此消息。
S-NODE CHANGE CONFIRM 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| … | |||
| PDU Session SN Change Confirm List | 0..1 | ||
| >Data Forwarding Info from target NG-RAN node | O | 9.2.1.16 | 关键！ 目标SN2的数据转发地址 |
陈工的解读：“CONFIRM消息的核心是给源SN1下达‘交接’指令。其中最重要的Data Forwarding Info就是新SN2的‘收货地址’。SN1收到后，就可以开始将缓存的下行数据转发给SN2，同时停止对UE的服务。这标志着‘禅让’仪式正式进入执行阶段。”
2.3 S-NODE CHANGE REFUSE (9.1.2.13) - “禅让”被驳回
如果MN不同意SN1的变更请求（例如，MN认为没有必要更换，或者推荐的SN2资源不足），则回复此消息，附带明确的Cause。SN1收到后将继续为UE服务。
3. 9.1.2.14 - 9.1.2.18 S-NODE RELEASE - “合作”的终结
释放流程分为MN发起和SN发起两种，我们分别来看其核心消息。
3.1 MN-initiated Release (MN发起，9.1.2.14 & 15 & 16) - “解散”命令
1. S-NODE RELEASE REQUEST (9.1.2.14)
这是MN发出的“解散”指令，是一个Class 1流程。
S-NODE RELEASE REQUEST 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| Cause | M | 9.2.3.2 |
| PDU Session To Be Released List | O | |
| UE Context Kept Indicator | O | 9.2.3.68 |
陈工的解读：“这封‘解雇信’写得有理有据。Cause说明了解雇原因（业务结束、无线质量差等）。PDU Session To Be Released List则精确到了需要释放哪些业务承载。而UE Context Kept Indicator则是一个重要的‘缓兵之计’，如果设为true，SN只需暂停服务但保留上下文，以备快速恢复。”
2. S-NODE RELEASE REQUEST ACKNOWLEDGE (9.1.2.15)
这是SN对“解散”命令的回执，表示已收到并开始执行。
S-NODE RELEASE REQUEST ACKNOWLEDGE 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| SCG UE History Information | O | 9.2.3.151 |
| SN Mobility Information | O | BIT STRING (SIZE(32)) |
| PDU sessions To Be Released List | O | 包含数据转发信息 |
陈工的解读：“这是SN的‘离职交接’。它会上交最后的‘工作日志’（SCG UE History），并可以在PDU sessions...List中请求将缓存数据转发给MN，实现无损释放。”
3. S-NODE RELEASE REJECT (9.1.2.16)
在极少数异常情况下，SN可能会拒绝释放请求，通过此消息告知MN。
3.2 SN-initiated Release (SN发起，9.1.2.17 & 18) - “请辞”报告
1. S-NODE RELEASE REQUIRED (9.1.2.17)
这是SN在检测到无法继续服务UE时（如RLF），主动向MN发出的“紧急辞呈”。
S-NODE RELEASE REQUIRED 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| Cause | M | 9.2.3.2 |
| S-NG-RAN node to M-NG-RAN node Container | O | OCTET STRING |
陈工的解读：“REQUIRED消息的核心是Cause，SN必须向MN报告‘出事了’，最常见的原因就是radio-connection-with-ue-lost。Container中可以附带一些辅助诊断信息。”
2. S-NODE RELEASE CONFIRM (9.1.2.18)
这是MN对SN“辞呈”的“批准回执”。
S-NODE RELEASE CONFIRM 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| PDU Session Resources Released List | O | 包含数据转发信息 |
陈工的解读：“MN收到SN的REQUIRED后，必须接受并开始处理。它会向UE下发RRC指令移除SCG，并在CONFIRM消息中，可以选择性地提供数据转发地址，让SN将‘遗留’数据转交回来。这封回执，就相当于告诉SN：‘你的辞职申请我已批准，后续工作我来接手，请做好数据交接。’”
4. 总结：灵活、健壮的“伙伴关系”管理
小林通过对这些消息的深入学习，对双连接的生命周期管理有了更全面的认识。S-NODE CHANGE和S-NODE RELEASE系列消息，共同构成了双连接关系从“动态调整”到“有序终结”的完整信令闭环。
S-NODE CHANGE流程，赋予了SN前瞻性的自我优化能力，使得双连接的移动性管理从被动的“故障驱动”演进为主动的“预测驱动”，是网络智能化的重要体现。S-NODE RELEASE流程，则通过MN和SN双向发起的机制，确保了无论是由上层策略驱动，还是由底层故障触发，双连接关系都能够被安全、可靠地终止，资源能够被及时回收，用户数据能够被最大程度地保留。
这些精细化的消息设计，确保了5G双连接不仅是一个强大的性能增强工具，更是一个具备高度灵活性、健壮性和智能性的“活”系统。对于开发者来说，精确实现这些消息的编解码和状态机流转，是保证双连接稳定可靠运行的基础；对于网络优化人员，分析这些消息中的Cause值和各种列表信息，则是洞察网络移动性性能、诊断疑难杂症的“金钥匙”。
FAQ
Q1：S-NODE CHANGE和Handover（切换）有什么关系？
A1：S-NODE CHANGE可以看作是一种**“只换副手，不换总指挥”**的特殊形式的切换。在普通的Handover中，UE的主服务节点（MN）会发生改变。而在S-NODE CHANGE中，MN保持不变，只是UE的次服务节点（SN）从一个基站变更到另一个基站。MN会协调这个过程，包括与新SN建立资源，并指令旧SN释放资源。
Q2：为什么MN发起的释放是REQUEST，而SN发起的释放是REQUIRED？
A2：这体现了两者在流程中的地位和紧迫性不同。
REQUEST(请求)：由MN发起，通常是基于策略的、计划内的操作。它是一个“请求”，虽然SN通常必须遵从，但在语义上留有协商的余地。REQUIRED(需要/必要)：由SN发起，通常是由于发生了无法继续服务的紧急事件，如无线链路失败。它是一个“紧急报告”，告知MN一个必须处理的事实。MN收到后没有拒绝的选项，必须接受并开始处理。
Q3：UE Context Kept这个标志有什么实际的性能优势？
A3：巨大的优势在于快速恢复。当UE的业务暂停又快速恢复时（例如，视频暂停/播放），如果SN保留了上下文，MN只需通过一个轻量级的S-NODE MODIFICATION流程（而不是完整的S-NODE ADDITION）就可以重新激活SN上的承载。这省去了安全上下文重建、RRC全量配置等耗时步骤，使得双连接的恢复时延从数百毫秒降低到几十毫秒，对于时延敏感业务体验提升巨大。
Q4：在S-NODE RELEASE REQUEST ACKNOWLEDGE中，SN上交的SCG UE History Information有什么用？
A4：这份“历史档案”是MN进行后续移动性决策的重要参考。例如，它记录了UE在SN上最后的驻留小区、信号质量、移动轨迹等。如果MN发现UE是因为在某个特定区域信号差而被释放的，MN的SON算法就可以记录这个信息，未来在为其他UE选择SN时，就会尽量避开这个“差评区域”，从而实现网络的自我学习和优化。
Q5：S-NODE RELEASE CONFIRM和UE Context Release有什么区别？
A5：在SN发起的释放流程中，这两个消息是前后衔接的。
S-NODE RELEASE CONFIRM: 是MN对SN的REQUIRED消息的同步响应。它告诉SN：“你的辞职申请我收到了，并已批准。” SN收到后，就知道MN已经接管此事，可以开始准备释放资源。UE Context Release: 是MN在完成了所有对UE的RRC重配、确保UE已经安全地从SCG上断开连接之后，再发送给SN的最终清理指令。它告诉SN：“所有善后工作已完毕，你可以彻底删除这个UE的所有信息了。” 前者是“批准”，后者是“销档通知”。