深度解析 3GPP TS 38.423：8.3.3 M节点发起的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”的核心章节。本文旨在为读者深入剖析在5G双连接（DC）建立之后，主节点（MN）如何作为“总指挥”，动态地、精细化地管理和调整次节点（SN）资源的关键信令流程。

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

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

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

“问得好！”陈工赞赏道，“你已经从‘建立连接’的思维，转向了‘管理连接’的思维。双连接的生命周期中，绝大部分时间都处于动态调整的状态。主节点MN作为这场‘协同作战’的唯一总指挥，必须拥有随时调整‘副手’（SN）任务和资源的能力。它需要一个强大的信令工具来下达这些调整指令。”

这个强大的工具，就是我们今天要深入剖析的XnAP流程——M-NG-RAN node initiated S-NG-RAN node Modification Preparation (M节点发起的S节点修改准备)。这不仅仅是一个简单的修改指令，它更像是一场由MN主导的、与SN之间的精密的“战术重估”与“资源再分配”的谈判。

2. 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 for supporting delta signalling in M-NG-RAN node initiated S-NG-RAN node change, or to provide the S-RLF-related information to the S-NG-RAN node.

陈工为小林逐一解析这段概述，揭示了这个流程蕴含的三大核心功能：

1. 修改UE上下文 (Modify UE Context)：这是最核心的功能。MN可以请求SN增加、删除或修改UE的承载资源。这就像总指挥下达命令：“友军，请增派一个火力小组（添加承载），或者让你的狙击手转移阵地（修改承载）。”
2. 查询SCG配置 (Query SCG Configuration)：MN在进行某些复杂操作（如MN发起的SN变更）前，可能需要先了解SN当前为UE配置的详细无线参数。这就像总指挥在下达新命令前，先问询：“友军，请报告你当前的兵力部署情况。” 这对于后续生成**增量配置（delta configuration）**至关重要，能极大地节省宝贵的空口资源。
3. 提供S-RLF信息 (Provide S-RLF-related information)：S-RLF即次节点无线链路失败（Secondary Radio Link Failure）。当MN检测到UE与SN之间的连接可能已经中断时，它需要将相关的失败信息通知给SN，以便SN进行故障诊断和资源清理。这就像总指挥通知：“友军，你与前方的联络可能已经中断，请核实。”

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

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

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

当MN决定需要调整SN的资源时，它会向SN发送S-NODE MODIFICATION REQUEST消息，并启动TXnDCprep定时器，等待SN的响应。

The S-NODE MODIFICATION REQUEST message may contain

• PDU session resources to be added within the PDU Session Resources To Be Added Item IE;
• PDU session resources to be modified within the PDU Session Resources To Be Modified Item IE;
• PDU session resources to be released within the PDU Session Resources To Be Released Item IE;
• the SCG Configuration Query IE;
• the M-NG-RAN node to S-NG-RAN node Container IE;

场景代入与核心IE解析： 让我们回到“V-Log小杰”的直播场景。

• 场景A：增加业务 直播期间，小杰收到了一份来自云盘的超大素材文件下载任务。核心网通知MN为这个下载任务建立一个新的GBR承载。MN判断自身上行资源紧张，但SN的下行资源充裕，于是决定将这个下载业务完全添加到SN上。MN会在PDU Session Resources To Be Added Item IE中详细描述这个新承载的QoS要求和安全参数。

• 场景B：修改业务 由于网络波动，MN的RRM算法决定需要调整直播流分离承载的QoS参数（例如，调整GBR值或RLC模式），以保证直播的流畅度。MN会在PDU Session Resources To Be Modified Item IE中携带这些需要修改的参数。

• 场景C：释放业务 小杰的8K直播结束了。MN需要通知SN释放为这个直播流分配的所有无线和传输资源。MN会在PDU Session Resources To Be Released Item IE中指明需要释放的DRB ID。

• 场景D：查询配置 MN准备将小杰切换到一个新的小区，新的小区将成为新的MN。在生成包含完整双连接配置的切换指令前，MN需要知道当前SN的精确RRC配置。此时，MN会在请求中包含SCG Configuration Query IE并设置为true。这相当于一个“只读”请求，告诉SN：“请把当前配置发给我，不要做任何修改。”

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

SN收到MN的请求后，会立即进行可行性分析和资源准备。

1. 资源准入：对于添加或修改的承载请求，SN会进行严格的资源准入控制。
2. 配置准备：SN根据请求，结合自身的资源状况，准备好需要更新的无线配置。
3. 生成响应：SN将处理结果打包成S-NODE MODIFICATION REQUEST ACKNOWLEDGE消息回复给MN。

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

• 反馈各类资源处理结果：通过PDU Session Resources Admitted To Be Added List、...Modified List、...Released List等列表，SN精确地向MN反馈了哪些请求被成功接受。
• PDU Session Resources Not Admitted List：对于无法满足的请求，SN会在这里明确列出，并附上失败原因Cause，例如no-radio-resources-available。
• S-NG-RAN node to M-NG-RAN node Container: 这是最重要的“回执”内容。SN将准备好的、需要UE应用的**RRC配置（或增量配置）**打包在这个透明容器中。如果是对查询请求的响应，这里将包含SN当前的完整SCG配置。

MN收到ACK后，停止TXnDCprep定时器。至此，XnAP层面的修改准备完成。接下来，MN会将SN返回的RRC容器中的内容，整合进发往UE的RRCReconfiguration消息中，完成最终的战术执行。

