深度解析 3GPP TS 38.423：8.3.8 - 8.3.11 双连接下的运维与监控

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.8 S-NG-RAN node Counter Check”、“8.3.9 RRC Transfer”、“8.3.10 Notification Control Indication”以及“8.3.11 Activity Notification”这四个核心章节。本文旨在将这些支撑双连接（DC）高效、安全、智能运行的辅助流程进行整合解读，为读者揭示5G网络精细化管理的“幕后英雄”。

1. 引言：从“连接”到“洞察”

在之前的系列文章中，我们跟随初级工程师小林和他的导师陈工，已经全面掌握了5G双连接（DC）从建立、动态修改到最终释放的完整生命周期。这些流程确保了网络能够为用户提供强大的数据传输能力。然而，仅仅“连接”是不够的，一个现代化的、智能化的网络，更需要具备强大的“洞察”能力——即实时监控连接状态、保障服务质量、传递关键信息并确保通信安全。

这天，运维中心转来一个棘手的投诉。一位名叫“电竞玩家小张”的用户反映，他在进行一场重要的云游戏比赛时，尽管手机信号满格且显示为5G+（表示处于双连接状态），但每隔几分钟就会出现一次短暂但致命的延迟抖动（lag spike），导致操作失误。

小林接到任务后有些犯愁：“陈工，从主流程来看，小张的双连接是稳定建立的，也没有发生频繁的修改或释放。我们该从何下手，去捕捉这种偶发的、瞬时的性能劣化呢？”

陈工微微一笑：“这正是检验我们是否真正理解网络‘神经系统’的时刻。主流程搭建的是‘骨架’，而我们今天要学习的这些辅助流程，就是遍布骨架之上的‘神经末梢’和‘传感器’。它们负责向‘大脑’（MN和后台O&M系统）实时汇报连接的各种细微状态。要诊断小张的问题，我们就必须学会使用这套精密的‘诊断工具箱’。”

这个“诊断工具箱”正是由XnAP协议中一系列看似不起眼，实则至关重要的流程组成：

• 8.3.10 Notification Control Indication (通知控制指示)：QoS承诺的“警报器”，在服务质量无法保证时及时拉响警报。
• 8.3.11 Activity Notification (活动通知)：用户活跃度的“心电图”，为网络节能和资源管理提供决策依据。
• 8.3.9 RRC Transfer (RRC传输)：节点间关键无线信息的“情报专线”。
• 8.3.8 S-NG-RAN node Counter Check (S节点计数器检查)：通信安全的“定期审计员”。

通过深入理解并联合运用这些流程，我们就能从“连接”的表象，深入到“洞察”的内核，揭开小张游戏卡顿背后的秘密。

2. 8.3.10 Notification Control Indication - QoS的“警报器”

云游戏对网络质量，特别是时延和保证带宽（GBR）的要求极为苛刻。双连接建立时，MN和SN共同为小张的游戏业务承诺了特定的QoS。但如果承诺无法兑现，网络必须有反馈机制。

2.1 8.3.10.1 General (概述)

The purpose of the Notification Control indication procedure is to provide information that for already established GBR QoS flow(s) for which notification control has been requested, the NG-RAN node involved in Dual Connectivity cannot fulfil the GFBR anymore or that it can fulfil the GFBR again.

陈工的解读：“这是双连接中关于服务质量的‘诚信系统’。‘notification control’（通知控制）是核心网在建立GBR承载时可以激活的一个功能。一旦激活，承载路径上的所有节点（包括MN和SN）就承担了一项义务：一旦发现自己无法满足承诺的GBR，必须立刻向上游或协同节点报告。反之，当资源恢复，能够重新满足时，也要及时通知。这保证了QoS状态的透明化。”

2.2 8.3.10.2 & 8.3.10.3 双向的“警报”

这是一个Class 2的单向通知流程，根据发起方的不同，有不同的含义。

• SN发起的通知 (S-NG-RAN node initiated) 场景代入：SN所在的区域突然涌入大量用户，导致无线资源拥塞。SN发现无法再为小张的游戏流保证承诺的带宽。

  1. SN发送NOTIFICATION CONTROL INDICATION：SN立即向MN发送此消息。
  2. 核心IE - not-fulfilled：消息中指明是哪个QoS流，并将Notification Information设置为not-fulfilled（不可满足）。
  3. 智能的“B计划”:

     For a QoS flow indicated as not fulfilled anymore the S-NG-RAN node may also indicate an alternative QoS parameters set which it can currently fulfil in the Current QoS Parameters Set Index IE. SN还可以在消息中附带一个Current QoS Parameters Set Index，告诉MN：“虽然我保证不了100Mbps了，但我还能保证50Mbps（一个预定义的备选QoS集合），你看是否能接受？”

  4. MN的决策：MN收到警报后，会立即采取行动。它可能会尝试将小张的游戏流完全切换回MN承载，或者接受SN提出的降级QoS方案并通知核心网，甚至直接释放SN以避免影响业务。

