51学通信

深度解析 3GPP TS 38.423：8.3.8-8.3.11 双连接的“管家”流程

21分钟阅读

深度解析 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. 引言：从“大战略”到“微操”

在之前的篇章中，我们跟随工程师小林和他的导师陈工，已经全面掌握了双连接（DC）的建立、修改、变更和释放等“主线任务”。这些流程如同战场上的大兵团作战，决定了UE是“联合作战”还是“分道扬镳”。

这天，小林在完成了一系列DC主流程的仿真后，陷入了新的思考：“陈工，一个双连接建立后，除了业务的增删改，似乎还有很多‘小事’需要处理。比如，网络如何知道UE是不是正在摸鱼发呆？如果之前承诺的QoS突然满足不了了，该怎么办？MN和SN之间想传递一些RRC层的‘悄悄话’，又该走哪个通道？还有，双连接的安全性如何进行日常的‘巡检’？”

“你的思考已经从‘战略家’转向了‘大管家’，”陈工赞许地说道，“一个高效的指挥部，不仅要有运筹帷幄的将军，更需要一群兢兢业业的参谋、通信兵和宪兵。他们处理着信息传递、状态监控、服务质量保障和安全审计等一系列‘琐事’，正是这些‘微操’，保证了整个战役的顺利进行。XnAP协议同样为双连接设计了这样一支‘管家团队’。”

今天，我们就来认识这支“管家团队”的四位核心成员，它们负责保障双连接在建立后的日常运营中，始终保持高效、敏捷和安全：

  • 8.3.10 Notification Control Indication (通知控制指示)：双连接QoS承诺的“晴雨表”。
  • 8.3.11 Activity Notification (活动通知)：UE数据传输的“心跳监测仪”。
  • 8.3.9 RRC Transfer (RRC传输)：节点间RRC信息的“专属信使”。
  • 8.3.8 S-NG-RAN node Counter Check (S节点计数器检查)：双连接安全性的“审计员”。

这些流程虽然不像主流程那样“惊天动地”，但它们是5G网络智能化、精细化运营的基石，是实现从“连接”到“优质连接”飞跃的关键。

2. 8.3.10 Notification Control Indication - QoS的“晴雨表”

场景设定： 视频博主“V-Log小杰”的8K直播流是一个GBR（Guaranteed Bit Rate，保证比特率）业务。在建立双连接时，MN和SN共同承诺为这个业务提供稳定的带宽保障。然而，网络负载是动态变化的。

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.

陈工解读道：“这个流程就是一张‘服务质量承诺履行情况通知单’。当一个节点（MN或SN）发现自己无法再满足之前承诺的GBR，或者之前无法满足的现在又可以满足了，它就有义务通知对方。这确保了参与双连接的双方，对关键业务的QoS状态有实时、同步的认知。”

2.2 两种方向的通知

这是一个Class 2流程，由状态变化的一方主动发起单向通知。

  • M-NG-RAN node initiated (MN发起，8.3.10.2)：

    • 场景：MN最初请求SN协助一个GBR业务，但现在MN自身的资源变得充裕，或者业务码率下降，MN可以独立支撑，不再需要SN的帮助了。
    • 动作：MN向SN发送NOTIFICATION CONTROL INDICATION，告知SN：“对于这个GBR流，你可以不必再为它预留保证带宽的资源了。”
    • 关键IE：消息中会包含QoS Flow Notification Control Indication Info，指明是哪个QoS流的状态发生了变化，以及新的状态是fulfilled（可满足）还是not-fulfilled（不可满足）。

  • S-NG-RAN node initiated (SN发起，8.3.10.3)：

    • 场景：SN之前承诺为某个GBR业务提供资源，但由于自身负载突然增加，无法再保证这个承诺。
    • 动作：SN向MN发送NOTIFICATION CONTROL INDICATION，告知：“报告总指挥，我这边资源紧张，无法再保证这个GBR流的带宽了。”
    • MN的反应：MN收到通知后，会立即评估情况。它可能会尝试自己承担全部流量，或者向核心网报告QoS无法满足，触发对业务码率的调整，甚至可能决定释放这个SN。
    • Current QoS Parameters Set Index:

      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在报告‘无法满足’的同时，还可以附带一个‘B计划’：‘虽然我满足不了你最初要求的100Mbps，但我现在还能保证50Mbps（一个预定义的Alternative QoS Set），你看行不行？’ MN收到后，就可以做出更灵活的决策。”

这个流程确保了对高价值GBR业务的QoS保障不是一句空话，而是一个动态监控、实时反馈的闭环系统。

3. 8.3.11 Activity Notification - 链路的“心跳监测仪”

