NR PDCCH 搜索空间

搜索空间概述

       在5G NR系统中，由于系统的带宽较大，以及终端解调能力的差异性，为了提高资源利用率，降低盲检复杂度，(1)PDCCH不再频域上占据整个带宽；此外，为了增加系统灵活性，适配不同的场景，(2)PDCCH在时域的起始位置也可配。因此，在5G NR中，UE需要完全获取PDCCH的时频域资源配置信息，才可以进一步对PDCCH进行解调，也才可以进一步对PDSCH进行解调

引入：

(PDCCH仅占用部分带宽即可提供足够的容量，NR的PDCCH也不必占用整个系统带宽，基于这些考虑，NR以控制资源集合(Control Resource Set,CORESET)为单位配置资源，一个CORESET占用的PRB个数以及PRB的位置可以根据网络部署灵活选择，这也就可以和Type0进行结合)。意味着：CORESET是占用了一部分的PRB，即CORESET的实质一部分时频资源，上面存放着一些信息(如PDCCH的信息等)。

       目前协议设计方案是：将PDCCH的频域资源信息和时域占用的OFDM符号数等信息封装在CORESET中，将PDCCH起始OFDM符号以及监听周期、关联的CORESET等信息封装在搜索空间中。
       5G NR中的搜索空间分为两种类型，公共搜索空间（CSS，Common Search Space）和UE特定搜索空间（USS，UE Specific Search Space）；CSS主要是在接入时和小区切换时使用CSS用于BCCH、寻呼、RAR等相关的控制信息，而USS则是在接入后使用。

例如：

SIB1对应的PDCCH的公共Search Space是type 0-PDCCH CSS（也就是去哪儿找这个调度信息）, 绑定的CORESET是CORESET#0(频率带宽与Initial BWP相同)（是实际的时频资源）.

注意：CORESET#0和type 0-PDCCH CSS并不是一回事，一个是对应的资源集合，即SIB1存放的位置资源？？一个是搜索空间，即说明去哪儿搜索SIB1。

搜索空间类型

       具体搜索空间的类型以及分类如下表所示

第一个即为：type 0-PDCCH CSS，绑定的CORESET是CORESET#0(SIB1配置)

                                                                MIB配置的CORESET0

 

搜索空间参数集

       TS38.331中对于SearchSpace参数集的定义如下所示

 

 对于搜索空间参数集中的每个参数，有如下：
       searchSpaceId：搜索空间集合的ID，每个BWP最多配置10个搜索空间
       controlResourceSetId：搜索空间集合所关联的CORESET，值为0的时候表示此搜索空间关联到由MIB配置的CORESET0
       searchSpaceType：搜索空间类型以及调度的DCI Format，搜索空间类型包括：CSS或者USS；DCI Format包括0-0，0-1，1-0，1-1，2-0，2-1，2-2，2-3
       nrofCandidates：搜索空间集合包括的聚合度信息以及每种聚合度下的候选PDCCH个数
       monitoringSlotPeriodicityAndOffset：检测搜索空间集合的周期（单位为slot）以及检测周期开始到实际检测搜索空间的slot偏移
       duration：连续检测搜索空间集合的slot数量，且slot数量要小于检测周期
       monitoringSymbolsWithinSlot：每个slot内，搜索空间关联CORESET的时域OFDM起始符号位置
       举例说明，假设检测周期为10个slot，slot偏移为5，slot数量为1，搜索空间关联的CORESET时域符号数为2，符号位置为0和7。因此，在此配置下，UE会在每个检测周期的slot5的sym0、sym1和sym7、sym8检测候选PDCCH。

 搜索空间确定

     1、根据当前搜索空间以及关联的CORESET配置，确定候选PDCCH的时域资源调度情况，其中时域起始符号位置由当前搜索空间配置决定，时域符号数目由此搜索空间关联的CORESET决定；

(比方确定SIB1信息，

(1) 那么就首先根据Type0 PDCCH CSS搜索空间确定时域位置，然后在根据CORESET确定频域位置，从而最终确定PDCCH的时频位置)
       2、根据当前搜索空间以及关联的CORESET配置，确定每个候选PDCCH在CORESET内的CCE索引（即CCE的起始位置以及CCE的个数），具体CCE的确定是通过搜索空间函数确定。

(2) （找到PDCCH以后，进而确定CCE位置和个数。从而就能找到PDCCH）
       3、对每个候选PDCCH进行Polar解码和Crc校验，当Crc校验通过后，则表示当前候选PDCCH解调成功。

(3) (找到这个PDCCH以后就能进行解码，知道了PDCCH的调度信息，从而就知道了PDSCH的调度，这样SIB1信息也能确定出来)

UE下行同步完成之后，需要接收SIB1消息，获得与上行同步相关的配置，才能进行RACH过程完成上行同步。

SIB1消息由PDSCH承载，若要接收/解码SIB1，需要知道PDSCH的调度信息，那么就需要监测对应的承载调度信息的PDCCH.

总结

SIB1消息由PDSCH承载，若要接收/解码SIB1，需要知道PDSCH的调度信息，那么就需要监测对应的承载调度信息的PDCCH.

SIB1用PDSCH传输，那么就要知道PDSCH的调度，而共享信道（干活的信道）又是由PDCCH的DCI信息控制的，所以就

(1)需要找到PDCCH的时频资源调度，解出DCI_format，
(2) 从而拿到PDSCH的调度，

(3) 接下来就可以从PDSCH中得到SIB1

关键就是在找PDCCH时频调度的时候，用到了两个概念：

Type0 -PDCCH CSS(搜索空间)需要找到 PDCCH，找到时域的起始符号位置；

然后找到CORESET#0，找到时域符号数目由此搜索空间关联的CORESET决定

从而最终确定了PDCCH所占用的视频资源；紧接着再确定CCE等，确定PDCCH，最后进行解码就可以拿到DCI