深度解析 3GPP TS 38.423：9.1.2 双连接消息 (Part 4 - 运维与监控的“四驾马车”)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.2 Messages for Dual Connectivity Procedures”的核心章节，特别聚焦于
S-NODE COUNTER CHECK REQUEST(9.1.2.19),RRC TRANSFER(9.1.2.20),NOTIFICATION CONTROL INDICATION(9.1.2.21), 和ACTIVITY NOTIFICATION(9.1.2.22)。本文旨在将这些支撑双连接（DC）高效、安全、智能运行的辅助消息进行整合解读，揭示5G网络精细化管理的“幕后英雄”。
1. 引言：从“连接”到“洞察”
在之前的篇章中，我们已经深入探讨了5G双连接（DC）从建立、动态修改到最终释放的完整生命周期。这些流程确保了网络能够为用户提供强大的数据传输能力。然而，仅仅“连接”是不够的，一个现代化的、智能化的网络，更需要具备强大的“洞察”能力——即实时监控连接状态、保障服务质量、传递关键信息并确保通信安全。
这天，运维中心转来一个棘手的投诉。一位名叫“电竞玩家小张”的用户反映，他在进行一场重要的云游戏比赛时，尽管手机信号满格且显示为5G+（表示处于双连接状态），但每隔几分钟就会出现一次短暂但致命的延迟抖动（lag spike），导致操作失误。
我们的工程师小林接到任务后有些犯愁：“陈工，从主流程来看，小张的双连接是稳定建立的，也没有发生频繁的修改或释放。我们该从何下手，去捕捉这种偶发的、瞬时的性能劣化呢？”
陈工微微一笑：“这正是检验我们是否真正理解网络‘神经系统’的时刻。主流程搭建的是‘骨架’，而我们今天要学习的这些辅助消息，就是遍布骨架之上的‘神经末梢’和‘传感器’。它们负责向‘大脑’（MN和后台O&M系统）实时汇报连接的各种细微状态。要诊断小张的问题，我们就必须学会解读这套精密的‘诊断工具箱’。”
这个“诊断工具箱”正是由XnAP协议中一系列看似不起眼，实则至关重要的消息组成：
S-NODE COUNTER CHECK REQUEST(S节点计数器检查请求): 通信安全的“定期审计员”。RRC TRANSFER(RRC传输): 节点间关键无线信息的“情报专线”。NOTIFICATION CONTROL INDICATION(通知控制指示): QoS承诺的“警报器”。ACTIVITY NOTIFICATION(活动通知): 用户活跃度的“心电图”。
通过深入理解这些消息的“语言”，我们就能从“连接”的表象，深入到“洞察”的内核，揭开小张游戏卡顿背后的秘密。
2. 9.1.2.19 S-NODE COUNTER CHECK REQUEST - 安全的“审计员”
场景设定： 小张的游戏已经持续了很长时间。为了确保通信链路的持续安全，防止数据被篡改或重放，次节点（SN）需要定期或在特定事件触发时，与主节点（MN）核对安全上下文的“账目”。
这是一个由SN发起的Class 2流程，目的是请求MN通过UE来验证SN侧承载的PDCP COUNT值是否同步。
S-NODE COUNTER CHECK REQUEST 消息内容
| IE/Group Name (信息元素/组名) | Presence (存在性) | IE type and reference (IE类型和引用) | Semantics description (语义描述) |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| M-NG-RAN node UE XnAP ID | M | 9.2.3.16 | |
| S-NG-RAN node UE XnAP ID | M | 9.2.3.16 | |
| Bearers Subject to Counter Check List | 1 | 需要检查的承载列表 | |
| >Bearers Subject to Counter Check Item | 1.. | ||
| >>DRB ID | M | 9.2.3.33 | |
| >>UL COUNT | M | COUNT Value… | SN侧记录的上行COUNT值 |
| >>DL COUNT | M | COUNT Value… | SN侧记录的下行COUNT值 |
陈工的解读：“Counter Check是一次安全审计。SN将自己记录的、关于某个DRB的上下行COUNT值（由PDCP SN和HFN组成）打包发给MN。MN收到后，会通过RRC信令向UE发起CounterCheck流程，询问UE‘你记录的这个DRB的COUNT值是多少？’。MN将UE的回复与SN上报的值进行比对。如果发现不一致，就意味着出现了严重的安全上下文失步，MN必须立即采取措施，如触发密钥更新或直接释放SCG，以防止安全漏洞。”
3. 9.1.2.20 RRC TRANSFER - 节点间的“情报专线”
场景设定： MN为了优化移动性，需要UE测量邻区（包括SN下的小区）的信号质量。UE执行测量后，会将MeasurementReport消息通过其主RRC连接发送给MN。但这份报告对SN同样至关重要，SN需要它来判断是否要发起SN修改或变更。
这是一个Class 2流程，如同一个可靠的“内部邮差”，用于在MN和SN之间透明地传递RRC消息。
RRC TRANSFER 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| M-NG-RAN/New NG-RAN node UE XnAP ID | M | 9.2.3.16 | |
| S-NG-RAN/Old NG-RAN node UE XnAP ID | M | 9.2.3.16 | |
| CHOICE RRC Transfer type | 0..1 | 包含不同场景的RRC容器 | |
| >Split SRB >RRC Container | O | OCTET STRING | 用于传输SRB1/SRB2的RRC消息 |
| >UE Report >RRC Container | M | OCTET STRING | 关键！ 用于传输UE上报的RRC消息 |
| … |
陈工的解读：“这个消息最核心的应用就是转发UE的测量报告。MN收到UE关于SCG的MeasurementReport后，会将其原封不动地放入UE Report容器中，通过RRC TRANSFER消息发给SN。SN收到后，其RRC层解析出报告内容，就能实时了解到自己在UE眼中的信号质量。如果SN发现链路质量下降，它就可以主动发起S-NODE MODIFICATION REQUIRED流程，向MN建议调整配置。这是实现闭环无线资源管理的关键一步。”
诊断小张的问题: 如果在小张报告卡顿的时间点前，MN转发给SN的MeasurementReport显示SN的信号质量（如RSRP/SINR）有瞬时的大幅下跌，那么问题的根源就基本锁定了——局部无线环境恶化。
4. 9.1.2.21 NOTIFICATION CONTROL INDICATION - QoS的“警报器”
场景设定：小张的云游戏是一个GBR（保证比特率）业务。SN在接入时承诺为其提供20Mbps的稳定带宽。但突然，SN所在区域涌入大量用户，导致无线资源拥塞。
这是一个Class 2流程，由状态变化的一方主动发起单向通知。
NOTIFICATION CONTROL INDICATION 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| … | |||
| PDU Session Resource Notify List | 0..1 | ||
| >PDU Session Resource Notify Item | 1.. | ||
| >>QoS Flow Identifier | M | 9.2.3.10 | |
| >>Notification Information | M | ENUMERATED (fulfilled, not-fulfilled, …) | |
| >>Current QoS Parameters Set Index | O | Alternative QoS Parameters Set Notify Index 9.2.3.104 |
陈工的解读：“当SN发现无法再保证小张游戏流的20Mbps带宽时，它必须立刻向MN‘拉响警报’，发送此消息，并将Notification Information设置为not-fulfilled。更智能的是，SN还可以在Current QoS Parameters Set Index中提出一个‘B计划’，告诉MN：‘虽然20Mbps不行了，但我还能保证10Mbps（一个预定义的备选QoS集合），你看行不行？’。MN收到警报后，会立即评估，可能会将业务切回MN，或接受降级方案。这个流程保证了对GBR业务的服务质量承诺不是一句空话，而是一个动态监控、实时反馈的系统。”
诊断小张的问题：如果在卡顿时间点，日志中出现了SN发往MN的NOTIFICATION CONTROL INDICATION，那么卡顿的原因几乎可以肯定是SN侧的瞬时拥塞。
5. 9.1.2.22 ACTIVITY NOTIFICATION - 节能的“心电图”
场景设定： 小张在两局游戏的间隙，放下手机休息。此时，他的手机屏幕关闭，没有数据传输。
这是一个由SN发起的Class 2流程，目的是向MN报告UE的用户面活动情况，核心是节能。
ACTIVITY NOTIFICATION 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| … | |||
| UE Context level user plane activity report | O | User plane traffic activity report 9.2.3.59 | 报告整个UE的活动状态 |
| PDU Session Resource Activity Notify List | 0..1 | 报告每个PDU会話的活动状态 |
陈工的解读：“双连接很耗电。为了省电，网络需要在UE空闲时及时释放SCG或让UE进入RRC_INACTIVE态。SN通过ACTIVITY NOTIFICATION报告inactive状态，就是给MN递送了‘可以节能’的信号。当MN确认所有链路（包括MN自身）都处于inactive时，就可以安全地执行节能操作。而当SN上再次出现数据时，它会立刻报告re-activated，阻止MN的节能操作，确保业务的快速恢复。”
6. 总结：双连接运维的“四梁八柱”
小林恍然大悟。他明白了，双连接的稳定运行，远不止是主流程的成功执行那么简单。这四个“管家”消息，从安全、信息、质量、能耗四个维度，为双连接的日常运营提供了全方位的精细化管理和监控能力。
S-NODE COUNTER CHECK REQUEST是安全的基石。RRC TRANSFER是协同的桥梁。NOTIFICATION CONTROL INDICATION是质量的保障。ACTIVITY NOTIFICATION是效率的标尺。
正是这些在后台默默运行的“微操”流程，将5G双连接从一个单纯的性能增强技术，提升为了一个具备强大自我监控、自我诊断和自我优化能力的智能化协同系统。要解决“电竞玩家小张”的卡顿问题，就需要将RRC TRANSFER中的测量报告与NOTIFICATION CONTROL INDICATION中的QoS告警进行关联分析，才能最终定位到瞬时干扰或资源瓶颈等根本原因。
FAQ
Q1：为什么这些运维与监控的消息大多是Class 2（无响应）的？ A1：因为它们本质上是**通知性（Informational）或事件触发性（Event-triggered）**的。发起方只是在告知一个状态或传递一份情报，它不强求接收方立即回复“已收到”。这种设计大大降低了信令开销和处理时延。可靠性由底层的SCTP协议保障，而流程的闭环则由更上层的应用逻辑（如定时器、后续事件）来保证。
Q2：RRC Transfer是否可以用来传输任何RRC消息？
A2：理论上可以，但规范对其用途做了限定。它主要用于那些没有专门XnAP流程来传递，但对于节点间协同又至关重要的RRC消息，最典型的就是UE上报的各类报告（测量报告、SCG失败信息等）。它不是一个通用的RRC消息“隧道”，滥用它会破坏XnAP协议的结构化设计。
Q3：Activity Notification报告的“不活动”和UE进入RRC_INACTIVE状态有什么区别？
A3：两者是因果关系，但处于不同层面。Activity Notification是SN向MN报告的一个用户面数据活动状态的事件。而UE进入RRC_INACTIVE是MN基于包括Activity Notification在内的多种输入（如RRC信令、业务类型等），做出的一个RRC状态迁移的决策。SN只负责“报告现象”，MN负责“做出决策”。
Q4：如果SN报告GBR流not-fulfilled，而MN也无能为力，UE的业务会立刻中断吗？
A4：不一定。GBR（保证比特率）是一个“软”保证。当网络无法满足时，并不会立即切断业务。首先，业务质量会下降，例如小张的8K直播可能会降为4K或1080p。同时，MN会向核心网（通过NGAP）报告QoS流未满足。核心网的PCF（策略控制功能）会根据策略做出最终决定，可能会接受降级的QoS继续提供服务，或者在极端情况下，如果连最低要求都无法满足，可能会决定释放这个QoS流，此时业务才会中断。
Q5：S-NODE COUNTER CHECK REQUEST和RRCReconfiguration中包含的安全密钥更新有什么关系？
A5：Counter Check是检查现有密钥体系是否正常工作。而RRCReconfiguration可以用于下发新的密钥。Counter Check如果发现了问题（COUNT值不一致），可能会触发MN发起一次包含新密钥的RRCReconfiguration流程。前者是“审计”，后者是“换锁”。