随机接入流程 - 2-Step RA
Overview
在LTE和R15 NR中，终端以及基站采用的接入技术均为四步随机接入(4-Step Random Access)技术，即终端和基站之间需要经过5次信息交互(这里我们所说是的基于竞争的随机接入过程，对于非竞争随机接入过程只需要3次信息交互)才能完成随机接入过程，如下：
- 终端向基站发送Msg1，即前导序列(preamble)，基站根据所收到的preamble来判断对应终端的上行传输需要提前多少时间；
- 基站如果允许终端接入，则向终端发送Msg2，即随机接入响应消息(RAR)，该消息主要包含了上行时间提前量指示(Timing advance)，对于第一条上行传输消息Msg3的上行授权(UL grant)，前导序列标识(RAPID)，临时C-RNTI(T-CRNTI);
- 终端使用Msg2中上行授权提供的上行时频域资源信息，向基站发送Msg3消息，即RRCSetupRequest消息，该消息的MAC CE(MAC control elemtent)中包含了长度为48个bits的竞争解决ID。
- 基站接收到多个终端发送的Msg3消息，从中选择一个终端向其发送Msg4消息，即RRCSetup消息，其中包含了该终端在Msg3中包含的竞争解决ID。
- 各终端接收Msg4消息，并检查其中的竞争解决ID是否与自己Msg3中发送的竞争解决ID相同，如相同则认为竞争成功，发送Msg5， 即RRCSetupComplete消息，随机接入过程完成；否则认为竞争失败，重新发起随机接入里程。
从以上步骤可以看出，当前的4-step随机接入流程引入了相当大的时延开销。为了降低随机接入过程中的时延开销(主要是控制面)，NR R16版本引入了2-step随机接入流程技术。顾名思义，这一新的随机接入技术只有2步流程：
- 第一步，设计上行MSGA传输消息，该消息包含了4-step RACH中的Msg1和Msg3消息。
- 第二步，设计下行MSGB传输消息，该消息包含了RAR消息，用于竞争解决。基站在接收到MSGA消息之后发送MSGB消息给终端。
从上图可以看出，竞争解决过程被放在了第二步骤之中。因此，2-step RACH技术简化了随机接入过程，提升了系统传输效率，它不仅能在终端接入基站建立RRC连接时降低时延开销，也能降低终端在RRC Connection resume过程的时延开销以及降低终端在毫米波场景中进行beam failure recovery流程的实验开销。
除了基于竞争的随机接入(CBRA)， 2-step RACH同样支持非竞争的随机接入(CFRA)，需要注意的是，2-step RACH的CFRA模式只能用于切换流程。
在3GPP R16版本引入2-step RACH以后，允许终端可以仅配置4-step RACH或者2-step RACH，同时也支持两种随机接入方式同时配置。由于终端同时配置了4-step和2-step RACH类型，终端就需要有一种机制可以判断接入时使用哪种RACH类型，具体如下：
- 当没有为终端配置非竞争随机接入资源时，终端使用RSRP阈值来判断使用4-step还是2-step RA：
- 当基站给终端配置了4-step RACH对应的非竞争随机接入(CFRA)资源，则终端使用4-step RACH进行随机接入；
- 当基站给终端配置了2-step RACH对应的非竞争接入资源，则终端使用2-step RACH进行随机接入。
N.B.
- 对于非竞争接入过程(CFRA)，基站不能在同一时间为一个终端在同一个BWP内既配置有4-step CFRA RACH资源，又配置2-step CFRA RACH资源。
- 在R16版本中，2-step RACH的非竞争接入过程只能用于切换过程。
MSGA - MSGA的传输设计与资源配置
我们前面说过，MsgA中包含了4-step RACH中的Msg1和Msg3，即preamble资源和传输Msg3所需的PUSCH资源，其中preamble资源使用RACH Occasion承载。根据是否给终端同时配置了2-step RACH和4-step RACH的场景，MSGA中的RO资源的分配也分为两类：
- 基站仅给终端配置了2-step RACH资源：在这种场景中，基站使用2-step RACH专有的信令msgA-SSB-PerRACH-OccasionAndCB-PreamblesPerSSB为终端配置RACH occasion资源。配置方式与4-step RACH类似，即N个SSB关联到一个RACH occasion上，同时每个有效RACH occasion上的每个SSB又关联R个基于竞争的preambles(这样做的原因我们已经在博文‘随机接入流程 - 4 Step RA’中解释过了，这里不再做更多说明)。
- 基站同时给终端配置了2-step RACH过程和4-step RACH过程，在这种场景下，2-step RACH过程通过信令参数msgA-CB-PreamblesPerSSB-perSharedRO和4-step RACH过程共享Rach occasion的配置参数(当然也可以分开配置，分开配置就相当于独立配置2-step RACH资源，即第一类)。也就是说2-step RACH可以和4-step RACH共享Rach occasion，但是在相同的Rach occasion中使用不同的preamble。4-step RACH中哪些Rach occasion可以和2-step RACH共享通过信令参数msgA-SSB-SharedRO-MaskIndex指定:
下面我们再看看MsgA中的PRACH资源和PUSCH资源的设计和选择。在4-step RACH中，终端首先确定是使用groupA还是GroupB发送preamble，基站接收到终端发送的preamble之后根据接收到的preamble测算出上行的TA值，也就是上行传输的时间提前量，然后在Msg2(RAR)消息中将TA值和一个UL grant信息发送给终端，终端根据收到的UL grant确定Msg3消息的时频域资源，再根据TA值确定需要提前发送的时间量，这样就可以把第一条上行消息Msg3发送出去。而在2-step RACH中，终端在第一步中，在不等待Msg2消息的情况下，就需要把Msg3紧随preamble之后发送出去，这样终端就需要提前知道Msg3对应的PUSCH资源的配置信息。很显然，这种基于竞争的2-step RACH过程的相关资源配置信息必然是以信令的方式存在，而且是必然存在于SIB1消息之中。对于非竞争的2-step RACH过程，相关资源配置信息则是存在于重配置消息中的切换相关的信令中，下面我们分开叙述。
基于竞争的随机接入流程
在基于竞争的2-step RACH中，指示MsgA上行传输资源对应的信令为msgA-PUSCH-Config-r16，在信令中的位置如下：
msgA-PUSCH-ResourceGroupA-r16/msgA-PUSCH-ResourceGroupB-r16：这两个参数分别定义了两组MsgA中的PRACH资源和PUSCH资源，其中msgA-PUSCH-ResourceGroupB-r16必须是配置了信令groupB-ConfiguredTwoStepRA-r16后才能配置，如果没有配置该信令，则默认使用group A定义的资源传输MsgA消息。在传输MsgA中的preamble和PUSCH时，具体使用哪一组资源取决于以下条件：
则终端选择GroupB中给出的PRACH资源和PUSCH资源信息发起MsgA中的preamble传输和PUSCH传输；同时由重建流程或者on-demand SI Request流程发起的随机接入流程，终端也选择GroupB中给出的PRACH资源和PUSCH资源信息发起MsgA中的preamble传输和PUSCH传输。
以上场景之外的2-step随机接入使用msgA-PUSCH-ResourceGroupA-r16中给出的PRACH资源和PUSCH资源信息发起MsgA中的preamble传输和PUSCH传输。
非竞争的随机接入过程
在非竞争的2-step RACH中，指示MsgA上行传输资源对应的信令为msgA-CFRA-PUSCH-r16，在信令中的位置如下：
与基于竞争的2-step RA过程一样，如果在信令中配置了信令groupB-ConfiguredTwoStepRA-r16以及信令msgA-PUSCH-ResourceGroupB-r16，则终端需要按照如下条件选择groupA或者groupB中的preamble进行传输：
如果MsgA的payload长度等于信令参数ra-MsgA-SizeGroupA所给出的数值，终端选择GroupB中的preamble来发送；否则，终端选择GroupA中的preamble来发送。
需要注意的是，对于非竞争的2-step RACH过程，无论终端选择GroupA还是GroupB中的preamble来传输，MsgA中PUSCH都只配置了一组。与基于竞争的2-step RACH一样，非竞争2-step RACH也使用信令 msgA-PUSCH-ResourceGroupA-r16来表示具体资源配置信息。
--------------------------------------------------------------------------------------------------------------------------------
下面我们再看看MsgA中的PUSCH资源的配置信息。首先3GPP规定了MsgA中的PUSCH资源在时域上必须放置在PRACH资源后面，PUSCH资源时域上的第一个OFDM符号与PRACH资源所在最后一个OFDM符号至少要持续N个OFDM符号的长度。N的长度与子载波间距有关，具体如下：
而MsgA中PUSCH资源所在slot的第一个OFDM符号与一个PRACH slot在时域上的第一个符号的相对位置由信令参数msgA-PUSCH-TimeDomainOffset给出，用slot的个数表示：
知道了MsgA中的PUSCH在时域上起始slot的位置，下一步我们就需要知道它在该slot内的起始符号位置以及持续时长，这些信息是由信令参数startSymbolAndLengthMsgA-PO 或者 msgA-PUSCH-timeDomainAllocation提供的：
需要注意的是，这两个信令参数不能同时配置给终端，只能二者选其一。
为了能正确解码终端在MsgA中发送的PUSCH传输，基站除了需要告诉终端PUSCH资源的时频域信息，还需要告诉终端PUSCH资源对应的相干解调信号(DM-RS)的配置信息(用于基站解调PUSCH传输)，PUSCH传输对应的MCS数值等等，具体信息都在信令MsgA-PUSCH-Resource-r16中给出：
在上面的表格中我们提到了Guard period(由信令参数guardPeriodMsgA-PUSCH 定义)，也就是说如果一个PUSCH slot中存在多个连续的PUSCH occasion，那么在每个相邻的PUSCH occasion之间就需要一个guard period来把它们分隔开。这样做的原因是为了防止符号间干扰(Inter-symbol Interference)，我们举一个例子来说明：
我们前面提到过，在4-step RA中，终端在接收到Msg2，也就是RAR消息后，得到其中的上行时间提前量(Timing Advance)，再根据基站给出的时间提前量来发送第一条上行消息，即Msg3。这样，对于处于不同地理位置的终端，他们的Msg3到达基站的时间也都是一致的，不会造成干扰。而在2-step RA中，由于MsgA中的PUSCH是跟随着preamble发送出去的，这个时候没有办法获取到基站的时间提前量指示，因此对于处于不同地理位置的终端，它们的TA都是0，这就会造成不同终端发送的MsgA PUSCH到达基站的时间是不同的。以上图为例，终端2的MsgA PUSCH到达基站后，其最后一个OFDM符号在时间上超出基站下一个符号的CP长度，与基站的下一个OFDM符号产生了重叠现象，这个时候无法通过CP进行规避，就发生了符号间干扰。解决方法就是在MsgA PUSCH occcasion的最后一个OFDM符号后面添加长度为1~3个OFDM符号的保护间隔(Guard period)，如下图所示：
为了防止终端之间的相互干扰，3GPP又做了如下规定：一个PUSCH occasion只有当其在时频域上不与任何一个其他的PRACH occasion(4-step RACH或者2-step RACH)相重叠，这个PUSCHoccasion才被认作为是有效的。
MsgA中PUSCH携带的是Msg3消息，其消息内容与4-step RACH中的msg3类似，大致如下：
1. 对于终端在RRC_CONNECTED状态发起的随机接入(比如上行失步后PDCCH order触发的RA)的场景，终端会在Msg3中携带C-RNTI MAC CE，然后基于RA流程的触发场景，Msg3中会携带不同的信令消息，比如切换流程中触发的非竞争随机接入，Msg3携带的是重配完成消息。
2. 对于终端初始接入小区的场景，终端会在Msg3中发送RRC连接(RRCSetupRequest)/恢复(RRCResumeRequest)/重建请求(RRCReestablishmentRequest)消息等。
当终端传输了MsgA消息之后，接下来就要监听MsgB消息，MsgB消息对应的PDCCH由MsgB-RNTI加扰。也就是说，终端需要监听使用RNTI为MsgB-RNTI加扰的DCI format 1_0来达到正确接收并解码MsgB消息的目的。MsgB-RNTI的计算方法如下：
MSGB - MSGB的传输设计与资源配置
与4-step RACH一样，为了监听MsgB消息(RAR消息)，终端需要在一个窗口期内监听来自基站的使用MsgB-RNTI加扰的DCI format 1_0，只要在整个窗口期内，终端都会持续监测MsgB消息对应的这个DCI format 1_0，一旦检测到之后，终端就可以从DCI format 1_0中获取到MsgB的时频域位置以及其他信息，从而可以继续去指定的时频域位置按照指定的信息(e.g., MCS, PRB个数等)去接收及解码MsgB消息。
这个窗口的长度(长度单位为slot)由信令msgB-ResponseWindow-r16给出：
该窗口的起始位置从终端用于接收RAR的PDCCH所在的COREST的第一个OFDM符号开始计算，从该时刻起，终端按照如下流程判断并接收MsgB消息：
终端接收到MsgB的结果以及后续行为分为以下几个场景：
终端成功接收并解码MsgB
1. 终端接收到的RAR使用C-RNTI加扰
这种情况是由于终端可能已经处于RRC_CONNECTED状态并在MsgA PUSCH传输中上报了C-RNTI信息(比如上行失步触发的随机接入等)，基站在发送MsgB时，会使用该终端的C-RNTI加扰MsgB的PDCCH，终端在MsgB-ResponseWindow中检测到使用自己发送MsgA PUSCH的C-RNTI加扰的PDCCH并成功解码对应的RAR消息，则随机接入成功。
2. 终端接收到的RAR使用MsgB-RNTI加扰
- 基站没有成功解码MsgA中的PUSCH传输
基站在接收终端发送的MsgA消息时，可能只成功接收了preamble，而对于随后的PUSCH传输可能由于各个终端之间资源的冲突(只是可能的原因之一)造成PUSCH接收失败。在这种场景下基站仍然会发送MsgB消息，MsgB携带的内容是fallbackRAR： 
从上图可见fallback RAR的格式以及内容与4-step RACH中的RAR是一样的。终端在监听并接收到MsgB消息后，首先确认fallbackRAR MAC subheader中的RAPID是否与自己在MsgA中传输的Preamble索引相同；如果不同，则终端判断该消息不属于自己并丢弃该MsgB消息，继续在MsgB
-ResponseWindow窗口内继续监听MsgB消息；如果相同并且RAR内容为fallbackRAR，则终端认为成功接收MsgB并确认MsgA中的PUSCH传输失败，此时终端从2-step RACH流程切换到4-step RACH流程，步骤如下：
a. 使用fallbackRAR中的Timing Advance Command与基站进行上行同步；
b. 使用fallbackRAR中的UL Grant发起Msg3消息，同时将fallbackRAR中的Temporary C-RNTI作为C-RNTI MAC CE，请求建立RRC连接。
c. 从step b开始按照4-step RACH流程完成当前的随机接入流程。
需要注意的是，如果终端发起的是非竞争的2-step RACH流程，那么即使终端接收到的MsgB消息包含的是fallbackRAR内容，终端也会认为随机接入流程成功并结束随机接入流程。
- 基站成功解码MsgA中的PUSCH传输
基站成功接收了终端发送的MsgA中的preamble和PUSCH传输，在这种场景下，基站向终端发送的MsgB消息所包含的内容为：
终端在MsgB-ResponseWindow中监听到MsgB消息，确认为successRAR之后，将其中的UE Contention Resolution Identity数值与自己在MsgA PUSCH中发送的UE Contention Resolution Identity数值相比较，如果不同，则终端认为竞争失败，重新发起MsgA消息；如果相同，则终端认为自己竞争接入成功，并进行以下操作：
a. 使用successRAR中的Timing Advance Command与基站进行上行同步;
b. 使用successRAR中PUCCH resource Indicator指示的资源在HARQ Feedback Timing Indicator指示的时刻点回复MsgB的HARQ-ACK反馈，该PUCCH传输对应的功率使用TPC指示的功率调整量。
c. 2-step RACH过程结束。
终端没有成功接收到MsgB
当基站没有接收到终端发送的MsgA消息时，基站不会发送对应的MsgB消息给终端，终端自然就无法接收到MsgB消息。此时终端会持续监听MsgB消息直到msgB-ResponseWindow超时，并按照如下流程继续随机接入流程：
其中，
PREAMBLE_TRANSMISSION_COUNTER - 初始值为0，每发送一次preamble数值加1；
preambleTransMax：由以下信令给出：
msgA-TransMax:由以下信令给出： 