51学通信

深度解析 3GPP TS 38.423：8.3.4 S节点发起的S节点修改

17分钟阅读

深度解析 3GPP TS 38.423：8.3.4 S节点发起的S节点修改

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.4 S-NG-RAN node initiated S-NG-RAN node Modification”的核心章节。本文旨在为读者深入剖析在5G双连接（DC）场景下，作为“副手”的次节点（SN）如何基于本地无线环境洞察，主动向主节点（MN）“建言献策”，共同完成对UE无线资源动态调整的精妙协同流程。

1. 引言：当“副手”有了自己的“想法”

在上一篇文章中，我们探讨了主节点（MN）作为“总指挥”，如何通过S-NODE MODIFICATION PREPARATION流程，主动发起对次节点（SN）资源的调整。这是一种自顶向下的、命令式的管理模式。然而，在瞬息万变的无线战场上，身处“前线”、与UE直接进行无线交互的SN，往往对局部的信道质量、干扰情况有着最直接、最实时的感知。

我们的主角工程师小林在观摩了一场双连接的路测后，向导师陈工提出了新的观察：“陈工，我发现有时候网络日志显示，是SN先检测到了问题，比如它与UE之间的某条链路质量突然下降，但MN似乎过了一小会儿才做出反应，下发重配指令。SN不能自己主动要求做点什么吗？难道只能被动等待MN的指令？”

“这个问题问到了双连接协同设计的精髓！”陈工赞许道，“你观察到的，正是5G网络智能化和分布式智能的体现。如果SN每次发现问题都只能‘干着急’，等待MN的‘遥控指挥’，那么整个系统的响应速度和优化效率将大打折扣。为了赋予‘前线士兵’一定的主动权，XnAP协议设计了一个‘自下而上’的沟通渠道，这就是我们今天要学习的流程——S-NG-RAN node initiated S-NG-RAN node Modification (S节点发気のS节点修改)。”

这个流程，就好比在“V-Log小杰”的直播中，SN（副手）发现了一条更干净、干扰更小的“小路”（频点或波束），可以更好地传输数据。但它不能直接命令UE走这条小路，因为它没有指挥权。于是，它通过这个流程，向MN（总指挥）提交了一份详细的“战术调整建议书”：“报告总指挥，我发现一条更优路径，建议调整兵力部署（无线配置）！” MN在收到建议后，从全局视角进行最终决策。

2. 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. The procedure uses UE-associated signalling.

这段概述简洁明了，但其背后的含义却与MN发起的修改流程截然不同：

  • 发起方 (Initiator)：S-NG-RAN node。这是与8.3.3流程最根本的区别，主动权掌握在SN手中。
  • 目的 (Purpose)：修改SN节点上与UE相关的上下文。虽然是SN发起，但它要修改的是自己的配置，这需要通过MN的中转和批准。
  • 驱动力 (Driver)：通常是SN侧的内部RRM（无线资源管理）算法。例如，SN检测到上行干扰、链路质量变化，或者需要进行载波聚合（CA）的动态激活/去激活等，这些都可能触发此流程。

这个流程赋予了SN基于本地实时无线环境进行快速响应的能力，是实现精细化、动态化无线资源管理的重要一环。

3. 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定时器。这个定时器用于监控从“提出建议”到“UE最终执行完毕”的整个漫长过程。如果中间任何环节卡住，定时器超时将触发SN的异常处理。

S-NODE MODIFICATION REQUIRED消息的核心内容解析：

  • S-NG-RAN node to M-NG-RAN node Container IE: 这是整个消息的灵魂。它是一个透明容器，里面装着SN的RRC层精心准备的“建议配置”（通常是SCG-Config的一部分）。 场景代入：SN发现小杰手机所在的位置，使用另一个辅载波（SCell）的信号质量更好。于是，SN的RRC层会生成一个包含“激活这个新SCell”的配置片段，打包到这个容器里，发送给MN。

  • Cause IE: SN通常会附上发起这次修改的原因，例如radio-reasons（无线原因）或resource-optimisation（资源优化）。

  • QoS Flow Mapping Indication IE: 如果SN的修改建议涉及到QoS流到DRB的映射关系调整，可以通过这个IE来指示。

