5GNR漫谈4:CORESET与SearchSpace

在介绍BWP的时候,我们提到了UE(User Equiment,用户设备,终端)在做完小区搜索SSB的检测后,为了检索SIB1信息,需要提取MIB里面的pdcch-ConfigSIB1消息,里面8位比特信息指示了SIB1的调度信息可能的时频资源位置,UE根据这个时频资源位置,去盲检SIB1的DCI信息,这个DCI是承载在PDCCH信道上的,从而根据得到的DCI消息去解承载SIB1消息的PDSCH,进一步获取详细的小区系统配置信息。

在LTE里面,需要用到一个专门的PCFICH信道来指示下行控制信道PDCCH占用了几个OFDM符号,从而计算可利用的下行控制信道资源,由4个资源粒度(Resource Element,RE)组成1个REG(ResourceElement Group ),再由9个REG组成CCE(Control Channel Element),再由多个(由聚合等级决定)CCE组成PDCCH的搜索空间,UE即在可能的搜索空间内搜索需要侦听的控制信息。
5GNR漫谈4:CORESET与SearchSpace_第1张图片
对于LTE而言,PDCCH占用的频域资源是占用整个系统带宽的,而我们知道,NR里面定义了BWP,使得UE不必在某一工作时间工作在整个系统带宽,可以在某一工作时间仅工作在一部分子带上。这种改变,使得NR里面对于下行控制信息DCI的调度发生了改变,不再用专门的信道来指示PDCCH占用了几个OFDM符号,而转用一个称为CORESET的信道来指示PDCCH占用的时频资源,不同的CORESET定义有不同的 ID,其中CORESET0专门用来承载SIB1的DCI调度信息。而对于CORESET调度信息,又由RRC消息里面的ControlResourceSet消息携带,除了CORESET 0的调度信息。因为CORESET 0指示的控制信息里面,携带的是SIB1的调度信息,非常重要,默认了一个参数集来供UE进行盲检。
5GNR漫谈4:CORESET与SearchSpace_第2张图片
对于控制信道频域资源的调度,NR里面仍沿继承LTE中的RE概念,在频域上占用一个子载波,而REG不再是4个RE,变为频域上12个RE,即占用了一个RB的频域大小。由多个(可选2,3,6)REG组成一个REG Bundles,具体的个数由高层RRC确定。再由6个REG组成一个CCE,再由CCE的个数确定PDCCH分配空间的聚合等级。
5GNR漫谈4:CORESET与SearchSpace_第3张图片
NR里面的CORESET在频域上由多个RB组成,在时域上由1或2或3个OFDM符号组成,具体参数由RRC高层信息来指示。由此可见,相比LTE对于控制资源的指示,更为灵活。
5GNR漫谈4:CORESET与SearchSpace_第4张图片
我们来看看RRC消息里的CORESET消息包含什么内容。
5GNR漫谈4:CORESET与SearchSpace_第5张图片
我们来看看几个重要的参数:

controlResourceSetId :即物理层里的’CORESET-ID’,CORESET-0即为MIB里面定义的pdcch-ConfigSIB1,或者ServingCellConfigCommon里面指定的initialDownlinkBWP。

frequencyDomainResources:指示CORESET占用的频域带宽,总共有45bit,每一位指示6个RB资源,总共可以指示270个RB资源,系统的最大带宽。这里采用了bitmap指示。

duration:指示CORESET在时域上占用的连续OFDM符号个数,取值为1,2,3.

这里用一张图来示例。在这张图里面,frequencyDomainResources=10000。。。。。,即占用了第起始位置的6个RB,duration=2,即占用了2个OFDM符号时间,reg-BundleSize=6,即由6个REG组成一个CCE,聚合等级为1.
5GNR漫谈4:CORESET与SearchSpace_第6张图片
这里出现了一个问题,UE解完RRC消息才能取得CORESET资源,但UE要接收RRC消息又要首先知道CORESET的资源,才能在具体的时频资源去接收解调PDCCH,进而解调PDSCH。为了解决这个先有蛋还是先有鸡的问题,协议里将系统初始接入的必要调度资源(SIB1)封装在CORESET 0里,而CORESET0的具体调度参数不需要在RRC里面传输,默认大家都知道,这样在解完SSB之后,UE知道在具体的时频资源位置去盲检SIB1的调度信息。CORESET 0具体的时频调度参数如下所示。其中,MIB pdcch-ConfigSIB1在介绍漫谈3中BWP简述已经做了说明,由SSB解析后可确定。
5GNR漫谈4:CORESET与SearchSpace_第7张图片
由上述RRC里面的消息可知, CORESET仅是告知了PDCCH的频域位置和时域占据几个OFDM符号,并没有告知具体的发送周期,以及具体的OFDM符号起始位置,那UE想要侦听DCI调度信息还是很麻烦。NR里面,将PDCCH出现的周期和发射的OFDM符号位置定义在搜索空间里面(SearchSpace)。一个搜索空间对应一个CORESET(由共同的参数controlResourceSetId确定),一个CORESET可对应多个搜索空间。对于SIB1调度信息DCI的搜索空间(对应的是CORESET 0),由解出MIB 中8位的pdcch-ConfigSIB1消息低4位确定。UE具体的搜索空间信息由RRC信令来配置。
在这里,我们发现,为了解析PDCCH,需要用到了两个RRC信令消息,分别封装在CORESET和SearchSpace。那为何搞得这么麻烦呢?目的还是灵活的调度资源以面对不同UE的业务类型。CORESET就像一个总开关,确定了能够利用的总的时频资源,大家都可以用,但是,这个时频资源什么时候用,就需要根据具体UE面对的业务场景来调度了。
5GNR漫谈4:CORESET与SearchSpace_第8张图片
我们来看看几个重要的消息:

searchSpaceId:搜索空间号,当为0时(解SIB1的PDCCH调度信息)指通过MIB获得搜索空间。

controlResourceSetId:对应的CORESET号

monitoringSlotPeriodicityAndOffset:侦听的slot周期,即发送的周期

monitoringSymbolsWithinSlot:侦听的OFDM符号在slot中的位置。

这里举一个例子来说明:
5GNR漫谈4:CORESET与SearchSpace_第9张图片
5GNR漫谈4:CORESET与SearchSpace_第10张图片

声明:文中部分图片来源于http://www.sharetechnote.com/
喜欢文章,可关注公众号,获得代码:
5GNR漫谈4:CORESET与SearchSpace_第11张图片

你可能感兴趣的:(5GNR漫谈4:CORESET与SearchSpace)