上图左边两部分在前面文章中已经总结：

• 随手记(16)5G NR CORESET配置与资源映射总结回顾

• 随手记(17)CORESET0及CSS0配置回顾总结

• 随手记(18)SSB与RMSI CORESET的复用pattern)

本文接上述几篇文章继续学习NR搜索空间和盲检方面的内容。这些文章提到了：NR中引入CORESET来提升定义PDCCH资源的效率，同时UE需要通过CORESET和搜索空间Search Space的信息来获取调度资源。也就是与LTE类似，NR也需要搜索空间，NR的搜索空间负责定义比如起始符号，监听周期及所关联的CORESET等信息。而且NR的搜索空间也分为两类，即：

一般来说，CSS主要用于接入及切换场景，而USS则应用于接入完成后。规范文本中NR搜索空间详细分类如下：

根据上面规范文本总结的更为详细的分类如下：

NR CCE聚合等级比LTE多一类，如下：

在CORESET包含的信息里只是告知了PDCCH的频域位置和时域占用的符号数量，而并没有告知发送周期和符号起始位置等信息，搜索空间将包含这些信息，每个搜索空间对应一个CORESET，每个CORESET可对应多个搜索空间。前面文章也描述过对于SIB1调度的DCI的搜索空间CORESET0，由MIB中的pdcch-ConfigSIB1这个8位组IE的低4位(LSB)来确定。而UE的其他具体的搜索空间由相应的RRC信令来配置，也就是在NR的设计中使用了两组RRC IE来分别定义配置CORESET和Search Space，目的就是为了针对不同的业务类型来进行灵活的资源配置，CORESET确定了能够使用的总的时频资源，作为一个共享资源块，所有的用户都可以引用，而具体什么时候用，怎么用还需要根据具体UE的业务应用场景来调度和配置。那么下面根据对搜索空间的定义，看一下高层RRC的相关配置：

searchSpaceId：搜索空间标识号，当等于0时候指的是需要通过MIB获得搜索空间(解码SIB1的PDCCH调度信息)。每个BWP最多配置10个搜索空间。

controlResourceSetId：所搜空间所关联的CORESET标识，当为0的时候表示此搜索空间关联到由MIB配置的CORESET0。

monitoringSlotPeriodicityAndOffset：以slot为单位粒度的监听的周期及偏移量，理解这个可参考文章5G消息periodicityAndOffset IE总结。

duration：duration在NR的多类IE组出现，这里的duration要配置的是连续监听搜索空间结合的slot数量，这里要求duration所包含的连续slot的数量要小于上面monitoringSlotPeriodicityAndOffset中的监听周期。

monitoringSymbolsSwithinSlot：用于定义在每个slot内，该搜索空间所关联的CORESET的起始符号位置。

这里举个例子来说明一下，比如监听周期是10个slot，周期内slot偏移为5，slot数量为1，而搜索空间关联的CORESET的符号长度为2，符号起始位置为0和7，则UE会在每10个slot的第5个slot中的符号0和符号7开始，各连续监听两个符号，则监听的符号为0,1,7和8，可图示如下：

nrofCandidates：表示每个AL的PDCCH候选数量，除非制定了特定的值和特定的格式，否则这里所配置的候选集数量和AL适用于所有的格式(通过searchSpace Type)。

搜索空间配置的其他部分如下：

这里定义了两类搜索空间(CSS和USS)特定的DCI参数，相应的DCI信息可以参考文章：5G DCI速查词典，另外R16中增加了一些新的DCI类型，大家可以进一步参考38212相关部分的描述。其他各部分的RRC配置汇总如下：

其中controlResourceSetZero和searchSpaceZero分别对应CORESET0和SearchSpace0的配置，与MIB中的pdcch-ConfigSIB1类似(NSA中需要)。可配置最多额外的11个CORESET(包括CORESET0最多12个)，缺省不配时候使用SSB关联的CORESET0 。还有就是图中所示的sousuokongjianIE中searchspaceSIB1、searchspaceOtherSystemInformation、pagingSearchSpace和ra-SearchSpace都是可选的IE，在没有配置情况下都默认使用SearchSpace0 。也就是说在SA场景中不配置PDCCH-Common时候，则使用CORESET0和Search Space0 。在UE级的PDCCH-Config IE组包含在BWP配置中，每个BWP最多配置3个CORESET及10个SearchSpace。

总结之，则小区级的PDCCH-ConfigCommon用于CSS配置，而UE级的PDCCH-Config用于USS和CSS配置。PDCCH-ConfigCommon这个IE在具体系统实现中，由于NSA(当前是ENDC)只对UE发送MIB(SIB1及其他SIB通过锚点eNB发送给UE，ENDC ANR功能除外)，则SA针对PDCCH-ConfigCommon这个IE组直接通过SIB1发送给UE，ENDC通过锚点的RRC重配发给UE。

由上面描述可以看到，根据当前搜索空间及其所关联的CORESET配置，便可确定PDCCH时频资源调度情况，监听参数及起始符号位置由搜索空间决定，符号数量和频域资源(频域调度范围)由搜索空间关联的CORESET定义，也就是说PDCCH在时域上的准确位置由搜索空间得出，但是UE只知道PDCCH会在CORESET中提供的RB范围内发送，但还不知道在哪些RB上发送。也因此需要进一步在不同的搜索空间按照不同的RNTI类型在CORESET上搜索PDCCH信息，即通过不停的对PDCCH候选集进行解调来获取并确定每个候选PDCCH在CORESET内的CCE索引，也就是CCE的起始位置及其数量，具体CCE的决定通过搜索空间函数确定，此过程也称为PDCCH盲检，前面介绍RRC参数时，UE通过接收搜索空间中的nrofCandidates参数知道了PDCCH可能发送的CCE聚合度等级及其所对应的盲检的次数，之后便可对每个候选集进行解码操作，一旦解码成功才会停止盲检流程：

进一步滴~，

基于对终端软硬件能力及调度效率的考虑，38213对每个小区上每时隙的最大候选集个数进行了明确规定：

此外，38213还针对时隙为粒度上的最大非重叠CCE个数进行了规定，由于每时隙上的非重叠CCE数量越大则同一小区内的UE之间PDCCH重叠概率就会越小，但是代价是PDCCH视频资源开销会比较大，通过明确规定这个CCE重叠的最大数量可以在效率和开销之间取得均衡。规范文本的定义如下：

当μ值增大时，由于所应用的频段相对较高，所服务的小区覆盖小，UE数量相对较少，因此候选集个数及非重叠CCE个数都设计使用的较小也是可以理解的了。

最后作为扰码使用的RNTI，相关内容可以参考以前的文章：5G x-RNTI小辞典，最新的R16的更新如下：

最新的规范文本中定义的多个下行接收类型“Reception Type”，按表中所示为Physical Channel物理信道-》Monitored RNTI-》Transport Channel传输信道的组合：

各类UE状态下所支持的Reception Type：

愉快！