# 5G两步随机接入MsgA/MsgB机制全链拆解 ## 引言：为什么需要"砍掉一半"的随机接入 随机接入（Random Access Channel, RACH）是5G NR中UE与gNB建立上行同步、获取C-RNTI的唯一入口。传统4-step RACH（Rel-15）需要经历 Msg1（Preamble）→ Msg2（RAR）→ Msg3（PUSCH）→ Msg4（竞争解决）四个步骤，往返两次（2 RTT）才能完成竞争解决。在URLLC（超低时延高可靠通信）、工业物联网、卫星NTN（Non-Terrestrial Networks，长传播时延）等场景下，这套流程的时延开销变得难以接受。 为此，3GPP在**Release 16**引入了**2-step RACH（Type-2 Random Access）**机制，其核心思想是把4-step中的 Msg1+Msg3 合并为 **MsgA**、把 Msg2+Msg4 合并为 **MsgB**，用一次往返完成接入。该机制在 **TS 38.321 §5.1.3（MAC随机接入过程）**、**TS 38.213 §8（物理层控制过程）**、**TS 38.331（RRC参数配置）** 中完成标准化，并在Rel-17/18中针对NTN、小数据传输SDT、波束失败恢复等场景持续增强。 本文聚焦2-step RACH这一具体机制，从**MsgA/MsgB消息结构、RO-PUSCH资源映射、MsgB三种响应（successRAR/fallbackRAR/backoffIndicator）、回退到4-step的衔接**几个关键环节展开拆解。 --- ## 一、2-step RACH的设计意图与触发场景 ### 1.1 设计目标：以一次上行"加塞"换两次往返 4-step RACH的瓶颈在于：Msg1只发了一个Preamble序列，gNB在Msg2之前完全不知道UE要传什么；而Msg3承载的RRC消息（如`RRCSetupRequest`、`RRCReestablishmentRequest`、`RRCResumeRequest`）其实可以更早发出。2-step RACH的逻辑就是：**既然Msg3迟早要发，不如与Msg1一起发**。 ```mermaid flowchart TD subgraph S4["4-step RACH (Rel-15)"] direction LR A1["Msg1
Preamble"] --> A2["Msg2
RAR(TA+Grant)"] A2 --> A3["Msg3
PUSCH(RRC)"] A3 --> A4["Msg4
竞争解决"] end subgraph S2["2-step RACH (Rel-16)"] direction LR B1["MsgA
Preamble+PUSCH"] --> B2["MsgB
success/fallback"] end S4 -->|"压缩2 RTT -> 1 RTT"| S2 ``` ### 1.2 六类触发事件 依据**TS 38.321 §5.1.1**，随机接入可由以下事件触发，其中大部分在Rel-16后同时支持4-step与2-step： | 事件 | 场景说明 | 2-step是否支持 | |------|---------|---------------| | 初始接入（RRC_IDLE→RRC_CONNECTED） | 从同步到发起`RRCSetupRequest` | ✅ CBRA | | RRC连接重建 | `RRCReestablishmentRequest` | ✅ CBRA | | 切换（Handover） | 目标gNB预分配资源 | ✅ CFRA/CBRA | | 上行失步时UL/SUL数据到达 | TA失步触发同步 | ✅ CBRA | | SR失败 / UL失步 | 调度请求失败回退 | ✅ CBRA | | 波束失败恢复（BFR） | 检测到BFI触发 | ✅ CBRA（R16增强） | | NTN定时提前调整（Rel-17） | 卫星场景TA预补偿 | ✅ 增强支持 | ### 1.3 RACH类型选择：由RSRP门限裁决 UE在发起随机接入前，需在4-step与2-step之间做选择。决定依据是**RSRP门限比较**，由`rsrp-ThresholdMsgA`（RRC参数）控制： ```mermaid flowchart TD Start["UE有上行数据/信令需求"] --> Check1{RACH资源是否配置了
msgA-PUSCH资源?} Check1 -->|否| Use4["选择 4-step RACH"] Check1 -->|是| Check2{RSRP ≥ rsrp-ThresholdMsgA?} Check2 -->|否| Use4 Check2 -->|是| Use2["选择 2-step RACH"] Use2 --> BeamCheck{波束CFRA资源可用?} BeamCheck -->|是| CFRA["CFRA模式2-step"] BeamCheck -->|否| CBRA["CBRA模式2-step"] ``` **设计意图**：2-step RACH的MsgA PUSCH承载实际数据，需要较好的信道条件才能被正确解调。**rsrp-ThresholdMsgA相当于一道"准入闸"**——只有处于小区中心（高RSRP）的UE才允许使用2-step，否则强制走稳健的4-step。这避免了"边缘UE发MsgA PUSCH失败、白白浪费上行资源"的问题。 --- ## 二、MsgA：Preamble与PUSCH的"捆绑一击" ### 2.1 MsgA的物理结构 MsgA在物理层由两部分组成，共享同一个时频资源单元的关联： ```mermaid flowchart LR subgraph MsgA["MsgA 物理资源结构"] P1["PRACH Preamble
(PRACH Occasion, RO)"] --> P2["PUSCH Payload
(PUSCH Occasion, PO)"] end P1 -.->|"1:N 或 1:1 映射"| P2 ``` - **PRACH部分**：与4-step Msg1完全相同的Preamble序列（基于Zadoff-Chu序列生成的preamble format），在PRACH Occasion（RO）上发送。 - **PUSCH部分**：承载MAC PDU（即4-step中Msg3的内容），在配置好的PUSCH Occasion（PO）上发送。配置参数包括MCS、时频资源大小、DM-RS图样等。 ### 2.2 RO与PO的映射关系 2-step RACH引入了**MsgA-PO（PUSCH Occasion）**这一新概念，并把RO与PO绑定起来，其映射在**TS 38.213 §8.1**中定义： ```mermaid flowchart TD RO1["RO #1"] --> PO1["PO #1 (DM-RS组A)"] RO1 --> PO2["PO #2 (DM-RS组B)"] RO2["RO #2"] --> PO3["PO #3 (DM-RS组A)"] RO2 --> PO4["PO #4 (DM-RS组B)"] RO3["RO #3"] --> PO5["PO #5 ..."] ``` - 每个**RO**可以关联到多个**PO**（通过DM-RS端口、码分复用区分），从而让多个UE在同一个RO上发不同PO而互不干扰。 - UE通过选定的Preamble索引（preamble index）和PO的DM-RS组合，**隐式编码自己的身份**——这正是2-step RACH竞争解决的物理基础。 **关键参数配置（RRC层，TS 38.331）**： | 参数名 | 含义 | 配置在 | |--------|------|--------| | `msgA-PreambleIndex` | CFRA专用Preamble索引 | SpCellConfig | | `msgA-TransMax` | MsgA最大重传次数 | RACH-ConfigCommonTwoStepRA | | `msgA-PUSCH-Resource` | MsgA PUSCH时频资源、MCS、DM-RS | MsgA-PUSCH-Config | | `msgA-RSRP-Threshold` | 启用2-step的RSRP门限 | RACH-ConfigCommonTwoStepRA | | `msgB-ResponseWindow` | 等待MsgB的窗口长度 | RACH-ConfigCommonTwoStepRA | | `powerRampingStepMsgA` | MsgA功率爬坡步长 | RACH-ConfigCommon | ### 2.3 MsgA的MAC PDU内容 MsgA PUSCH承载的MAC PDU与4-step Msg3一致，典型内容包括： - `RRCSetupRequest`（含UE identity: 39-bit `randomValue` 或 `ng5G-S-TMSI`） - `RRCReestablishmentRequest`（含C-RNTI、PCI、reestablishmentCause） - `RRCResumeRequest`（用于SDT/RRC_INACTIVE状态小数据传输，Rel-16增强重点） --- ## 三、MsgB：三种响应的分流与处理 MsgB是2-step RACH的精华所在。gNB收到MsgA后，根据对**Preamble和PUSCH的解码情况**，给出三种可能的响应。这是理解整个机制的钥匙。 ### 3.1 完整时序图 ```mermaid sequenceDiagram participant UE participant gNB Note over UE: RSRP≥门限，选定2-step RACH UE->>gNB: MsgA (PRACH Preamble + PUSCH Payload) Note over gNB: gNB解码MsgA alt 场景A: Preamble✓ 且 PUSCH✓ (解码成功) gNB-->>UE: MsgB = successRAR
(C-RNTI, TA, 竞争解决, UL Grant) Note over UE: 接入完成，进入RRC_CONNECTED else 场景B: Preamble✓ 但 PUSCH✗ (PUSCH解码失败) gNB-->>UE: MsgB = fallbackRAR
(含Msg3 UL Grant, TC-RNTI) Note over UE: 回退到4-step流程 UE->>gNB: Msg3 (用fallbackRAR给的Grant重发PUSCH) gNB-->>UE: Msg4 (竞争解决) else 场景C: 网络拥塞，无资源响应 gNB-->>UE: MsgB = backoffIndicator Note over UE: 按BI随机退避后重发MsgA end ``` ### 3.2 三种MsgB响应逐项解析 **（1）successRAR（成功响应）** 这是2-step RACH的理想终态。当gNB同时成功解码了MsgA的Preamble和PUSCH时，用一个MAC子PDU直接完成RAR+竞争解决。其关键字段包括： - **UE Contention Resolution Identity**：回显UE在MsgA PUSCH中上报的身份（如CCCH SDU的前48 bit），用于UE确认是自己的MsgA被接收——这是竞争解决的核心。 - **Timing Advance Command**：时间提前量，完成上行同步。 - **C-RNTI**：分配的小区无线网络临时标识。 - **UL Grant**：用于后续上行传输的授权。 - **TAC（Timing Advance Command）**。 successRAR的MAC RAR结构示意如下： ```mermaid flowchart LR subgraph MsgB_SUCC["successRAR MAC subPDU"] R1["RAPID
(Preamble ID回显)"] --> R2["UE Contention
Resolution Identity"] R2 --> R3["Timing
Advance"] R3 --> R4["C-RNTI"] R4 --> R5["UL Grant"] end ``` **（2）fallbackRAR（回退响应）** 当gNB**解码Preamble成功但PUSCH失败**时——常见于MsgA PUSCH功率不足、信道突发恶化——gNB不浪费已经成功获取的Preamble，而是下发fallbackRAR，把流程"半路接入"到4-step。 fallbackRAR的内容与4-step Msg2（RAR）几乎一致：包含 **RAPID、TA、TC-RNTI、Msg3 UL Grant**。UE收到后，**把刚发的MsgA Preamble视为Msg1**，用fallbackRAR中的Grant在Msg3时刻重发PUSCH负载，然后等Msg4完成竞争解决。 这种设计的关键价值：**前一次MsgA的Preamble不浪费**，已经完成了竞争资源占用，只是PUSCH重传一次。 **（3）backoffIndicator（退避指示）** 网络拥塞时下发，指示UE在 `[0, BI]` 范围内随机退避后重传MsgA。这与4-step RACH的BI机制一致。 ### 3.3 MsgB的监听机制：MSGB-RNTI UE发送MsgA后，在`msgB-ResponseWindow`窗口内监听PDCCH，用 **MSGB-RNTI**（而非4-step的RA-RNTI）去加扰DCI。MSGB-RNTI的取值由MsgA所在RO的时频位置决定，使得多个UE可以复用同一搜索空间而各取所需。 --- ## 四、回退机制：2-step与4-step的"无缝衔接" ### 4.1 MAC层状态机视角 从MAC实体状态机看（TS 38.321 §5.1.3），2-step到4-step的回退是**同一次RA过程内部的状态迁移**，而非重新开始： ```mermaid stateDiagram-v2 [*] --> RA_Type_Selection RA_Type_Selection --> RA_Procedure_2step: RSRP≥门限 RA_Type_Selection --> RA_Procedure_4step: RSRP<门限 RA_Procedure_2step --> MsgA_Tx: 选择preamble+PO MsgA_Tx --> Wait_MsgB: 启动msgB-ResponseWindow Wait_MsgB --> SUCCESS: 收到successRAR Wait_MsgB --> FALLBACK: 收到fallbackRAR Wait_MsgB --> BACKOFF: 收到backoff / 超时 FALLBACK --> Msg3_Tx: 视MsgA preamble为Msg1
用fallbackRAR grant发Msg3 Msg3_Tx --> Wait_Msg4: 启动contentionResolutionTimer Wait_Msg4 --> SUCCESS: 收到Msg4竞争解决 BACKOFF --> MsgA_Tx: 退避后重发 SUCCESS --> [*]: RA完成 ``` ### 4.2 回退衔接的关键细节 1. **TC-RNTI的继承**：fallbackRAR中分配的TC-RNTI将作为后续Msg3/Msg4使用的临时标识，直到竞争解决后转为C-RNTI。 2. **功率爬坡不归零**：从MsgA回退到Msg3时，MsgA的功率爬坡计数（`PREAMBLE_POWER_RAMPING_COUNTER`）会继续累加，保证重传时的功率提升。 3. **Msg3重用MsgA负载**：UE在Msg3重发的PUSCH负载，与MsgA中的内容相同（除被fallbackRAR调整的资源映射外）。 --- ## 五、CBRA vs CFRA在2-step中的差异 2-step RACH同样区分为基于竞争（CBRA）和免竞争（CFRA）两种模式： | 维度 | 2-step CBRA | 2-step CFRA | |------|-------------|-------------| | Preamble来源 | UE从竞争池随机选 | gNB专用分配 | | PO资源 | 从共享PO池按规则映射 | gNB专用分配的PO | | 竞争解决 | 必须依赖successRAR中的CR Identity | 无竞争，无需解决 | | 典型场景 | 初始接入、重建、SDT | 切换、波束恢复（专用资源） | | 时延确定性 | 不确定（可能冲突） | 确定（无冲突） | **注意**：2-step CFRA仅用于**切换和波束失败恢复**这两种gNB能预先为UE分配专用MsgA资源的场景；初始接入只能用CBRA。 --- ## 六、实战连接：抓包识别与故障排查 ### 6.1 如何在抓包中识别2-step RACH 使用Wireshark/TShark分析5G NR空口抓包（基于SCF FAPI或MAC/PHY层log）时，2-step RACH的识别要点： | 观测点 | 2-step特征 | 4-step特征 | |--------|-----------|-----------| | 第一条UL消息 | 同一TTI内含PRACH Preamble **+ PUSCH** | 仅PRACH Preamble | | RNTI类型（PDCCH DCI） | **MSGB-RNTI** 加扰 | **RA-RNTI** 加扰 | | 响应窗口 | `msgB-ResponseWindow` | `ra-ResponseWindow` | | 响应内容 | successRAR（含CR Identity）/ fallbackRAR | RAR（仅TA+Grant+TC-RNTI） | | TShark过滤（MAC层） | `mac-lte.rrc_setup_req_in_msga` | `mac-lte.msg3` | **TShark实操命令**示例： ```bash tshark -r 5g_capture.pcapng -Y "mac-nr && (fapi.dl_info.type == 1)" \ -T fields -e frame.number -e mac-nr.rnti -e mac-nr.rnti_type ``` 通过RNTI类型字段可区分MSGB-RNTI（2-step响应）与RA-RNTI（4-step响应）。 ### 6.2 常见故障点与排错 | 故障现象 | 可能原因 | 排查思路 | |---------|---------|---------| | UE始终走4-step，不走2-step | `rsrp-ThresholdMsgA`配置过高；gNB未配置MsgA-PUSCH资源 | 检查SIB1中`rach-ConfigCommonTwoStepRA`是否下发 | | MsgA发不出/PO资源找不到 | RO-PO映射配置错误；DM-RS端口冲突 | 核对`msgA-PUSCH-Config`中的DM-RS图样与PO数量 | | 频繁收到fallbackRAR | MsgA PUSCH功率不足；MCS过高 | 检查`powerRampingStepMsgA`、MCS表；增大初始PUSCH功率 | | MsgB窗口超时无响应 | MSGB-RNTI计算错误；PDCCH搜索空间未配置 | 核对MSGB-RNTI与RO时频位置公式（TS 38.213 §8.2） | | 回退到Msg3后竞争解决失败 | 多UE preamble碰撞 | 统计同一RO上的preamble冲突率，扩大preamble池 | ## 七、Rel-17/18的增强演进 2-step RACH在后续版本中持续增强，体现了标准对低时延场景的持续投入： 1. **Rel-17 NTN增强**：针对卫星长时延（RTT可达数十至上百毫秒），2-step RACH减少了RTT次数，显著降低接入时延。同时引入基于星历的TA预补偿，让MsgA Preamble更准确。 2. **Rel-17/18 SDT（Small Data Transmission）**：在RRC_INACTIVE状态下，UE通过2-step RACH的MsgA直接携带小数据包（如物联网周期上报），无需进入RRC_CONNECTED，大幅降低信令开销和功耗。`RRCResumeRequest`成为MsgA的高频负载。 3. **Rel-18 多TRP随机接入**：通过多个TRP同时接收MsgA Preamble，提升覆盖和可靠性，为URLLC场景提供冗余。 4. **RedCap UE支持**：Rel-17 RedCap（轻量化UE）在带宽受限下仍可通过配置较小的MsgA PUSCH资源使用2-step，降低时延。 --- ## 八、4-step与2-step RACH对比总表 | 对比维度 | 4-step RACH (Rel-15) | 2-step RACH (Rel-16) | |---------|----------------------|----------------------| | 步骤数 | 4步（Msg1-4） | 2步（MsgA/MsgB） | | 往返次数 | 2 RTT | 1 RTT（理想情况） | | Preamble | Msg1单独发 | MsgA含Preamble+PUSCH | | 竞争解决 | Msg4（单独） | successRAR内置（或回退Msg4） | | RNTI（PDCCH） | RA-RNTI / TC-RNTI | **MSGB-RNTI** / TC-RNTI | | 适用信道 | 任意RSRP | RSRP≥`rsrp-ThresholdMsgA`（小区中心） | | 失败处理 | 退避重发Msg1 | 退避重发MsgA / fallbackRAR→Msg3 | | 时延（中心UE） | 基准 | 约降低40%-50% | | 资源开销 | 每UE最小（仅Preamble） | 每UE较大（Preamble+PUSCH） | | 典型场景 | 边缘UE、拥塞场景 | URLLC、SDT、NTN、小区中心 | --- ## 常见问题 **Q1：2-step RACH一定比4-step快吗？** A：不一定。仅当UE处于小区中心（高RSRP、信道好）且gNB能成功解码MsgA PUSCH时，2-step才体现1 RTT的时延优势。若MsgA PUSCH解码失败触发fallbackRAR，则时延反而可能略高于直接走4-step（因为多了MsgA的PUSCH开销）。这也是`rsrp-ThresholdMsgA`门限存在的根本原因。 **Q2：fallbackRAR和successRAR的物理承载有何区别？** A：两者都在MsgB PDCCH（MSGB-RNTI加扰）调度的PDSCH中承载，但MAC子PDU结构不同：successRAR内含"UE Contention Resolution Identity + TA + C-RNTI + UL Grant"完成全流程；fallbackRAR仅含"RAPID + TA + TC-RNTI + Msg3 Grant"，相当于4-step的Msg2，需要UE继续走Msg3/Msg4。 **Q3：为什么初始接入只能用CBRA，而切换可以用CFRA？** A：CFRA要求gNB预先为UE分配专用Preamble和PO资源。切换时源gNB可通过Xn接口提前向目标gNB为UE申请专用资源；而初始接入时UE尚无RRC连接，gNB无从为其预分配，只能从竞争池随机选择，因此必须用CBRA。 **Q4：MSGB-RNTI和RA-RNTI如何计算？** A：两者都基于MsgA/Msg1所在RO的时频位置（symbol index、slot index、frequency index、UL carrier）通过公式计算（详见TS 38.213 §8.2），但2-step RACH使用MSGB-RNTI以保证与4-step监听空间的区分，避免响应混淆。 **Q5：2-step RACH在卫星NTN场景有什么特殊价值？** A：NTN链路RTT极长（GEO卫星可达~540ms），4-step的2 RTT接入时延超过1秒。2-step RACH压缩为1 RTT，配合Rel-17引入的基于星历的TA预补偿，可使卫星场景的接入时延减半，对卫星物联网/应急通信意义重大。 --- ## 参考来源 1. [3GPP TS 38.321 NR MAC协议规范](https://www.3gpp.org/dynareport/38321.htm) — §5.1.3 随机接入过程（2-step/4-step MAC过程定义、回退机制） 2. [ShareTechnote - 5G RACH 2-step](https://www.sharetechnote.com/html/5G/5G_RACH_2step.html) — MsgA/MsgB结构与4-step对比的可视化讲解 3. [WirelessBrew - 2-Step RACH in Release 16 of 5G NR](https://wirelessbrew.com/5g-nr/2-step-rach-in-release-16-of-5g-nr/) — MsgB接收窗口与三种响应的工程解析 4. [CSDN - 5G NR Rel16 两步接入技术解析](https://blog.csdn.net/weixin_29197835/article/details/158162823) — MsgA到MsgB革新的中文机制剖析 5. [TechPlayon - 5GNR 2-Step RACH](https://www.techplayon.com/5gnr-2-step-rach/) — Preamble选择与MsgA PUSCH资源映射的工程实现细节 --- > 本文由「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 等场景全覆盖。