51学通信

深度解析 3GPP TS 38.331：5.3.13 ~ 5.3.15 快速返回：RRC连接恢复与统一接入控制

22分钟阅读

好的，我们继续跟随工程师阿哲，对3GPP TS 38.331规范的RRCReconfiguration流程进行更深层次的探索。在前几篇文章中，我们已经见证了RRC协议如何完成安全激活，并通过RRCReconfiguration消息铺设数据通路、部署测量任务，甚至导演了一场精彩的无缝切换大戏。阿哲的手机在他移动过程中，始终保持着稳定、高速的连接。

现在，阿哲的手机在短暂的数据交互后，被网络通过RRCRelease消息迁移到了RRC_INACTIVE状态，以节省宝贵的电量。就在此时，他的朋友发来了一条微信消息。核心网（UPF）将下行数据包推送到gNB，gNB发现UE处于非活动态，于是立即在UE所在的RAN通知区（RNA）内发起了寻呼。

阿哲的手机在其寻呼时机（Paging Occasion）“醒来”，并成功接收到寻呼消息。现在，它必须快速恢复到RRC_CONNECTED状态来接收这条微信。这个过程，就是5G相比4G在时延和信令效率上的一大飞跃——RRC连接恢复（RRC Connection Resume）。然而，如果阿哲此刻身处万人演唱会的现场，网络极度拥塞，他这次看似简单的“唤醒”请求，还必须先通过网络“门卫”的严格审查——统一接入控制（Unified Access Control, UAC）。

本篇文章，我们将聚焦于RRC连接生命周期中“从静到动”的关键一跃，深入探讨规范中5.3.13节到5.3.15节的核心内容，涵盖RRC连接恢复、统一接入控制以及连接拒绝等一系列紧密关联的流程。

深度解析 3GPP TS 38.331：5.3.13 ~ 5.3.15 快速返回：RRC连接恢复与统一接入控制

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.3.13 RRC connection resume”、“5.3.14 Unified Access Control”和“5.3.15 RRC connection reject”的核心章节，旨在为读者详细剖析UE从RRC_INACTIVE状态快速恢复连接的完整流程，以及在此之前必须通过的网络拥塞控制机制。

1. RRC连接恢复：从“休眠”到“战斗”的闪电切换 (解读 5.3.13 RRC connection resume)

RRC连接恢复是5G为支持低时延、高能效的“永远在线”体验而设计的核心机制。与从RRC_IDLE状态发起的全套“三步握手”连接建立相比，恢复流程利用UE和gNB中保存的上下文，大大简化了信令交互，缩短了恢复时延。

1.1 恢复的目的与启动时机 (5.3.13.1 General & 5.3.13.2 Initiation)

The purpose of this procedure is to resume a suspended RRC connection, including resuming SRB(s), DRB(s) and multicast MRB(s) or perform an RNA update. This procedure is also used to initiate SDT in RRC_INACTIVE.

如规范所述，恢复流程的核心目的是恢复一个被“挂起”的RRC连接。启动该流程的扳机有多种：

  • 上层请求：最常见的场景。例如，阿哲要发送一条微信（Uplink Data），或者后台应用有数据要传输。

  • 响应RAN寻呼：我们开篇的场景，核心网有下行数据到达，gNB通过寻呼“唤醒”UE。

  • RAN通知区更新（RNAU）：UE在RRC_INACTIVE状态下移动，当它发现自己即将移出当前gNB为其配置的RNA区域时，需要主动发起恢复流程来向网络报告新位置。

  • 小数据传输（SDT）：如果配置了SDT，UE可以在不完全进入RRC_CONNECTED状态的情况下，通过恢复流程来传输少量数据。

1.2 恢复前的准备工作

The UE initiates the procedure when upper layers or AS … requests the resume… The UE shall ensure having valid and up to date essential system information…

在发起恢复之前，UE会执行一系列准备动作：

  1. 接入控制检查：与连接建立一样，UE必须首先执行**统一接入控制（UAC）**检查（详见后文第2节）。如果当前接入被禁止，流程将终止。

  2. 恢复上下文：这是与连接建立最本质的区别。UE会从内存中“唤醒”之前被挂起时存储的UE Inactive AS context，包括安全上下文（密钥）、MAC配置、spCellConfig、所有承载（SRBs/DRBs）的PDCP/RLC配置等。

  3. 启动T319定时器：这是一个“恢复请求”的超时定时器。如果在T319超时前没有收到网络的任何响应，则认为恢复失败。

1.3 恢复流程的“两步半”握手

恢复流程的核心交互比建立流程更短，可以看作是“两步半”握手。

步骤一：UE的“身份验证” - RRCResumeRequest或RRCResumeRequest1

UE通过随机接入过程，在UL-SCH上发送恢复请求消息。规范定义了两种请求消息：

1> if useFullResumeID is signalled in SIB1:

2> select RRCResumeRequest1 as the message to use;

2> set the resumeIdentity to the stored fullI-RNTI value;

1> else:

2> select RRCResumeRequest as the message to use;

2> set the resumeIdentity to the stored shortI-RNTI value;

  • RRCResumeRequest vs RRCResumeRequest1：两者的区别在于使用的UE标识。如果SIB1中useFullResumeID为真，UE使用包含gNB ID的完整I-RNTI，这有助于UE移动到新的gNB下时，新gNB能快速定位到保存其上下文的旧gNB。否则，UE使用在RNA内唯一的短I-RNTI。

无论使用哪种消息，其核心内容都是为了向网络证明“我是谁”：

  • resumeIdentity：UE的I-RNTI。

  • resumeMAC-I: 这是恢复流程中最关键的安全凭证。它是一个16位的消息认证码，使用UE保存的KRRCint密钥，对包括resumeIdentity、resumeCause在内的核心信息进行计算得出。

  • resumeCause: 恢复原因，如mt-Access（响应寻呼）、ul-Data、rna-Update等。

resumeMAC-I的作用是“一石二鸟”：

  1. 完整性保护：保护请求消息不被篡改。

  2. 身份认证：gNB收到请求后，会用自己保存的该UE的KRRCint密钥，以同样的方式计算MAC-I。只有当计算结果与UE上报的resumeMAC-I完全一致时，gNB才能确认这个请求确实是来自合法的UE，而不是伪造的。

步骤二：网络的响应 - RRCResume, RRCSetup, RRCRelease, or RRCReject

gNB收到恢复请求并成功验证resumeMAC-I后，会根据UE的上下文是否能找到以及网络策略，做出以下四种响应之一：

  1. RRCResume (恢复成功 - 5.3.13.4)：这是最理想的情况。gNB成功找到了UE的上下文。它会发送RRCResume消息，其中可能包含一些增量的配置更新（如新的安全密钥、更新的DRB配置等）。UE收到后，停止T319，应用新配置，并立即恢复所有之前被挂起的承载。最后，UE发送RRCResumeComplete消息确认恢复完成，并正式进入RRC_CONNECTED状态。整个过程极快，因为无需重新建立和配置所有承载。

  2. RRCSetup (回退到建立 - 5.3.13.7)：gNB没能找到UE的上下文。这可能是因为UE移动到了一个完全没有准备上下文的新gNB，或者旧的上下文已因超时被gNB删除。此时，网络选择“另起炉灶”，回复一条RRCSetup消息。整个流程无缝地回退到我们之前讨论过的RRC连接建立流程。UE会丢弃旧的Inactive上下文，按照RRCSetup的指示重新开始。

  3. RRCRelease (释放或继续挂起 - 5.3.13.9)：UE发起的可能只是一个RNAU，并无数据传输需求。网络处理完更新后，可能决定让UE继续保持非活动状态。此时，网络会回复一条带有suspendConfig的RRCRelease消息，UE会更新其上下文（如新的I-RNTI），然后重新进入RRC_INACTIVE状态。如果消息不带suspendConfig，则UE会被直接释放到RRC_IDLE状态。

  4. RRCReject (拒绝 - 5.3.13.10)：因网络拥塞或其他策略原因，网络拒绝了UE的恢复请求。UE会进入RRC_IDLE状态，并可能被告知一个waitTime以避免立即重试。

这“两步半”的握手，以及灵活的四种网络响应，共同构成了RRC连接恢复流程的鲁棒性和高效性。

2. 拥塞的“守门人”：统一接入控制 (解读 5.3.14 Unified Access Control)

在阿哲所在的万人演唱会现场，成千上万的手机都可能因为接收消息、分享照片而同时尝试接入网络，这极易引发信令风暴，导致网络瘫痪。为了防止这种情况，RRC协议引入了**统一接入控制（UAC）**机制。它就像一个智能的“门禁系统”，在网络拥塞时，有序地控制UE的接入。

2.1 UAC的适用范围与启动 (5.3.14.1 General & 5.3.14.2 Initiation)

The purpose of this procedure is to perform access barring check for an access attempt associated with a given Access Category and one or more Access Identities upon request from upper layers…

UAC在UE每一次尝试从RRC_IDLE或RRC_INACTIVE状态发起接入时（无论是建立还是恢复）都会被执行。它是一个前置的守卫流程。

2.2 UAC的“身份检查”与“摇号”机制 (5.3.14.5 Access barring check)

UAC的核心是一个基于“接入类别”和“接入身份”的概率性准入机制。

  1. 接入类别与身份：

    当上层请求接入时，会提供两个关键参数：

    • Access Category (AC): 0-9，代表了接入的优先级。例如，2通常用于紧急呼叫，0用于多播恢复，8用于RNA更新。

    • Access Identity (AI): 0-2, 11-15，代表了用户的特殊身份。例如，1代表MPS（多媒体优先服务），2代表MCS（关键任务通信），11-15代表特定的运营商或机构用户。

  2. 获取准入规则：

    UE会从SIB1中广播的uac-BarringInfo中，根据自己的PLMN、接入类别和身份，找到对应的准入规则。这个规则包含两个核心参数：

    • uac-BarringFactor: 一个概率因子，如p00, p05, …, p95，分别代表0%, 5%, …, 95%的准入概率。

    • uac-BarringTime: 一个平均退避时间，如s4, s8, …, s512，代表4秒，8秒，…, 512秒。

  3. 执行“摇号”：

    if for at least one of these Access Identities the corresponding bit in the uac-BarringForAccessIdentity contained in “UAC barring parameter” is set to zero:

    2> consider the access attempt as allowed;

    1> else:

    …

    3> draw a random number ‘rand’ uniformly distributed in the range: 0 ≤ rand < 1;

    3> if ‘rand’ is lower than the value indicated by uac-BarringFactor…

    4> consider the access attempt as allowed;

    3> else:

    4> consider the access attempt as barred;

    UAC的检查逻辑如下：

    • 特殊身份豁免：首先检查UE持有的Access Identity是否有“豁免权”（对应的比特位为0）。如果有，则直接允许接入。

    • 概率性摇号：如果没有豁免权，UE会生成一个0到1之间的随机数rand。如果rand小于网络配置的uac-BarringFactor，则“中签”，允许接入。否则，“未中签”，接入被禁止。

  4. “中签”与“未中签”的后果：

    • 允许接入：UAC检查通过，UE继续执行后续的连接建立或恢复流程。

    • 禁止接入：UAC检查失败。UE会启动一个T390定时器，其时长由uac-BarringTime和一个随机因子共同决定。在T390运行期间，该接入类别的所有后续接入尝试都会被自动禁止。

通过这套机制，在网络拥塞时，gNB可以在SIB1中为普通数据业务（如mo-Data）设置一个较低的uac-BarringFactor（如p05，即只有5%的概率成功），同时为紧急呼叫设置豁免或较高的概率，从而在控制总接入量的同时，保障了高优先级业务的畅通。

3. 收到“闭门羹”：连接拒绝 (解读5.3.15 RRC connection reject)

如果UE的接入请求（无论是建立还是恢复）通过了UAC，但gNB由于内部原因（如资源耗尽）仍然无法接纳，网络就会发送RRCReject消息。

5.3.15.2 Reception of the RRCReject by the UE

The UE shall:

1> stop timer T300, if running; [or T319]

…

1> if waitTime is configured in the RRCReject:

2> start timer T302, with the timer value set to the waitTime;

收到RRCReject后，UE会：

  1. 停止相应的请求定时器（T300或T319）。

  2. 进入RRC_IDLE状态。

  3. 如果消息中包含了waitTime，则启动T302定时器。在T302运行期间，禁止所有（除了紧急呼叫等高优先级）的接入尝试。这是一种比UAC更直接、更强硬的接入控制手段。

结语：在效率与稳定之间寻求平衡

通过对5.3.13至5.3.15节的深入剖析，阿哲对RRC协议的设计哲学有了更深的理解。RRC Connection Resume流程是5G追求极致低时延和高效率的典范，它通过上下文保存和轻量级信令交互，实现了从“休眠”到“战斗”的闪电般切换。