4. 失败与异常：当“计划”遭遇现实

4.1 8.3.3.3 Unsuccessful Operation (失败操作)

If the S-NG-RAN node does not admit any modification requested by the M-NG-RAN node, or a failure occurs during the M-NG-RAN node initiated S-NG-RAN node Modification Preparation, the S-NG-RAN node shall send the S-NODE MODIFICATION REQUEST REJECT message…

如果SN完全无法满足MN的任何一项修改请求，例如SN自身发生故障或处于极度拥塞状态，它将直接回复S-NODE MODIFICATION REQUEST REJECT，彻底拒绝这次“战术调整”。

4.2 8.3.3.4 Abnormal Conditions (异常条件) - 超时的代价

If the timer TXnDCprep expires before the M-NG-RAN node has received the S-NODE MODIFICATION REQUEST ACKNOWLEDGE message, the M-NG-RAN node shall regard the M-NG-RAN node initiated S-NG-RAN node Modification Preparation procedure as being failed and shall release the UE Context at the S-NG-RAN node.

陈工严肃地对小林说：“这是你需要特别注意的一条规则，它体现了协议的严厉性。如果MN的‘耐心计时器’TXnDCprep超时，它不仅会认为这次修改失败，而且会做出一个激进的决定：释放整个SCG。也就是说，它会启动S-NODE RELEASE流程，直接把SN这个‘失联’的副手给‘开除’了。这保证了UE的连接不会因为一个状态未知的SN而处于风险之中，体现了‘宁可断其一指，不伤其十指’的设计思想。”

5. 总结：双连接的“动态大脑”

M-NG-RAN node initiated S-NG-RAN node Modification Preparation流程，是双连接生命周期管理的核心工具，是主节点MN行使其“总指挥”权力的主要信令手段。它使得双连接不再是一个静态的配置，而是一个能够根据业务需求和网络环境实时演进的“活”系统。

• 它是资源管理的“瑞士军刀”：集增、删、改、查功能于一体，提供了对SN资源的全面、精细化管理能力。
• 它是空口效率的“优化器”：通过支持配置查询和增量配置，最大限度地减少了不必要的RRC信令开销。
• 它是系统健壮性的“守护者”：通过严密的定时器机制和失败处理流程，确保了在任何情况下，双连接的状态都能保持一致和可控。

对于小林这样的协议开发者而言，这个流程的复杂性在于需要处理多种不同类型的修改请求组合，并正确地与RRC层进行交互以生成和解析透明容器。对于网络优化工程师，通过分析REJECT消息和修改成功率，可以深入洞察网络中双连接的动态性能瓶颈。

FAQ

Q1：MN发起的修改（本章）和SN发起的修改（后续章节）有什么根本区别？ A1：根本区别在于决策的发起者和驱动力。MN发起的修改通常是“上层驱动”或“全局视角”的决策，例如：核心网请求建立新承载、MN自身发生拥塞需要进行负载均衡、MN为了执行切换而需要查询SN配置等。MN是决策者。而SN发起的修改通常是“底层驱动”或“局部视角”的建议，例如：SN检测到其与UE之间的无线链路质量变化，建议调整无线参数。SN是建议者，最终决策权仍在MN。

Q2：S-NODE MODIFICATION REQUEST中的“Preparation”是什么意思？ A2：这里的“Preparation”（准备）与“Handover Preparation”中的含义类似。这个XnAP流程本身并不会直接改变UE的配置。它只是MN和SN之间的一次“幕后”协商和准备过程。SN在回复ACKNOWLEDGE时，仅仅是准备好了RRC配置信息，并将其交给了MN。真正的修改要等到MN将这些配置通过RRCReconfiguration消息发送给UE，并且UE成功应用后才算完成。

Q3：为什么MN在定时器超时后要直接释放SCG，这个处理方式是不是太激进了？ A3：这是一种“快速失败”（Fail-fast）的设计哲学，以保证用户业务的稳定性为最高优先级。当MN无法在规定时间内确认SN的状态时，它会面临一个不确定的局面：SN是否已经崩溃？它是否还能正常服务UE？为了避免UE的数据被发往一个状态未知的节点，或者RRC信令出现混乱，最安全、最保守的做法就是立即切断与这个“失联”节点的联系，将所有业务收回到可控的MN上。虽然这可能会暂时降低UE的速率，但保证了连接的连续性，避免了掉话等更严重的问题。

Q4：一个S-NODE MODIFICATION REQUEST消息中可以同时包含添加、修改和释放承载的请求吗？ A4：是的，可以。这个流程非常灵活，允许MN在一个消息中打包多个不同类型的操作。例如，MN可以同时请求释放一个已经结束的业务承载，并为另一个新业务添加一个新的承载。SN会对列表中的每一个item进行独立处理，并在响应中分别反馈各自的结果。

Q5：SCG Configuration Query IE的主要用途是什么？ A5：它的主要用途是为了支持增量RRC配置（delta configuration）。当MN需要对SN的配置进行微调时，如果它能知道SN当前的完整配置，就可以只计算出变化的“增量”部分，然后通过RRC信令只告诉UE这些变化点，而不是每次都发送完整的SCG配置。这可以大大减小RRCReconfiguration消息的体积，节省空口资源，降低信令开销。SCG Configuration Query IE就是MN获取这个“配置基线”的标准方式。