5G/NR 随机接入过程之Msg2

21.6 Msg2

UE发送了preamble之后，将在RAR时间窗(RA Response window)内监听PDCCH，以接收对应RA-RNTI的RAR(此时不考虑可能出现的测量gap)。如果在RAR时间窗内没有接收到gNB回复的RAR，则认为此次随机接入过程失败。

RAR窗起始时刻：RAR窗起始于最早的CORESET的第一个符号，该CORESET是UE被配置用于接收Type1-PDCCH CSS集的PDCCH，而最早的CORESET与PRACH传输相对应的PRACH occasion的最后一个符号之后至少间隔一个符号，其RAR窗起始时刻示意图如图21.11所示(值得注意的是，图21.11中a描述的RO虽然与CORESET挨着，但是并没有间隔一个符号，因此RAR窗并不能在挨着的CORESET的第一个符号启动，而是其后面那个CORESET，而b描述的RO与第一个CORESET间隔两个符号，因此ROC与最早的CORESET间隔了一个符号，则RAR窗在第一个CORESET就会启动)。RAR窗的长度由ra-ResponseWindow提供，单位是slot，其长度基于Type1-PDCCH CSS集的SCS。

图21.11 preamble format B4的PRACH occasion不同起始符号下RAR窗的起始时刻示意图

当UE成功地接收到一个RAR(使用前面介绍的RA-RNTI来解码)，且该RAR中的preamble index与UE发送的preamble index相同时，则认为成功接收了RAR，此时UE就可以停止监听RAR了。

21.6.1 MAC PDU(RAR)

MAC RAR组成的MAC PDU如图21.12所示。

图21.12 MAC RAR组成的MAC PDU的示意图

从图21.12可以看出，RAR MAC PDU由1个或多个MAC subPDU和可选的padding组成，其中MAC subPDU由如下组成：

- 仅具有BI的MAC子头(可单独存在)；

- 仅具有RAPID的MAC子头(即对SI请求的确认，可单独存在)；

- 具有RAPID的MAC RAR的MAC子头。

仅包括BI的MAC subPDU被放置在RAR MAC PDU的开头(如果包括BI)。仅具有RAPID的MAC subPDU(如SI请求的确认)和具有RAPID的MAC RAR的MAC subPDU可以被放置在BI(如果存在)和padding(如果存在)的MAC subPDU之间的任何地方。

从RAR MAC PDU的结构可以看出，如果gNB在同一PRACH资源上检测到来自多个UE的随机接入请求(RA-RNTI一样)，则使用一个RAR MAC PDU就可以对这些接入请求进行响应，每个随机接入请求(对应一个preamble index)的响应对应一个RAR。

如果多个UE在同一 PRACH资源(时频位相同，使用同一 RA-RNTI)发送 preamble，则对应的RAR复用在同一RAR MAC PDU中。

RAR MAC PDU在DL-SCH上传输，并用以RA-RNTI加扰的PDCCH来指示。知果使用相同 PRACH资源发送 preamble(preamble不一定需要相同)的所有UE都监听相同的RA-RNTI加扰的PDCCH，并接收相同的 RAR MAC PDU，但不同 preamble index对应不同的 MAC RAR，即 RAR MAC PDU中的1个 MAC subPDU。

由于 RAR MAC PDU只能使用一个RA-RNTI加扰，这也意味着使用不同 PRACH资源(时频位置不同)发送的preamble对应的RAR不能复用到同个 RAR MAC PDU中。

值得注意的是，在NR中，随机接入过程的触发增加了几个触发事件，其中包括了其他SI请求触发景。对其他SI的请求，在随机接入过程中UE可有两种方式通知gNB，其为随机接入过程中的消息1或消息3携带请求信息，描述如下：

1) 从38.331可知，UE与gNB了一条高层信令，即： RRCSystemInfoRequest，该信今是随接入过程中的消息3，可直接通和gNB，gNB.则通过消息4进行确认请求(如何确认或者不要确认，是LCID吗？但是没有，还是直接通过收到收到消息4竞争解决成功就可以确认gNB已经收到了UE的消息3(详情见本章疑问部分)；而消息1的话，可能会出现RAR MAC PDU并不是UE本身的，就算收到RAR也可能是其他UE的，所以要确认)；

