在介绍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即在可能的搜索空间内搜索需要侦听的控制信息。
对于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进行盲检。
对于控制信道频域资源的调度，NR里面仍沿继承LTE中的RE概念，在频域上占用一个子载波，而REG不再是4个RE，变为频域上12个RE，即占用了一个RB的频域大小。由多个（可选2，3，6）REG组成一个REG Bundles，具体的个数由高层RRC确定。再由6个REG组成一个CCE，再由CCE的个数确定PDCCH分配空间的聚合等级。
NR里面的CORESET在频域上由多个RB组成，在时域上由1或2或3个OFDM符号组成，具体参数由RRC高层信息来指示。由此可见，相比LTE对于控制资源的指示，更为灵活。
我们来看看RRC消息里的CORESET消息包含什么内容。
我们来看看几个重要的参数：
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.
这里出现了一个问题，UE解完RRC消息才能取得CORESET资源，但UE要接收RRC消息又要首先知道CORESET的资源，才能在具体的时频资源去接收解调PDCCH，进而解调PDSCH。为了解决这个先有蛋还是先有鸡的问题，协议里将系统初始接入的必要调度资源（SIB1）封装在CORESET 0里，而CORESET0的具体调度参数不需要在RRC里面传输，默认大家都知道，这样在解完SSB之后，UE知道在具体的时频资源位置去盲检SIB1的调度信息。CORESET 0具体的时频调度参数如下所示。其中，MIB pdcch-ConfigSIB1在介绍漫谈3中BWP简述已经做了说明，由SSB解析后可确定。
由上述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面对的业务场景来调度了。
我们来看看几个重要的消息:
searchSpaceId：搜索空间号，当为0时（解SIB1的PDCCH调度信息）指通过MIB获得搜索空间。
controlResourceSetId：对应的CORESET号
monitoringSlotPeriodicityAndOffset：侦听的slot周期，即发送的周期
monitoringSymbolsWithinSlot：侦听的OFDM符号在slot中的位置。
这里举一个例子来说明：
声明：文中部分图片来源于http://www.sharetechnote.com/
喜欢文章,可关注公众号: