51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 7 - RRC连接建立与恢复流程)

20分钟阅读

好的，我们继续深入探索3GPP TS 38.331规范的第六章。在前几部分中，我们已经覆盖了UE从开机、连接、移动、到释放的整个生命周期中的关键RRC消息。现在，我们将进入一个更为基础但也同样至关重要的领域：RRC连接建立与恢复。我们将详细剖析UE是如何敲开网络的大门，以及在短暂失联后如何快速“重返岗位”的。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 7 - RRC连接建立与恢复流程)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及RRCReestablishmentRequest, RRCReconfiguration, RRCReconfigurationComplete, RRCReject, RRCResume, RRCResumeComplete, RRCSetup, RRCSetupComplete等核心消息的内容。本文旨在为读者构建一幅完整的RRC连接控制信令交互图谱，从零开始建立连接到链路失败后的重建，再到非激活态的恢复，无一遗漏。

场景再现：从“初次见面”到“失而复得”

为了生动地展现本章内容，我们再次请出主角“小明”。我们将跟随他经历三个经典的通信场景：

  1. 场景一：开机入网（RRC Setup）。小明刚买了一部新5G手机，第一次开机。手机将如何向陌生的5G网络“介绍自己”，并成功建立起第一条RRC连接？我们将通过RRCSetupRequest → RRCSetup → RRCSetupComplete的“三步握手”来揭晓答案。
  2. 场景二：电梯失联后的快速恢复（RRC Re-establishment）。小明在通话中走进电梯，信号中断导致无线链路失败（RLF）。走出电梯后，手机如何不经过漫长的重连过程，快速恢复通话？RRCReestablishmentRequest → RRCReestablishment → RRCReestablishmentComplete的“急救”流程将展示这一过程。
  3. 场景三：从省电模式中唤醒（RRC Resume）。小明的手机在闲置时进入了RRC_INACTIVE状态。当他突然想刷短视频时，手机如何被快速“唤醒”并恢复数据连接？RRCResumeRequest → RRCResume → RRCResumeComplete的“唤醒”流程将给出答案。

1. RRC连接建立 (RRC Connection Establishment)

这是UE与网络建立通信的第一步。

1.1 RRCSetupRequest (RRC建立请求)

The RRCSetupRequest message is used to request the establishment of an RRC connection.

  • 方向: UE to Network
  • 逻辑信道: CCCH

解读：这是UE向网络发出的第一声“你好，我想加入”。它承载在公共控制信道上，因为此时双方还没有建立专用信道。

RRCSetupRequest-IEs 字段描述

字段名描述
establishmentCause提供从上层收到的信息，说明RRCSetupRequest的建立原因。gNB不应因UE使用了未知的原因值而拒绝RRCSetupRequest。
ue-IdentityUE身份，用于帮助底层进行竞争解决。
  • ue-Identity: UE的初始身份标识。它是一个CHOICE类型：
    • ng-5G-S-TMSI-Part1: 如果UE有核心网分配的有效TMSI，它会在这里填入TMSI的右边39位。
    • randomValue: 如果UE没有任何有效ID，它会生成一个39位的随机数。 这个ID将与底层的PRACH前导码一起，帮助网络在多个UE同时发起接入时区分它们（竞争解决）。
  • establishmentCause: 建立原因。这是一个至关重要的枚举字段，告诉网络“我为什么来”。例如：
    • emergency: 紧急呼叫。
    • highPriorityAccess: 高优先级接入（如特定签约用户、物联网紧急事件）。
    • mt-Access: 被叫接入，响应寻呼。
    • mo-Data: 主叫数据。
    • mo-VoiceCall: 主叫语音。 网络会根据这个原因，进行接入控制（ACDC）和资源分配。

1.2 RRCSetup (RRC建立)

The RRCSetup message is used to establish SRB1.

  • 方向: Network to UE
  • 逻辑信道: DL-CCCH

解读：这是网络的回应：“欢迎加入，这是你的专属信道”。RRCSetup的核心任务是建立SRB1（信令承载1），这是后续所有专用信令交互的基础。

RRCSetup-IEs 字段描述

