【5G NR】CORESET存在的意义

CORESET是什么

CORESET：Control Resource Set，控制资源集
用于指示PDCCH在BWP中可能出现的频域范围和持续的时间长度。RRC信令中有相应的IE（information element）：ControlResourceSet。

1、频域范围
通过45位的bitmap指示，每一位代表一个包含6个连续RB的RB组，最高位代表BWP的第一个RB组。举个例子：frequencyDomainResources=110000……0表示PDCCH存在于BWP的前12个RB中。
2、持续时间
对应duration参数，表示PDCCH占用几个OFDM符号（1~3）。

UE如何找到自己的PDCCH？

从前面的介绍可以知道，CORESET只是PDCCH存在的范围，但PDCCH并不是映射在整个CORESET上。基站可能在这个CORESET中调度10个用户，也就意味着10个PDCCH在这个CORESET上发送。那么UE就需要在CORESET中搜索自己的PDCCH。
看到这里，大家可能会有疑问：基站为什么不直接告诉UE在哪些资源上监测其PDCCH？
可以从两方面解释：

1. 使用有限的资源调度尽可能多的用户
   接入网络的UE个数通常比较多，如果为每个UE都分配专用的PDCCH资源可能是不够的。因此不同UE组合对应不同CORESET，同一个CORESET里面的相同资源上，可能这个时隙调度UE1，下一个时隙调度UE2，这样有限的资源就可以用于调度更多用户了。
2. UE是否被调度具有不确定性
   基站一般使用某种调度算法来调度用户，比如轮询算法、最大载干比算法、比例公平算法等。因此某个UE是否被调度具有不确定性。比如在前面举的例子中，这个CORESET调度10个UE，没有UE1，但UE1并不知道这个情况。可以通俗地理解为，虽然UE想收到调度信息，但基站有自己的想法。从这个角度来看，基站不可能为UE配置固定的资源发送PDCCH。

PDCCH candidate

既然无法使用特定的资源发送PDCCH，也不能让UE漫无目的地寻找，所以调度能力和检测复杂度之间需要有个折中，具体做法就是给UE划定一个范围搜索PDCCH，并且预设一个搜索准则，尽量减小检测复杂度。
给定了CORESET，UE能够确定的是，如果存在自己的PDCCH，那它一定存在于某些资源上，因此引入了PDCCH candidate。UE对每一个PDCCH candidate尝试解码，用RNTI解扰CRC校验位，如果解扰成功，则说明这就是其PDCCH，接着进一步解码，获取DCI。