51学通信

深度解析 3GPP TS 38.331：5.3.6 ~ 5.3.11 连接的鲁棒性：从计数器检查到链路失败恢复

23分钟阅读

好的，我们继续跟随工程师阿哲的脚步，深入探索3GPP TS 38.331的奥秘。在前几篇文章中，我们已经见证了RRC协议如何完成安全激活，并通过RRCReconfiguration消息铺设数据通路、部署测量任务、执行无缝切换，甚至构建了Sidelink、Relay和Multi-path等高级连接。阿哲的手机现在已经是一个全副武装、功能强大的5G终端。

但是，再完美的系统也需要面对现实世界的“熵增”——网络信号会波动，配置可能出错，连接终将终结。一个成熟的协议，其伟大之处不仅在于它如何高效地“建功立业”，更在于它如何优雅地“处理危机”和“功成身退”。

本篇文章，我们将聚焦于RRC连接生命周期的后半段——连接的维护、终止与恢复。我们将深入探讨规范中5.3.6节到5.3.11节的核心内容，涵盖计数器检查、RRC连接重建、RRC连接释放、无线链路失败等一系列关键流程。我们将看到，当通信链路遭遇挑战时，RRC是如何扮演“审计师”、“急救医生”和“清算人”的多重角色，以确保网络的鲁棒性、安全性，并实现资源的有序回收。

深度解析 3GPP TS 38.331：5.3.6 ~ 5.3.11 连接的鲁棒性：从计数器检查到链路失败恢复

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.3.6 Counter check”、“5.3.7 RRC connection re-establishment”、“5.3.8 RRC connection release”、“5.3.9 RRC connection release requested by upper layers”、“5.3.10 Radio link failure related actions”和“5.3.11 UE actions upon going to RRC_IDLE”的核心章节，旨在为读者全面剖析RRC连接在面临异常、需要终止或从失败中恢复时的完整协议机制。

1. RRC的“数据审计”：计数器检查流程 (解读5.3.6 Counter check)

场景: 阿哲正在长时间下载一部大型文件。数据包在空口中高速穿梭。为了确保通信的安全性，防止潜在的“中间人攻击”（如数据包注入），网络决定发起一次例行的“数据审计”——计数器检查（Counter Check）。

这个流程的目的并非检查数据内容是否正确（那是上层协议的职责），而是核对UE和gNB双方在PDCP层的“账本”——COUNT值是否同步。COUNT值是一个随每个数据包递增的序列号，它是空口加密算法的关键输入之一。如果双方的COUNT值不同步，不仅意味着可能存在数据包丢失或注入，更严重的是会导致加解密失败。

1.1 流程的启动与目的 (5.3.6.1 General & 5.3.6.2 Initiation)

The counter check procedure is used by the network to request the UE to verify the amount of data sent/ received on each DRB. More specifically, the UE is requested to check if, for each DRB, the most significant bits of the COUNT match with the values indicated by the network.

NOTE: The procedure enables the network to detect packet insertion by an intruder (a ‘man in the middle’).

如规范所述，网络是此流程的唯一发起方。它通过发送CounterCheck消息来启动检查。

1.2 两步式“对账” (5.3.6.3 Reception of the CounterCheck message)

Figure 5.3.6.1-1: Counter check procedure 清晰地展示了这个简单的两步交互。

  1. 网络发送CounterCheck消息：

    网络在消息的drb-CountMSB-InfoList中，列出它所关心的每个DRB以及它期望的COUNT值的最高有效位（Most Significant Bits, MSB）。为什么只发送MSB？因为COUNT值很长（32位或36位），完整发送会占用较多资源。而MSB的变化频率远低于LSB（最低有效位），足以检测出较大的COUNT不同步或恶意注入。

  2. UE的响应CounterCheckResponse：

    阿哲的手机收到CounterCheck消息后，会逐一核对列表中的每个DRB：

    Upon receiving the CounterCheck message, the UE shall:

    1> for each DRB that is established:

    …

    2> else if, for at least one direction, the most significant bits of the COUNT are different from the value indicated in the drb-CountMSB-InfoList:

    3> include the DRB in the drb-CountInfoList in the CounterCheckResponse message by including the drb-Identity, the count-Uplink and the count-Downlink set to the value of TX_NEXT – 1 and RX_NEXT – 1...

    • 如果UE侧的COUNT MSB与网络发来的一致，UE则认为“账目相符”，无需在响应中提及这个DRB。

    • 如果UE发现某个DRB的COUNT MSB不一致，它就会在CounterCheckResponse消息中包含这个DRB的信息。但它报告的不是MSB，而是完整的当前COUNT值（即下行期望接收的RX_NEXT和上行将要发送的TX_NEXT减一）。这能帮助网络精确地了解偏差，并采取纠正措施（如重新同步或释放连接）。

