51学通信

深度解析 3GPP TS 38.331：5.3.2 Paging & 5.3.3 RRC Connection Establishment (从寻找到握手：建立通信的第一座桥梁)

22分钟阅读

好的，我们继续跟随阿哲的脚步，深入探索3GPP TS 38.331的奥秘。在前文中，我们已经详细解读了UE如何通过获取系统信息（5.2节）来完成“睁眼看世界”的第一步，并成功驻留在一个小区。现在，阿哲的手机处于RRC_IDLE状态，万事俱备，只待东风。

阿哲准备给朋友打个电话，分享他学习RRC的心得。当他的手指在屏幕上按下拨号键时，一场更为复杂和关键的RRC大戏——“连接控制”（Connection Control）即将拉开帷幕。这一部分对应规范的5.3节，是RRC协议中最为核心和庞大的章节之一。为了保证解读的深度和清晰度，我们将分多篇文章来详细拆解5.3节的内容。

本篇文章将聚焦于“连接控制”的开篇大戏：寻呼（Paging）和RRC连接建立（RRC connection establishment），分别对应规范的5.3.2和5.3.3节。我们将看到，无论是网络主动寻找UE（寻呼），还是UE主动联系网络（连接建立），RRC都扮演着无可替代的“信使”和“守门人”角色。

深度解析 3GPP TS 38.331：5.3.2 Paging & 5.3.3 RRC Connection Establishment (从寻找到握手：建立通信的第一座桥梁)

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.3.2 Paging (寻呼)”和“5.3.3 RRC connection establishment (RRC连接建立)”的核心章节，旨在为读者详细拆解UE与网络建立通信连接的两种基本场景：被动响应（寻呼）与主动发起（连接建立）的完整信令流程与协议行为。

1. 网络世界的“寻人启事”：寻呼流程 (解读5.3.2 Paging)

在阿哲准备拨打电话之前，我们先假设一个相反的场景：他的朋友正巧给他打来了电话。此时，阿哲的手机正静静地躺在口袋里，处于省电的RRC_IDLE或RRC_INACTIVE状态。网络是如何在茫茫人海中精准地找到并“唤醒”他的手机呢？答案就是寻呼（Paging）。

1.1 寻呼的目的与发起 (5.3.2.1 General & 5.3.2.2 Initiation)

The purpose of this procedure is:

  • to transmit paging information to a UE in RRC_IDLE or RRC_INACTIVE.
  • to transmit paging information for a L2 U2N Remote UE … to its serving L2 U2N Relay UE…

寻呼的主要目的有两个：

  1. 通知核心网（CN）来话/数据：当有电话呼入，或有下行数据（如微信消息）到达核心网时，网络需要通知处于RRC_IDLE状态的UE。
  2. 通知RAN侧事件：对于处于RRC_INACTIVE状态的UE，当有下行数据到达gNB时，RAN（无线接入网）可以通过寻呼来唤醒UE。此外，系统信息更新、公共告警（PWS）等事件也会通过寻呼机制来广播通知。

网络通过在UE可能在的寻呼区域（Paging Area）或RAN通知区（RNA）内的所有小区上，广播Paging消息来发起此过程。

1.2 UE的“谛听”时刻与消息接收 (5.3.2.3 Reception of the Paging message)

UE并不会一直监听网络信号，否则电池将很快耗尽。它只在自己专属的“谛听”时刻——寻呼时机（Paging Occasion, PO）——醒来。PO的计算是一个复杂但精确的过程，它基于UE的ID和DRX周期等参数，确保每个UE的监听时间点是分散且确定的。

当阿哲的手机在其PO时刻醒来，它会监听PDCCH，寻找由P-RNTI (Paging RNTI) 加扰的DCI。如果找到，这个DCI就会指向承载Paging消息的PDSCH资源。

Upon receiving the Paging message…, the UE shall: 1> if in RRC_IDLE, for each of the PagingRecord, if any, included in the Paging message… 2> if the ue-Identity included in the PagingRecord matches the UE identity allocated by upper layers: … forward the ue-Identity… to the upper layers;

