无线通信，最重要的前提是建立接收端和发射端之间的时间同步。
NR中，下行链路的同步，一般在小区搜索过程通过decode PSS SSS PBCH（MIB),之后根据协议规定CORESET和 search space 去找SIB1，完成小区驻留的过程完成；这个过程可以获得小区信息，系统帧号，initial Rach参数等必要的信息，进而完成下行同步过程。 而随机接入过程的作用是完成上行同步，进而向网络端发送data 。随机接入包含CBRA 和CFRA两种方式。 为什么要区分这两种方式?下面简单说明下两者的区别。典型的'Contention Based' RACH Procedure 如下 : i) UE --> NW : RACH Preamble (RA-RNTI) msg1
ii)UE<--NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message) msg2
iii) UE --> NW : L2/L3 message(UE ID) msg3
iv) Msg4 for early contention resolution msg4
假如两个UE 具有相同的RA-RNTI 且发送了相同的preamble 给网络，之后网络端在第二步又给UE发送了相同的msg2 (T-C-RNTI 和UL grant)，两个UE会在相同的时频域资源发送msg3 ，至此对于网络端来说是一个冲突问题，两台UE用相同的资源和网络端通信显然是不能发生的，因此这时候就需要第三和四步，通过UE ID解解决这个冲突问题，确定网络端到底和哪一个UE进行进一步交流。这就是CBRA基本过程及其必要性。
对于CFRA，网络端会提前给配置UE preamble 等专用资源，这里就确保了不可能出现多台UE 拥有相同资源的情况，因而可以省去解决冲突的过程，过程也相对简单。CFRA基本过程：
i) UE<--NW:RACH Preamble (PRACH) Assignment
ii) UE-->NW : RACH Preamble (RA-RNTI)
iii)UE<--NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)
RA触发场景
在NR R16 版本中，引入了2-step随机接入（2-step RACH）
因此从NR 16开始，有两种类型的随机接入：
4-step RACH,也称为 Type-1 random access procedure
2-step RACH,也称为 Type-2 random access procedure
这两种类型的随机接入都支持：
基于竞争的随机计入CBRA
基于非竞争的随机接入CFRA- CFRA 的2 step RACH接入
下面先讲述常规的4-step RACH。
PRACH 资源的选择
UE获得随机接入所需配置后，可以发起初始随机接入流程，首先要选择Preamble资源
UE初始接入时：
选择一个满足RSRP门限要求的SSB（SSB和PRACH 对应），发起接入，如果都不满足RARP门限，则选择任意一个SSB。
如果MSG3没有发送过，则根据Group A/B配置，判定MSG3大小，选择Group A或Group B的Preamble资源；
如果MSG3重传，则选择第一次传输时所用Group 的Preamble资源
从当前SSB的Preamble Group中等概率的随机选择RA-PreambleIndex进行发送。
下面以CBRA 为例进行介绍
Msg1 - PRACH Preamble
PRACH power control
Msg1 的发送功率如上述，Msg 3的发送要用到PUSCH power control ，这里先略过
其中 PREAMBLE_RECEIVED_TARGET_POWER = preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP
如果UE没有在RA-ResponseWindow 内成功接收Msg2/在ra-ContentionResolutionTimer expiry前没有收到Msg4 /收到的Msg2的RAPID和Msg1不匹配，/Msg4携带的UE ID（或加扰的C-RNTI）和Msg3不匹配，都是失败，会再次进行RA资源选择，重新发送Msg1（Preamble）。
Msg 1 重传时 会进行功率抬升PREAMBLE_POWER_RAMPING_STEP ++
当超过 preambleTransMax 时，会向RRC 报Random Access problem RLF。
DELTA_PREAMBLE 的确定
RA-RNTI 的计算
s_id 是PRACH 的起始符号索引（0<=s_id<14）
t_id是系统帧内 PRACH occasion的起始slot 的索引（0<=t_id<80）
f_id 是PRACH 频域位置索引（0<=f_id<80）
ul_carrier_id是Msg1 发送的上行载波指示（ 0 for NUL carrier, and 1 for SUL carrier）
PRACH Occasion 的时频域资源之前的帖子有解释，这里主要集中在信令流程处理过程。
Frequency domain location (resource) for PRACH Preamble 由 RRC parameter msg1-FDM 和 msg1-FrequencyStart决定
Time domain location (resource) for PRACH Preamble由 RRC parameter prach-ConfigurationIndex 决定
Msg 2 - RAR (PDCCH/PDSCH )
1 gNB发送用RA-RNTI加扰的DCI给UE。
2 UE 尝试在RAR-window period内用RA-RNTI 检测 PDCCH (DCI) 接收RAR，DCI 1_0 。
3 Msg2 PDSCH Resource Allocation Type 是Resource Allocation Type 1
4 PDSCH Time Domain Resource Allocation 由 DCI format 1_0(RA RNTI)和PDSCH-ConfigCommon K0，SLIV 决定.
5 RAR-Window 由SIB1 中的IE rar-WindowLength 配置
6 UE 成功decode PDCCH ,就可收到PDSCH 上的RAR。
7 收到RAR后, UE会检测RAR 中的RAPID in RAR 是否与UE RAPID 一致
SIB1 中会在 initialDownlinkBWP 中配置RA-SearchSpace与CORESET 0 确定的时频域资源 用于进行RAR 的接收.
如何确定 Resource Allocation Type ?
当用DCI 1_0 调度时，则用resource allocation type 1;
当使用高级DCI 1_1时，如果RRC 层参数pdsch-Config中 resourceAllocation 设置为dynamicswtich,这由收到的DCI 中的Frequency domain resource assignment 决定用resource allocation type 0 还是type 1；其他情况就参照resourceAllocation 中的设置，采用对应的type。
Tips:pdsch-Config（BWP级别配置）中 配置resourceAllocation，多出现在RRC Setup和RRCReconfiguration；在idle->connected 的RACH 情况，SIB1 配置小区级参数PDSCH-ConfigCommon，并不会配置resourceAllocation，一般使用DCI 1_0 调度，所以应用黄色字体部分 用resource allocation type 1；具体resource allocation type 0/1 代表什么意思 后面介绍PDSCH时再阐述。
UE发送MSG1后，开始ra-ResponseWindow窗口，在窗口内检测RAR的调度
RAR包含三种MAC subPDU:
a MAC subheader with Backoff Indicator only;
a MAC subheader with RAPID only(i.e. acknowledement for SI request);
a MAC subheader with RAPID and MAC RAR.
Backoff indicator
RA fail且RAR 中带有BI ,但RA 过程还没有结束时，会进行BI 的设置，从[0,preamble_backoff] 均匀分布中 选取一值，作为BI，
如果 在backoff 期间 UE根据提供的Dedicated Preamble CFRA 条件满足，比如相关的Dedicated Preamble的SSB波束满足RSRP门限，忽略BI 直接进行RA资源选择。
否则 等BI 超时后再进行下一次RA 过程
MAC payload for Random Access Response
RAR 最重要的参数就是TA UL Grant 及TC-RNTI
上面TPC command主要涉及到Msg3 的PUSCH 功控 ，之后再介绍
收到RAR 后 需不需要发送HARQ ACK.NACK?
根据协议收到RAR 后不需要发送HARQ ACK/NACK
实际中，如果UE 没有再次发送PRACH ，则gNB认为UE 收到了RAR;否则，UE 会再次发送PRACH.
Step (3) and (D) : Msg3 (PUSCH)
GroupA GroupB 的选择：
1 Msg3 没有传输时，
有配置Group B：
Msg3 size 大于ra-Msg3SizeGroupA 时，就选择GroupB发送 ，否则选Group A。
没有配置GroupB 就选择GroupA发送
2 如果Msg3 是重传，这选择第一次发送Msg3的group。
1 UE 决定是否对Msg3 应用transform precoding 根据RRC 参数msg3-transformPrecoder
2 之后UE在PUSCH 上发送 Msg3 携带UE ID
NR中，如果UE处于RRC IDLE状态，UE标识是ng-5G-S-TMSI-part1或随机数（39位），如果UE处于RRC INACTIVE状态，UE标识是resume Identity（24位或40位）
协议中规定，UE 收到RAR后 根据UL grant 发送PUSCH data时，应该使用RV 0。
Msg3 PUSCH 重传（有的话），要用TC-RNTI 加扰DCI 0_0 发送。
在收到RAR 至发送PUSCH 之间的时隙间隔 为n+k2+
RAR 与之后RAR UL grant 的PUSCH传输的符号间隔 为
Step (4) and (E) : Msg4 - Contention Resolution (PDCCH/PDSCH)
发送完Msg3后：
1 开启ra-ContentionResolutionTimer
2 监听TC-RNTI 加扰的DCI
如果对应DCI 成功decode，之后解析出MAC CE，基站在MSG4通过UE Contention Resolution Identity MAC CE（48位）携带UE标识（如果长度超过48位，只取前48位），如果MSG4和MSG3携带的UE标识相同，UE认为竞争解决，随机接入成功。并将TC-RNTI 升级为C-RNTI。
......
Step (5) and (F) : HARQ ACK for Msg4
一旦成功解析Msg4，UE要在PDSCH 上发送对应的HARQ ACK。
PDSCH 的最后一个符号与HARQ-ACK的第一个PUCCH 符号的间隔为
在LTE 时，UE发送MSG1 后，在随机接入响应窗口 RA-ResponseWindow范围内没有收到RAR，UE需要重发MSG1，重发时，要进行功率攀升（Ramping）
38.321 5.1.2 RA 资源选择章节中 并没有找到针对CBRA Msg1失败后应该怎么做的描述；从5.1.3 章节中有看到一句如下描述，应该是在重传Msg1时，可能会重新选择SSB，当继续使用之前的SSB 时，需要进行功率攀升
如果切换了SSB ，则就不需要进行功率攀升
