<!-- title: 5G PRACH随机接入四步信令全链拆解 -->
<!-- domain: ran -->

# 5G PRACH随机接入四步信令全链拆解：从Preamble到竞争解决的MAC层全视角

## 一、随机接入的本质：为什么需要RACH？

在5G NR的OFDM系统中，上行传输严格要求时间同步——UE发送的信号必须在gNB分配的上行时间窗内精确到达。但UE在刚开机、切换、或失步后，并不知道自己到gNB的传播时延是多少。**随机接入（Random Access, RA）就是UE"敲门"的过程**：通过PRACH物理信道发送一个前导码（Preamble），gNB测量往返时延后回复Timing Advance（TA），从而建立上行同步。

根据3GPP TS 38.321 Section 5.1的定义，5G NR支持两种随机接入类型：

| 类型 | 步骤 | 适用场景 | 规范章节 |
|------|------|----------|----------|
| **CBRA（基于竞争）** | 4步 / 2步 | 初始接入、RRC重建、UL失步恢复 | TS 38.321 §5.1.2 / §5.1.3 |
| **CFRA（无竞争）** | 2步 | 切换、波束失败恢复（BFR） | TS 38.321 §5.1.4 / §5.1.5 |

本文聚焦最核心的**4步CBRA流程**（Msg1→Msg2→Msg3→Msg4），这是绝大多数UE接入5G网络时走的第一条信令路径。

## 二、4步CBRA完整信令时序图

```mermaid
sequenceDiagram
    participant UE as UE (MAC/PHY)
    participant gNB as gNB (MAC/PHY)

    Note over UE: Step 0: PRACH资源配置<br/>SIB1 → RACH-ConfigCommon
    Note over UE: 选择前导码索引 preamble index<br/>计算RA-RNTI

    UE->>gNB: Msg1: PRACH Preamble<br/>(Zadoff-Chu序列)<br/>RA-RNTI = f(s_id, t_id, f_id, ul_carrier_id)
    Note over UE: 启动ra-ResponseWindow定时器

    gNB->>UE: Msg2: Random Access Response (RAR)<br/>DCI 1_0 (RA-RNTI加扰) → PDSCH<br/>携带: TA, UL Grant, TC-RNTI

    Note over UE: 停止ra-ResponseWindow<br/>应用TA命令

    UE->>gNB: Msg3: Scheduled Transmission (PUSCH)<br/>携带: RRCSetupRequest / C-RNTI MAC CE<br/>使用TC-RNTI加扰

    Note over UE: 启动mac-ContentionResolutionTimer

    gNB->>UE: Msg4: Contention Resolution<br/>DCI 1_0 (TC-RNTI加扰) → PDSCH<br/>携带: Contention Resolution Identity MAC CE<br/>或 RRCSetup

    Note over UE: 竞争解决成功<br/>TC-RNTI → C-RNTI<br/>随机接入完成
```

## 三、Step 0：随机接入初始化与资源配置

### 3.1 触发条件（TS 38.321 §5.1.1）

随机接入过程由以下事件触发：

| 触发事件 | 触发方式 |Msg3内容 |
|----------|----------|---------|
| 初始接入（从RRC_IDLE） | UE自主 | RRCSetupRequest |
| RRC连接重建 | UE自主 | RRCReestablishmentRequest |
| 切换（HO） | RRC信令（含CFRA preamble） | RRCReconfigurationComplete |
| UL失步时新数据到达 | MAC层 | C-RNTI MAC CE |
| SI请求 | RRC层 | SI请求消息 |
| 波束失败恢复（BFR） | MAC层 | BFR MAC CE / TRS恢复 |

### 3.2 PRACH资源配置（TS 38.213 §8, TS 38.331）

UE通过**SIB1**中的`RACH-ConfigCommon`获取PRACH参数。关键参数结构如下：

```text
graph TD
    A[RACH-ConfigCommon] --> B[prach-ConfigurationIndex<br/>时域资源映射表]
    A --> C[msg1-FrequencyStart<br/>频域起始位置]
    A --> D[preambleReceivedTargetPower<br/>目标接收功率dBm]
    A --> E[preambleTransMax<br/>最大前导码发送次数]
    A --> F[powerRampingStep<br/>功率攀升步长dB]
    A --> G[ra-ResponseWindow<br/>RAR接收窗口(slots)]
    A --> H[cb-PreamblePerSSB<br/>每个SSB的前导码数]
    A --> I[contentionResolutionTimer<br/>竞争解决定时器]
    A --> J[PRACH Root Sequence Index<br/>ZC根序列起始索引]
```

