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

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确认。

 

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

5G/NR 随机接入过程之Msg2_第1张图片

你可能感兴趣的:(NR,5G/NR)