然而，极致的效率必须建立在网络稳定的基础之上。Unified Access Control 和 RRCReject 机制则共同构成了保障网络稳定性的两道关键防线。UAC是基于概率的、精细化的“流量调节阀”，在拥塞时对接入请求进行“削峰填谷”；而RRCReject则是确定性的、强制性的“紧急刹车”。

这一放一收，一张一弛，完美地体现了RRC协议在追求极致用户体验与保障网络整体稳定性之间的精妙平衡。

阿哲的手机最终还是在演唱会的人潮中成功恢复了连接，接收了微信消息，这得益于他可能持有的某个高优先级接入身份，或者仅仅是运气好，“摇号”中签了。他的RRC探索之旅还在继续，接下来，他将把目光投向UE自身，研究UE是如何向网络“自我介绍”的——UE能力上报流程。

FAQ

Q1：RRC连接恢复（Resume）相比于RRC连接建立（Establishment），到底快在哪里？

A1：主要快在三个方面：

  1. 信令交互少：恢复流程是“两步半”（Request → Resume → Complete），而建立是完整的三步（Request → Setup → Complete）。

  2. 配置开销小：RRCSetup需要下发完整的初始配置，消息体很大。而RRCResume通常只下发增量修改，消息体小得多，传输更快。

  3. 无需重新安全激活和承载建立：这是最关键的节省。恢复流程直接重用已有的安全上下文和承载配置，省去了耗时的密钥派生、安全模式协商、以及逐一建立DRB和SRB2的完整流程。

Q2：resumeMAC-I是如何保证安全的？如果有人截获了我的I-RNTI，能冒充我发起恢复吗？

A2：不能。resumeMAC-I的核心安全保障在于它使用了只有UE和gNB知道的共享密钥KRRCint进行计算。即使攻击者截获了你的I-RNTI和RRCResumeRequest消息，由于他没有KRRCint密钥，他无法计算出正确的resumeMAC-I。当gNB收到伪造的请求时，它用自己保存的KRRCint计算出的MAC-I将与攻击者伪造的MAC-I不匹配，gNB会立即丢弃该请求，从而防止了冒充攻击。

Q3：统一接入控制（UAC）是只针对普通数据业务吗？紧急呼叫会被禁止吗？

A3：UAC是一个分级的控制系统，它会对不同优先级的业务区别对待。紧急呼叫（通常对应Access Category ‘2’）几乎总是被允许的。网络在SIB1中为每个接入类别配置不同的uac-BarringFactor。在网络拥塞时，运营商会为普通数据业务设置一个很低的接入概率（如5%），但为紧急呼叫、关键任务通信等高优先级业务设置100%的接入概率（即不进行概率性禁止），从而实现“有保有压”，在控制整体负荷的同时保障关键业务的生命线。

Q4：如果UE在RRC_INACTIVE状态下移动到了一个新的gNB（旧gNB没有机会将UE上下文转发给新gNB），此时发起RRC Resume会发生什么？

A4：这正是RRCSetup作为恢复流程“回退”机制发挥作用的典型场景。UE会像往常一样，使用其I-RNTI和计算出的resumeMAC-I向新gNB发送RRCResumeRequest。新的gNB收到后，无法在本地找到该I-RNTI对应的上下文。如果UE使用的是fullI-RNTI，新gNB可以根据其中的旧gNB ID，尝试通过核心网向旧gNB请求UE上下文。如果这个过程成功且迅速，新gNB仍然可以回复RRCResume。但如果上下文获取失败或超时，新gNB会放弃恢复，直接向UE回复一条RRCSetup消息，将整个流程转为一次全新的RRC连接建立。

Q5：SDT（小数据传输）和RRC连接恢复是什么关系？

A5：SDT是RRC_INACTIVE状态下的一种优化传输方式，它复用了RRC连接恢复的信令流程。当UE在非活动态有少量上行数据要发送时，它会发起一个cause为ul-Data的RRC恢复流程。如果网络在RRCResume消息中指示允许SDT，UE可以在不完全进入RRC_CONNECTED状态的情况下，直接在恢复流程中或之后短暂的时间内完成小数据的收发，然后快速返回RRC_INACTIVE状态。这避免了完整的状态跃迁（INACTIVE → CONNECTED → INACTIVE），进一步降低了信令和功耗，非常适合物联网设备等频繁传输小包数据的场景。

关系图谱