**PRACH前导码格式**由`prach-ConfigurationIndex`映射到TS 38.211 Table 6.3.3.2-2/3/4：

| 序列类型 | 格式 | 序列长度L_RA | CP长度(μs) | 适用场景 |
|----------|------|-------------|------------|----------|
| 长序列 | Format 0 | 839 | 3168 | FR1宏站（~100km覆盖） |
| 长序列 | Format 1 | 839 | 21024 | FR1超远覆盖 |
| 长序列 | Format 2 | 839 | 4736 | FR1中等覆盖 |
| 长序列 | Format 3 | 839 | 4736 | FR1/FDD小小区 |
| 短序列 | A1/B1 | 139 | 288 | FR2 mmWave |
| 短序列 | A2/B2/C2 | 139 | 576/1248 | FR2 |

## 四、Msg1：PRACH前导码发送

### 4.1 Zadoff-Chu序列生成（TS 38.211 §6.3.3.1）

PRACH前导码基于**Zadoff-Chu (ZC)序列**生成。其核心特性是**恒包络零自相关（CAZAC）**，使得gNB能在噪声中可靠检测并精确估计时延。

对于长序列（L_RA=839）：
$$x_u[n] = e^{-j\frac{\pi u n(n+1)}{L_{RA}}}$$

其中u为**根序列索引**，由`PRACH Root Sequence Index`指定。每个小区配置一个根序列起始索引，通过**循环移位（N_CS）**生成64个前导码。当循环移位不够生成64个时，递增根序列索引继续生成。

### 4.2 RA-RNTI计算

UE在发送Msg1时需要计算RA-RNTI，gNB用此RNTI在Msg2中寻址对应UE：

$$\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}}$$

| 参数 | 含义 | 取值范围 |
|------|------|----------|
| s_id | PRACH occasion的首个OFDM符号索引 | 0~13 |
| t_id | PRACH occasion在一个系统帧内的首个时隙索引 | 0~79 |
| f_id | PRACH occasion在频域的索引 | 0~7 |
| ul_carrier_id | 上行载波标识（NUL=0, SUL=1） | 0~1 |

### 4.3 功率控制（TS 38.321 §5.1.3）

Msg1发送功率采用**开环功率控制 + 逐步攀升**策略：

$$P_{PRACH} = \min\{P_{CMAX}, PREAMBLE\_RECEIVED\_TARGET\_POWER + PL\}$$

其中：
- **PREAMBLE_RECEIVED_TARGET_POWER** = preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER - 1) × powerRampingStep
- **PL**（路径损耗）= 参考信号功率 – RSRP
- **PREAMBLE_POWER_RAMPING_COUNTER**每次Msg1重传递增1

典型配置：preambleReceivedTargetPower = -100dBm，powerRampingStep = 2dB，preambleTransMax = 8次。

## 五、Msg2：随机接入响应（RAR）

### 5.1 RAR接收窗口

UE发送Msg1后，在**ra-ResponseWindow**内监听DCI format 1_0（RA-RNTI加扰）调度的PDSCH。窗口起始点为Msg1发送后至少一个符号的下一个PDCCH监听时机。

窗口长度由`ra-ResponseWindow`配置，在FR1下取值1/2/3/4/5/6/7/8/10/20/30/40/50/60/80/100/200个slot。

### 5.2 RAR MAC PDU结构（TS 38.321 §6.2.2）

```mermaid
graph LR
    A[RAR MAC PDU] --> B[BI字段<br/>回退指示<br/>1字节扩展位]
    A --> C[RAR #1]
    A --> D[RAR #2]
    A --> E[...]
    A --> F[RAR #N]

    C --> C1[E/T=1<br/>RAPID<br/>1字节]
    C --> C2[T_A<br/>Timing Advance<br/>12 bits]
    C --> C3[UL Grant<br/>Msg3调度<br/>27 bits]
    C --> C4[TC-RNTI<br/>临时标识<br/>16 bits]
```

| IE字段 | 长度 | 说明 |
|--------|------|------|
| **BI (Backoff Indicator)** | 4 bits | E=1时存在；回退参数索引，0~1280ms |
| **E** | 1 bit | Extension bit，1=后续还有MAC subPDU |
| **T** | 1 bit | Type bit，T=1表示RAPID，T=0表示BI |
| **RAPID** | 6 bits | Random Access Preamble ID，匹配Msg1的前导码索引 |
| **Timing Advance** | 12 bits | TA命令，0~3846，步长16×Tc/2 |
| **UL Grant** | 27 bits | Msg3 PUSCH调度信息（跳频、MCS、TBS等） |
| **TC-RNTI** | 16 bits | 临时C-RNTI，后续Msg3/Msg4使用 |

