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确认。
目前文章逐步移至微信公众号更新,有兴趣可扫下面二维码进行关注,谢谢。