NR中的PDCCH时频域介绍[CORESET && searchspace]【原创】

        本文参考协议介绍NR 5G 中的PDCCH信道上资源放置规则，并罗列关键IE及log实例。

        如有错误敬请指正，转载请注明出处。

1.PDCCH信道基本概念

        检测PDCCH，离不开两个概念：CORESET & search space

        概述：

• CORESET规定了PDCCH的频域形状，更偏向频域上的范围，以及时域上的宽度。
• search space更多的告诉UE，去哪里检测，更偏向时域上的位置（起点/周期等）。
• 1个search space只能对应唯一一个CORESET，反之则可以一对多（一个CORESET可以对应多个search space）

2.CORESET 介绍

LTE中，PDCCH信道的频域上：全带宽，时域上，子帧的第1~3个symbol

NR中，全带宽太浪费资源，于是引入CORESET

频域粒度：

• 一组REG（1symbol * 12SCS）
• 最小粒度是6个REGs（被称作一组CCE）--盲检PDCCH的最小单元
• CCE的可以以1 2 4 8 16个绑定成一块（被称为聚合等级，表示PDCCH需要用多少个CCE来装）
• CCE到REG的映射可以用交织或者非交织（排序而已，CORESET#0 必交织，且交织参数被定死了）

频域限制：

• 每个cell最多12个CORESET（#0通过MIB配置下来）
• 每个BWP最多能配置3个CORESET
• CORESET #0最特殊，只用在Type 0 CSS（search space概念，后续介绍）使用，通过MIB配下来（initial BWP的一部分），作用在于解析SIB（SIB1和Other SIB）

时域粒度：

• 1~3个symbols
• 习惯上一般放在slot首位
• 放满编3个symbols是有前提的：一般来讲时域前面是PDCCH，紧跟着DMRS，然后是PDSCH。
• 而PDSCH DMRS时域配置规定死了一半是pos2/pos3（MIB会带dmrs-TypeA-Position），所以DMRS只能放置在时域上的第3或者第4个symbol上，若DMRS已经放在第3个symbol上，CORESET就不可能取3（已经被DMRS占了）。反之，若CORESET 占用3个symbol时，DMRS-pos必为3。

举例（实际上PDCCH的DMRS放置也是1/4，梳状放置，每个REG上3个DMRS）

• note1
  • CORESET是针对终端去定义的，表示的含义是UE可以能在这里收到PDCCH，而不是表示gNB一定去发PDCCH。
• note2
  • CORESET 更多介绍的是频域上的概念，以及时域上可能的持续时间，即更像是时域上固定频域宽度的一个滑块限制。PDCCH的频域资源，就只能放到固定宽窄（时域symbol）的频域范围上。

3. search space介绍

        search space严格规定了时域上的位置，而且search space会和CORESET关联        

3.1 主要参数：

• 关键的CORESET id
• 每隔多少个slot监听（monitoringSlotPeriodicityAndOffset，单位slot）
• 监听周期>1时需要看持续多少个slot监听（duration，单位slot）
• 在哪个符号上开始监听（单位symbol），注意这个是开始位置，监听多少个symbol是CORESET给出的
• 聚合等级个数
• searchspace类型（CSS/USS，type 0/1/2/3）

注意：前文介绍过，1个search space只能对应唯一一个CORESET，反之则可以一对多（一个CORESET可以对应多个search space）。这里的理解是CORESET规定出来搜索的频域形状，不同search space可以套用这个形状，所以一个CORESET可以有多个searchspace。

3.2 search space的类型：

        p.s. 大致写了几个常用的，R16/17规定一些1A/2A的特殊用途的Type。笔者工作实际接触不多，暂不介绍。

• note1
  • 关于searchspace聚合等级，如果是CSS，聚合度只能用4 8 16，USS的可以使用1 2 4 8 16
  • 且检测之前是不知道具体哪个聚合度的是此次下发的PDCCH，所有所有出现的聚合度都要盲检（个数/类型越多，UE计算要求越高）
• note2
  • 初始的CORESET #0和searchspace #0怎么带下来？
  • 在MIB中，通过pdcch-ConfigSIB1携带，一般log工具会自动解析出来，直接根据值查表即可。
• CORESET 的初始表格：

   

• searchspace的初始表格：

4.CORESET和searchspace的IE解读，及log实战看DCI配置

        IE:

• ControlResourceSet information element字段
• SearchSpace information element字段

        先通过一个例子解读下CORESET和searchspace的对应关系和IE作用范围。

        p.s. 实际现网参数几乎不会这么配置，仅用于理解参数。

4.1 配置MIB之后拿到了什么？

A：后续定位的起点

• controlResourceSetZero拿到CORESET位置
• searchSpaceZero拿到searchspace位置

4.2 找到SIB1后拿到了什么？

CORESET没有再进行额外的配置，新配置了2个searchspace

解读：

        searchSpaceId 1搜的很快(sl1)，所以适用于paging/RA这种业务，而searchSpaceId 8搜的较慢(sl40)，所以适用于读其他SIB（时效性低）

截止到这里，CORESET和SS列表为

4.3 RRC配置（RRC Setup）做了什么？

增加2个searchspace，1个CORESET，且配置成了USS

截止到这里，CORESET和SS列表为

4.4 进行RRC重配后什么发生变化？

BWP进行切换，所以BWP0上的非common配置被干掉

BWP1上新增3个SS

截止到这里，CORESET和SS列表为

5.盲检原因

时频资源都已经确定了，为什么还要盲检？

• CCE  aggregation本身可能存在多种
• 搜索的时候从频域上哪个点搜也没定
• DCI format类型又比较多，DCI size也可能不同

如上几个因素叠加，若不增加一些算法限制，复杂度太高了。

解决方案：

• 协议给出了算法，频域上无需检测全部的频点，而是设置一些既有的检索点，假设CCE聚合度是8，对应48个REG的情况，就可以在0/4/8/16/…的RE上开始盲检，而不是0/1/2/..每个都检测
• 公式过于复杂此处不赘述，只简单了解到和如下几个参数相关即可：聚合度(1/2/4/8/16)/聚合度对应的个数n/时隙号

写在最后：

        PDCCH这部分协议很复杂，以上只是结合log梳理下流程，具体的算法要依据具体问题具体看配置。

        关于盲检的限制和个数没有看的很透彻，且本人工作中接触到的机会不多，先将结论放在此处，后续若遇到实际问题再查表感受含义。

Q：设置既有检索点了，还是有可能搜索的个数太多

A：针对这种情况，spec直接定了

        1.不同子载波下的 一个slot内的最大盲检次数（38213 table 10.1-2）

        2.不同子载波下的 一个slot内的最大非重叠CCE的个数（38213 table 10.1-3）

        以上两个其实都是为了规避搜太多费时费力的问题，但是有2个问题

        1.该先搜谁，协议规定是：一个时隙内，同时有CSS / USS时，优先盲检CSS，USS优先级则按照searchspaceid从小到大的顺序排序，小的先搜

        2.怎么算个数？协议规定是：以下条件同时满足时不计数；1.PDCCH候选集相同，或者采用相同CCE；2.PDCCH候选集使用相同加扰；3.PDCCH候选集DCI大小相同。

        而对于DCI format size，为了规范化，也定了一些规定： 

        一个 cell，UE在1个时隙监听的不同DCI size个数不超过4个，在1个时隙使用C-RNTI检测的DCI size个数不超过3个。