在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网络时走的第一条信令路径。
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/>随机接入完成
随机接入过程由以下事件触发:
| 触发事件 | 触发方式 | 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恢复 |
UE通过SIB1中的RACH-ConfigCommon获取PRACH参数。关键参数结构如下:
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 |
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个时,递增根序列索引继续生成。
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 |
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次。
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。
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使用 |
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 |
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之间的功率差异。
Msg3支持HARQ重传。若gNB解码Msg3失败,可通过TC-RNTI加扰的DCI 0_0调度重传。重传不触发新的随机接入过程。
在CBRA中,多个UE可能同时选择相同的前导码索引(preamble collision),在相同的PRACH occasion发送Msg1。gNB无法区分这些UE,会为它们分配相同的TC-RNTI。Msg4的核心使命就是解决这种竞争。
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]
两种竞争解决方式:
Contention Resolution Identity MAC CE(初始接入场景):gNB将Msg3中UE发送的48-bit UE Identity原封不动回传。UE比对——匹配则成功,不匹配则竞争失败。
C-RNTI MAC CE(已连接态场景):对于已分配C-RNTI的UE(如UL失步恢复),gNB直接用C-RNTI调度该UE,即表示竞争解决成功。
| 参数 | 取值范围 | 作用 |
|---|---|---|
| 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) |
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用于切换和波束失败恢复场景。gNB通过RRC信令(如HandoverCommand中的ra-PreambleIndex)或PDCCH order为UE专用分配前导码,消除了竞争冲突。
流程简化为Msg0(专用preamble分配)→ Msg1(发送专用preamble)→ Msg2(RAR),无Msg3/Msg4。
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 |
| 层 | 工具 | 关键字段 |
|---|---|---|
| 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。
| 故障现象 | 根因分析 | 排查手段 |
|---|---|---|
| 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较大的场景容易发生。
本文由「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 等场景全覆盖。