通过这个简单的流程，RRC为PDCP层的安全运行提供了一道重要的保障。

2. “灾后重建”：RRC连接重建流程 (解读5.3.7 RRC connection re-establishment)

场景: 阿哲驾车驶入一个长长的隧道，手机信号突然中断，视频通话瞬间卡死并断开。屏幕上出现了“正在搜索网络”的提示。这就是一次典型的无线链路失败（Radio Link Failure, RLF）。

此时，UE不能坐以待毙。它会立即启动RRC连接重建流程，尝试在无线链路中断后“原地复活”，恢复RRC连接。

2.1 重建的触发条件 (5.3.7.2 Initiation)

The UE initiates the procedure when one of the following conditions is met:

1> upon detecting radio link failure of the MCG…, in accordance with 5.3.10; or

1> upon re-configuration with sync failure of the MCG, in accordance with clause 5.3.5.8.3; or

1> upon integrity check failure indication from lower layers…; or

1> upon an RRC connection reconfiguration failure…

触发重建的都是“致命性”事件：

  • 无线链路失败（RLF）：最常见的原因，详见后文5.3.10节的分析。

  • 切换失败：T304定时器超时。

  • RRC重配置失败：UE无法应用网络下发的RRCReconfiguration消息。

  • 完整性校验失败：收到一条无法通过完整性校验的RRC消息，表明安全上下文可能已失效。

2.2 重建的“四步曲”

这是一个由UE主导的、与时间赛跑的流程，如Figure 5.3.7.1-1所示。

  1. 准备阶段：

    一旦触发重建，UE会立即：

    • 启动T311定时器：这是“重建尝试”定时器。如果在该定时器超时前未能成功恢复，则宣告彻底失败，UE将返回RRC_IDLE。

    • 暂停所有业务：重置MAC，暂停所有SRB（SRB0除外）和DRB。此时，用户数据传输完全中断。

  2. 小区选择：

    UE会立即在所有支持的频段上搜索一个“合适的”小区（suitable cell）。这个小区可以是掉线前的那个小区，也可以是任何一个信号质量满足驻留条件的新小区。

  3. 发送RRCReestablishmentRequest消息：

    选定一个小区后，UE通过该小区的随机接入过程，发送RRCReestablishmentRequest消息。这是向网络发出的“求救信号”。

    2> set the c-RNTI to the C-RNTI used in the source PCell…

    2> set the physCellId to the physical cell identity of the source PCell…

    2> set the shortMAC-I to the 16 least significant bits of the MAC-I calculated…

    该消息包含三个关键信息，用于向网络证明“我是谁，我从哪来”：

    • c-RNTI: UE在掉线前使用的C-RNTI。

    • physCellId: UE掉线前的PCell的物理小区ID。

    • shortMAC-I: 一个基于UE上下文和c-RNTI、physCellId计算出的简短消息认证码。这是最重要的“身份凭证”。

  4. 网络响应与后续动作：

    收到请求后，目标gNB（可能就是原来的gNB，也可能是新的gNB）会根据这些信息在网络中查找UE的上下文。

    • 情况A：找到上下文，重建成功

      网络找到了UE的上下文，并通过了shortMAC-I的验证。它会向UE回复RRCReestablishment消息。UE收到后，会停止T311，重新激活AS安全，并恢复SRB1。最后，UE发送RRCReestablishmentComplete消息，标志着连接成功恢复。中断的DRB可以被恢复，业务得以继续。

    • 情况B：未找到上下文，回退到连接建立

      网络找不到UE的上下文（可能因为UE移动到了一个没有准备上下文的新gNB）。此时，网络会回复一条RRCSetup消息，这相当于放弃重建，直接回退到初始的RRC连接建立流程。

    • 情况C：网络拒绝

      网络回复RRCReestablishmentReject消息，UE停止尝试，直接进入RRC_IDLE状态。

