随机接入流程 - 4 Step RA
Overview
随机接入流程可以由以下事件触发：
- 终端从RRC_IDLE状态发起接入；
- RRC连接重建流程；
- 终端在RRC_CONNECTED状态时有上下行数据业务，但是此时上行同步状态为失步，此时由基站的PDCCH order发起；
- Scheduling Request无响应并超过最大发送次数，此时终端使用随机接入流程来获取UL grant；
- 在同步重配置(比如handover)时由RRC发起接入请求；
-
在添加SCell (CA场景)或者SN (NSA尝尽)的时候建立时间同步；
-
请求除了MIB和SIB1之外的其他系统消息；
-
Beam failure recovery。
其中最常见的随机接入场景就是终端在开机后进行小区搜索并在搜索到合适的小区后使用随机接入来接入该小区。
在NR中支持两种随机接入方式：4-step RA和2-step RA，其中2-step RA是R16中新引入的，我们会在下一篇博文详细介绍。
NR中的两种随机接入方式都支持基于竞争的随机接入流程 (Contetion-based RA)和非竞争的随机接入流程 (Contention-free RA)，流程图如下：
处于RRC_IDLE状态的终端一旦发现一个小区就可能会发起随机接入流程接入该小区，该随机接入流程分作四步：
- Msg1：终端按照RRC信令的指示(e.g., SIB1)选择合适的preamble并发送；
- Msg2：基站接收到终端发送的preamble后发送随机接入响应，也就是RAR (Random Access Response)，基站基于所接收到的preamble的时间，在RAR中发送timing advance指令来完成终端的上行同步；
- Msg3：终端发送RRC连接建立请求消息 (RRCSetupRequest)给基站，消息中携带竞争解决ID；
- Msg4：基站发送RRC连接建立成功消息 (RRCSsetup)给终端，其中携带发送Msg3消息的终端的竞争解决ID，所有接收到Msg4消息的终端将消息中的竞争解决ID与自己发送Msg3消息中的竞争解决ID相对比，如果相同则认为竞争解决，随机接入流程成功；反之则竞争失败，终端重新发起随机接入流程。
以上是基于竞争的随机接入的流程，对于非竞争的随机接入，则省去了竞争解决这一步，具体请看上图中的图(c)。
需要注意的是，我们将4-step中每一步的交互消息分别称之为Msg1~Msg4，按照随机接入触发场景的不同，除了Msg1是用于传输preamble不变，Msg2/3/4所对应的消息是可能与用于小区接入的随机接入流程中的Msg2/3/4有所不同的。比如在重建流程中，Msg2为RAR，而Msg3为“RRCReestablishmentRequest”消息，Msg4为“RRCReestablishment”消息。
下面我们来详细介绍每一步流程 (这里我们以小区接入场景中的随机接入流程作为示例)。
Msg1 - 随机接入资源的选择与发送
由于终端是从RRC_IDLE状态接入小区并且使用的是基于竞争的随机接入过程， 此时终端所需要的随机接入资源指示只能从小区的系统广播消息 - SIB1中获取，主要参数包括preamble索引，preamble的SCS，preamble的发射功率以及PRACH资源在时频域上的位置等。具体描述请看下表 (这里我只列出了主要参数，一些涉及到新功能的参数(比如IAB)没有列出，此类参数会在对应新功能的博文中给出)：
CBRA (基于竞争的随机接入)：
对于非竞争的随机接入，主要用于重新取得上行同步 (比如由于上行失步使用PDCCH order发起的RA)或者切换过程中与target cell取得上行同步，此时终端早已与基站建立了RRC连接，因此不存在建立RRC连接，只要获取到基站发送的RAR消息之后，使用其中的Timing advance命令进行上行同步后，随机接入流程也就结束了，相关参数主要是在信令RRCReconfiguration中的信令参数Rach-ConfigDedicated给出：
CFRA (非竞争的随机接入)：
下面我们会对以上表格中的关键参数做详细解释。
大家可能首先就会注意到'ssb-perRACH-OccasionAndCB-PreamblesPerSSB'这个参数，正如以上表格所做的解释：这个参数表明了每个RACH occasion对应的SSB个数以及每个SSB对应的基于竞争的preamble的个数。
说到这里，大家肯定很疑惑，为什么要把SSB和PRACH occasion放在一起考虑？在LTE里面，UE读取到相关小区的PSS，SSS，MIB之后，直接按照SIB的配置来发起随机接入就行了，到了NR为什么SSB提供了PSS，SSS和MIB之后还需要把它和PRACH occasion一起做随机接入资源选择呢？要知道这个原因，我们需要从5G NR的Beam management说起，如果大家看过之前的博文'波束管理（Beam Management）',我们在里面提到过beam sweeping的概念，什么意思呢？因为5G NR都是高频空口资源，路损大，抗干扰性弱，因此5G NR采用的是beamforming的massive MIMO传输方式，也就是说NR中基站传输的空口信息都是带有方向性的，在一定方向上是一束窄波。这样又带来一个问题，既然是在某一个方向上的窄波，那么5G NR基站如何能做到像LTE基站一样具有覆盖一定范围的稳定信号(比如120度的扇形区域)。5G NR引入了天线阵列的概念，也就是说可以使用天线阵列形成多个beamforming从而达到覆盖指定区域的目的，既然有多个beam，那么终端就要找到一个最适合自己的beam(即上下行信号质量最好的beam)来做随机接入。为了区别每一个beam，NR基站可以在每个波束上配置不同的SSB(这里牵涉到小区搜索终端用户的算法过程，不再展开讨论)，这些SSB具有不同的索引，对应的PRACH occasion也是不同的。 很显然，当UE搜索到一个适合自己的beam后，读取该beam上的SSB(包含PSS，SSS，MIB)后，通过SSB所在的时频域位置就可以知道该SSB的索引(请参考博文‘小区同步流程’)，通过该SSB的索引就可以知道对应的PRACH occasion索引(因为PRACH occasion是时频域相关的，因此对于不同的beam，对应的PRACH occasion是不可能相同的)，从而在该索引对应的PRACH occasion（也就是在通过SSB索引选定的beam）上发起随机接入流程。
现在我们知道了在NR中为什么要把SSB和PRACH occasion关联在一起的原因了。
下一个问题就是：'ssb-perRACH-OccasionAndCB-PreamblesPerSSB'这个信令参数只给出了每个SSB相关联的RACH occasion的个数和每个SSB相关联的preamble个数，终端是如何知道在5ms周期内的每个SSB上对应的RACH occasion的具体时频域位置以及可以使用的preamble索引呢？
首先，终端必须知道基站有多少个SSB在周期性发送。终端通过系统消息SIB1中的信令参数'ssb-PositionsInburst'来知晓基站有多少个周期性发送的SSB：
下一步，终端需要知道每个SSB是如何关联到PRACH occasion和preamble上的。在这方面，3GPP做了如下硬性规定：
- 首先，在一个PRACH occasion中，SSB索引按照preamble index的升序进行映射；
- 其次，在频域上，SSB索引按照升序映射到频分复用的PRACH occasion上；
- 再其次，SSB索引在时域上映射到一个PRACH slot上的时分复用的PRACH occasion上；
- 最后，SSB索引在下一个有效PRACH slot上重复步骤1~3。
在这里，我们必须把CBRA (基于竞争的随机接入)和CFRA (非竞争的随机接入)分开来进行详细介绍，因为这两种场景对于PRACH资源的选择方式是不同的。
基于竞争的随机接入过程中的RA资源选择
从参数‘ssb-perRACH-OccasionAndCB-PreamblesPerSSB’我们知道了每个SSB可以关联多少个PRACH occasion和多少个preambles。这里需要注意的是，对于一个特定的SSB，它所对应的PRACH occasion必须有效才有意义，有效是什么意思呢：
- 对于FDD，或者在补充上行 (SUL)上发送的PRACH occasion，所有的PRACH occasion均为有效；
- 对于TDD，对于一个SSB而言，时域上在这个SSB最后一个OFDM符号后至少
(该变量取值请参考下表， N.B.,对于preamble format B4，该变量数值为0)个OFDM符号后出现的PRACH occasion均为有效PRACH occasion；
那么现在问题就清楚了，对于N个SSB关联一个PRACH occasion的场景，无论
还是N < 1，每个SSB都是从自己的最后一个OFDM符号之后的个符号开始匹配第一个PRACH occasion。如果，那么就意味着多个SSB关联到同一个PRACH occasion，而这个PRACH occasion在时域上的位置必然是晚于所有这些SSB，并且距离时域上最晚的一个SSB至少个OFDM符号；如果N < 1，这意味着一个SSB关联到多个PRACH occasion上，也就是说从该SSB最后一个 OFDM符号之后的个符号开始连续1/N个PRACH occasons都关联到该SSB，以下是一个简单的示意图 (假设不存在频分复用的RO，每个RO都是在时域上连续分布)：
通过阅读博文‘小区同步流程’，我们知道在NR中，在SSB的5ms周期内，按照子载波间距的不同和所处频段的不同，一个小区最大可以发送的SSB个数可以为4，8，64。结合我们以上提到的场景，如果对RO在时域上不做额外的定义，仅仅按照PRACH的配置周期(PRACH Confiuration Period)去关联SSB和RO，就有可能出现以下两种情况：1. 无法保证每个SSB都可以关联到至少一个有效的RO；2. 每个SSB关联到至少一个有效的RO后，还有剩余的RO没有可关联的SSB。
为了解决我们提到的这两种情况，3GPP又提出了association period这一概念，一个association period是PRACH配置周期的倍数，具体见下表：
N.B. PRACH configuration Period指的是38.211 Table 6.3.3.2-3/4中第三列所指示‘x’，见上图。
一个association period从系统帧0开始，其持续时长如Table8.1-1所示为PRACH配置周期的整数倍 ，最大为160ms。对于PRACH配置周期为10ms，20ms，40ms和80ms的场景，一个association period可以配置为对应PRACH配置周期的N倍(请参考以上Table 8.1-1)。此时N具体取哪个整数值由以下条件确定：对于某个特定的PRACH配置周期，如果其对应的association period可以取多个数值，则取其中满足可以使得每个SSB至少可以映射到一个PRACH occasion这一条件的最小的一个。
需要注意的是，在一个association period之后，如果仍然存在没有关联到SSB的PRACH occasion(s)，那么这个(些)PRACH occasion(s)不能用于随机接入流程。
下面我们再说一下preamble的选择。preamble的选择过程和LTE中preamble的选择过程非常相似。在NR中，每个小区最多支持64个preamble，这64个preamble被分为三个部分，如下图所示：
在配置信令时，基站可以设置信令参数：numberOfRA-PreamblesGroupA，来确定group A中的preamble个数。终端根据待发送的Msg3消息的大小(ra-Msg3SizeGroupA)和路损大小 (messagePowerOffsetGroupB)来确定使用group A还是group B中的preamble来发起随机接入:
当终端待发送的Msg3的长度大于信令参数ra-Msg3SizeGroupA指定的数值；并且，
pathloss < 当前小区随机接入的最大发射功率PCMAX - preambleReceivedTargetPower - msg3-DeltaPreamble – messagePowerOffsetGroupB;
其中，
PCMAX = min {终端最大发射功率，preambleReceivedTargetPower + 终端对PRACH occasion相关联的SSB上的DMRS测量得到的实际路损}；
信令参数msg3-DeltaPreamble在SIB1中定义， 表征msg3传输功率和RACH preamble传输功率之间的偏移量。
那么，终端选择使用group B中的preamble发起随机接入；否则，终端选择group A中的preamble发起随机接入。
对于基于竞争的随机接入，基站并不需要为终端指定preamble索引。因此，终端只需要知道和SSB相关联的preamble范围即可：
当个SSB关联到一个PRACH occasion上时，每个SSB所关联的R (
)个preambles，其索引范围为
，其中
由信令参数totalNumberOfRA-Preambles给出并且必须是N的整数倍；
当1个SSB关联到1/N (N < 1)个PRACH occasion上时，每个SSB上的R个preamble的索引范围为(0，R)。
N.B. 正是由于终端可以自主选择preamble索引， 才会引起随机接入过程中的竞争行为。
非竞争的随机接入过程中的RA资源选择
非竞争的随机接入过程通过基站为每个终端指定不同的PRACH occasion和preamble索引，避免了竞争的出现。这个是与基于竞争的随机接入过程的最大不同。我们先看一下相关信令参数：
其中的csirs部分属于Beam Failure Recovery，与本博文主题无关，我们先不关注。以上表格中的信令参数ssb-ResourceList给出了随机接入所需要的SSB(由SSB-Index指定)和preamble(由ra-PreambleIndex指定)；信令参数ra-ssb-OccasionMaskIndex则给出了发送preamble所需的PRACH occasion (由PRACH occasion索引指定)。
看到这里大家肯定有个疑问：前面两个都好理解，问题是最后一个，我怎么根据RO索引在时频域上找到的PRACH occasion资源？
这里我们就要再次提到在“基于竞争的随机接入过程中的RA资源选择”一节中提到association period，这里需要注意2点：
- association period从系统帧0就开始了，也就是说每个association period在时域上的起始时间点和结束时间点都可以计算得出。
- PRACH occasion索引在每个association period重新开始时都会重置。
因此，对于终端而言，只要找到SSB所对应association period就可以借助38.211 Table6.3.3.2-2或者Table 6.3.3.2-3并利用PRACH occasion index找到对应的PRACH资源。
Preamble发射功率
任何一种随机接入过程中的preamble发射功率的功控都是开环功控，也就是说终端无法通过任何来自基站的反馈来调整preamble发射功率。终端只能通过preamble是否发送成功来判断是否要按照以下方法调整preamble发射功率：
- 如果当前preamble传输被判定为失败 (判定因素与RAR有关，我们在下一章节就会说到)，则将变量PREAMBLE_TRANSMISSION_COUNTER加1 (该变量初始值为0)；
- 如果PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1，则认为当前随接入流程失败，重新选择随机接入资源发起一次新的随机接入流程；否则；
- 将变量PREAMBLE_POWER_RAMPING_COUNTER加1 (该变量初始值为0)；
- 设置PREAMBLE_RECEIVED_TARGET_POWER = preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
- 按照新的preamble发射功率重新发送preamble。
其中，preambleTransMax对应信令参数preambleTransMax，preambleReceived TargetPower对应信令参数：preambleReceivedTargetPower；DELTA_PREAMBLE由下表给出：
为PRACH资源的子载波间距，由信令参数msg1-SubcarrierSpacing给出。
随机接入响应接收
终端一旦发出preamble，就会开启一个Msg2消息等待窗口等待RAR消息的到来，在这个窗口期内终端收到的RAR均认为有效。RAR窗口的长度和起始时间见以下示意图：
Msg2消息由PDSCH承载，对应的PDCCH由RA-RNTI加扰，RA-RNTI由以下公式计算得出：
下面我们看看RAR到底向终端传递了哪些信息。
我们首先看看RAR的MAC PDU组成。RAR MAC PDU由一个或多个MAC subPDUs和padding(可选)组成。
RAR的MAC subPDU有以下几种：
从上图我们可以了解到，RAR一共有3个MAC subPDU:
1. BI，全称是Backoff Indicator，用于随机接入失败后终端等待重新发起随机接入的回退时间，回退时间一般是取0~scalingFactorBI*BI之间的一个任意值，scalingFactorBI是一个信令参数，如下表。另外需要注意的是BI是一个4个bits长度的字段，表示的是一个索引值，它所表示的真实时间如下表：
2. RAPID，全称是Random Access Preamble ID，其实就是终端发起随机接入使用的preamble的索引号。这个地方我们需要着重说一下，前面我们说过在基于竞争的随机接入过程中将选择preamble索引的权限交由每个终端独立进行是造成终端之间存在竞争的主要原因。现在我们可以解释一下了，对于基于竞争的随机接入，基站还是需要尽量避免终端之间的竞争接入，因为这会导致终端接入时间过长。基站主要通过以下两个步骤来规避：
1. 终端使用不同的preamble索引来发起随机接入；
2. 在发送Msg2消息时，加扰使用的RA-RNTI不同；
第一步我们已经说过了，终端自己选择preamble索引，这个在很大程度上就可能使得不同的终端使用相同的preamble索引来发起随机接入。此时就需要步骤2来保证不会引发竞争，如果RA-RNTI不同的话，那么不同的终端使用不同RA-RNTI来监听Msg2对应的PDCCH，就可以保证不会引发竞争。但是在极端情况下，如果每个终端的RA-RNTI也相同 (这个是有可能的，请参考我们上面说的RA-RNTI的计算公式)，这样就会造成多个终端共同去监听同一个Msg2消息。然后在检查其中的RAPID之后，如果这些终端的preamble索引也相同，这些终端就会认为这个Msg2消息是给自己的，然后就会使用该消息中的UL grant发起Msg3消息，而承载这些Msg3消息的PUSCH在时频域上是完全重合的，这样就造成了竞争。
3. MAC RAR，这个就是Msg2消息中最重要的部分，承载着以下主要信息：
- Timing Advance，即上行时间提前量，用于指示终端提前多少时间发送上行传输以保证上行数据达到基站后能保证和基站的上行空口时间一致。该时间提前量是基站物理层通过测量终端发送的preamble来得到的。
- Temporary C-RNTI，即TC-RNTI。当终端竞争成功后，将TC-RNTI直接升级为C-RNTI。
- UL-Grant，上行授权。因为终端还没有和基站建立RRC连接也没有进行上行同步，因此没法通过Scheduling Request来向基站请求上行授权进行上行传输，只能通过在RAR消息中携带上行授权信息让终端发送第一条上行消息Msg3，也就是RRCSetupRequest，RRC连接请求。
下面我们主要看看UL grant的组成：
对于RAR中的‘PUCHfrequency resource allocation’和‘PUSCH time resource allocation’字段，我们需要详细解释一下。
Msg3时域位置
RAR中的‘PUSCH time resource allocation’字段长度为4个bits，这4个bits对应的数值范围为0~15，对应信令参数PUSCH-TimeDomainResourceAllocation在信令参数PUSCH-TimeDomainResourceAllocationList中的位置,数值0对应PUSCH-TimeDomainResourceAllocationList中的第一个PUSCH-TimeDomainResourceAllocation，数值1对应PUSCH-TimeDomainResourceAllocationList中的第二个PUSCH-TimeDomainResourceAllocation，以此类推。
同时开始符号S和持续的连续符号个数L的确定还受PUSCH映射类型影响：
Msg3频域位置
在R16中对于上行PUSCH传输引入了交织 (interlace)的方式，这样在传输Msg3资源的时候，也增加了对于交织方式的描述。下面我们来一一介绍。
非交织方式
Msg3频域资源的分配方式是uplink resource allocation type 1(即连续PRB分配方式)， 对于一个长度为
的initial UL BWP来说，终端按照如下方式处理频域信息：
- 如果
，则DCI format 0_0中的‘Frequency domain resource assignment’字段长度为![\left [ log_{2}\left ( N_{BWP}^{size}\cdot \left ( N_{BWP}^{size}+1 \right )/2 \right ) \right ]](http://img.e-com-net.com/image/info8/d8ea43b0f4c44e1a9a54ced19b992b0b.gif)
，最大长度为14个bits。如果UL grant中的‘Frequency hopping flag’字段的数值不为0，则存在跳频。具体形式如下:
- 如果
，则需要在原有的14个bits中再添加![\left ( \left [ log_{2}\left ( N_{BWP}^{size}\cdot \left ( N_{BWP}^{size}+1 \right )/2 \right ) \right ] - 14 \right )](http://img.e-com-net.com/image/info8/25986dc346ab40a085dc15579d6b37be.gif)
个bits，这些bits均取值为0:
Msg3的PUSCH传输资源在频域上的位置则由以上公式中的RIV部分确定：
当存在跳频时，上面公式中提到的
的长度以及对应的跳频方式由下表确定：
交织方式
在交织方式下，Msg3频域资源的分配方式是uplink resource allocation type 2 ，终端按照如下方式处理频域信息：
- 对于PUSCH SCS = 15 kHz的场景，DCI format 0_0中的‘Frequency domain resource assignment’字段长度为6 bits; 对于PUSCH SCS = 30 kHz的场景，DCI format 0_0中的‘Frequency domain resource assignment’字段长度为5 bits;
- 对于使用RAR UL grant提供的上行资源进行上行传输的Msg3消息，组成该上行资源的RB set仅有一个
DCI format 0_0中的'Frequency domain resource assignment'字段即为RIV信息：
- 对于PUSCH SCS = 15 kHz的场景
- 对于PUSCH SCS = 30 kHz的场景，RIV使用位图的方式来指示UL grant所对应的上行资源的交织信息：
N.B.
1. 交织 (interlace)的概念是R16引入的，Uplink resource allocation type2使用的就是基于交织和RB set的分配方式，这个我们会在后面讲上下行资源分配方式的时候详细介绍。
2. 交织这个概念的引入主要是用于unlicensed spectrum上面，用于满足OCB(Occupied Channel Bandwidth)的需求以及弥补由于PSD (Power Spectrum Density)限制造成终端上行发射功率受限的场景。
3. 我对于非授权频谱共享这块不打算仔细研究，因为这块内容的市场主要是在北美。上面的内容我已经做了灰化处理，原因一是不打算深入研究，二是我再次校对的时候发现在“Frequency domain resource assignment”这块的描述上有所遗漏，所以请大家略过这部分内容。如果以后我发现非授权共享频谱需求场景很多，我会单独开一篇博文来介绍。
对于非竞争的随机接入过程而言，当接收到RAR之后，终端和基站取得上行同步，非竞争的随机接入过程到此也就是结束了。而对于基于竞争的随机接入过程而言，再下面就是极其重要的竞争解决流程。
竞争解决 (Msg3/Msg4)
终端在收到RAR，利用RAR消息中的Timing advance取得与基站的上行同步之后，就会使用RAR中携带的UL grant所指示的上行时频域资源来发送Msg3，对于终端接入小区的随机接入流程而言就是RRC消息：RRCSetupRequest。
首先我们来看看终端是如何知道基站指示其在哪个时刻发送Msg3的。在本文前面我们提到过终端如何从RAR消息中获取到
值的，据此我们就可以得到Msg3在时域上哪个时刻可以发送：
Msg3消息包含了一个长度为48个bits的竞争解决Id的MAC CE，如下：
同时Msg3还携带了RRCSetupRequest信令消息。
终端在发送了Msg3消息之后，同时会开启ra-ContentionResolutionTimer定时器，在该定时器超时之前，终端都会持续监听Msg4的PDCCH。如果该定时器超时，则终端认为竞争失败，重新发起随机接入流程。
在以接入小区为目的的随机接入流程中，Msg3为第一条可以重传的上行PUSCH传输，当Msg3传输失败时，终端重传Msg3消息，并重新启动ra-ContentionResolutionTimer定时器。
基站在接收到终端发送的Msg3之后，会向某一个终端发送Msg4 (即RRCSetup消息，该消息对应的PDCCH使用RAR中指示的TC-RNTI加扰)，并在承载msg4消息的PDSCH的MAC CE中携带该终端在Msg3中发送的竞争解决Id。处于竞争中的多个终端在接收到Msg4消息后，会将消息中的竞争解决Id取出来与自己Msg3中的竞争解决Id做对比，如果两者相同，则该终端认为竞争解决成功，发送Msg5消息 (即RRCSetupComplete)；否则，终端认为竞争失败，重新发起随机接入流程。
Reference
3GPP 38.214 Physical layer procedures for data
3GPP 38.331 Radio Resource Control (RRC) protocol specification
3GPP 38.133 Requirements for support of radio resource management
3GPP 38.213 Physical layer procedures for control