字段名描述
masterCellGroup网络仅为SRB1配置RLC承载、mac-CellGroupConfig、physicalCellGroupConfig和spCellConfig。
radioBearerConfig在RRC setup中只能配置SRB1。
sl-ConfigDedicatedNR包含NR sidelink通信的专用配置。
sl-L2RemoteUE-Config包含用于L2 U2N中继相关操作的专用配置。
  • radioBearerConfig: 定义了SRB1的RLC和逻辑信道配置。
  • masterCellGroup: 包含了PCell（主小区）的几乎所有配置，如MAC配置、物理层配置、SpCell配置等。UE收到后，就知道了如何在这个小区上进行专用的上下行通信。

1.3 RRCSetupComplete (RRC建立完成)

The RRCSetupComplete message is used to confirm the successful completion of an RRC connection establishment.

  • 方向: UE to Network
  • 逻辑信道: DCCH (通过新建的SRB1)

解读：UE在成功配置好SRB1后，通过这个新建立的信道向网络发送确认：“我已经准备好了”。这条消息标志着RRC连接建立成功，UE正式进入RRC_CONNECTED态。

RRCSetupComplete-IEs 字段描述

字段名描述
guami-Type该字段用于指示所包含的GUAMI是原生的（从原生的5G-GUTI派生）还是映射的（从EPS GUTI派生）。
iab-NodeIndication该字段用于指示连接是由一个IAB节点建立的。
idleMeasAvailable指示UE有空闲/非激活测量报告可用。
mobilityState该字段指示UE在进入RRC_CONNECTED状态之前的UE移动性状态。
selectedPLMN-IdentityUE从SIB1中包含的plmn-IdentityInfoList或npn-IdentityInfoList字段中选择的PLMN或SNPN的索引。
  • selectedPLMN-Identity: UE报告它选择服务的PLMN。
  • registeredAMF: UE报告它注册在哪个AMF（核心网接入与移动性管理功能）下。
  • dedicatedNAS-Message: 这是极其重要的一个字段。UE会将NAS层的第一条上行消息（如Registration Request）“搭载”在这条消息中一并发送给网络。这种“捎带”机制极大地缩短了整个入网的时延。

1.4 RRCReject (RRC拒绝)

  • 方向: Network to UE
  • 逻辑信道: DL-CCCH

解读：如果网络因拥塞或其他原因决定不接纳UE的连接请求，就会发送RRCReject。

RRCReject-IEs 字段描述

字段名描述
waitTime等待时间值（秒）。该字段总是包含在内。
  • waitTime: 拒绝UE的同时，告诉它需要等待多长时间（1-16秒）才能再次尝试发起连接。这是一种有效的防拥塞机制。

2. RRC连接重建 (RRC Connection Re-establishment)

当UE在RRC_CONNECTED态遭遇无线链路失败（RLF）时触发。

2.1 RRCReestablishmentRequest (RRC重建请求)

  • 方向: UE to Network
  • 逻辑信道: CCCH

解读：UE在发生RLF并重选到一个合适的小区后，发送此消息请求恢复RRC连接。

RRCReestablishmentRequest-IEs 字段描述

字段名描述
reestablishmentCause指示触发重建过程的失败原因。gNB不应因UE使用了未知的原因值而拒绝RRCReestablishmentRequest。
ue-Identity包含UE身份，用于检索UE上下文并促进底层竞争解决。
  • ue-Identity: 包含了UE在失败前的所有身份信息：
    • c-RNTI: 在原PCell中的C-RNTI。
    • physCellId: 原PCell的物理小区ID。
    • shortMAC-I: 一个基于安全密钥计算出的短MAC值，用于网络验证UE身份的合法性。
  • reestablishmentCause: 失败原因，如reconfigurationFailure（重配失败）、handoverFailure（切换失败）、otherFailure。

2.2 RRCReestablishment & RRCReestablishmentComplete

这两条消息在Part 6中已有提及，这里总结一下：

  • RRCReestablishment: 网络找到UE上下文后，下发此消息，提供新的安全参数（nextHopChainingCount），用于重建SRB1。
  • RRCReestablishmentComplete: UE成功重建SRB1后，发送此确认消息。

重建成功后，UE不会像RRCSetupComplete那样携带NAS消息，因为NAS层上下文在RLF期间并未丢失。后续的DRB（数据承载）恢复，将由网络通过RRCReconfiguration消息来完成。

3. RRC连接恢复 (RRC Connection Resume)

当UE处于RRC_INACTIVE状态，需要恢复连接时触发。

