根据 38.321， NR RACH 过程与 LTE RACH 过程非常相似。
具体参数会有很小的差别，但总体流程几乎相同。实际上， LTE RACH、LTE BL/CE(M1) RACH、LTE NB RACH和 NR RACH的整体流程几乎相同，尽管参数上存在很小的差别。
按照以下顺序，按照步骤标记为(A)~(J)，将步骤标记为(1)~(9)。
步骤(A)～(J)是gNB和UE发送的具体消息。
步骤(1)～(9)是UE和gNB中发送或接收消息所需的内部过程。
步骤 (A) 和 (1)：系统信息（用于初始附着）或 RRC 连接重新配置（用于 LTE 交互）
完成这两个步骤后，UE应该能够获得如下所有信息（基于38.213-8随机接入过程）
根序列表的索引
循环移位(Ncs)
集类型（无限制、限制集 A 或限制集 B）
步骤 (B) ：Msg1 - PRACH 前导码
在此步骤，如果满足PRACH传输的所有条件，则UE发送具有RA-RNTI的PRACH前导码。
步骤(2)和(C) ：消息2 -RAR (PDCCH/PDSCH)
在这一步（即在PRACH传输之后），将发生以下过程（基于38.213-8.2随机接入响应）
gNB发送使用如上计算的RA-RNTI值加扰的DCI。
UE尝试在RAR-Window周期内检测具有相应RA-RNTI的PDCCH（DCI）。（在ra-ResponseWindow内，UE在搜索空间中寻找DCI：类型1PDCCH公共搜索空间）
用于调度RARPDSCH的DCI格式是具有RARNTI的DCI格式1_0。
Msg2 PDSCH的资源分配类型将是资源分配类型1。
PDSCH的频域资源分配由具有RARNTI的DCI格式1_0指定。
PDSCH的时域资源分配由具有RARNTI和PDSCH-ConfigCommon的DCI格式1_0指定。
RAR-Window由SIB消息中的rar-WindowLengthIE配置。
如果UE成功解码PDCCH，则其解码承载RAR数据的PDSCH。
在解码RAR之后，UE检查RAR中的RAPID是否与分配给UE的RAPID匹配。
该PDCCH和PDSCH应该以与SIB1相同的子载波间隔和循环前缀来承载。
以下是携带RAR（随机接入响应）的MAC PDU的数据结构。“Msg3 PUSCH时域资源分配”将引用RrcReconfiguration（在NSA的情况下）或SIB1（在SA的情况下）中的pusch-ConfigCommon->pusch-TimeDomainAllocationList。如果没有配置该IE，则参考PUSCH默认资源分配表。
UE是否必须发送HARQACK/NACK来响应RAR接收？否。如果使用RA-RNTI查看DCI1_0，则没有有关PUCCH或K1值的信息。
那么gNB如何知道RAR是否被UE正确接收/解码？根据38.213-8.2，如果UE不再发送PRACH，则gNB可以断定UE正确接收/解码了RAR。
步骤(3)和(D)：Msg3(PUSCH)
在这一步（即发送Msg3之前），将发生以下事情（基于38.213-8.3Msg3PUSCH）
UE应根据称为msg3-tp(msg3-transformPrecoding)的RRC参数确定是否对Msg3PUSCH应用变换预编码。
UE应根据称为msg3-scs（子载波间隔）的RRC参数确定Msg3PUSCH的子载波间隔。
UE应在发送PRACH的同一服务小区上发送Msg3PUSCH。
举例：
下面是一个示例，展示了在实际协议栈中如何确定RAR和msg3PUSCH之间的延迟。这是SA初始附加过程。
步骤(4)和(E)：Msg4-竞争解决(PDCCH/PDSCH)
在这一步（即发送Msg3之后），将发生以下事情（基于38.321-5.1.5）。
启动ra-ContentionResolutionTimer
监视以TC-RNTI解码PDCCH（当ra-ContentionResolutionTimer运行时，UE在搜索空间中查找DCI：类型1PDCCH公共搜索空间）
如果PDCCH解码成功
解码携带MACCE的PDSCH
设置C-RNTI=TC-RNTI
丢弃ra-ContentionResolutionTimer
此随机访问过程完成
步骤(5)和(F)：Msg4的HARQ ACK
一旦UE成功解码Msg4（竞争解决），UE就发送数据的HARQACK（携带Msg4的PDSCH）
发表于 2025-10-20 16:02:48
