深度解析 3GPP TS 38.423：8.3.3 & 8.3.4 S节点修改 (总指挥的命令与副手的建议)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.3 M-NG-RAN node initiated S-NG-RAN node Modification Preparation”和“8.3.4 S-NG-RAN node initiated S-NG-RAN node Modification”这两个核心章节。本文旨在通过对比解读，为读者深入剖析5G双连接（DC）建立之后，主节点（MN）与次节点（SN）之间两种截然不同但又相辅相成的动态资源调整机制。

1. 引言：从“联手”到“协同作战”

在上一篇中，我们见证了主节点（MN）如何为视频博主“V-Log小杰”的8K直播成功招募了一个“最佳拍档”——次节点（SN），建立了双连接。但这仅仅是协同作战的开始。一场成功的战役，不仅需要精妙的开局，更需要根据战场形势变化进行持续的、动态的战术调整。

我们的工程师小林在他的导师陈工的指导下，开始思考一个更深层次的问题：“陈工，双连接建立后，是不是就一成不变了？如果小杰的直播业务突然需要更高的码率，或者核心网要求为他建立一个新的专用承载怎么办？又或者，MN自身的负载发生了变化，希望SN承担更多或更少的流量，该如何操作？”

“问得好！”陈工赞许道，“你已经从‘建立连接’的思维，转向了‘管理连接’的思维。双连接的生命周期中，绝大部分时间都处于动态调整的状态。网络必须具备灵活调整资源配置的能力。XnAP协议为此设计了两套核心的修改流程，分别代表了两种不同的指挥哲学：一种是自顶向下的命令，另一种是自下而上的建议。”

今天，我们将深入剖析这两种流程，看看作为“总指挥”的MN是如何下达调整指令，以及作为“前线副手”的SN又是如何基于战场洞察提出战术建议的：

• 8.3.3 M-NG-RAN node initiated S-NG-RAN node Modification Preparation：总指挥的命令 - MN主导的资源再分配。
• 8.3.4 S-NG-RAN node initiated S-NG-RAN node Modification：副手的建议 - SN基于本地情况主动请示调整。

2. 8.3.3 M节点发起的S节点修改准备 - “总指挥”的命令

这是双连接中最主要的资源调整方式，体现了MN的核心控制地位。当MN基于全局信息（如核心网指令、自身负载、UE的总体移动性等）认为需要调整SN的资源时，便会发起此流程。

2.1 8.3.3.1 General (概述) - 总指挥的三板斧

This procedure is used to enable an M-NG-RAN node to request an S-NG-RAN node to either modify the UE context at the S-NG-RAN node or to query the current SCG configuration … or to provide the S-RLF-related information…

陈工的解读：“这个流程赋予了MN三大权力，就像总指挥手中的三板斧：”

1. 修改 (Modify)：这是最核心的权力，可以命令SN增加、删除或修改UE的承载资源。
2. 查询 (Query)：在做出重大决策前，MN可以先向SN“摸底”，查询SN当前为UE配置的详细无线参数，做到知己知彼。
3. 通告 (Provide)：当MN检测到SCG可能发生无线链路失败（S-RLF）时，可以将相关信息通告给SN，用于故障诊断。

2.2 8.3.3.2 Successful Operation (成功操作) - 一场精密的“战术推演”

这是一个标准的Class 1流程，有来有回，确保了每一次战术调整都能得到确认。

第一步：MN的“战术调整令” - S-NODE MODIFICATION REQUEST

The M-NG-RAN node initiates the procedure by sending the S-NODE MODIFICATION REQUEST message to the S-NG-RAN node. When the M-NG-RAN node sends the S-NODE MODIFICATION REQUEST message, it shall start the timer TXnDCprep.

MN向SN发送S-NODE MODIFICATION REQUEST消息，并启动TXnDCprep定时器，等待SN的响应。

核心IE解析：

