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 |
Frequency offset for 2nd hop |
| |
0 |
|
| 1 |
|
|
| |
00 |
|
| 01 |
|
|
| 10 |
|
|
| 11 |
Reserved |
UE在
个RBs的激活UL BWP中处理频域资源分配如下描述：
如果
，则只使用该字段的最低
个比特，其解析方式与正常的DCI format 0_0中的频域资源分配字段相同。
如果
，14bits会被分为2部分：
个跳频bit和剩余14 –比特。如果“hopping flag”域设置为1，则 个跳频比特的定义如表21.9所示。如果“hopping flag”域设置为0，则为0，即此时不存在跳频。由于14比特并不足以表示所有的资源分配情况，因此协议中规定会在 个跳频比特后插入值为0的 
特。也就是说，此时认为Msg3 PUSCH frequency resource allocation域包含 +
+ (14 - )比特，然后扩展后的频域资源分配域的解析方式按照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确认。
目前文章逐步移至微信公众号更新，有兴趣可扫下面二维码进行关注，谢谢。
