深度解析 3GPP TS 38.423：9.1.2 双连接消息 (Part 1 - S节点添加)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.2 Messages for Dual Connectivity Procedures”的核心章节，特别聚焦于双连接建立的开篇之作：
S-NODE ADDITION REQUEST(9.1.2.1),S-NODE ADDITION REQUEST ACKNOWLEDGE(9.1.2.2), 和S-NODE ADDITION REQUEST REJECT(9.1.2.3)。本文将深入剖析主节点（MN）是如何通过这些消息，为UE“招募”一个次节点（SN）“合伙人”的。
1. 引言：从“独行侠”到“黄金搭档”
在前面的篇章中，我们已经对XnAP协议中的基础移动性管理（切换）和RRC_INACTIVE态下的UE唤醒流程有了全面的了解。这些流程确保了用户在不同基站间的移动连续性。然而，5G的雄心远不止于“连接不断”，更在于提供“极致体验”。当单个基站的资源无法满足用户的“胃口”时，5G双连接（Dual Connectivity, DC）技术便应运而生。
让我们再次回到视频博主“V-Log小杰”的8K直播场景。他所连接的主基站（MN）发现上行链路即将饱和，无法独立保障其超高的码率需求。此时，MN决定从“独行侠”变身为“项目经理”，为小杰的直播业务招募一个“黄金搭档”——邻近的次基站（SN）。
这场“招募”行动的信令“剧本”，正是我们今天要深入解读的S节点添加流程。小林，我们的主角工程师，在他的导师陈工的指导下，将逐一解构这场“合伙人谈判”中的三封关键“信函”：
S-NODE ADDITION REQUEST(S节点添加请求)：MN发出的详尽“招募说明书”，详细阐述了UE的情况和需要SN协助的任务。S-NODE ADDITION REQUEST ACKNOWLEDGE(S节点添加请求确认)：SN回复的“合作意向书”，确认了自己愿意并有能力承担任务，并反馈了资源准备情况。S-NODE ADDITION REQUEST REJECT(S节点添加请求拒绝)：SN发出的“婉拒函”，说明自己无法接受这次合作请求的原因。
通过对这三个消息的深度剖析，我们将揭示双连接建立的底层逻辑，理解MN和SN是如何通过精密的信令交互，共同为用户构建起一条超宽的“数据高速公路”的。
2. 9.1.2.1 S-NODE ADDITION REQUEST - “总指挥”的招募令
当MN决定为UE启动双连接时，它会向选定的候选SN发送此消息。这是双连接建立的第一个信令步骤。
2.1 消息结构概览
S-NODE ADDITION REQUEST 消息内容 方向: M-NG-RAN node → S-NG-RAN node
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| M-NG-RAN node UE XnAP ID | M | NG-RAN node UE XnAP ID 9.2.3.16 | 由MN分配的UE在Xn接口上的ID |
| UE Security Capabilities | M | 9.2.3.49 | UE的安全能力 |
| S-NG-RAN node Security Key | M | 9.2.3.51 | 关键！ MN为SN计算的安全密钥 |
| Selected PLMN | O | PLMN Identity 9.2.2.4 | UE在SN上将要使用的PLMN |
| PDU Session Resources To Be Added List | 1 | 需要SN建立资源的PDU会话列表 | |
| >PDU Session Resource Setup Info - SN terminated | O | 9.2.1.5 | SN终止承载的配置信息 |
| >PDU Session Resource Setup Info - MN terminated | O | 9.2.1.7 | 分离承载或SCG承载的配置信息 |
| M-NG-RAN node to S-NG-RAN node Container | M | OCTET STRING | 关键！ RRC配置信息的透明容器 |
| … (其他可选IE) | O | … | 如移动性限制、PCell ID等 |
2.2 核心IE深度剖析
陈工向小林解释道：“这封‘招募令’必须写得极其详尽，因为它几乎是从零开始，为SN构建关于这个UE的完整上下文。”
1. S-NG-RAN node Security Key (S节点安全密钥)
- Presence: M
- 陈工解读：“这是建立信任的第一步。双连接中，SN需要独立地与UE进行用户面数据的加密和完整性保护。这个密钥（S-KeNB或S-KgNB）是由MN根据UE和网络共享的顶级密钥计算出来的，专门供SN使用。MN通过这个受保护的IE将其安全地传递给SN。SN拿到这个‘令牌’后，才能与UE建立起安全的通信链路。这是一个绝对的强制项。”
2. PDU Session Resources To Be Added List (待添加的PDU会话资源列表)
- Presence: 1 (至少有一项)
- 陈工解读：“这是‘工作任务书’。MN必须明确告知SN，需要它为哪些业务、以何种方式提供资源。”
- SN Terminated Bearer (SN终止承载): 当MN希望将某个业务（如下载）完全卸载给SN时，会使用
PDU Session Resource Setup Info - SN terminated。此时，数据流将从核心网UPF直接流向SN。 - Split Bearer / SCG Bearer (分离/SCG承载): 当MN希望与SN分担同一个业务（如小杰的8K直播上行流）时，会使用
PDU Session Resource Setup Info - MN terminated。此时，数据流先到MN，再由MN分流一部分给SN。 “这两个IE至少要出现一个，否则这次‘招募’就没有任何意义了。”
- SN Terminated Bearer (SN终止承载): 当MN希望将某个业务（如下载）完全卸载给SN时，会使用
3. M-NG-RAN node to S-NG-RAN node Container (MN到SN的容器)
- Presence: M
- 陈工解读：“这是具体的‘施工图纸’。MN的RRC层会在这里面放入一个
CG-ConfigInfo（Cell Group Configuration Information）RRC信令。这个信令详细描述了SN需要为UE配置的所有无线资源参数，比如：要建立的DRB ID、RLC模式、逻辑信道配置、物理层配置等等。SN的RRC层收到后，会解析这个‘施工图’，并据此准备自己的无线资源。这是一个透明容器，XnAP层只负责传递，不解析内容。”
3. 9.1.2.2 S-NODE ADDITION REQUEST ACKNOWLEDGE - “合伙人”的承诺
如果SN有能力并且愿意接受MN的请求，它就会回复此消息，表示“合作愉快”。
3.1 消息结构概览
S-NODE ADDITION REQUEST ACKNOWLEDGE 消息内容 方向: S-NG-RAN node → M-NG-RAN node
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| S-NG-RAN node UE XnAP ID | M | NG-RAN node UE XnAP ID 9.2.3.16 |
| PDU Session Resources Admitted To Be Added List | 1 | |
| >PDU Session Resource Setup Response Info - SN terminated | O | 9.2.1.6 |
| >PDU Session Resource Setup Response Info - MN terminated | O | 9.2.1.8 |
| PDU Session Resources Not Admitted List | O | 9.2.1.3 |
| S-NG-RAN node to M-NG-RAN node Container | M | OCTET STRING |
3.2 核心IE深度剖析
1. S-NG-RAN node UE XnAP ID
- 陈工解读：“SN在同意合作后，会在本地为这个UE创建一个XnAP上下文，并分配一个自己的ID。这个ID将用于后续所有与该UE相关的、由SN发起的信令交互中。”
2. PDU Session Resources Admitted... 与 ...Not Admitted List
- 陈工解读：“这是SN对‘工作任务书’的逐项批复。对于能够满足的承载请求，SN会在
Admitted列表中，提供自己为该承载分配的用户面隧道地址（GTP-U隧道信息）。这个地址就是MN（或UPF）后续发送分流数据的‘目的地’。对于无法满足的请求，SN会在Not Admitted列表中明确拒绝，并附上原因。”
3. S-NG-RAN node to M-NG-RAN node Container
- 陈工解读：“这是SN返回给MN的‘最终版施工图纸’。SN根据MN的建议和自身的资源情况，生成了最终要下发给UE的RRC配置（
CG-Config），并将其封装在这个容器中。MN收到后，会将这个容器的内容整合进RRCReconfiguration消息，发送给UE，完成SCG的最终配置。”
4. 9.1.2.3 S-NODE ADDITION REQUEST REJECT - “婉拒”合作
如果SN无法接受MN的请求，它会回复此消息。
S-NODE ADDITION REQUEST REJECT 消息内容
| IE/Group Name | Presence | Semantics description |
|---|---|---|
| … | ||
| Cause | M | 拒绝的原因 |
| Criticality Diagnostics | O | 更详细的诊断信息 |
陈工的解读：“REJECT消息的核心就是Cause IE。它必须明确告知MN拒绝的原因，常见的有：”
no-radio-resources-available: SN无线资源不足。invalid-qos-combination: MN请求的QoS参数组合，SN无法支持。encryption-and-or-integrity-protection-algorithms-not-supported: UE的安全能力与SN不匹配。
MN收到REJECT后，就知道这次招募失败，它可能会选择另一个候选SN重试，或者放弃为该UE建立双连接。
5. 总结：双连接建立的严谨“三步曲”
S节点添加的“请求-确认/拒绝”三部曲，构成了一个完整、严谨的资源协商和配置流程。它不仅仅是资源的申请，更是一次安全上下文的建立、QoS承诺的转移、以及跨节点RRC配置的协同。
- 请求的完备性 (
REQUEST)：MN必须提供足够的信息，让一个对UE一无所知的SN能够为其建立起完整的服务能力。 - 响应的精确性 (
ACKNOWLEDGE)：SN必须精确反馈其资源准备情况和最终的RRC配置，为MN的最终决策提供依据。 - 失败的明确性 (
REJECT)：拒绝必须有理有据，为MN的后续策略调整（如选择新SN）提供指导。
对于工程师小林来说，这三个消息的实现，是开发双连接功能的起点。他必须精确地处理每一个IE的编解码，并在MN和SN的状态机中，严格遵循请求-响应的交互逻辑和定时器管理。只有这样，才能确保双连接的“黄金搭档”能够被成功、可靠地建立起来。
FAQ
Q1：为什么S-NODE ADDITION REQUEST中，S-NG-RAN node UE XnAP ID是可选的，而MN的ID是强制的？
A1：因为在MN发起这个请求时，它可能之前已经与这个SN就该UE进行过其他交互（虽然不常见），并且已经知道了SN为该UE分配的ID。如果是这样，带上这个ID可以帮助SN更快地关联到已有的上下文。但绝大多数情况下，这是第一次为该UE与此SN交互，所以SN还没有分配ID，此时这个IE就可以不带。而MN的ID是强制的，因为它作为发起方，必须提供自己的标识，以便SN知道这个请求来自谁，并将响应正确地回送。
Q2：MN是如何选择候选SN的？
A2：这取决于MN的RRM算法，通常基于UE上报的测量报告。UE会周期性地测量并上报邻区的信号质量。当MN决定需要启用双连接时，它会从UE上报的邻区列表中，选择一个信号质量好、且（通过Xn接口的RESOURCE STATUS UPDATE等流程）已知其负载较低的邻居gNB作为候选SN。
Q3：PDU Session Resource Setup Info - SN terminated和- MN terminated这两个IE可以同时出现在一个REQUEST消息中吗？
A3：可以。MN完全可以在一个S-NODE ADDITION REQUEST中，同时请求SN为UE建立一个SN终止承载（例如，一个新的下载业务），并为另一个已有的业务建立分离承载（例如，分担直播的上行流量）。SN会对PDU Session Resources To Be Added List中的每一个Item进行独立处理。
Q4：为什么需要M-NG-RAN node to S-NG-RAN node Container这个透明容器来传递RRC信息，而不是将所有RRC参数都定义成XnAP的IE？
A4：这主要是为了协议解耦和灵活性。RRC配置参数非常庞杂，并且随着3GPP版本的演进而频繁变化。如果将所有RRC参数都在XnAP中重新定义一遍，会导致XnAP协议异常臃肿，并且RRC的任何微小改动都可能需要XnAP同步升级。采用透明容器的方式，XnAP只负责传递“信封”，不关心“信件”内容。这样，RRC协议可以独立演进，只要保证MN和SN的RRC层能够相互理解CG-ConfigInfo的内容即可，大大增强了系统的可扩展性和向后兼容性。
Q5：如果SN回复了ACKNOWLEDGE，但MN后续因为某种原因（比如UE突然掉线）没有向UE下发RRC重配指令，会发生什么？
A5：SN在回复ACKNOWLEDGE后，会启动一个内部定时器。如果在规定时间内，它没有收到来自MN的进一步指令（如UE Context Release或S-NODE RECONFIGURATION COMPLETE），SN会认为MN侧的流程已经失败，并会自动清理为这次未完成的添加操作所预留的所有资源。这确保了网络中不会存在因上游流程失败而导致的“僵尸”资源占用。