2) 如果请求的SI与PRACH资源的子集相关联(通过参数rach-OccasionsSI进行配置)，在这种情况下，Msg1用于指示UE需要请求的SI，并且会为SI请求划分专有的preambles，而当使用Msg1时进行SI请求时，请求的最小粒度是一个SI(即一组SIBs)，其中1个preamble或PRACH资源可用于请求多个SI消息，并且通过RAR中的子头进行SI请求的确认。

为什么会有其他SI请求以及UE如何判断是否需要请求SI?在NR中，SI的方式除了广播(分为周期广播和按需广播)之外，还可以进行单播，其中其他SI请求的SIB包括SIB2~SIB9，不包括MIB和SIB1(MIB进行周期广播，SIB1可周期广播也可在RRC_CONNECTED进行单播)。如果对其他SI进行广播，则是在RRC_IDLE态和RRC_INACTIVE态下进行；如果对其他SI进行单播，其需要进行随机接入请求，因此是在RRC_CONNECTED态下进行。对于UE而言，如果在SIB1中SI-SchedulingInfo->si-BroadcastStatus被配置为notBroadcasting，则UE需要请求其他SI时，需要通过上述两种方式的其中一种进行请求(通过竞争或者非竞争随机接入)。

具有BI的MAC子头由五个头部字段E/T/R/R/BI组成，如图21.13所示。

图21.13 E/T/R/R/BI MAC子头示意图

如果UE收到了一个BI子头，则会保存一个backoff值，该值等于该subheader的BI值(其为一个backoff的索引值)所对应索引所对应的值；否则UE会将backoff值设为0。

BI(Backoff Indicator)指定了UE重发preamble前需要等待的时间范围(取值范围见38.321.的7.2节)。如果UE在RAR时间窗内没有接收到RAR，或接收到的RAR中没有一个preamble与自己的相符合，则认为此次RAR接收失败，此时UE需要等待一段时间后，再次发起随机接入请求。等待的时间为在0至BI值指定的等待时间区间内随机选取一个值。

BI的取值从侧面反映了小区的负载情况，如果接入的UE多，则该值可以设置得大些；如果接入的UE少，该值就可以设置得小一些，这由基站实现所决定。

RAPID为Random Access Preamble Identifier的简称，为gNB在检测preamble时所得到的preamble index。如果UE发现该值与自己发送preamble时使用的索引相同，则认为成功接收到对应的RAR。其对应的RAPID MAC子头由三个字段E/T/RAPID组成。如图21.14所示。

图21.14 E/T/RAPID MAC子头示意图

其中MAC子头中各域含义如表21.7所示。

表21.7 RAR MAC PDU中MAC子头各域参数

参数名称	参数描述
R(Reserved)域	取值为0
E(Exension)域	指示当前MAC subPDU是否是最后一个 0：指示当前MAC subPDU是最后一个 1：指示当前MAC subPDU后至少还有一个MAC subPDU
T(Type)域	0：指示BI MAC子头 1：指示RAPID MAC子头
BI(Backoff Indicator)域	指示当前小区的过载情况
RAPID域	指示传输的睡觉接入前导

21.6.2 RAR组成

固定RAR如图21.15所示。

图21.15 MAC RAR的组成示意图

RAR UL Grant调度用于UE的PUSCH传输。从MSB开始到以LSB结束的RAR UL Grant的内容在表21.8中给出。

表21.8 RAR UL Grant组成大小(38.213 Table 8.2-1)

RAR grant field	Number of bits
Frequency hopping flag	1
PUSCH frequency resource allocation	14
PUSCH time resource allocation	4
MCS	4
TPC command for PUSCH	3
CSI request	1

14比特PUSCH frequency resource allocation用于确定Msg3传输的频域资源位置，该字段解释如下：

Msg3 PUSCH频率资源分配用于上行链路资源分配类型1。在具有跳频的Msg3 PUSCH传输的情况下，Msg3 PUSCH频率资源分配字段的钱一个或两个比特被用作跳频信息比特，且与激活的UL BWP的大小相关，如表21.9所述。

表21.9 Frequency offset for second hop of PUSCH transmission with frequency hopping scheduled by RAR UL grant(38.213 Table 8.3-1)