Paging消息中可以包含多个PagingRecord，每个记录都针对一个特定的UE。当阿哲的手机接收到Paging消息后，它会逐一检查其中的PagingRecord：

  • 身份匹配：检查ue-Identity字段是否与自己的5G-S-TMSI匹配。如果匹配成功，说明这则“寻人启事”就是找自己的。
  • 响应动作：
    • 如果UE在RRC_IDLE态：匹配成功后，RRC层会将寻呼的域（cn-Domain，是来自核心网的电路域CS还是分组域PS）和寻呼原因（pagingCause，如果提供）等信息上报给NAS层。NAS层随即会发起业务请求（Service Request）流程，这会触发UE发起RRC连接建立流程，从而响应寻呼。
    • 如果UE在RRC_INACTIVE态：匹配成功后，UE会直接发起**RRC连接恢复（RRC Resume）**流程，以更快的速度回到连接态。

特殊场景：MT-SDT (Mobile Terminated Small Data Transmission) 如果寻呼消息中包含了mt-SDT指示，并且满足SDT（小数据传输）的条件，处于RRC_INACTIVE状态的UE可以不进入RRC_CONNECTED状态，而是直接在RRC_INACTIVE状态下完成这次小数据接收，从而进一步降低信令和功耗。

通过这套精密的寻呼机制，网络能够在UE保持低功耗的同时，依然能及时地联系到它，实现了“节电”与“可达”的完美平衡。

2. 主动出击：RRC连接建立流程 (解读5.3.3 RRC connection establishment)

现在，让我们回到阿哲主动拨打电话的场景。他的手机处于RRC_IDLE状态，当他按下拨号键时，上层（NAS层）会向RRC层发出“建立连接”的请求。RRC层随即启动了5G时代最基础也最重要的信令流程之一——RRC连接建立。

整个过程是一个标准的三步握手协议，其成功和失败的信令流程如规范中的Figure 5.3.3.1-1和Figure 5.3.3.1-2所示。

2.1 连接建立的前提条件 (5.3.3.1a Conditions for establishing RRC Connection)

并非所有情况都可以随意发起RRC连接。规范在5.3.3.1a节中特别为Sidelink等场景定义了严格的触发条件。例如，对于车联网（V2X）通信，只有在满足特定条件时（如需要获取网络调度的资源），UE才会发起RRC连接。这体现了RRC作为资源“守门人”的严谨性，避免了不必要的信令风暴。

2.2 流程的启动与准备 (5.3.3.2 Initiation)

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in RRC_IDLE and it has acquired essential system information…

流程启动有两个关键前提：

  1. 上层请求：必须是NAS层发出的明确请求。
  2. 获取了基本系统信息：UE必须已经成功获取了MIB和SIB1，知道如何在这个小区进行接入。

在正式发送请求前，UE还需完成两项重要的准备工作：

  • 接入控制检查：

    perform the unified access control procedure as specified in 5.3.14… UE会根据上层提供的接入类别（Access Category）和接入身份（Access Identities），执行统一接入控制（UAC）检查。这就像是进入一个热门景点前，先查看门口的公告，看自己所属的游客类别（如普通游客、VIP、紧急救援等）当前是否允许进入。如果接入被禁止（barred），则流程终止。

  • 初始配置应用：

    apply the default L1 parameter values as specified in corresponding physical layer specifications except for the parameters for which values are provided in SIB1; apply the default MAC Cell Group configuration as specified in 9.2.2; apply the CCCH configuration as specified in 9.1.1.2; UE会应用SIB1中的公共配置和规范中定义的默认配置，初始化自己的L1和L2协议栈，为即将到来的随机接入和信令传输做好准备。同时，启动一个至关重要的定时器T300，这是连接请求的超时定时器。

2.3 交互第一步：UE的“敲门砖” - RRCSetupRequest (5.3.3.3)

万事俱备，UE通过随机接入过程（RACH）在UL-SCH上发送第一条消息：RRCSetupRequest。这条消息的内容在5.3.3.3节中有详细规定。

