# 5G随机接入原理：从"敲门"到"握手"的全流程图解 > 你有没有想过，当你的手机从飞行模式切回正常模式，或者你坐的高铁从一个基站覆盖区驶入下一个——手机是怎么在几毫秒内和网络"对上暗号"的？这一切的起点，就是**随机接入（Random Access, RA）**。本文将带你从"为什么需要随机接入"出发，逐层拆解 PRACH 前导码、4步/2步接入流程、竞争解决机制，直到现网调试中的实战技巧。 --- ## 一、为什么需要随机接入？—— 从"举手发言"说起 想象一间大教室，几十个学生（UE）想向老师（gNB）提问。但教室没有"举手"规则的话，所有人同时喊叫，老师什么也听不清。**随机接入就是移动通信系统里的"举手规则"**——它解决的核心问题是： | 问题 | 随机接入的解法 | |------|---------------| | 上行时间未同步 | gNB 通过检测前导码估算传播时延，返回 **TA（Timing Advance）** 校正值 | | UE 没有网络分配的标识 | 通过 RA 过程分配 **Temporary C-RNTI** | | 多个 UE 同时接入 | **竞争解决（Contention Resolution）** 机制确保只有一个 UE 胜出 | | UE 没有上行资源 | Msg2 中附带 **UL Grant**，为后续信令交换分配资源 | ### 随机接入的触发场景 随机接入并非只在"开机"时发生，以下场景都会触发： ``` ┌─────────────────────────────────────────────────────┐ │ 随机接入触发场景全景 │ ├─────────────────────────────────────────────────────┤ │ 1. 初始接入（从 RRC_IDLE → RRC_CONNECTED） │ │ 2. RRC 重建（无线链路失败后恢复） │ │ 3. 切换（Handover，目标小区同步） │ │ 4. 上行失步（RRC_CONNECTED 但 TA 超时） │ │ 5. SI 请求（按需获取系统信息） │ │ 6. 其他（如 PDCCH order 触发） │ └─────────────────────────────────────────────────────┘ ``` 其中场景 1、2 采用 **基于竞争的随机接入（CBRA）**；场景 3（切换）通常采用 **非竞争随机接入（CFRA）**，因为网络可以提前给 UE 分配专用前导码。 --- ## 二、PRACH 前导码——"敲门砖"是怎么造出来的 ### 2.1 前导码的结构 一个 PRACH 前导码由两部分组成： ``` ┌──────────────┬──────────────────────────┐ │ CP（循环前缀）│ Sequence（ZC 序列部分） │ └──────────────┴──────────────────────────┘ │←── 吸收时延 →│←──── 携带签名信息 ──────→│ ``` - **CP（Cyclic Prefix）**：作用是"吸收"不同 UE 到 gNB 的传播时延差异。CP 越长，支持的小区覆盖半径越大。 - **Sequence**：承载前导码签名，使用 **Zadoff-Chu（ZC）序列**。 ### 2.2 Zadoff-Chu 序列—— 为什么选它？ ZC 序列的数学定义为： $$x_u[n] = e^{-j\frac{\pi u \cdot n(n+1)}{N_{\text{ZC}}}}, \quad n = 0, 1, \ldots, N_{\text{ZC}}-1$$ 其中 $u$ 是**根序列索引**（root sequence index），$N_{\text{ZC}}$ 是序列长度。 **为什么 ZC 序列是 PRACH 前导码的"天选之子"？** 因为它有三大"超能力"： | 特性 | 专业术语 | 实际意义 | |------|---------|---------| | 恒包络 | CAZAC（Constant Amplitude Zero Auto-Correlation） | 信号功率均匀分布，功放效率最高，不会出现功率峰值烧毁功放 | | 理想自相关 | Zero Auto-Correlation（旁瓣为零） | gNB 在噪声中精准定位前导码的到达时刻，从而精确估算 TA | | 低互相关 | Low Cross-Correlation | 不同 UE 使用不同根/循环移位的序列，gNB 能同时区分多个 UE 的前导码 | > **通俗类比**：把 ZC 序列想象成一组"独特嗓音"。每个人嗓音不同（不同根序列），即使同时说话，老师也能分辨出谁在喊。而且每个人嗓音的回声特性极其规律（理想自相关），老师能精确算出每个学生距离多远。 ### 2.3 从一个根序列生成 64 个前导码 每个小区需要提供 **64 个可用前导码**。gNB 在 SIB1 中广播根序列索引和零相关区配置（$N_{\text{CS}}$）。生成规则如下： ```mermaid flowchart TD A["gNB 广播 rootSequenceIndex
（如 u=1）"] --> B["UE 根据公式生成
ZC 根序列 x_u[n]"] B --> C["对根序列进行循环移位
步长 = N_CS"] C --> D{"一个根序列能生成
≥ 64 个前导码？"} D -->|是| E["✅ 共 64 个前导码
全部就绪"] D -->|否| F["使用下一个逻辑根序列
u+1 继续生成"] F --> G{"累计前导码数
≥ 64？"} G -->|否| F G -->|是| E style A fill:#e1f5fe style E fill:#c8e6c9 ``` 关键参数： - **$N_{\text{CS}}$**（零相关区长度）：由 `zeroCorrelationZoneConfig` 配置，决定循环移位的最小间隔。$N_{\text{CS}}$ 越大，支持的小区半径越大（因为需要更大的时延容忍），但每个根序列能生成的前导码越少。 - 前导码 0~63 中，部分可保留给 CFRA 使用（由 `ssb-perRACH-Occasion` 等参数控制）。 ### 2.4 前导码格式：长格式 vs 短格式 | 格式类型 | 序列长度 | 典型格式 | 支持小区半径 | 典型场景 | |---------|---------|---------|------------|---------| | **长格式**（Format 0-3） | 839 | Format 0: ~100km
Format 1: ~3km
Format 2: ~180km
Format 3: ~180km | 大 | FR1（Sub-6GHz），宏覆盖 | | **短格式**（A1/A2/A3/B1/B4/C0/C2） | 139 | 受限于 CP 长度 | 小 | FR2（毫米波），小小区，低时延 | > **为什么短格式序列长度只有 139？** 因为短格式用于毫米波频段，覆盖半径小、时延小，不需要那么长的序列来抵抗噪声。更短的序列意味着更少的处理时间，有利于降低接入时延。 --- ## 三、4步基于竞争的随机接入（CBRA）—— 逐帧拆解 这是最经典、也是现网中使用最频繁的随机接入流程。以下用交互时序图详解每一步： ```mermaid sequenceDiagram participant UE as UE（手机） participant gNB as gNB（基站） Note over UE: 选择随机 preamble ID
（从64个中随机选一个） UE->>gNB: Msg1: PRACH Preamble
（PRACH信道，ZC序列） Note over gNB: 检测前导码，估算TA
计算 RA-RNTI Note over UE: 在 RAR 窗口内监听
PDCCH（RA-RNTI 加扰） gNB->>UE: Msg2: RAR（随机接入响应）
包含: RAPID + TA + UL Grant + TC-RNTI Note over UE: 调整上行定时(TA)
使用 UL Grant 发送 UE->>gNB: Msg3: RRC Setup Request
（PUSCH，携带 UE ID） Note over gNB: 识别胜出 UE
回传竞争解决 ID gNB->>UE: Msg4: Contention Resolution
（PDSCH，携带 UE ID 回显） Note over UE: 比对 Msg4 中的 ID
匹配→接入成功
不匹配→竞争失败，退避重试 ``` ### Msg1 —— 举起你的手（发送前导码） **UE 做了什么：** 1. 从 SIB1 获取 PRACH 配置（时频资源位置、前导码格式、根序列信息） 2. 随机选择一个 preamble index（0~63） 3. 在对应的 PRACH Occasion 上发送前导码 **关键计算——RA-RNTI：** $$\text{RA-RNTI} = 1 + s\_id + 14 \times t\_id + 14 \times 80 \times f\_id + 14 \times 80 \times 8 \times ul\_carrier\_id$$ RA-RNTI 由 PRACH Occasion 的时域位置（$s\_id$：OFDM符号索引，$t\_id$：时隙索引）、频域位置（$f\_id$）和上行载波标识决定。**它的作用是让 UE 在 Msg2 时只关心"属于自己的响应"**。 **如果 Msg1 冲突了怎么办？** 多个 UE 可能碰巧选了同一个 preamble。此时 gNB 检测到这个前导码，返回一个 RAR，但不知道有多个 UE 在抢。这个冲突在 Msg3/Msg4 阶段才被解决。 ### Msg2 —— 老师点名回应（随机接入响应） **gNB 做了什么：** 1. 检测到前导码后，估算出 TA 值 2. 在 RAR 窗口内，用 **RA-RNTI** 加扰的 PDCCH 调度 PDSCH，发送 RAR MAC PDU **RAR 包含的核心内容：** | 字段 | 作用 | 类比 | |------|------|------| | **RAPID**（Random Access Preamble ID） | 标识 gNB 检测到的是哪个前导码 | "我听到的是 37 号同学" | | **TA Command** | 上行定时提前量，UE 据此调整发送时间 | "你的表慢了 3 微秒，调快" | | **UL Grant** | 为 Msg3 分配上行 PUSCH 资源 | "给你 2 分钟发言时间" | | **Temporary C-RNTI** | 临时 UE 标识 | "你先暂时代号'甲同学'" | > **实战注意**：RAR 窗口长度由 `ra-ResponseWindow` 配置，UE 在窗口内持续监听 PDCCH。如果窗口超时未收到 RAR，UE 会执行**功率攀升**后重发 Msg1。 ### Msg3 —— 自我介绍（调度传输） **UE 做了什么：** 1. 根据 TA 调整上行定时（从此刻起上行同步建立） 2. 使用 UL Grant 指定的 PUSCH 资源发送 **RRC 层消息** 3. 消息类型取决于触发场景： | 触发场景 | Msg3 中的 RRC 消息 | 携带的 UE 标识 | |---------|-------------------|---------------| | 初始接入 | `RRCSetupRequest` | 39 bit 随机值 或 S-TMSI | | RRC 重建 | `RRCReestablishmentRequest` | C-RNTI + PCI + ShortMAC-I | | RRC 恢复 | `RRCResumeRequest` | Resume ID + 认证令牌 | | 系统信息请求 | 不含 RRC 消息（MAC 层交互） | — | **竞争在此埋下伏笔**：如果两个 UE 在 Msg1 选了同一个 preamble，它们都会收到同一个 RAR，用同一个 UL Grant 发 Msg3。此时两个 Msg3 在 gNB 侧发生碰撞。 ### Msg4 —— 确认最终赢家（竞争解决） **gNB 做了什么：** 1. 在多个碰撞的 Msg3 中，成功解码其中一个 2. 将该 UE 在 Msg3 中发送的 **UE Identity** 原封不动回显，通过 MAC CE 发送 **UE 的判定逻辑：** ```mermaid flowchart TD A["UE 收到 Msg4"] --> B["解析 Contention Resolution MAC CE"] B --> C{"Msg4 中的 UE ID
与自己在 Msg3 发送的
一致吗？"} C -->|一致| D["✅ 竞争成功！
RRC 进入 CONNECTED
Temporary C-RNTI → C-RNTI"] C -->|不一致| E["❌ 竞争失败
丢弃 Temporary C-RNTI"] E --> F["根据 Backoff Indicator
等待随机退避时间"] F --> G["功率攀升 PREAMBLE_POWER_RAMPING_STEP
重新发送 Msg1"] ``` **功率攀升机制**的关键参数： - **`PREAMBLE_POWER_RAMPING_STEP`**：每次重试增加的发射功率（通常 0~6 dB） - **`preambleTransMax`**：最大前导码发送次数（如 N3、N5 等） - **`POWER_RAMPING_BACKOFF`**：在某些场景（如波束切换失败）下可暂停功率攀升 --- ## 四、2步随机接入（2-Step RACH）—— 更快的"敲门" 4步 RACH 的往返时延约 10~20 ms。对于 URLCC（超可靠低时延通信）和小数据传输场景，这个时延太大了。3GPP Release 16 引入了 **2-Step RACH**，将 4 步合并为 2 步： ```mermaid sequenceDiagram participant UE as UE participant gNB as gNB Note over UE: MsgA = Msg1 + Msg3 合并 UE->>gNB: MsgA: PRACH Preamble +
PUSCH Payload（RRC请求 + UE ID） Note over gNB: 同时检测前导码
和解码 PUSCH gNB->>UE: MsgB = Msg2 + Msg4 合并
包含: TA + 竞争解决 + UL Grant Note over UE: 竞争解决成功 → 完成 ``` ### 4步 vs 2步对比 | 对比维度 | 4-Step RACH | 2-Step RACH | |---------|-------------|-------------| | **消息数** | 4（Msg1~4） | 2（MsgA, MsgB） | | **往返时延** | ~10-20 ms | ~5-10 ms | | **信令开销** | 4 次空口交互 | 2 次空口交互 | | **UE 功耗** | 较高（多次收发） | 较低 | | **gNB 复杂度** | 中等 | 高（需同时检测前导码和解码数据） | | **适用场景** | 通用 | 小区半径小、负载低、URLCC、RedCap | | **引入版本** | Rel-15 | Rel-16 | > **为什么 2-Step RACH 不能完全替代 4-Step？** 因为 2-Step 的 MsgA 把前导码和数据"捆在一起"发送，这要求 gNB 有更强的处理能力（同时做相关检测和 PUSCH 解码），而且在大小区、高负载场景下，碰撞概率更高。所以 2-Step 更适合小小区和低负载场景。 --- ## 五、非竞争随机接入（CFRA）—— 切换时的"VIP通道" 切换场景下，源 gNB 可以提前通过 **HO Command（RRCReconfiguration）** 给 UE 分配一个**专用前导码**。这样 UE 不需要和别人竞争： ```mermaid flowchart TD A["源 gNB 向目标 gNB
请求专用 preamble"] --> B["目标 gNB 分配
专用 preamble index"] B --> C["源 gNB 通过
HO Command 转发给 UE"] C --> D["UE 使用专用 preamble
发送 Msg1"] D --> E["目标 gNB 检测到
专用 preamble"] E --> F["返回 Msg2（RAR）
→ 接入完成！"] style A fill:#fff3e0 style F fill:#c8e6c9 ``` **CFRA 只需要 Msg1 + Msg2 两步**，因为前导码是专用的，不存在竞争，自然也不需要 Msg3/Msg4 的竞争解决。 CFRA 的其他触发场景： - PDCCH Order 触发（gNB 主动要求 UE 重新同步） - SCG 添加/变更（EN-DC/NR-DC 场景） --- ## 六、随机接入全流程参数速查表 以下表格汇总了与 RA 相关的关键参数，在日常网优和故障排查中经常用到： | 参数名 | 含义 | 典型值 | 影响范围 | |-------|------|-------|---------| | `prach-ConfigurationIndex` | PRACH 时域/频域资源位置 | 0~255 | 决定 UE 在哪些时隙/符号可以发 Msg1 | | `rach-RootSequenceIndex` | 根序列索引起始值 | 0~837（长格式） | 决定本小区使用哪组 ZC 序列 | | `zeroCorrelationZoneConfig` | N_CS 配置索引 | 0~15 | 影响小区半径和每个根生成的前导码数量 | | `preambleTransMax` | Msg1 最大发送次数 | n3/n5/n10/n20/n50/n100 | 超过后判定 RA 失败 | | `PREAMBLE_POWER_RAMPING_STEP` | 功率攀升步长 | 0/2/4/6 dB | 影响远端 UE 接入成功率 | | `ra-ResponseWindow` | RAR 监听窗口长度 | 1~10 slot | 影响接入时延和重试节奏 | | `ra-ContentionResolutionTimer` | 竞争解决定时器 | 8/16/24/.../64 SF | Msg3 发送后等待 Msg4 的超时时间 | | `BACKOFF_INDICATOR` | 退避指示 | 0~960 ms | 竞争失败后的等待时间上限 | --- ## 七、波束管理与随机接入的联动 5G NR（特别是毫米波频段）中，随机接入与**波束管理**深度耦合： 1. **SSB-RO 映射**：UE 检测到某个 SSB（同步信号块）后，在对应的 PRACH Occasion 上发 Msg1。这隐含了 UE 选择的下行波束信息。 2. **gNB 波束响应**：gNB 根据 Msg1 到达的 PRACH Occasion，推断出 UE 所在方向，使用对应波束发送 Msg2。 3. **波束失败恢复（BFR）**：当 UE 检测到波束质量下降时，会发起基于 CFRA 的随机接入（使用新波束对应的专用 preamble），实现快速波束切换。 ``` SSB#0 ←→ PRACH Occasion#0 ←→ preamble 范围 A SSB#1 ←→ PRACH Occasion#1 ←→ preamble 范围 B SSB#2 ←→ PRACH Occasion#2 ←→ preamble 范围 C ... UE 选择信号最强的 SSB，在对应的 RO 上发 Msg1 → gNB 据此确定 UE 的最佳下行发送波束 ``` --- ## 八、现网调试实战—— 工程师怎么看 RA 问题 ### 场景 1：UE 反复 RACH 失败无法附着 **排查步骤：** 1. **查 UE 日志**：Msg1 是否发出？功率是否足够？`preambleTransMax` 用尽？ 2. **查 gNB 日志**：gNB 是否检测到 preamble？是否发送了 RAR？ 3. **常见原因**： - PRACH 资源配置错误（UE 和 gNB 的 PRACH 配置不一致） - 干扰导致 preamble 检测失败 - 小区半径超过前导码格式支持范围（如 Format 0 不够用） - UE 功率不足（地下室/电梯场景） ### 场景 2：切换时 RACH 失败率高 **排查重点：** - 目标小区是否正确分配了专用 preamble？ - CFRA preamble 数量是否足够？ - UE 收到的 HO Command 中的 `rach-ConfigDedicated` 是否正确？ - 目标小区 PRACH 资源是否拥塞？ ### 场景 3：Msg2 丢失导致 RA 重试风暴 **关键指标：** - `ra-ResponseWindow` 是否配置过短（导致 UE 提前放弃） - gNB 负载是否过高（来不及处理 RAR） - PDCCH 拥塞（RA-RNTI 加扰的 DCI 无法及时调度） ### 调试技巧速查 | 日志/工具 | 看什么 | |----------|-------| | UE L1/L2 Log | preamble index、发射功率、PRACH Occasion 编号 | | gNB L2 Log | preamble 检测率、RAR 发送数量、Msg3 解码成功率 | | Wireshark/QXDM | NAS 信令中 RA 失败原因值（如 cause = 'ra-ResponseFailure'） | | 网管 KPI | RA 成功率、平均 RA 时延、Msg1 重传次数分布 | --- ## 九、从 LTE 到 5G：随机接入的演进 | 演进维度 | 4G LTE | 5G NR | |---------|--------|-------| | 前导码格式 | Format 0~4（仅长格式） | Format 0~3 + A1~C2（长+短） | | 序列长度 | 839 | 839（FR1）+ 139（FR2） | | 接入方式 | 仅 4-Step CBRA/CFRA | 4-Step + **2-Step**（Rel-16） | | 波束联动 | 无（LTE 无模拟波束） | SSB-RO 映射，波束级 RA | | 覆盖增强 | CE Mode A/B（eMTC） | Repetition（Msg1/Msg3 重复） | | RedCap 支持 | 无 | 2-Step RACH 优化 | > **为什么 5G 需要短格式前导码？** 毫米波频段使用大规模天线阵列，波束极窄。UE 需要快速完成波束对齐和随机接入。短格式前导码序列更短（139 vs 839），处理时间更短，适合低时延场景。而且 gNB 的接收机可以用同一套 FFT 处理数据信道和短前导码，简化了硬件设计。 --- ## 常见问题 **Q1: CBRA 和 CFRA 的本质区别是什么？** A: **核心区别在于 preamble 的分配方式**。CBRA 中 UE 随机选择 preamble，可能与其他 UE 冲突，需要 Msg3/Msg4 竞争解决；CFRA 中 gNB 提前分配专用 preamble，不会冲突，只需 Msg1+Msg2 两步即可。打个比方：CBRA 是"公共自习室先到先得"，CFRA 是"预约了固定座位"。 **Q2: 2-Step RACH 的 MsgA 中，前导码和数据怎么同时发？** A: MsgA 实际上包含两部分：PRACH 上的前导码 + PUSCH 上的负载（RRC 请求）。它们在**不同的时频资源**上发送，但紧邻排列，作为一个整体"MsgA"看待。gNB 需要先检测前导码获取 TA，再用 TA 辅助解码 PUSCH 上的数据。 **Q3: 如果 Msg1 发了 preambleTransMax 次都没成功，UE 会怎样？** A: UE 会向高层（RRC）报告随机接入失败。根据触发场景的不同：初始接入时，UE 可能重选到其他小区再尝试；切换场景时，UE 可能发起 RRC 重建。这就是为什么网优中需要关注 RA 成功率指标——它是用户体验的"第一道关卡"。 **Q4: 为什么 N_CS 大了，支持的小区半径就大？** A: N_CS 决定了同一根序列生成的不同 preamble 之间的循环移位间隔。小区半径越大，不同距离的 UE 到达 gNB 的时延差越大，前导码之间的"时间模糊"越大。需要更大的 N_CS 来确保不同 preamble 在时延扩展后仍然正交。代价是每个根序列能生成的 preamble 数量减少，可能需要更多根序列。 **Q5: PRACH 和 SSB 的映射关系对 RA 性能有什么影响？** A: 在毫米波场景下，SSB 通过不同波束发送。UE 选择信号最强的 SSB，在对应的 PRACH Occasion 上发 Msg1。如果 SSB-RO 映射不合理（比如一个 RO 对应太多 SSB），UE 可能选到次优波束，导致 Msg2 接收失败。合理配置 SSB-perRACH-Occasion 参数是毫米波网优的关键。 --- ## 参考来源 1. [5G RACH Procedure — 4-Step and 2-Step Random Access (CafeTele)](https://www.cafetele.com/5g-rach-procedure/) — 4步/2步RACH完整流程详解 2. [PRACH (Physical Random Access Channel) — Complete Guide (CafeTele)](https://www.cafetele.com/5g-prach/) — PRACH前导码格式与配置详解 3. [2-Step RACH in Release 16 of 5G NR (WirelessBrew)](https://wirelessbrew.com/5g-nr/2-step-rach-in-release-16-of-5g-nr/) — Rel-16 两步RACH原理与设计动机 4. [RACH Failure Reasons in 5G NR (WirelessBrew)](https://wirelessbrew.com/5g-nr/rach-failure-reasons-in-5g-nr/) — 现网RA失败原因分析与排查 5. [ShareTechnote — 5G RACH](https://www.sharetechnote.com/html/5G/5G_RACH.html) — 通信技术百科全书级参考 6. [A Primer on Zadoff-Chu Sequences (arXiv)](https://arxiv.org/html/2211.05702v3) — ZC序列数学原理综述 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。