Number of PRBs in initial UL BWP	Value of $N_{UL,hop}$ Hopping Bits	Frequency offset for 2nd hop
$N_{BWP}^{size} < 50$	0	$\left \lfloor N_{BWP}^{size}/2 \right \rfloor$
$N_{BWP}^{size} < 50$	1	$\left \lfloor N_{BWP}^{size}/4 \right \rfloor$
$N_{BWP}^{size} \geq 50$	00	$\left \lfloor N_{BWP}^{size}/2 \right \rfloor$
	01	$\left \lfloor N_{BWP}^{size}/4 \right \rfloor$
	10	$-\left \lfloor N_{BWP}^{size}/4 \right \rfloor$
	11	Reserved

UE在 $N_{BWP}^{size}$ 个RBs的激活UL BWP中处理频域资源分配如下描述：

如果 $N_{BWP}^{size} \leq 180$ ，则只使用该字段的最低 $\left \lceil log_{2} \left ( N_{BWP}^{size} * \left ( N_{BWP}^{size} + 1 \right ) /2\right )\right \rceil$ 个比特，其解析方式与正常的DCI format 0_0中的频域资源分配字段相同。

如果 $N_{BWP}^{size}\geq 180$ ，14bits会被分为2部分： $N_{UL,hop}$ 个跳频bit和剩余14 – $N_{UL,hop}$ 比特。如果“hopping flag”域设置为1，则个跳频比特的定义如表21.9所示。如果“hopping flag”域设置为0，则 $N_{UL,hop}$ 为0，即此时不存在跳频。由于14比特并不足以表示所有的资源分配情况，因此协议中规定会在 $N_{UL,hop}$ 个跳频比特后插入值为0的 $\left \lceil log_{2} \left ( N_{BWP}^{size} * \left ( N_{BWP}^{size} + 1 \right ) /2\right )\right \rceil - 14$ 特。也就是说，此时认为Msg3 PUSCH frequency resource allocation域包含 $N_{UL,hop}$ + $\left \lceil log_{2} \left ( N_{BWP}^{size} * \left ( N_{BWP}^{size} + 1 \right ) /2\right )\right \rceil - 14$

+ (14 - $N_{UL,hop}$ )比特，然后扩展后的频域资源分配域的解析方式按照DCI format 0_0中的频域资源分配字段进行解析

4比特PUSCH time resource allocation用于确定Msg3传输的时域资源位置，如果UE在slot n收到带有RAR消息的PDSCH，则UE在slot 传输PUSCH(Msg3)，其中k2指的是时隙偏移，由PUSCH time resource allocation确定， Δ指的是第一次Msg3传输附加子载波间隔特定时隙延迟值，其值参见38.214表6.1.2.1.1-5。

1比特Frequency hopping flag，用于判断PUSCH传输是否跳频，如果其值为0，则UE在没有跳频的情况下发送PUSCH(Msg3)；否则，UE通过跳频发送PUSCH(Msg3)。

4比特MCS，取值0~15，说明RAR对应的PUSCH传输(Msg3)的MCS的取值范围为0~15，可参考38.214。

3比特TPC command for PUSCH，用于设置PUSCH传输(Msg3)的功率，如何使用参考38.213的7.1.1，其定义参考38.213的表8.2-2。

1比特CSI request，对于基于非竞争的随机接入而言，RAR中的CSI request字段用于决定在对应的PUSCH传输是否包含非周期CSI上报。而对于基于竞争的随机接入而言，RAR中的CSI request字段是预留的，即没有任何作用。

疑问：

1. 其他SI请求的其中一种请求方式，是通过RRCSystemInfoRequest进行，也就是随机接入过程中的消息3，其相对于另外一种通过Msg1进行请求的方式而言，在Msg2中有RAPID作为SI确认，而该请求方式没有，那么其如何受到SI确认?并且UE在发起消息3时，此时还没有唯一标识，那么UE如何判断SI请求是否成功？

A：从38.331中可得知RRCSystemInfoRequest是48比特，其在CCCH逻辑信道上传输，则此时UE并没有C-RNTI，那么对于UE MAC而言，整个RRCSystemInfoRequest就是一个CCCH SDU，则RRCSystemInfoRequest中requested-SI-List就相当于一个唯一标识，或者说整个RRCSystemInfoRequest相当于一个唯一标识，当UE收到Msg4的时候，则UE会使用保存的CCCH SDU(即RRCSystemInfoRequest)与解码得到的Contention Resolution Identity MAC CE进行匹配，如果匹配成功，并且随机接入过程是由SI请求触发，则MAC会给高层指示一个SI确认。

目前文章逐步移至微信公众号更新，有兴趣可扫下面二维码进行关注，谢谢。