### 5.3 关键处理逻辑

1. UE用RA-RNTI在PDCCH搜索Type1-PDCCH CSS
2. 若DCI 1_0中的Random Access Preamble ID与自身Msg1发送的preamble index匹配 → RAR成功
3. 应用TA命令：N_TA = TA × 16 × 16/64 × Tc，调整上行发送定时
4. 提取UL Grant，准备Msg3
5. 若窗口超时无匹配RAR → PREAMBLE_POWER_RAMPING_COUNTER++，重新发送Msg1

## 六、Msg3：调度传输

### 6.1 Msg3内容

Msg3是通过Msg2中UL Grant调度的PUSCH传输，其内容取决于随机接入触发原因：

| 触发原因 | Msg3负载 | MAC CE / RRC消息 |
|----------|----------|------------------|
| 初始接入 | RRCSetupRequest | 含UE Identity（39-bit随机值或5G-S-TMSI） |
| RRC重建 | RRCReestablishmentRequest | 含C-RNTI、pci、reestablishmentCause |
| 切换 | RRCReconfigurationComplete | 确认切换完成 |
| UL失步 | C-RNTI MAC CE | 仅含已有C-RNTI |
| BFR | BFR MAC CE | 含失败的服务Beam ID |

### 6.2 Msg3功率控制

Msg3 PUSCH功率考虑了Msg1与Msg3之间的功率偏移：

$$P_{Msg3} = \min\{P_{CMAX}, P_{O\_PUSCH} + 10\log_{10}(M) + \alpha \cdot PL + \Delta_{TF} + f(i)\}$$

其中功率基准包含**Msg3-deltaPreamble**偏移量（TS 38.321 §7.1.1），用于补偿PRACH和PUSCH之间的功率差异。

### 6.3 HARQ重传

Msg3支持HARQ重传。若gNB解码Msg3失败，可通过TC-RNTI加扰的DCI 0_0调度重传。重传不触发新的随机接入过程。

## 七、Msg4：竞争解决

### 7.1 竞争问题产生的原因

在CBRA中，多个UE可能**同时选择相同的前导码索引**（preamble collision），在相同的PRACH occasion发送Msg1。gNB无法区分这些UE，会为它们分配相同的TC-RNTI。Msg4的核心使命就是**解决这种竞争**。

### 7.2 竞争解决机制

```mermaid
flowchart TD
    A[UE发送Msg3] --> B[启动mac-ContentionResolutionTimer]
    B --> C{收到TC-RNTI/C-RNTI<br/>加扰的PDCCH?}
    C -->|否| D{定时器超时?}
    D -->|是| E[竞争解决失败]
    E --> F[清空HARQ缓冲区<br/>PREAMBLE_POWER_RAMPING_COUNTER++<br/>返回Step 0]
    D -->|否| C
    C -->|是| G{Msg3是C-RNTI MAC CE?}
    G -->|是| H{PDSCH包含<br/>C-RNTI MAC CE?}
    H -->|是| I[竞争解决成功 ✓]
    H -->|否| C
    G -->|否| J{PDSCH中的Contention Resolution<br/>Identity MAC CE与Msg3 UE Identity匹配?}
    J -->|匹配| K[竞争解决成功 ✓<br/>TC-RNTI → C-RNTI]
    J -->|不匹配| L[竞争解决失败 ✗<br/>释放TC-RNTI<br/>返回Step 0]
```

**两种竞争解决方式**：

1. **Contention Resolution Identity MAC CE**（初始接入场景）：gNB将Msg3中UE发送的48-bit UE Identity原封不动回传。UE比对——匹配则成功，不匹配则竞争失败。

2. **C-RNTI MAC CE**（已连接态场景）：对于已分配C-RNTI的UE（如UL失步恢复），gNB直接用C-RNTI调度该UE，即表示竞争解决成功。

### 7.3 定时器与计数器

| 参数 | 取值范围 | 作用 |
|------|----------|------|
| mac-ContentionResolutionTimer | 8/16/24/32/40/48/56/64 SF | 等待Msg4的定时器，发送Msg3后启动 |
| preambleTransMax | 3/4/5/6/7/8/10/20/50/100/200 | Msg1最大发送次数，超时则RA失败 |
| PREAMBLE_POWER_RAMPING_COUNTER | 1~preambleTransMax | 功率攀升计数器 |
| PREAMBLE_BACKOFF | BI字段映射值 | gNB指示的回退时间（0~1280ms） |