场景设定： 小杰的直播结束后，双连接仍然保持着，用于他日常的网页浏览和社交媒体。这些业务的数据传输是突发性的，时断时续。

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 for the UE, or
  • user data traffic activity of already established QoS flows or PDU sessions, or
  • RAN Paging failure.

陈工解释说：“这个流程就像一个活动探测器。它主要用于SN向MN报告UE的用户面活动情况，核心目的是节能。”

3.2 8.3.11.2 Successful Operation (成功操作)

NG-RAN node1 initiates the procedure by sending the ACTIVITY NOTIFICATION message to NG-RAN node2.

这是一个Class 2的单向通知流程，通常由SN（node1）发往MN（node2）。

  • 报告inactive (不活动)：当SN在一段时间内没有检测到任何上行或下行数据活动时，它会向MN发送ACTIVITY NOTIFICATION，并在UE Context level user plane activity report IE中报告状态为inactive。

    • MN的决策：MN收到多个SN（如果UE配置了多个SCG）或同一个SN上所有承载的inactive通知后，就可以判断UE当前处于空闲状态，从而可以决策将UE切换到RRC_INACTIVE态，或者释放SN以节省网络资源和UE功耗。

  • 报告re-activated (重新激活)：当一个已报告为inactive的承载上，突然又有新的数据到达时，SN会立刻发送ACTIVITY NOTIFICATION，报告状态为re-activated。

    • MN的决策：这会阻止或推迟MN即将做出的释放SN或让UE休眠的决定。

这个流程使得MN对UE的活动状态了如指掌，从而能够做出更智能、更及时的功耗与资源管理决策。

4. 8.3.9 RRC Transfer - 节点间的“信息信使”

场景设定： MN为了优化移动性，需要UE测量邻区（包括SN下的小区）的信号质量。UE执行测量后，会将MeasurementReport消息通过其主RRC连接发送给MN。但这份报告对SN同样至关重要，SN需要它来判断是否要发起SN修改或变更。

4.1 8.3.9.1 General (概述)

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

陈工解读道：“这个流程就是MN和SN之间的一条‘RRC消息专用快递通道’。它允许一个节点将一个完整的RRC消息（或其核心内容）透明地转发给另一个节点。”

4.2 双向的“快递服务”

这是一个Class 2流程，根据方向有不同的用途：

  • 从MN到SN (下行传输)：MN可以将需要SN侧配合的RRC消息（如包含SCG配置的RRCReconfiguration的一部分）通过这个流程发给SN，尽管更常见的做法是用主流程中的专用容器。
  • 从SN到MN (上行传输)：这是更典型的用途。
    • RRC Container in UE Report IE: 当SN需要将从UE收到的、但必须由MN处理的RRC消息（例如，在某些特定配置下）转发给MN时使用。
    • Fast MCG Recovery via SRB3: 在SRB3（一种特殊的信令承载）上，当SN检测到与MN的连接（MCG）可能发生故障时，UE可以通过SN向MN发送MCG Failure信息，这个信息就是通过RRC Transfer流程传递的。

场景代入：

  1. UE将关于SN小区的MeasurementReport发给MN。
  2. MN的RRC层收到后，发现这个报告内容与SN密切相关。
  3. MN的XnAP层将这个MeasurementReport打包进RRC TRANSFER消息的RRC Container中，发送给SN。
  4. SN收到后，其RRC层解析出报告内容，并根据其中的测量结果做出下一步的RRM决策（例如，向MN发起8.3.4流程请求修改配置）。

这个流程极大地增强了双连接的协同灵活性，使得RRC层的紧密互动不再局限于初始建立时的配置下发。

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

场景设定： 双连接已经稳定运行了一段时间。为了确保通信链路的持续安全，防止数据被篡改或重放，SN需要定期或在特定事件触发时，与MN核对安全上下文的“账目”。

5.1 8.3.8.1 General (概述)

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 established in the S-NG-RAN node.

陈工解释道：“这是SN发起的一次安全审计请求。我们知道，PDCP COUNT值是安全算法（加密和完整性保护）的关键输入之一，它必须在UE和网络侧严格同步。如果出现不同步，就可能意味着存在安全漏洞。这个流程就是SN请求MN：‘请你通过UE核实一下，我们双方记录的COUNT值是否一致？’”

5.2 8.3.8.2 Successful Operation (成功操作)

这是一个Class 2流程，SN只负责发起请求。