值得注意的是消息的名称——REQUIRED（需要），而不是REQUEST（请求）。这在3GPP的语言体系中，暗示了SN认为这次修改是从其自身视角来看，对于维持或优化服务质量是必要的、紧迫的。

第二步：MN的“全局裁决” - S-NODE MODIFICATION CONFIRM

MN收到SN的“建议书”后，作为“总指挥”，它不会全盘照收，而是会从全局视角进行评估：

  1. 策略符合性检查：SN的建议是否符合全网的RRM策略？例如，SN建议使用某个频点，但MN的策略是该频点优先用于高优先级用户，可能会否决。
  2. UE能力检查：UE是否支持SN建议的新配置？
  3. 与其他承载的协同：SN的修改是否会对MN侧的承载或其他业务产生负面影响？

评估完成后，如果MN同意执行（可能在SN建议的基础上做了微调），就会回复S-NODE MODIFICATION CONFIRM消息。

The M-NG-RAN node may also provide configuration information in the M-NG-RAN node to S-NG-RAN node Container IE.

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

  • M-NG-RAN node to S-NG-RAN node Container: 这是MN的“最终批示”。它里面装着MN最终决定要下发给UE的SCG配置。这个配置可能与SN最初建议的完全一样，也可能是MN修改后的版本。SN必须以这个容器里的内容为准。

流程的闭环：

  1. SN收到CONFIRM后，知道自己的建议已被批准，并将按MN的“最终版本”执行。它继续等待。
  2. MN将CONFIRM消息中容器里的配置，打包进RRCReconfiguration消息发给UE。
  3. UE成功应用配置后，回复MN。
  4. MN收到UE的成功回复后，再向SN发送**S-NODE RECONFIGURATION COMPLETE**消息（即我们在8.3.2节学习的流程）。
  5. SN收到COMPLETE消息后，停止TXnDCoverall定时器，一次完整的“SN发起-MN决策-UE执行-MN反馈”的闭环宣告完成。

4. 8.3.4.3 Unsuccessful Operation (失败操作) - 当“建议”被“驳回”

In case the requested modification cannot be performed successfully the M-NG-RAN node shall respond with the S-NODE MODIFICATION REFUSE message to the S-NG-RAN node with an appropriate cause value in the Cause IE. The M-NG-RAN node may also provide configuration information in the M-NG-RAN node to S-NG-RAN node Container IE.

如果MN在评估后决定拒绝SN的建议，它会回复S-NODE MODIFICATION REFUSE消息。

S-NODE MODIFICATION REFUSE的智慧：

  • Cause IE: MN必须给出拒绝的理由，例如unspecified（未指明）或rrm-purpose（RRM策略不允许）。
  • Container IE (可选): 这是该流程一个非常精巧的设计。MN可以在拒绝的同时，通过这个容器提出一个“反建议”。 场景代入：SN建议激活辅载波S1，但MN发现S1上有干扰，于是拒绝。但MN同时知道S2载波是空闲的，它可以在REFUSE消息的容器中附上“激活S2”的建议配置。SN收到后，虽然原始请求被拒，但可以评估并接受MN的“反建议”，从而避免了一次新的流程发起，极大地提高了协同效率。这使得简单的“拒绝”变成了一次有效的“协商”。

5. 8.3.4.4 Abnormal Conditions (异常条件) - “指挥链”中的冲突

If the timer TXnDCoverall expires before the S-NG-RAN node has received the S-NODE MODIFICATION CONFIRM or the S-NODE MODIFICATION REFUSE message, the S-NG-RAN node shall regard the requested modification as failed… Interaction with the M-NG-RAN node initiated S-NG-RAN node Modification procedure: …the M-NG-RAN node shall refuse the S-NG-RAN node modification procedure…

  • SN侧的超时：如果SN发出的REQUIRED消息石沉大海，其TXnDCoverall定时器超时，SN会认为修改失败，并可能采取措施，如上报SCG失败。
  • 流程冲突：如果MN正在进行一个自己发起的修改流程（8.3.3），此时收到了来自SN的修改请求（8.3.4），MN通常会拒绝SN的请求，以避免向UE发送相互冲突的RRC指令。这确立了MN发起流程的优先级高于SN发起流程的基本原则，保证了“总指挥”的绝对权威。

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