• PDU Session Resources To Be Added/Modified/Released Item IE: 这是MN的“指令清单”。

  • 场景A：增加业务 - 直播时，小杰又开始了一个云盘下载。MN决定将这个新业务添加到SN。MN会在PDU Session Resources To Be Added Item IE中详细描述新承载的QoS要求。
  • 场景B：修改业务 - 网络波动，MN决定修改直播流分离承载的QoS参数。MN会在PDU Session Resources To Be Modified Item IE中携带这些需要修改的参数。
  • 场景C：释放业务 - 直播结束，MN需要通知SN释放相关资源。MN会在PDU Session Resources To Be Released Item IE中指明要释放的DRB ID。

• SCG Configuration Query IE: 当MN需要SN的当前配置时，会将此IE设为true。这是一个“只读”请求。

• M-NG-RAN node to S-NG-RAN node Container IE: MN下达具体无线配置的“施工图纸”（RRC CG-ConfigInfo），封装在这个透明容器中。

第二步：SN的“可行性分析”与响应 - S-NODE MODIFICATION REQUEST ACKNOWLEDGE

SN收到请求后，会进行资源准入和配置准备，然后回复S-NODE MODIFICATION REQUEST ACKNOWLEDGE消息。

核心IE解析：

• PDU Session Resources Admitted... 与 ...Not Admitted List: SN在此逐项反馈对MN指令的执行结果。对于成功的，会提供用户面隧道信息；对于失败的，会附上原因。
• S-NG-RAN node to M-NG-RAN node Container: 这是最重要的“回执”。SN将准备好的、需要UE应用的RRC配置（或查询结果）打包在此容器中，交还给MN。

MN收到ACK后，停止定时器，并将SN返回的RRC配置通过RRCReconfiguration消息发给UE，完成最终的战术执行。

3. 8.3.4 S节点发起的S节点修改 - “副手”的建议

当SN基于其本地的、更实时的无线环境洞察，认为需要调整配置时，它也可以主动向MN发起流程。

3.1 8.3.4.1 General (概述) - 来自前线的“炮火校准”请求

This procedure is used by the S-NG-RAN node to modify the UE context in the S-NG-RAN node.

陈工的解读：“这是双连接中‘分布式智能’的体现。SN就像前线的炮兵观察员，它最清楚目标区域（与UE的空口）的风向、湿度等实时情况。当它发现炮弹落点有偏差时（如链路质量变化），它可以主动向后方指挥部（MN）发起一次‘炮火校准’请求。”

3.2 8.3.4.2 Successful Operation (成功操作) - 从“提议”到“联席决策”

这也是一个Class 1流程。SN的“建议”必须得到MN的“批准”。

第一步：SN的“战术建议书” - S-NODE MODIFICATION REQUIRED

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

SN向MN发送S-NODE MODIFICATION REQUIRED消息，并启动一个TXnDCoverall长定时器，监控整个流程的端到端完成。

核心IE解析：

• S-NG-RAN node to M-NG-RAN node Container IE: 这是消息的灵魂。SN的RRC层将自己建议的新配置（如SCG-Config的片段）打包在这个容器里。例如，建议激活一个新的辅载波（SCell）。
• Cause IE: SN说明发起修改的原因，如radio-reasons。

第二步：MN的“全局裁决”与回复

MN收到SN的建议后，会从全局视角评估其可行性，然后回复S-NODE MODIFICATION CONFIRM（同意）或S-NODE MODIFICATION REFUSE（拒绝）。

• S-NODE MODIFICATION CONFIRM (9.1.2.9)：如果MN同意，它会在响应的Container中放入最终批准的RRC配置，这个配置可能与SN的原始建议有所不同。
• S-NODE MODIFICATION REFUSE (9.1.2.10)：如果MN拒绝，它必须在Cause IE中说明原因。更有趣的是，MN还可以在Container中提出一个“反建议”，实现了一次高效的“协商”。

完整的闭环:

1. SN发起REQUIRED → MN回复CONFIRM。
2. MN向UE发送RRCReconfiguration。
3. UE回复RRCReconfigurationComplete给MN。
4. MN向SN发送S-NODE RECONFIGURATION COMPLETE（8.3.2节流程），告知UE已成功执行。
5. SN收到COMPLETE后，停止TXnDCoverall定时器。