3.1 RRCResumeRequest / RRCResumeRequest1

  • 方向: UE to Network
  • 逻辑信道: CCCH (SRB0)

解读：UE向网络发出“唤醒”请求。

RRCResumeRequest-IEs 字段描述

字段名描述
resumeCause提供上层或RRC提供的RRC连接恢复请求的原因。
resumeIdentityUE身份，用于在gNB处促进UE上下文检索。
resumeMAC-I认证令牌，用于在gNB处促进UE认证。
  • resumeIdentity: UE的非激活态ID，即shortI-RNTI。
  • resumeMAC-I: 同样是一个用于身份验证的安全MAC值。
  • resumeCause: 恢复原因，如mt-Access（响应寻呼）、mo-Data等。

3.2 RRCResume (RRC恢复)

  • 方向: Network to UE
  • 逻辑信道: DCCH (通过SRB1)

解读：网络找到UE上下文后，下发此消息恢复连接。

RRCResume-IEs 字段描述

字段名描述
masterCellGroup主小区组的配置。
measConfig测量配置。
radioBearerConfig包括SDAP/PDCP的无线承载（DRBs, SRBs, 多播MRBs）的配置。
restoreSCG指示UE应从UE非激活AS上下文中恢复SCG配置（如果已存储）。
sk-Counter一个计数器，用于在RRC Resume期间基于新派生的KgNB派生S-KgNB或S-KeNB。
  • masterCellGroup, radioBearerConfig, measConfig: 与RRCReconfiguration类似，网络可以在恢复连接的同时，直接更新UE的无线资源配置。
  • restoreSCG: 如果UE在进入INACTIVE之前是双连接状态，网络可以通过这个字段指示UE“恢复你之前保存的SCG配置”，实现DC状态的快速恢复。
  • sk-Counter: 用于更新SCG的安全密钥。

3.3 RRCResumeComplete (RRC恢复完成)

  • 方向: UE to Network
  • 逻辑信道: DCCH

解读：UE完成恢复配置后的确认消息。与RRCSetupComplete类似，它也可以捎带NAS消息，如果这次恢复是由上行NAS请求触发的。

RRCResumeComplete-IEs 字段描述

字段名描述
dedicatedNAS-Message专用NAS消息。
selectedPLMN-IdentityUE选择的PLMN索引。
uplinkTxDirectCurrentList如果网络请求，上报配置的服务小区和BWP的Tx直流位置。
measResultIdleNRRRC_INACTIVE期间执行的NR测量结果。
  • measResultIdleNR: UE可以将在INACTIVE期间执行的测量结果（如小区重选测量）上报给网络，帮助网络了解UE的移动轨迹和周边环境。

4. RRCReconfiguration & RRCReconfigurationComplete (RRC重配与完成)

RRCReconfiguration是RRC_CONNECTED态下最核心、最复杂的消息，几乎所有的连接态下的配置变更都由它来完成。

The RRCReconfiguration message is the command to modify an RRC connection. It may convey information for measurement configuration, mobility control, radio resource configuration (including RBs, MAC main configuration and physical channel configuration) and AS security configuration.

功能概览：

  • 切换控制: 包括同频/异频/异RAT切换。
  • 载波聚合/双连接管理: 添加、修改、释放SCell或整个SCG。
  • 无线承载管理: 建立、修改、释放SRB和DRB。
  • 测量配置: 配置、修改、释放测量任务。
  • MAC/PHY层重配: 修改调度、功耗、波束等相关参数。
  • 安全配置: 更新安全密钥。
  • …等等。

由于其结构极其庞大复杂，包含了大量的SetupRelease结构和OPTIONAL字段，我们将在未来的专题文章中对其进行详细的拆解。在这里，只需理解它是连接态下所有动态配置的“总管”即可。

RRCReconfigurationComplete则是UE在成功应用了RRCReconfiguration消息中的配置后，向网络发送的确认消息。

FAQ环节