## 八、功率攀升与回退机制全流程

```mermaid
stateDiagram-v2
    [*] --> Init: RA触发
    Init --> Msg1_Send: 选择preamble<br/>计算功率
    Msg1_Send --> Wait_RAR: 启动ra-ResponseWindow

    Wait_RAR --> Msg2_Received: RAR匹配RAPID
    Wait_RAR --> Backoff_Check: 窗口超时

    Backoff_Check --> Power_Ramp: preambleTransMax未超
    Backoff_Check --> RA_Failure: preambleTransMax已超

    Power_Ramp --> Msg1_Send: PREAMBLE_POWER_RAMPING_COUNTER++<br/>等待回退时间

    Msg2_Received --> Msg3_Send: 应用TA<br/>提取UL Grant
    Msg3_Send --> Wait_CR: 启动contentionResolutionTimer

    Wait_CR --> Msg4_Success: 竞争解决成功
    Wait_CR --> CR_Fail: 定时器超时

    CR_Fail --> Power_Ramp: 计数器不变<br/>重新选preamble
    CR_Fail --> RA_Failure: 达到最大重试次数

    Msg4_Success --> [*]: RA完成<br/>TC-RNTI→C-RNTI
    RA_Failure --> [*]: 上报RRC层<br/>RA失败
```

## 九、CFRA与2-Step RACH对比

### 9.1 CFRA（无竞争随机接入）

CFRA用于切换和波束失败恢复场景。gNB通过**RRC信令**（如HandoverCommand中的`ra-PreambleIndex`）或**PDCCH order**为UE**专用分配前导码**，消除了竞争冲突。

流程简化为Msg0（专用preamble分配）→ Msg1（发送专用preamble）→ Msg2（RAR），无Msg3/Msg4。

### 9.2 2-Step RACH（Rel-16引入，TS 38.321 §5.1.3A）

R16引入2-Step RACH将Msg1+Msg3合并为**MsgA**，Msg2+Msg4合并为**MsgB**，减少时延：

| 对比维度 | 4-Step CBRA | 2-Step RACH | CFRA |
|----------|-------------|-------------|------|
| 消息数 | 4 | 2 | 2(含Msg0) |
| 时延 | 基准 | ~50%降低 | 最低 |
| 竞争 | 有 | 有(MsgB含fallback指示) | 无 |
| MsgA/Msg1负载 | 仅preamble | Preamble + PUSCH payload | 仅preamble |
| 适用场景 | 通用初始接入 | 小包/时延敏感/覆盖增强 | 切换/BFR |
| 规范章节 | §5.1.2 | §5.1.3A | §5.1.4 |

## 十、抓包识别与故障排查

### 10.1 抓包识别要点

| 层 | 工具 | 关键字段 |
|----|------|----------|
| PHY | 频谱仪/扫频仪 | PRACH occasion时频位置、格式 |
| MAC/L1 | Wireshark (pcap) | RAR MAC PDU（RAPID、TA、TC-RNTI、UL Grant） |
| RRC | Wireshark (NAS) | RRCSetupRequest、RRCSetup |
| L1 MAC | 基站日志 | PREAMBLE_POWER_RAMPING_COUNTER、RAR窗口统计 |

**Msg1识别**：在PRACH时频资源上出现ZC序列功率突增，RA-RNTI由时频位置计算得出。

**Msg2识别**：DCI 1_0以RA-RNTI加扰→PDSCH包含RAR MAC PDU，重点看BI、RAPID、TA、TC-RNTI、UL Grant五个字段。

**Msg3识别**：DCI 0_0以TC-RNTI加扰→PUSCH承载RRCSetupRequest或C-RNTI MAC CE。

**Msg4识别**：DCI 1_0以TC-RNTI加扰→PDSCH承载Contention Resolution Identity MAC CE + RRCSetup。

### 10.2 常见故障点与排查