• MN发起的通知 (M-NG-RAN node initiated) 场景代入：对于一个由MN承载但由SN提供分离承载（Split Bearer）的GBR业务，如果MN一侧的资源发生变化，也需要通知SN。

  • 动作：MN向SN发送NOTIFICATION CONTROL INDICATION。例如，如果MN发现自己可以独立承担全部流量，它会通知SN该GBR流fulfilled，暗示SN可以降低为此流预留的资源级别。

诊断小张的问题：陈工指导小林检查网络日志。如果在小张报告卡顿的时间点附近，出现了SN发往MN的NOTIFICATION CONTROL INDICATION消息，且原因为not-fulfilled，那么问题的根源很可能就是SN侧的瞬时拥塞。

3. 8.3.11 Activity Notification - 节能的“心电图”

场景代入： 小张在两局游戏的间隙，放下手机休息了1分钟。此时，他的手机屏幕关闭，没有数据传输。

3.1 8.3.11.1 General (概述)

The purpose of the Activity Notification procedure is to allow an NG-RAN node to send notification to another NG-RAN node concerning: user data traffic activity…

陈工的解读：“双连接虽然性能强大，但代价是UE需要同时维护与两个基站的连接，功耗相对较高。为了省电，网络需要在UE空闲时，及时地将其转入RRC_INACTIVE状态或释放掉不必要的SCG。但MN如何知道UE在SN那一边是不是也在‘摸鱼’呢？Activity Notification就是SN向MN打的‘小报告’。”

3.2 8.3.11.2 Successful Operation (成功操作)

这是一个由SN发起的Class 2流程。

• 报告inactive: 当SN在配置的一段时间内（inactivityTimer）没有检测到任何属于小张的数据活动时，它就会向MN发送ACTIVITY NOTIFICATION，报告状态为inactive。
• 报告re-activated: 如果之后SN上又检测到了数据活动，它会立刻再发一个ACTIVITY NOTIFICATION，报告状态为re-activated。

MN的智能决策: MN作为“总指挥”，会汇总来自自身和所有SN的活动报告。如果所有链路都报告inactive，MN就知道整个UE都空闲了，便可以安全地启动节能程序：

1. 释放SCG：如果只是短期空闲，MN可以先通过S-NODE RELEASE流程释放掉SN，让UE只保持与MN的连接，降低功耗。
2. 转入INACTIVE：如果UE持续空闲，MN可以进一步将UE从RRC_CONNECTED态迁移到RRC_INACTIVE态，实现最大程度的节能。

诊断小张的问题：虽然这个流程与小张的卡顿问题不直接相关，但它体现了网络管理的精细化。如果网络为了过于激进的节能策略，频繁地释放和重建SCG，也可能在业务恢复的瞬间引入额外的时延。

4. 8.3.9 RRC Transfer - 节点间的“情报专线”

场景代入： MN需要了解SN侧的无线环境，以便做出更优的移动性决策。于是，MN通过RRC信令，指示小张的手机测量SN小区以及SN周围的邻区，并将测量报告（MeasurementReport）发回给MN。

4.1 8.3.9.1 & 8.3.9.2 - 透明的“信件”传递

The purpose of the RRC Transfer procedure is to deliver a PDCP-C PDU encapsulating an LTE RRC message or NR RRC message … from the S-NG-RAN-NODE, if it was received from the UE.

陈工的解读：“RRC Transfer就像一个可靠的‘内部邮差’。MN的RRC层收到UE发来的、但内容与SN高度相关的RRC消息时，可以直接把这个消息‘原封不动’地打包，通过XnAP的RRC TRANSFER流程发给SN。”

核心用途 (Dual Connectivity)：

• 转发UE测量报告：这是最常见的用途。MN将UE上报的关于SCG的测量报告，通过此流程转发给SN。SN收到后，就能实时了解到自己在UE眼中的信号质量，以及其邻区的状况，从而判断是否需要发起SN修改（8.3.4）或SN变更（8.3.5）流程。
• 转发UE能力信息：UE在连接过程中可能会上报更新的能力信息，如果与SN相关，MN也会通过此流程同步给SN。
• 转发SCG失败信息：当UE检测到SCG链路失败时，它会向MN上报SCGFailureInformation消息。MN收到后，必须通过RRC TRANSFER将这个“坏消息”立刻转发给SN，以便SN进行故障分析和记录。

诊断小张的问题：陈工让小林重点关注RRC TRANSFER消息中携带的MeasurementReport。如果在卡顿发生前，报告显示SN的信号质量（如RSRP/SINR）有瞬时的大幅下跌，或者检测到了强烈的外部干扰，那么问题的根源就基本锁定了——局部无线环境恶化。SN可能来不及发起修改流程，或者MN的响应不够快，导致了短暂的业务质量下降。

5. 8.3.8 S-NG-RAN node Counter Check - 安全的“审计员”