4. 主从发起的修改流程对比 - 命令与建议的艺术

特性/维度	8.3.3 MN-initiated Modification (MN发起)	8.3.4 SN-initiated Modification (SN发起)
发起方	M-NG-RAN node (主节点)	S-NG-RAN node (次节点)
驱动力	全局/上层驱动 (核心网指令, 全局负载)	局部/底层驱动 (本地无线环境变化)
发起消息	S-NODE MODIFICATION REQUEST	S-NODE MODIFICATION REQUIRED
流程角色	命令与执行	建议与裁决
定时器	TXnDCprep (短定时器，监控准备阶段)	TXnDCoverall (长定时器，监控端到端完成)
场景比喻	总指挥下达作战命令	前线军官提出战术建议

5. 总结：双连接的“民主集中制”

M-NG-RAN node initiated S-NG-RAN node Modification Preparation和S-NG-RAN node initiated S-NG-RAN node Modification这两个流程，共同构成了5G双连接动态管理的“民主集中制”。

• “民主”：赋予了身处一线的SN基于实时无线环境的“发言权”和“建议权”，使得网络的优化决策能更快地响应局部变化。
• “集中”：始终将最终的决策权和对UE的唯一指挥权保留在MN手中，保证了UE配置的唯一性和全网策略的一致性。

这套双向、互补的修改机制，使得双连接系统能够像一个拥有“大脑”（MN）和“敏锐神经末梢”（SN）的有机体一样高效运作，根据瞬息万变的业务需求和无线环境，进行着永不停歇的自我调整和优化。

FAQ

Q1：为什么MN发起的修改流程叫做“Preparation”（准备），而SN发起的没有？ A1：这是一个细微但重要的命名差异。M-NG-RAN node initiated S-NG-RAN node Modification Preparation的流程目标是在SN侧准备好修改所需的资源和配置，这个准备动作本身就是一个完整的Class 1流程。而S-NG-RAN node initiated S-NG-RAN node Modification流程，SN发起的REQUIRED消息本身只是一个“提议”，真正的资源准备和配置生成发生在MN收到提议并决策之后，并最终通过CONFIRM消息返回给SN。因此，从SN的角度，它发起的是一个完整的“修改”请求，而不仅仅是“准备”。

Q2：如果MN和SN几乎同时向对方发起了修改请求，会发生什么？ A2：这被称为“glare case”或流程冲突。规范（8.3.4.4节）明确了处理原则：MN发起的流程优先级更高。如果MN正在进行一个自己发起的修改流程，此时收到了来自SN的修改请求，MN应该拒绝SN的请求（回复REFUSE），以避免产生配置冲突。这确保了“总指挥”的绝对权威。

Q3：SN如何知道MN是否修改了它的原始提议？ A3：SN会将自己提议的配置（在REQUIRED的容器中）与MN在CONFIRM消息的容器中返回的最终配置进行比对。如果两者不一致，SN就知道MN进行了修改。无论如何，SN都必须无条件接受并应用MN在CONFIRM中给出的最终配置。

Q4：为什么SN发起修改时，启动的是长定时器TXnDCoverall？ A4：因为SN作为流程的发起者，它关心的是这次修改从“提出”到“UE最终执行完毕”的整个端到端过程是否成功闭环。它不仅需要等待MN的CONFIRM，还需要等待MN完成与UE的RRC交互后，再发来的S-NODE RECONFIGURATION COMPLETE。只有收到这个最终的“完成”通知，SN才能确认自己的优化建议真正落地生效。TXnDCoverall正是用来监控这个长周期的。

Q5：这些修改流程对用户的体验是无感的吗？ A5：绝大多数情况下是无感的。这些修改通常是微调，例如改变QoS参数、增加/删除一个辅载波等。整个过程通过RRC信令完成，UE在执行RRCReconfiguration时会有极短的中断（通常在毫秒级），对于大多数业务（包括视频和游戏）来说，这个中断时间短到用户无法察觉。这些流程的目的正是为了通过主动优化，避免未来可能出现的、用户能够感知到的性能劣化。