RRC连接重建机制为连接态提供了一套强大的“自救”方案，大大提升了网络的鲁棒性。

3. 连接的终结：释放流程 (解读5.3.8 & 5.3.9)

天下没有不散的筵席，RRC连接最终也需要被释放，以节约网络资源和UE功耗。连接的释放分为两种：网络发起的和UE发起的。

3.1 网络发起的“体面告别” (5.3.8 RRC connection release)

场景: 阿哲结束了通话，并且在一段时间内没有数据活动。网络检测到这种空闲状态，决定释放其RRC连接。

网络会向UE发送RRCRelease消息，这是RRC流程中功能最丰富的消息之一。

The purpose of this procedure is:

  • to release the RRC connection…
  • to suspend the RRC connection…

RRCRelease可以实现多种目的：

  • 彻底释放，返回IDLE：这是最基本的功能。UE收到后会释放所有专用资源，清空上下文，并转换到RRC_IDLE状态。

  • 挂起连接，进入INACTIVE：

    if the RRCRelease includes suspendConfig: … enter RRC_INACTIVE…

    如果消息中包含了suspendConfig，UE则不会清空上下文，而是将其保存起来，并转换到RRC_INACTIVE状态，为快速恢复做准备。

  • 重定向（Redirection）：

    if the RRCRelease message includes redirectedCarrierInfo…

    网络可以在释放连接的同时，指示UE去另一个NR频率或另一个RAT（如LTE）上驻留。这是一种高效的负载均衡手段。

  • 临时禁止接入：

    if the RRCRelease message is including the waitTime: … start timer T302…

    消息中可以包含一个waitTime，指示UE在接下来的几秒钟内禁止发起任何RRC连接请求，用于临时性的接入控制。

3.2 UE发起的“主动离开” (5.3.9 RRC connection release requested by upper layers)

场景: 阿哲主动开启了飞行模式。

The UE initiates the procedure when upper layers request the release of the RRC connection…

此时，UE的NAS层会通知RRC层释放连接。RRC层会执行本地的资源释放操作，然后直接进入RRC_IDLE状态。这个过程通常不会向网络发送任何信令，是一种“单方面”的断开。网络会在一段时间没有收到UE的任何信号后，通过底层机制或定时器超时来发现UE已离网，并释放其上下文。

我们回到隧道中的场景，究竟是什么机制让UE判断出“无线链路失败”（RLF）了呢？5.3.10节给出了详细的定义。

4.1 “失步”与“同步”的博弈 (5.3.10.1 & 5.3.10.2)

UE的物理层会持续对PCell（或PSCell）的下行参考信号进行测量，以维持同步。

  • 失步指示（“out-of-sync”）：当信号质量低于某个门限（Qout），物理层会向上层报告一次“失步”。

  • 同步指示（“in-sync”）：当信号质量高于某个门限（Qin），物理层会报告一次“同步”。

RRC层维护着两个关键的计数器和两个定时器：

  • N310：连续失步指示的次数。

  • T310：无线链路问题定时器。

  • N311：连续同步指示的次数。

  • T312：无线链路恢复定时器（在某些场景下使用）。

当UE连续收到N310次失步指示后，RRC会启动T310定时器。如果在T310运行期间，UE连续收到了N311次同步指示，则认为链路已恢复，T310会被停止。

4.2 宣判“死亡”：RLF的触发 (5.3.10.3)

1> else:

2> upon T310 expiry in PCell; or

2> upon random access problem indication from MCG MAC…; or

2> upon indication from MCG RLC that the maximum number of retransmissions has been reached…

T310定时器超时是宣告RLF的最主要条件。这意味着在一段足够长的时间内，无线链路的质量始终没有恢复。

此外，以下事件也会直接触发RLF：

  • 随机接入问题: 在连接态下，当需要进行随机接入（如上行数据到达，需要同步）时，如果多次尝试后仍然失败。

  • RLC最大重传失败: 某个SRB或DRB的RLC层达到了最大重传次数，仍然没有收到对方的确认。这表明链路可能已经中断。

一旦RLF被宣告，UE就会立即启动前述的RRC连接重建流程。

结语：一个完整的闭环