The UE shall set the contents of RRCSetupRequest message as follows: 1> set the ue-Identity as follows: … 1> set the establishmentCause in accordance with the information received from upper layers;

  • ue-Identity (UE身份)：
    • 如果UE在当前跟踪区（TA）注册过，它会使用核心网分配的ng-5G-S-TMSI的一部分（ng-5G-S-TMSI-Part1）作为身份标识。
    • 如果UE是首次接入或没有有效的TMSI，它会生成一个39位的随机数。
  • establishmentCause (建立原因)： 这个字段至关重要，它告诉网络UE本次发起连接的目的。例如：
    • emergency: 紧急呼叫，最高优先级。
    • mps-PriorityAccess: 多媒体优先服务接入。
    • mo-Signalling: 移动台发起的信令流程（如注册更新）。
    • mo-Data: 移动台发起的数据传输。阿哲拨打电话，就属于mo-Signalling或mo-Voice（如果定义了）。

这条消息通过SRB0承载在CCCH逻辑信道上，是UE对网络世界的第一次“自我介绍”。

2.4 交互第二步：网络的“通行证” - RRCSetup (5.3.3.4)

gNB收到RRCSetupRequest后，如果同意UE的接入，就会回复RRCSetup消息。这条消息同样通过CCCH（逻辑信道）→ DL-SCH（传输信道）→ PDSCH（物理信道）发送给UE。

The UE shall perform the following actions upon reception of the RRCSetup: 1> … perform the cell group configuration procedure in accordance with the received masterCellGroup and as specified in 5.3.5.5; 1> perform the radio bearer configuration procedure in accordance with the received radioBearerConfig and as specified in 5.3.5.6;

收到RRCSetup后，UE会立即停止T300定时器，并开始应用其中的配置，这标志着连接建立取得了阶段性成功。RRCSetup消息的核心内容包括：

  • masterCellGroup: 包含了对主小区（PCell）的完整配置，包括物理层参数（如上行BWP）、MAC层参数（如RACH配置、DRX配置）等。
  • radioBearerConfig: 最重要的配置，它指示UE建立SRB1。这意味着UE和gNB之间正式建立了一条专用的信令通道。
  • masterCellId: 为UE分配一个在小区内唯一的C-RNTI。从此，UE在小区内就有了正式的“学号”。

2.5 交互第三步：UE的“投名状” - RRCSetupComplete (5.3.3.4)

UE应用完RRCSetup的配置后，会通过新建立的SRB1（承载于DCCH）发送RRCSetupComplete消息。这是三步握手的最后一步，也是至关重要的一步。

1> set the content of RRCSetupComplete message as follows: 2> set the dedicatedNAS-Message to include the information received from upper layers; 2> set the selectedPLMN-Identity to the PLMN selected by upper layers…

RRCSetupComplete消息的主要作用是：

  1. 确认连接成功：告知网络，UE已经成功完成了RRC连接的建立。
  2. 携带初始NAS消息：这是它的核心使命。dedicatedNAS-Message字段会携带UE的第一条NAS消息，对于阿哲的场景，这通常是Registration Request或Service Request。gNB收到后，会将这条NAS消息透明地转发给核心网的AMF。
  3. 上报所选网络信息：UE会告知gNB它所选择的PLMN，以及可能的S-NSSAI（网络切片信息）等。

消息发送后，UE正式进入RRC_CONNECTED状态。对于阿哲来说，电话接通前的“嘟嘟”声即将响起，RRC已经为他铺平了通往核心网的道路。

2.6 意外情况处理 (5.3.3.5, 5.3.3.6, 5.3.3.7)

  • RRCReject (连接拒绝): 如果gNB因为资源不足或其他原因拒绝了UE的请求，它会发送RRCReject消息。消息中可能包含一个waitTime，建议UE等待一段时间后再尝试。
  • 小区重选: 如果UE在等待RRCSetup的过程中（T300运行时）发现了一个信号更好的小区，它会停止当前的连接尝试，并立即在新小区上重新发起流程。
  • T300超时: 如果在T300定时器超时后，UE仍未收到RRCSetup或RRCReject，则认为本次连接尝试失败。UE会重置MAC层，并向上层报告连接建立失败。它可能会在一段时间后再次尝试。

结语：从寻找到握手

通过对5.3.2和5.3.3节的深入解读，阿哲清晰地理解了UE与网络建立通信连接的两条截然不同的路径：

  • 寻呼：是网络驱动的、被动的流程。它是在茫茫人海中找到沉睡UE的“扩音器”。
  • RRC连接建立：是UE驱动的、主动的流程。它是UE在需要服务时，向网络发起的“敲门”和“握手”。

这两个流程，一个“寻”，一个“建”，构成了所有通信服务的起点。无论是被动的电话呼入，还是主动的上网冲浪，都离不开这两座基础桥梁的搭建。

阿哲的电话已经拨通，他正在和朋友愉快地交谈。他不知道的是，为了维持这次通话的稳定，他的手机RRC实体正在后台不知疲倦地工作着，执行着更为复杂的测量、切换等流程。在下一篇文章中，我们将继续深入5.3节的后续内容，探索RRC是如何通过“万能”的RRCReconfiguration消息，来动态地管理和配置无线资源的。

FAQ

Q1：UE在RRC_IDLE状态下，是如何知道自己的寻呼时机（PO）的？ A1：UE通过一个精确的公式来计算自己的PO。这个公式的输入参数主要有两个：1) UE的ID（通常是5G-S-TMSI）；2) 网络在SIB1中广播的DRX（非连续接收）配置，如defaultPagingCycle。通过这个公式，UE和网络可以各自独立且一致地计算出UE应该在哪一个系统帧（SFN）和哪一个时隙（slot）醒来监听寻呼。这种机制避免了所有UE在同一时间监听，分散了网络负荷，也保证了UE可以最大限度地休眠省电。

Q2：RRC连接建立过程中的“建立原因”（establishmentCause）有什么实际作用？ A2：establishmentCause对于网络侧的资源分配和优先级处理至关重要。例如：

  • 如果原因是emergency，网络会给予最高优先级，即使在网络拥塞的情况下也要保证其接入成功。
  • 如果原因是mo-Data，网络可能会预期接下来会有大量数据传输，从而在初始配置中就分配一个比较高的带宽。
  • 如果原因是mo-Signalling，网络则知道这可能只是一次短暂的信令交互（如TAU），从而分配较少的初始资源以节省开销。 通过这个字段，网络可以对UE的意图有一个初步的判断，从而做出更智能的无线资源管理决策。

Q3：为什么RRCSetupComplete消息需要携带NAS消息？这种“捎带”设计有什么好处？ A3：这种“捎带”（piggybacking）设计是为了提高信令效率，缩短业务建立总时延。RRC连接建立的最终目的是为了承载上层业务（无论是语音还是数据），而这需要NAS层首先完成注册、鉴权、PDU会话建立等信令流程。如果RRC连接建立完成后，再单独发起一次上行传输来发送第一条NAS消息，会增加额外的时延和信令开销。将初始NAS消息直接封装在RRCSetupComplete中，实现了AS层和NAS层信令的“捆绑”发送，减少了一次独立的上行调度和传输过程，从而加快了整个业务的建立速度。

Q4：如果在RRC连接建立过程中，UE从小区A移动到了小区B，会发生什么？ A4：这取决于移动发生的具体阶段。

  • 如果在发送RRCSetupRequest之前，UE进行了小区重选，那么它会直接在新的小区B上发起全新的连接建立流程。
  • 如果UE已经在小区A发送了RRCSetupRequest，并且正在等待RRCSetup消息（T300运行时），此时发生了小区重选。根据规范5.3.3.6节，UE会停止在小区A的流程，并在小区B重新发起一次全新的RRC连接建立流程。之前的尝试会被放弃。这保证了UE总是在当前信号最好的小区上尝试接入。

Q5：L2 U2N Remote UE（二层用户到网络远端UE）在寻呼和连接建立方面和普通UE有什么不同？ A5：L2 U2N Remote UE是一种通过一个L2 U2N Relay UE（中继UE）来接入网络的终端，它本身不直接与gNB通信。

  • 寻呼：网络发送给Remote UE的寻呼消息会先被Relay UE接收。Relay UE再通过Sidelink（PC5接口）将PagingRecord转发给Remote UE。
  • 连接建立：当Remote UE需要建立连接时，它会通过Sidelink向Relay UE发送请求。Relay UE再代表它，向gNB发起RRC连接建立流程。在这个过程中，establishmentCause可能会被特殊设置，以告知网络这是一个由中继触发的连接。整个流程对于gNB来说，交互的主体是Relay UE，但服务的最终对象是Remote UE。

关系图谱