NR两步RACH竞争解决与回退机制深度解析

一、为什么需要2-step RACH？

4-step RACH（Msg1→Msg2→Msg3→Msg4）自LTE时代沿用至今，但在5G三大场景下暴露出明显短板：

• URLLC：四次握手引入的空口时延难以满足1ms级URLLC需求
• mMTC/IoT：海量设备频繁接入，四步信令风暴消耗大量PDCCH资源
• 小数据传输（SDT）：RRC_INACTIVE态设备仅传输几十字节数据，却需完整四步接入+RRC恢复流程

3GPP在Release 16（TS 38.321 V16.0.0 Section 5.1.3A）引入2-step RACH，将四步压缩为两步：MsgA（前导码+PUSCH负载）→ MsgB（RAR+竞争解决）。理想情况下接入时延减半，PDCCH开销降低50%。

但2-step RACH并非简单的"四步合并两步"——MsgA的PUSCH负载在无调度授权（Grant-free）条件下发射，gNB可能只检测到前导码而无法解码PUSCH。回退机制（Fallback） 因此成为2-step RACH最精巧也最易被误解的设计。

二、MsgA结构：前导码与PUSCH的联合发射

2.1 MsgA双部件模型

MsgA由两个物理层部件组成，在时间上连续发射：

┌──────────────────────────────────────────────────┐
│                    MsgA                          │
│  ┌─────────────┐     ┌───────────────────────┐  │
│  │ PRACH       │ Gap │ PUSCH Payload         │  │
│  │ Preamble    │     │ (RRC Request / Data)  │  │
│  │ (Msg1等效)  │     │ (Msg3等效)            │  │
│  └─────────────┘     └───────────────────────┘  │
└──────────────────────────────────────────────────┘

关键设计决策：前导码与PUSCH之间的Gap必须满足gNB处理时间要求（TS 38.213 Section 8.1A），典型值为0-2个OFDM符号。

2.2 前导码到PUSCH资源的映射

这是2-step RACH最独特的物理层设计。每个前导码索引（preamble index）通过配置参数映射到一个特定的PUSCH Occasion（PO）。

映射规则遵循TS 38.321 Section 5.1.3A：

PUSCH Occasion Index = (preamble_index) mod (N_preamble_per_PO)

其中N_preamble_per_PO由RRC参数msgA-PUSCH-PreambleGroup-Config配置，典型值为：