通过对5.3.6到5.3.11节的系统性学习，阿哲终于理解了RRC连接在“生老病死”各个阶段的应对机制。这不仅仅是一系列孤立的流程，而是一个紧密耦合、逻辑闭环的强大系统：

  • Counter Check 像例行体检，预防安全风险。

  • RRC Release 是计划内的生命终结，实现资源的有序回收。

  • RLF 检测机制是敏锐的病症诊断系统，及时发现连接的“休克”状态。

  • RRC Re-establishment 则是高效的急救复苏手段，尽最大努力挽救连接。

  • Going to RRC_IDLE 是最终的宣告死亡和后事处理，确保系统状态的最终一致。

这些机制共同构成了RRC协议的鲁棒性核心，是5G网络能够提供“永远在线”般可靠服务的幕后英雄。阿哲对RRC协议的设计者充满了敬意。

在接下来的文章中，我们将跳出连接控制的核心流程，转向RRC的另一个重要领域——UE能力（5.6节），看看UE是如何向网络“亮家底”，以及网络是如何“知人善任”的。

FAQ

Q1：Counter Check流程失败（即UE上报了CounterCheckResponse）后，网络会做什么？

A1：网络会根据其策略采取不同的行动。Counter Check失败表明UE和gNB之间的PDCP COUNT值存在严重不同步，这是一个潜在的安全漏洞。网络可能会：1) 发起一次RRC连接重建或重配置，强制重新同步安全上下文和PDCP状态；2) 在极端情况下，如果怀疑存在恶意攻击，网络可能会直接释放RRC连接，并可能通过核心网上报异常。这个流程的目的是检测问题，具体的恢复动作由网络实现来决定。

Q2：RRC连接重建（Re-establishment）和切换（Handover）都可能涉及到UE接入一个新的小区，它们有什么不同？

A2：核心不同在于网络是否“知情”和“有准备”。

  • 切换是网络预先规划好的。源gNB已经和目标gNB协商完毕，为UE准备好了所有资源。UE是带着“录取通知书”（RRCReconfiguration消息）去新小区报到的，过程快速且业务无中断。

  • 重建是UE在链路失败后的“盲目求救”。UE不知道哪个小区能接收它，网络侧也没有任何准备。UE在新小区上发起重建请求时，新gNB需要去网络中“大海捞针”般地寻找UE的上下文。这个过程时延长，且必然导致业务中断。

Q3：UE在RRC_INACTIVE状态和RRC_IDLE状态下掉线了，处理方式有什么不同？

A3：处理方式基本相同，但后续恢复的潜力不同。

  • 在RRC_IDLE状态下，UE本身就没有连接，所谓的“掉线”其实就是找不到合适的可以驻留的小区。此时UE会持续进行小区搜索。一旦找到合适的小区，就驻留下来，继续处于RRC_IDLE状态。

  • 在RRC_INACTIVE状态下，如果UE发现当前小区信号丢失（类似于RLF），它也会启动小区搜索和重选。如果重选到了一个新的小区（无论是否在原RNA内），它可以尝试发起RRC Resume流程来恢复连接。如果多次尝试失败，或者在T311（可用于resume的定时器）超时，它最终会放弃，清空上下文，进入RRC_IDLE状态。

Q4：为什么RLC达到最大重传次数会触发RLF？这和TCP的重传有什么关系？

A4：RLC是空口的可靠性保障层，它负责确保数据包在UE和gNB之间被成功传输。如果一条承载（特别是信令承载SRB）上的某个RLC SDU经过了最大次数的重传后，仍然没有收到对端的ACK，RLC层有理由相信底层的物理链路已经完全中断，无法通信。此时，它会向RRC层报告“RLC失败”，RRC层则会将此事件判定为RLF。这与TCP的重传超时类似，都是在数据链路层或传输层，通过重传机制的持续失败来推断底层连接的可用性，但RLC工作在空口，其失败直接指向无线链路问题。

Q5：RRCRelease消息中同时包含suspendConfig和redirectedCarrierInfo时，UE应该如何动作？

A5：UE会遵循一个明确的顺序。它会首先处理redirectedCarrierInfo，根据重定向信息去目标频率或目标RAT进行小区选择。在成功驻留到新的小区后，它不会像普通释放那样进入RRC_IDLE状态，而是会应用suspendConfig的配置，将UE上下文保存起来，并进入RRC_INACTIVE状态。这个组合操作实现了从连接态到另一个频率/RAT的非活动态的平滑过渡，是网络进行跨频/跨系统负载均衡和移动性管理的一种高效手段。

关系图谱