The S-NG-RAN node initiates the procedure by sending the S-NODE COUNTER CHECK REQUEST message to the M-NG-RAN node. Upon reception of the S-NODE COUNTER CHECK REQUEST message, the M-NG-RAN node may perform the RRC counter check procedure as specified in TS 33.401 and 33.501.

  1. SN发起S-NODE COUNTER CHECK REQUEST：消息中包含了需要检查的承载列表。
  2. MN执行RRC Counter Check：MN收到请求后，会触发一个RRC层的CounterCheck流程。它向UE发送CounterCheck消息，要求UE上报其本地记录的、与SN相关的承载的COUNT值。
  3. 结果处理：MN收到UE的CounterCheckResponse后，会将UE上报的值与网络侧的值进行比对。如果发现不一致，MN会采取相应的安全措施，例如触发密钥更新，甚至释放SCG连接。

这个流程虽然不直接参与数据传输，但它为双连接提供了一道重要的安全防线，确保了长期运行下的数据通信安全。

6. 总结：“管家团队”的协同智慧

小林恍然大悟。他明白了，双连接的稳定运行，远不止是主流程的成功执行那么简单。这四个“管家”流程，从QoS、功耗、信令和安全四个维度，为双连接的日常运营提供了全方位的精细化管理和监控能力。

  • Notification Control Indication 保证了服务质量的透明与可协商。
  • Activity Notification 实现了对终端功耗和网络资源的智能管理。
  • RRC Transfer 打通了节点间RRC层的信息壁垒，实现了更深度的无线协同。
  • S-NG-RAN node Counter Check 构筑了双连接长期运行的安全基石。

它们共同协作，确保了双连接在各种动态变化中，始终能够以最高效、最安全、最可靠的方式为用户服务，真正体现了5G网络设计的深度与智慧。

FAQ

Q1：Activity Notification报告的“不活动”和UE进入RRC_INACTIVE状态有什么区别？ A1：两者是因果关系，但处于不同层面。Activity Notification是SN向MN报告的一个用户面数据活动状态的事件。而UE进入RRC_INACTIVE是MN基于包括Activity Notification在内的多种输入（如RRC信令、业务类型等），做出的一个RRC状态迁移的决策。SN只负责“报告现象”，MN负责“做出决策”。

Q2：为什么需要一个通用的RRC Transfer流程，而不是为每种RRC消息都定义一个专门的XnAP流程？ A2：这是为了协议的可扩展性和解耦。RRC协议本身非常复杂，且版本演进迅速。如果为每一种需要跨节点传递的RRC消息都定义一个XnAP流程，会导致XnAP协议变得异常臃肿，且每次RRC协议增加新消息，XnAP都需要同步修改。采用通用的RRC Transfer，将RRC消息作为“透明”的载荷来传递，使得XnAP与RRC的演进解耦，XnAP只提供一个可靠的“快递服务”，而无需关心“包裹”里的具体内容是什么。

Q3：如果SN报告一个GBR流not-fulfilled，MN一定会降低业务码率或释放SN吗？ A3：不一定。MN会根据全局信息做出最优决策。例如：

  • 如果MN发现自己有足够的备用资源，它可能会选择自己完全接管这个GBR流，然后通过SN修改流程，将该承载从SN上释放。
  • 如果SN提供了Alternative QoS Set（B计划），并且这个B计划仍然能满足业务的基本要求，MN可能会接受这个降级的QoS，并通知核心网。
  • 只有在MN也无法满足，且没有更好的选择时，才可能触发核心网对业务进行降级，或者为了保住更重要的业务而释放整个SCG。

Q4：为什么Counter Check流程是由SN发起，而不是由拥有RRC连接的MN主动发起？ A4：这体现了安全责任的划分。对于SN终止的承载（SN Terminated Bearer），其PDCP实体位于SN，安全密钥（S-KeNB）也由SN管理和使用。因此，SN是这些承载安全的第一责任人。当SN的内部安全策略（如定时审计、检测到异常等）要求进行一次安全校验时，由它主动发起Counter Check请求是最合乎逻辑的。MN在这里扮演的是一个“代理执行者”的角色，它利用自己与UE的RRC主连接，帮助SN完成这次对账。

Q5：这些流程都是Class 2的，如果消息丢失怎么办？ A5：作为Class 2流程，它们确实没有应用层的成功/失败响应机制。健壮性主要依赖于：

  • 底层SCTP的可靠传输：保证了消息在网络正常时不丢失、不乱序。
  • 上层应用的超时机制：例如，在S-NODE MODIFICATION REQUIRED中，SN会启动TXnDCoverall来监控整个流程。如果后续的S-NODE RECONFIGURATION COMPLETE（也是一个Class 2流程）丢失，SN的定时器会超时，从而触发异常处理。对于其他纯通知类的流程，如果丢失，可能会导致一次优化机会的错失，但通常不会破坏协议状态机，因为后续的事件会触发新的状态同步。

关系图谱