5G NR Search space和CORESET

PDCCH是下行控制信道，承载着PUSCH和PDSCH的控制信息DCI。在LTE中，PDCCH频域上占据全部带宽，时域上占据每个子帧的前1-3个符号，由资源的多少动态调度。在NR中，PDCCH若沿用LTE的方式，继续占据全部带宽，无疑是资源的浪费，而且会对UE提出很高的要求，不利于降低UE成本，所以NR中PDCCH会在BWP内，而且时域也不是占据固定的一些时隙，下面就讲述一下决定PDCCH时频资源的大概过程。主要涉及两个概念 search space 和 CORESET。
Search space有很多类型，首先分为common search space（CSS）和UE Specific search space（USS），具体如下：

• Type0-PDCCH CSS set
• Type0A-PDCCH CSS set
• Type1-PDCCH CSS set
• Type2-PDCCH CSS set
• Type3-PDCCH CSS set
• USS set

不同类型的CSS有不同的适用情形，比如Type1用于随机接入，具体的可以参考38213第10章。
不同类型的search space会有不同RNTI加扰的PDCCH。
UE在决定到底该去哪里寻找PDCCH时，高层会提供一个参数来指示search space。指示的来源在不同情况下有所不同：

• PDCCH-configCommon在SIB1中，配置cell specific的common search space：
  
• PDCCH-config配置UE specific的search space：
  
• 还有MIB中的信息PDCCH-configSIB1是专门配置search space 0 和CORESET0的。CORESET0和search space 0 在38213第13章有详细介绍。

Search space中就会包含以下信息：

这里只截取了与PDCCH时频位置相关的一部分参数，其他参数具体可以参考协议38331.这些参数的具体含义如下：

monitoringSlotPeriodicityAndOffset：
指示search space的周期和周期内的偏移，以时隙为单位，从图中可以看出有sl1、sl2等不同的可选项，sl表示slot的意思，比如sl40就表示search space的周期是40个时隙，后面对应的整数表示偏移，意思是在40个时隙中的哪个时隙开始是search space；
Duration：
上个参数指示了周期和偏移，这个参数指示了每个周期内search space持续的时隙个数；
monitoringSymbolsWithinSlot：
指示了在监测PDCCH的时隙中，具体从哪个符号开始监测，它是一个14位的bit串，每一个bit对应时隙中的一个OFDM符号，哪位值是1就表示从该符号开始监测PDCCH，对于扩展CP，由于一个时隙中只有12个符号，所以UE会忽略最后2bit，每个时隙中用于监测PDCCH的若干个符号其实就是所说的CORESET；
controlResourceSetId：
一个search space会与一个CORESET相对应，这个参数就指示了对应这个search space的CORESET。

一个search space只能对应唯一的CORESET。

CORESET中又会包含下列内容：

其中与CORESET的时频资源有关的两个参数如下：
Duration：指示了CORESET持续的符号数；
frequencyDomainResources：指示了CORESET的频域资源。
其余关于交织方式、CCE-REG映射类型等参数不做介绍，大家可以自己参考38211和38213以及38331。从图中可以看到frequencyDomainResources是一个长为45的bit串，它指示频域资源的方式具体如下：
参数frequencyDomainResources 提供一个bitmap，bitmap中的每个bit和互不重叠的一组6个RB有一一映射关系，以BWP内RB的index升序排列。共45个bit，最高bit代表第一个RB组，以此类推。bit值为1表示这个RB group是CORESET的频域资源。BWP内第一个RB group的起始位置为6*roundup（N/6）所指示的CRB的位置，也就是说第一个RB group的起始位置并不是BWP的第一个RB，而是BWP内的第一个6的整数倍的CRB的位置。式中roundup表示向上取整，N表示BWP起始位置的CRB编号。具体的大家自己可以参考28213。

所以总结起来就是：

1. 当UE想要找到PDCCH时，高层参数指示的search space中会指示search space的时域周期和偏移、每周期内持续监测的时隙数和每个时隙内的监测的具体起始符号，这些其实就是指示了CORESET的时域位置；
2. 然后按照该search space指示的与其对应的CORESET中包含的信息，进一步获取每个CORESET的资源大小。

通过时域位置和资源大小，就可以确定下来一个CORESET0，从而UE可以从中盲检PDCCH。CORESET0也会将解码PDCCH的信息也一并告知UE，比如REG bundle的size等，这些在这里就不再细说，这篇主要讲UE如何找到去哪里检测PDCCH。

盲检PDCCH 的过程就是挨个对PDCCH candidate进行译码，如果CRC校验通过，则认为所译码的PDCCH就是UE要找的PDCCH。具体关于PDCCH相关的介绍可以看另一篇：https://blog.csdn.net/m0_45416816/article/details/99962825