| 故障现象 | 根因分析 | 排查手段 |
|----------|----------|----------|
| Msg1反复重发，功率持续攀升 | gNB未检测到前导码；PRACH功率不足或覆盖盲区 | 检查preambleReceivedTargetPower配置、RSRP、路径损耗 |
| RAR窗口超时 | gNB处理拥塞或DCI未下发 | 查gNB侧PRACH检测日志，ra-ResponseWindow是否过短 |
| Msg3解码失败 | UL Grant不足、MCS过高、干扰 | 查Msg2 UL Grant中TBS大小，调整Msg3-deltaPreamble |
| 竞争解决失败（Msg4不匹配） | 前导码碰撞率高，小区负载过大 | 统计PRACH preamble collision率，增加root sequence数量 |
| mmWave场景RA频繁失败 | Beam correspondence问题，波束未对准 | FR2需检查SSB beam与PRACH occasion映射关系 |
| 大量UE同时接入导致风暴 | 事件触发（如体育馆场景） | 配置ACB（Access Class Barring）、EAB，扩展PRACH资源 |
## 十一、5G NR vs LTE PRACH关键差异

| 对比项 | 5G NR | LTE |
|--------|-------|-----|
| 前导码格式数量 | 13种（长4+短9） | 5种（Format 0~4） |
| 序列长度 | 839/139 | 839 |
| 波束关联 | SSB beam与PRACH occasion绑定 | 无（非mmWave） |
| SUL支持 | 支持（ul_carrier_id区分） | 不支持 |
| 2-Step RACH | R16支持 | 不支持 |
| BFR专用RACH | 支持（CFRA） | 不支持 |
| PRACH前导码数/小区 | 64 | 64 |
| 功率攀升步长范围 | 0/2/3/4/6 dB | 0/2/4/6 dB |

## 常见问题

**Q1: CBRA和CFRA在实际网络中如何选择？**
A: 对于初始接入、RRC重建等UE自主发起的场景，必须使用CBRA。对于切换（gNB通过RRC Reconfiguration with Sync分配专用preamble）和波束失败恢复（gNB通过PDCCH order或BFR配置分配专用preamble），使用CFRA以消除竞争、降低时延。网络侧控制CFRA的触发。

**Q2: 为什么Msg4的竞争解决是通过回传Msg3的UE Identity实现的？**
A: 因为Msg1只携带6-bit的preamble index，多个UE可能碰巧选择相同的preamble，gNB无法区分。而Msg3中UE发送了唯一的48-bit identity（随机值或5G-S-TMSI），gNB将其回传后，只有identity匹配的那个UE才能确认竞争成功，其他UE知道"不是我"并重新发起RA。

**Q3: RA-RNTI为什么由时频位置计算而不是随机分配？**
A: 设计意图是**无状态关联**。gNB在收到Msg1时，通过检测到的PRACH occasion的时频位置即可算出RA-RNTI，用其在PDCCH寻址对应的UE。这避免了gNB维护"preamble index→RNTI"映射表的开销，且天然支持同一时刻多个UE在不同频域PRACH occasion发起接入。

**Q4: PRACH前导码碰撞率高的优化手段有哪些？**
A: (1) 增加`PRACH Root Sequence Index`对应的小区根序列数，扩展循环移位生成的preamble池；(2) 调整`prach-ConfigurationIndex`增加PRACH occasion密度；(3) 在负载高的场景配置ACB（Access Class Barring）控制接入速率；(4) 启用2-Step RACH分担负载。

**Q5: 2-Step RACH什么场景下会fallback到4-Step？**
A: 当gNB收到MsgA后仅成功检测到preamble但未能解码PUSCH payload时，MsgB中携带fallbackRAR（结构与Msg2 RAR相同），指示UE回退到4-Step流程的Msg3发送。这在覆盖较差或MsgA payload较大的场景容易发生。

## 参考来源

1. [3GPP TS 38.321 V19.x.x — NR MAC Protocol Specification, Section 5.1](https://www.3gpp.org/DynaReport/38321.htm) — 随机接入过程完整定义
2. [3GPP TS 38.211 V19.x.x — NR Physical Channels and Modulation, Section 6.3.3](https://www.3gpp.org/DynaReport/38211.htm) — PRACH前导码生成与ZC序列
3. [3GPP TS 38.213 V19.x.x — NR Physical Layer Procedures for Control, Section 8](https://www.3gpp.org/DynaReport/38213.htm) — PRACH资源配置
4. [ShareTechnote — 5G/NR RACH](https://www.sharetechnote.com/html/5G/5G_RACH.html) — PRACH流程可视化与参数详解
5. [HiCellTek — RACH Failure Analysis in LTE and 5G NR](https://hicelltek.com/en/blog/rach-failure-analysis-lte-5g/) — RACH故障诊断与对策
6. [3GLTEInfo — 5G NR MAC Random Access Procedure](https://www.3glteinfo.com/5g/protocols/mac/random-access/) — MAC层随机接入流程参考

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)