Q1：RRC连接建立、重建、恢复这三个流程的“三步握手”消息（请求、指令、完成），在功能上有何异同？ A1：它们在形式上都是“请求-指令-完成”的三步交互，但在初始状态、携带的核心信息、以及流程目标上有本质区别：

  • 建立 (Setup): 从无到有。RRCSetupRequest携带的是临时ID和建立原因；RRCSetup核心是建立SRB1和PCell；RRCSetupComplete核心是确认SRB1建立并将初始NAS消息上报。
  • 重建 (Re-establishment): 从失败中恢复。RRCReestablishmentRequest携带的是UE失败前的C-RNTI、PCI和安全校验码；RRCReestablishment核心是基于新的NCC恢复SRB1的安全上下文；RRCReestablishmentComplete仅确认SRB1恢复，不带NAS消息。
  • 恢复 (Resume): 从休眠中唤醒。RRCResumeRequest携带的是I-RNTI和安全校验码；RRCResume不仅恢复连接，还可以同时进行重配（如恢复SCG）；RRCResumeComplete可以根据需要捎带NAS消息。

Q2：为什么RRCSetupComplete和RRCResumeComplete可以捎带NAS消息，而RRCReestablishmentComplete却不行？ A2：这取决于流程触发时NAS层的状态。

  • Setup和Resume (由UE主动发起时): 通常是由NAS层有数据或信令要发送而触发的。例如，手机开机后，NAS层需要发起“注册”流程。它请求RRC建立连接，RRC连接成功后，自然就要把NAS的这条“注册请求”消息第一时间发出去。捎带机制就是为了这个“第一时间”。
  • Re-establishment: 是由RRC层检测到的无线链路失败 (RLF) 触发的。这对于NAS层来说是一个底层的、突发的无线问题，NAS层的连接（NAS Connection）并未中断，它仍然认为自己与核心网保持着联系。因此，RRC层在“抢救”完无线链路后，不需要也没必要再发送一条新的NAS初始消息。

Q3：RRCReconfiguration消息如此庞大，UE处理时会很耗时吗？会不会影响业务？ A3：是的，处理庞大的RRCReconfiguration消息（尤其是涉及双连接建立或切换的）确实会消耗UE的处理器资源，并引入一定的处理时延。这个时延是切换中断时间的一部分。为了最大限度地减少影响：

  1. UE实现优化: 高性能的手机基带芯片会用硬件加速等方式优化ASN.1解码和配置应用过程。
  2. 协议设计: 3GPP设计了增量配置（Delta Configuration） 机制，网络尽可能只发送变化的配置，而不是每次都发送全量配置。
  3. DAPS切换: 对于时延敏感业务，5G引入了DAPS（双激活协议栈）切换，允许UE在与目标小区建立连接的同时，短暂保持与源小区的连接，实现“先连后断”，将切换中断时间压缩到接近零。

Q4：如果UE发送RRCSetupRequest后，一直没有收到网络的RRCSetup或RRCReject，UE会怎么办？ A4：UE不会无限期地等待。RRC协议中定义了相关定时器来管理这个过程。

  1. UE在发送RRCSetupRequest（Msg3）后，会启动定时器T300。
  2. 如果在T300超时前，UE没有收到任何响应（RRCSetup, RRCReject），或者收到了但无法成功解析，UE会认为本次接入尝试失败。
  3. T300超时后，UE会返回到物理层，可能会增加发射功率，并重新尝试发起随机接入过程（RACH），再次发送RRCSetupRequest。
  4. UE内部会有一个计数器，记录连续失败的次数。如果超过了网络在SIB1中广播的最大次数（connEstFailCount），UE会启动定时器T302，在T302时长内禁止再次尝试接入，以避免对网络造成持续的拥塞。

Q5：RRC重建（Re-establishment）一定能成功吗？在什么情况下会失败？ A5：不一定能成功。重建的成功率是衡量网络鲁棒性的一个关键KPI。失败的常见原因包括：

  1. 找不到合适的 hücre: UE在RLF后，在其搜索的频率上没有找到任何一个可以驻留的、属于同一PLMN的 hücre。
  2. 网络侧无UE上下文: UE虽然找到了一个 hücre并发起了重建请求，但这个新 hücre（或者原 hücre，但上下文已丢失）没有该UE的有效上下文。这可能是因为UE在RLF期间移动太远，超出了上下文可被转发的范围，或者网络侧因为某种原因提前清除了该UE的上下文。
  3. 身份验证失败: UE请求中的shortMAC-I校验失败，网络认为该UE非法，会拒绝重建。
  4. T311超时: UE在发起重建后，会启动定时器T311。如果在此期间没有成功收到RRCReestablishment消息，T311超时后，UE会放弃重建，并转入RRC_IDLE状态，后续只能发起全新的RRC连接建立。

关系图谱