graph TD
    A[SSB #0] --> B[PRACH Occasion #0]
    A --> C[PRACH Occasion #1]
    B --> D[Preamble 0-27 → PO #0]
    B --> E[Preamble 28-63 → PO #1]
    C --> F[Preamble 0-27 → PO #2]
    C --> G[Preamble 28-63 → PO #3]
    D --> H[MsgA PUSCH: RB 0-11]
    E --> I[MsgA PUSCH: RB 12-23]
    F --> J[MsgA PUSCH: RB 24-35]
    G --> K[MsgA PUSCH: RB 36-47]
    style A fill:#4a90d9,color:#fff
    style D fill:#50b86c,color:#fff
    style E fill:#50b86c,color:#fff
    style H fill:#e8963e,color:#fff
    style I fill:#e8963e,color:#fff

2.3 MsgA PUSCH负载内容

MsgA PUSCH承载的负载取决于接入场景：

三、MsgB三径响应：successRAR、fallbackRAR、Backoff

3.1 MsgB MAC PDU结构

MsgB在PDCCH上以MSGB-RNTI（或RA-RNTI）加扰调度，其MAC PDU由多种subPDU组合而成。这是2-step RACH最复杂的协议设计点。

TS 38.321 Section 6.1.5定义的MsgB MAC PDU结构：

┌─────────┬──────────────┬──────────────┬─────┬──────────────┐
│ BI      │ fallbackRAR  │ fallbackRAR  │ ... │ successRAR   │
│ Subhdr  │ SubPDU #1    │ SubPDU #2    │     │ SubPDU #N   │
│(optional)│              │              │     │              │
└─────────┴──────────────┴──────────────┴─────┴──────────────┘

排列规则（严格的协议约束）： - BI subPDU（若存在）必须排在最前 - fallbackRAR subPDU排在successRAR之前 - successRAR subPDU排在最后

3.2 LCID标识与subPDU类型识别

UE通过MAC subheader中的LCID字段区分MsgB subPDU类型（TS 38.321 Table 6.2.1-1b）：

3.3 fallbackRAR内部结构

当gNB检测到前导码但无法解码MsgA PUSCH时，下发fallbackRAR：

关键设计意图：fallbackRAR的UL Grant字段直接调度Msg3传输，UE收到后无缝衔接4-step RACH的第三步，避免重新发起随机接入。

3.4 successRAR内部结构

当gNB成功解码MsgA前导码+PUSCH时，下发successRAR：

竞争解决ID匹配：successRAR中的UE Contention Resolution Identity必须与MsgA PUSCH中承载的CCCH SDU前48 bits完全匹配。这是2-step RACH竞争解决的核心验证逻辑。

四、完整信令时序图

sequenceDiagram
    participant UE
    participant gNB

    Note over UE: 1. 选择SSB（基于RSRP测量）
    Note over UE: 2. 选择PRACH Occasion + Preamble
    Note over UE: 3. 确定映射的PUSCH Occasion

    UE->>gNB: MsgA PRACH Preamble（功率PreamblePower）
    Note right of UE: Gap（N_gap个符号）
    UE->>gNB: MsgA PUSCH Payload（含RRC请求 + 40bit UE ID）

    rect rgb(240, 248, 255)
    Note over UE,gNB: MsgB Response Window（msgB-ResponseWindow）
    gNB-->>UE: 情况A：MsgB = successRAR
    Note right of UE: UE竞争解决ID匹配？
    Note right of UE: YES → 接入成功
    Note right of UE: NO → 竞争解决失败
    end

    rect rgb(255, 245, 238)
    gNB-->>UE: 情况B：MsgB = fallbackRAR（含Msg3 UL Grant）
    UE->>gNB: Msg3 PUSCH（RRC请求重传）
    gNB->>UE: Msg4（竞争解决）
    end

    rect rgb(255, 255, 230)
    gNB-->>UE: 情况C：MsgB = BI only（或无响应）
    Note right of UE: 等待backoff时间后重发MsgA
    Note right of UE: preamblePowerRampingStep递增功率
    end

五、2-step RACH状态机与定时器链

5.1 MAC层状态转换

2-step RACH的MAC层行为由TS 38.321 Section 5.1.3A定义的有限状态机驱动：

stateDiagram-v2
    [*] --> MsgA_Selection: RACH触发
    MsgA_Selection --> MsgA_Transmit: 选择preamble+PO
    MsgA_Transmit --> MsgB_Wait: 发射MsgA

    MsgB_Wait --> MsgB_Success: 收到successRAR\nn且ID匹配
    MsgB_Wait --> MsgB_Fallback: 收到fallbackRAR
    MsgB_Wait --> MsgB_Backoff: 收到BI或超时

    MsgB_Success --> [*]: 接入完成
    MsgB_Fallback --> Msg3_Transmit: 使用fallbackRAR\n中的UL Grant
    Msg3_Transmit --> Msg4_Wait: 等待Msg4
    Msg4_Wait --> [*]: Msg4竞争解决成功

    MsgB_Backoff --> MsgA_Selection: 功率爬升\n（powerRampingStep）
    MsgB_Backoff --> [*]: 达到preambleTransMax\n宣告RACH失败

5.2 关键定时器参数

六、MsgA功率控制双环机制

MsgA的两个部件采用独立的功率计算，但通过deltaPreamble参数建立耦合关系。

6.1 MsgA前导码功率

$$P_{\text{MsgA,preamble}} = \min\left{P_{\text{CMAX}},\ P_{\text{target}} + \text{PL}\right}$$

其中： - $P_{\text{target}}$ = preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER − 1) × powerRampingStep - PL = 参考信号功率 − RSRP（UE估计的下行路损）

6.2 MsgA PUSCH功率

$$P_{\text{MsgA,PUSCH}} = \min\left{P_{\text{CMAX}},\ P_{O} + 10\log_{10}(M_{RB}) + \alpha \cdot \text{PL} + \Delta_{TF}\right}$$

其中 $P_O$ = $P_{\text{MsgA,preamble}}$ + msgA-Pusch-DeltaPreamble

设计博弈：deltaPreamble为正时，PUSCH功率高于前导码，提高负载解码率但增加UE功耗；为负时节省功耗但可能增加fallback概率。运营商需要根据IoT设备电池能力和小区负载进行权衡。

七、2-step vs 4-step RACH深度对比

八、实战：抓包识别2-step RACH流程

8.1 抓包关键标识

8.2 常见故障场景与排错

场景1：反复收到fallbackRAR - 现象：UE发MsgA后持续收到fallbackRAR，无法完成2-step接入 - 根因：MsgA PUSCH功率不足或DMRS配置错误，导致gNB无法解码PUSCH - 排错：检查msgA-Pusch-DeltaPreamble是否合理，确认MsgA PUSCH DMRS参数（scrambling ID、端口映射）

场景2：MsgB超时无响应 - 现象：MsgA发射后msgB-ResponseWindow内无MsgB - 根因：gNB未检测到前导码（功率过低、SSB选择错误、PRACH资源配置不匹配） - 排错：检查前导码功率计算，确认msgA-SSB-PerRACHOccasion与SSB测量结果一致

场景3：successRAR中竞争解决ID不匹配 - 现象：收到successRAR但UE竞争解决ID不匹配，宣告竞争解决失败 - 根因：多UE在同一PRACH Occasion选择了相同前导码+PO（概率碰撞） - 排错：分析numberOfPreambles-perMsgA-PO是否配置过小（导致映射碰撞概率增大）

九、Rel-17/18/19增强演进

9.1 Rel-17关键增强

TS 38.321 V17.x引入以下增强：

• MsgA PUSCH重复：通过numRepetitionsMsgA-PUSCH配置PUSCH重复次数（1/2/4/8），提升覆盖边缘接入成功率
• SDT over 2-step RACH：RRC_INACTIVE态设备在MsgA PUSCH中直接携带上行小数据（TS 38.331 Section 6.2.2）
• MsgA PUSCH资源配置增强：支持更灵活的时频资源分配，降低资源浪费

9.2 Rel-18/19演进方向

• RedCap设备优化：简化2-step RACH配置，降低UE复杂度
• NTN（非地面网络）：2-step RACH适配卫星场景的超大RTT，MsgB Response Window扩展至数百毫秒
• AI辅助接入：基于历史接入信息预测最优preamble/PO组合

十、运营商部署策略博弈

2-step RACH的部署决策涉及多层资源与性能权衡：

graph LR
    A[2-step RACH\n部署决策] --> B[PUSCH资源预留]
    A --> C[前导码分组]
    A --> D[功率参数调优]

    B --> B1[预留资源多→\n接入成功率↑但\nPUSCH容量↓]
    B --> B2[预留资源少→\nPUSCH容量↑但\nfallback概率↑]

    C --> C1[每组前导码少→\n映射粒度细\n但碰撞概率↑]
    C --> C2[每组前导码多→\n碰撞概率↓\n但PO数量↓]

    D --> D1[deltaPreamble高→\nPUSCH解码率↑\n但UE功耗↑]
    D --> D2[deltaPreamble低→\nUE功耗↓\n但fallback↑]

    style A fill:#d94040,color:#fff
    style B1 fill:#50b86c,color:#fff
    style B2 fill:#e8963e,color:#fff
    style C1 fill:#50b86c,color:#fff
    style C2 fill:#e8963e,color:#fff
    style D1 fill:#50b86c,color:#fff
    style D2 fill:#e8963e,color:#fff

典型配置建议：

常见问题

Q1: 2-step RACH的fallback和4-step RACH的Msg3重传有什么区别？

A: fallbackRAR是gNB主动触发的回退——gNB检测到前导码但无法解码PUSCH时，通过fallbackRAR提供Msg3 UL Grant，UE利用该授权继续完成4-step流程的Msg3→Msg4。而4-step RACH的Msg3重传是Msg2（RAR）后UE发送Msg3但HARQ失败时的重传。两者触发条件不同，但都使用Msg3 PUSCH传输。

Q2: 运营商如何选择在某个小区启用2-step RACH还是4-step RACH？

A: 3GPP设计允许两种RACH类型共存。通过SIB1中的rach-ConfigCommon和msgA-Config分别配置4-step和2-step资源。UE根据rsrp-ThresholdMsgA决定：RSRP高于阈值时优先使用2-step（信道条件好，PUSCH解码率高），低于阈值时使用4-step。运营商需评估小区IoT设备比例、URLLC需求、PUSCH资源余量等因素。

Q3: MsgA PUSCH的负载大小有限制吗？

A: 有严格限制。MsgA PUSCH的TBS（Transport Block Size）由msgA-PUSCH-MCS和msgA-PUSCH-NrofRBs共同决定。典型配置下TBS为56-200 bits，刚好容纳一个RRCSetupRequest（含40-bit UE Identity）或C-RNTI MAC CE。若需传输更大负载（如SDT场景），Rel-17扩展了MsgA PUSCH的TBS范围，但仍有上限。

Q4: CFRA（无竞争随机接入）能用2-step RACH吗？

A: 可以。TS 38.321 Section 5.1.3A明确支持2-step CFRA，主要应用于切换（HO）和波束失败恢复（BFR）场景。gNB通过RRC专用信令为UE分配专用前导码和PUSCH资源，此时MsgB仅需返回successRAR（无需竞争解决ID匹配，因为前导码是专用的）。

Q5: 2-step RACH在NTN（卫星通信）场景有什么特殊处理？

A: NTN场景中RTT可达数十到数百毫秒，Rel-17/18对2-step RACH做了专项适配。msgB-ResponseWindow需要大幅扩展（远超过地面网络的10 slots上限），同时MsgA重传的功率爬升策略需要考虑超长RTT带来的反馈延迟。此外，NTN的TA（Timing Advance）预补偿机制也影响MsgA的发射定时。

参考来源

1. 3GPP TS 38.321 V19.x.x — Section 5.1.3A（2-step RA procedure）、Section 6.1.5（MsgB MAC PDU format）
2. 3GPP TS 38.213 V19.x.x — Section 8.1A（2-step RA type power control）、Section 8（PRACH资源映射）
3. 3GPP TS 38.331 V19.x.x — Section 6.2.2（RACH-ConfigCommon IE、MsgA-Config IE）
4. ShareTechnote - 5G RACH 2-step — 2-step RACH流程图解与参数说明
5. Amarisoft NR SA 2Step RACH — 2-step RACH低层日志分析与实测案例

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