随机接入流程 - 4 Step RA-CSDN博客

本文链接：https://blog.csdn.net/zhangbin_leo/article/details/126835620

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 occasio