场景代入： 小张的游戏已经持续了很长时间。为了防止潜在的安全攻击（如重放攻击），网络需要确认UE和SN之间的安全上下文依然同步。

5.1 8.3.8.1 & 8.3.8.2 - 请求一次“对账”

This procedure is initiated by the S-NG-RAN node to request the M-NG-RAN node to execute a counter check procedure to verify the value of the PDCP COUNTs associated with SN terminated bearers…

这是一个由SN发起的Class 2流程。

1. SN发起S-NODE COUNTER CHECK REQUEST: SN基于内部策略（如定时触发），向MN发起请求。
2. MN执行RRC CounterCheck: MN收到请求后，利用其与UE的SRB1（主信令承载），向UE发送一个CounterCheck RRC消息，要求UE上报其本地为SN侧承载所记录的PDCP COUNT值。
3. MN处理结果: MN收到UE的CounterCheckResponse后，会将结果进行处理（在某些架构下可能需要转发给SN进行最终比对）。如果发现COUNT值不匹配，说明安全上下文可能已经泄露或失步，MN会立即采取措施，如触发密钥更新或直接释放SCG，以保障通信安全。

诊断小张的问题：虽然这与性能问题不直接相关，但它保证了小张在长时间游戏过程中的账户和数据安全。一个完整的网络诊断，不仅要看性能，也要关注安全状态。

6. 总结：从“管家”流程看网络智慧

小林恍然大悟。原来，双连接的稳定运行，背后有这么多“沉默的守护者”在辛勤工作。它们看似琐碎，却构成了网络自我感知、自我优化、自我修复能力的基石。

• Notification Control Indication是QoS的守护者，确保了服务承诺的可信度。
• Activity Notification是能耗的守护者，实现了极致性能与绿色节能的平衡。
• RRC Transfer是信息的守护者，打通了MN和SN的“信息孤岛”，实现了真正的协同RRM。
• S-NG-RAN node Counter Check是安全的守护者，为长期运行的连接提供了可靠的安全审计机制。

正是通过这些精细化的“管家”流程，5G双连接才不仅仅是一个简单的带宽叠加工具，而是一个能够感知环境、适应变化、保障质量、确保安全的智能化协同系统。要诊断小张的游戏卡顿问题，就需要将这些流程的日志信息与无线测量报告、用户面KPI进行关联分析，才能最终定位到瞬时干扰、资源瓶颈或信令交互延迟等根本原因。

FAQ

Q1：Activity Notification报告的“不活动”定时器是由哪个节点配置的？ A1：这个不活动定时器（inactivityTimer）是在SN侧配置和运行的。通常，它是在SN Addition或SN Modification流程中，由MN通过RRC容器（CG-ConfigInfo）告知SN的。这体现了MN作为主节点，对整个双连接的策略（包括节能策略）拥有最终的决定权。

Q2：RRC Transfer和流程中的各种Container IE有什么区别？ A2：两者都用于传递RRC信息，但用途和性质不同。Container IE（如M-NG-RAN node to S-NG-RAN node Container）是特定流程的一部分，用于在该流程中传递与该流程强相关的、一次性的RRC配置信息，例如在SN添加时传递初始配置。而**RRC Transfer是一个通用的、独立的流程**，它可以在双连接建立后的任何时刻，用于传递任意的、MN和SN之间需要共享的RRC消息，如周期性的测量报告、突发的SCG失败信息等。前者是“合同附件”，后者是“日常公文往来”。

Q3：为什么Counter Check只检查SN终止的承载，不检查分离承载（Split Bearer）？ A3：因为对于分离承载，其PDCP实体位于MN。MN是该承载的“主人”，它直接与UE进行该承载的PDCP层交互，因此MN可以自己直接发起针对分离承载的CounterCheck流程，无需通过XnAP请求SN。SN只对自己“当家作主”的SN终止承载负有安全审计的主要责任，因此它也只发起针对这些承载的检查请求。

Q4：如果SN报告GBR not-fulfilled，而MN也无能为力，UE的业务会立刻中断吗？ A4：不一定。GBR（保证比特率）是一个“软”保证。当网络无法满足时，并不会立即切断业务。首先，业务质量会下降，例如小张的8K直播可能会降为4K或1080p。同时，MN会向核心网（通过NGAP）报告QoS流未满足。核心网的PCF（策略控制功能）会根据策略做出最终决定，可能会接受降级的QoS继续提供服务，或者在极端情况下，如果连最低要求都无法满足，可能会决定释放这个QoS流，此时业务才会中断。

Q5：这些监控流程都是Class 2的，它们的可靠性如何保证？ A5：它们的可靠性主要由下层的SCTP协议保证。SCTP是一个可靠的传输协议，自带确认和重传机制。在网络链路正常的情况下，可以认为消息是能够可靠送达的。设计为Class 2主要是为了应用层的效率，因为这些通知和报告，丢失一次通常不是致命的（后续的报告会更新状态，或者上层有超时机制），而省去了应用层的确认交互，可以大大降低信令处理的开销和时延。