PDCCH盲检

1    CCE
在PDCCH上，承载DCI（Downlink Control Information）的基本单元是CCE（Control Channel Element）。每个CCE包含9个REGs（Resource Element Group），每个REG包含4个REs，也就是一个CCE是包含36个RE的一个连续资源块。那么在系统带宽和用于PDCCH的symbol数量确定后基本可以计算出总的CCE数量（从总的RE数量中去掉PCFICH，PHICH以及参考信号所占的RE，再除以36）。
CCE是如何编号的呢，是每个symbol的CCE都从0开始编号？或者symbol 1中CCE的编号从symbol 0的最后一个CCE开始递增？从36.213中计算UE-Specific Search Space起始位置的HARSH函数来看似乎是每个symbol的CCE是独立编号的，都从0开始（need confirmation）。

2    盲检
UE一般不知道当前DCI传送的是什么format的信息，也不知道自己需要的信息在哪个位置。但是UE知道自己当前在期待什么信息，例如在Idle态UE期待的信息是paging, SI；发起Random Access后期待的是RACH Response；在有上行数据等待发送的时候期待UL Grant等。对于不同的期望信息UE用相应的X-RNTI去和CCE信息做CRC校验，如果CRC校验成功，那么UE就知道这个信息是自己需要的，也知道相应的DCI format，调制方式，从而进一步解出DCI内容。这就是所谓的“盲检”过程。
那么UE是不是从第一个CCE开始，一个接一个的盲检过去呢？这也未免太没效率了。所以协议首先划分了CCE公共搜索空间（Common Search Space）和UE特定搜索空间（UE-Specific Search Space），对于不同的信息在不同的空间里搜索。
另外对于某些format的信息，一个CCE是不够承载的，可能需要多个CCE，因此协议规定了所谓的CCE Aggregation Level取值为1，2，4，8。例如对于位于公共空间里的信息Aggregation Level只有4，8两种取值，那么UE搜索的时候就先按4 CCE为粒度搜索一遍，再按8 CCE为粒度搜索一遍就可以了。
3    Seach Space
DCI信息包括
UL Grant（format 0）
DL Assignment（format 1）
Paging（format 1c）
RACH Response（format 1c）
System Information（format 1c）
MIMO Downlink Assignment（format 2）
Power Control Command（format 3）
…
可以看出，有些信息如paging, SI, RACH response是所有UE都要去监听的，有一些则是跟特定UE相关的如上下行调度指令。所以协议将CCE划分为CCE公共搜索空间（Common Search Space）和UE特定搜索空间（UE-Specific Search Space），从而提高UE的盲检效率。其中公共搜索空间是最前面的16个CCE。UE特定搜索空间的起始位置根据36.213 9.1.1中的公式计算，空间大小则和Aggregation Level有关，最小为6 CCEs最大为16 CCEs。
从36.213表9.1.1-1可以查到不同搜索空间的可能Aggregation Level取值，UE一般不知道应该使用那种Aggregation Level，所以UE能做的是把所有可能性都尝试一遍。例如对于Common Search Space，UE需要分别按Aggregation Level = 4和Aggregation Level = 8来搜索。当按AL=4搜索时，16个CCE需要搜索4次，也就是有4个Control Channel Candidates；当按AL=8搜索时，16个CCE需要搜索2次，也就是有2个CCH Candidates；那么对于公共空间一共有4+2=6个CCH Candidates。


对于UE Specific来说，对应于AL=1，2，4，8分别有6，6，2，2个CCH Candidates，一共有16个。