欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

5GNR漫谈4:CORESET与SearchSpace

程序员文章站 2022-06-22 22:50:27
在介绍BWP的时候,我们提到了UE(User Equiment,用户设备,终端)在做完小区搜索SSB的检测后,为了检索SIB1信息,需要提取MIB里面的pdcch-ConfigSIB1消息,里面8位比特信息指示了SIB1的调度信息可能的时频资源位置,UE根据这个时频资源位置,去盲检SIB1的DCI信息,这个DCI是承载在PDCCH信道上的,从而根据得到的DCI消息去解承载SIB1消息的PDSCH,......

在介绍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
对于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
对于控制信道频域资源的调度,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
NR里面的CORESET在频域上由多个RB组成,在时域上由1或2或3个OFDM符号组成,具体参数由RRC高层信息来指示。由此可见,相比LTE对于控制资源的指示,更为灵活。
5GNR漫谈4:CORESET与SearchSpace
我们来看看RRC消息里的CORESET消息包含什么内容。
5GNR漫谈4:CORESET与SearchSpace
我们来看看几个重要的参数:

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
这里出现了一个问题,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
由上述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
我们来看看几个重要的消息:

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

controlResourceSetId:对应的CORESET号

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

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

这里举一个例子来说明:
5GNR漫谈4:CORESET与SearchSpace
5GNR漫谈4:CORESET与SearchSpace

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

本文地址:https://blog.csdn.net/guet208/article/details/105467043