S-NG-RAN node initiated S-NG-RAN node Modification流程，是5G双连接智能化管理的重要体现。它与MN发起的修改流程共同构成了一套完整的、双向的动态协同机制，堪称双连接管理中的“民主集中制”。

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

这个流程的设计，完美地平衡了分布式智能的快速响应和集中式控制的全局最优，使得双连接系统能够像一个拥有“大脑”（MN）和“敏锐神经末梢”（SN）的有机体一样高效运作。

FAQ

Q1：S-NODE MODIFICATION REQUIRED和S-NODE MODIFICATION REQUEST有什么区别？ A1：在XnAP中，REQUIRED和REQUEST通常用于区分流程的发起方和性质。REQUIRED（如本章的S-NODE MODIFICATION REQUIRED）通常由下级或对等节点向上级或协调节点发起，表示“我（发起方）认为这个改变是必要的”。而REQUEST（如8.3.3节的S-NODE MODIFICATION REQUEST）通常由上级或主导方向下级或被动方发起，表示“我（发起方）请求你执行这个操作”。这是3GPP信令命名的一种惯例，用以体现流程中的主从关系和驱动力来源。

Q2：如果MN在S-NODE MODIFICATION CONFIRM中修改了SN的提议，SN是否可以再次拒绝或协商？ A2：不可以。XnAP的这个流程设计是一轮“提议-裁决”模式。SN发送REQUIRED是提议，MN回复CONFIRM或REFUSE是最终裁决。一旦MN回复了CONFIRM，即使内容与SN的原始提议不同，SN也必须接受这个结果，并准备好按MN的最终版本来更新自己的上下文。如果SN认为MN的决策会导致严重问题，它后续的纠正手段通常是触发SCG Failure流程。

Q3：SN在什么情况下会发起这个修改流程？ A3：场景非常多，主要由SN的RRM算法驱动。例如：

  • 负载均衡：SN发现自身负载过高，可能会请求MN将部分分离承载（Split Bearer）的数据流更多地切回MN侧。
  • 载波聚合（CA）管理：SN发现UE可以聚合一个新的辅载波（SCell），于是请求添加该SCell；或者发现某个SCell质量不佳，请求去激活。
  • 波束管理：SN希望UE切换到另一组更优的波束上。
  • 上行传输优化：SN检测到上行干扰，请求MN调整UE的上行功率控制参数或调度策略。

Q4：整个“SN发起修改”的完整信令闭环是怎样的？ A4：一个完整的成功流程包含三个XnAP基本流程：

  1. SN发起（本章 8.3.4）: SN发送 S-NODE MODIFICATION REQUIRED → MN回复 S-NODE MODIFICATION CONFIRM。
  2. (RRC交互，空口): MN根据CONFIRM中的配置，向UE发送 RRCReconfiguration → UE回复 RRCReconfigurationComplete。
  3. MN反馈（8.3.2）: MN收到UE的成功回复后，向SN发送 S-NODE RECONFIGURATION COMPLETE。 只有当SN收到第3步的COMPLETE消息后，它才能100%确认自己的修改建议最终被UE成功执行了。

Q5：为什么SN启动的是TXnDCoverall定时器，这个定时器不是用于监控整个流程的吗？ A5：是的，这正是这个流程设计的严谨之处。TXnDCoverall是一个长定时器，其目的就是监控从SN发起请求开始，直到最终收到MN关于UE执行结果的反馈（即S-NODE RECONFIGURATION COMPLETE）为止的全过程。这与MN在S节点添加（8.3.1）或修改准备（8.3.3）成功后启动的TXnDCoverall不同（MN是在收到SN的ACK后才启动）。SN在发起请求时就启动这个长定时器，体现了它作为流程发起者，需要对整个流程的端到端完成情况负责。

关系图谱