LTE下行物理层传输机制（4）-CCE

在之前的博文中已经讲到，小区专用参考信号的基本映射单位是RE（参考博文《LTE下行物理层传输机制（1）-天线端口Antenna Port和小区特定参考信号CRS》），PCFICH信道的基本映射单位是REG（参考博文《LTE下行物理层传输机制（2）-PCFICH信道和资源组REG》），PHICH信道的基本映射单位也是REG（参考博文《LTE下行物理层传输机制（3）-PHICH信道》），而本文所提到的PDCCH信道，它的基本映射单位则是CCE。

1.CCE的组成

CCE，全称Control Channel Elements，是PDCCH（physical downlink control channel）信道的基本组成单位，每个CCE由9个REG组成（参考下文中的示意图）。CCE只用作PDCCH信道的映射，不用于小区参考信号、PCFICH信道和PHICH信道的映射，因此，组成CCE的REG或RE是不包括小区参考信号、PCFICH信道和PHICH信道等已经占用的RE或REG的。

如果用N_REG变量来表示除去PCFICH、PHICH信道占用之后还剩下的REG个数，那么每个下行子帧CCE的个数N_CCE=floor（N_REG/9）。比如某个子帧控制区域总的REG个数等于88，其中PCFICH信道占了4个REG，PHICH信道占了6个REG，那么用于PDCCH的CCE个数=（88-4-6）/9=8.67=8个（向下取整）。

2.CCE的REG在物理上不连续

组成一个PDCCH信道的CCE个数，一般称为聚合等级（aggregation level ）。聚合等级有4种值，分别是CCE_lv=1、2、4、8，即如果某个PDCCH信道的聚合等级CCE_lv=4，则意味着该PDCCH信道由4个索引连续的CCE组成。这里所谓的“索引连续”是指逻辑意义上的连续，而不是物理REG上的连续，如下图所示。

上图列出了6个PDCCH信道，分别是：

CCE索引为0的CCE组成了一个聚合等级=1的PDCCH信道；CCE索引为2-3的CCE组成了一个聚合等级=2的PDCCH信道；CCE索引为16-17的CCE组成了一个聚合等级=2的PDCCH信道；CCE索引为4-7的CCE组成了一个聚合等级=4的PDCCH信道；CCE索引为20-23的CCE组成了一个聚合等级=4的PDCCH信道；CCE索引为8-15的CCE组成了一个聚合等级=8的PDCCH信道。

这些组成PDCCH信道的CCE，它的索引在逻辑上是连续的，但是单独展开某个特定的CCE，如上图中的CCE_index=8的CCE，组成它的9个REG在物理资源上并不是连续的，这9个REG可以分布在时域上的3个OFDM符号中。每个CCE与它的REG的映射关系，可以参考36211协议中的相关公式。因此，控制区域中PCFICH信道、PHICH信道、PDCCH信道的位置可能如下图所示。

这这个例子中，eNB首先为参考信号预留RE，然后为PCFICH分配4个REG，再为PHICH分配3个REG，最后剩余的REG组成相应的CCE，映射到2个不同的PDCCH信道中：CCE0和CCE1组成PDCCH信道1，因此PDCCH信道1的聚合等级是2；CCE4组成PDCCH信道2，因此PDCCH信道2的聚合等级是1。

一般来说，eNB侧的MAC层负责PDCCH信道的CCE聚合等级和起始位置索引的调度分配，而物理层则负责CCE位置到物理REG的映射。

3.CCE的盲检测和搜索空间

如前文所示，在LTE里，每个PDCCH信道会映射到不同聚合等级（或不同个数）的CCE中。在标识PDCCH信道的时候，除了使用聚合等级这个参数外，还需要CCE的起始位置索引这个参数。由于下行或上行资源的动态调度是在eNB侧进行的，聚合等级和起始位置都由eNB侧分配，因此在某个下行子帧里，终端事先无法确切的知道PDCCH占用的CCE的聚合等级是多少，以及CCE的起始位置索引在哪里。所以，对于终端来说，每次都是通过盲检测来获取PDCCH信道即CCE的位置的，而盲检测所消耗的时间是比较多的，因此协议也做了一些降低盲检测时间的约定：

（1）对于聚合等级，前文已经有描述，协议只约定了4种CCE聚合等级，即1、2、4、8，降低了盲检的可能性。

（2）对于不同的搜索空间（search space），允许使用的CCE聚合等级不同，候选位置（Number of PDCCH candidates）也是有限的，具体见下表所示。

对于UE专用空间（UE-specific search space），可以使用1、2、4、8这四种聚合等级，而在公共空间（common search spaces），综合考虑抗干扰和盲检测处理时间，只使用4、8这两种聚合等级。

CCE聚合等级最大是8，而可以使用的CCE总个数有可能比较多，比如可用CCE总个数N_CCE可以等于88这种值，因此聚合等级为8的PDCCH信道在CCE可用个数为88的控制区域中，存在着很多的可能性位置，这些可能的位置，我们称之为“候选位置集（set of PDCCH candidates）”。为了降低终端的盲检测时间，这些“候选位置”个数也是有限的，如上表所示，比如在公共搜索空间中，聚合等级为8的PDCCH信道，候选的位置只有2个。如果终端在所有的候选位置经过盲检测，都没有找到PDCCH信道，则退出该盲检侧过程。CCE候选位置在CCE空间中的位置如下图所示。

组成PDCCH信道的所有候选位置的每个CCE位置，都可以通过下面的公式计算得出（图中有个错误，应该是i的取值范围，而不是m的取值范围，感谢傲天-18）。从公式中可以看到，某个PDCCH信道的所有候选位置的CCE位置，与该PDCCH信道的聚合等级、搜索空间类型、子帧号、可用CCE总个数、RNTI等参数有关。

比如，某个PDCCH信道的聚合等级是4、属于公共空间、N_CCE=88、子帧号=0，从上文的表Table9.1.1-1中可以看到，此PDCCH信道的候选位置有4个，因此可以得到参数：L=4，Yk=0，m=0～3，N_CCE=88，i=0～3。通过上面的公式可以计算得到：

PDCCH候选位置1的CCE位置（m=0时的情况）：第一个CCE位置：4*[0 mod (88/4)]+0=0；第二个CCE位置：4*[0 mod (88/4)]+1=1；第三个CCE位置：4*[0 mod (88/4)]+2=2；第四个CCE位置：4*[0 mod (88/4)]+3=3。

PDCCH候选位置2的CCE位置（m=1时的情况）：第一个CCE位置：4*[1 mod (88/4)]+0=4；第二个CCE位置：4*[1 mod (88/4)]+1=5；第三个CCE位置：4*[1 mod (88/4)]+2=6；第四个CCE位置：4*[1 mod (88/4)]+3=7。

PDCCH候选位置3的CCE位置（m=2时的情况）：第一个CCE位置：4*[2 mod (88/4)]+0=8；第二个CCE位置：4*[2 mod (88/4)]+1=9；第三个CCE位置：4*[2 mod (88/4)]+2=10；第四个CCE位置：4*[2 mod (88/4)]+3=11。

PDCCH候选位置4的CCE位置（m=3时的情况）：第一个CCE位置：4*[3 mod (88/4)]+0=12；第二个CCE位置：4*[3 mod (88/4)]+1=13；第三个CCE位置：4*[3 mod (88/4)]+2=14；第四个CCE位置：4*[3 mod (88/4)]+3=15。

需要注意的是，根据上面的公式可以得到，公共空间的CCE范围是0～15，但UE专用空间的范围也可以落在0～15中，因此公共搜索空间和UE专用搜索空间是可以互相重叠的。在同个子帧时刻，一旦某个CCE已经被分配，则不能再分配给其他用户。以下图为例，在同个子帧，如果终端A分配的CCE范围是16～23，那么eNB就不能给终端B分配16～23这个范围的CCE。

正是由于在相同子帧里CCE位置的不可复用，或者说独占性，因此当小区中有多个UE需要传输数据，此时即便RB资源足够多，也可能会因PDCCH信道的CCE位置冲突而导致无法调度某个或某些UE。比如说，某个系统的业务总流量可以达到Pbps，现有10个UE进行数据传输业务，每个UE的业务量占用的RB均较少，此时10个UE总的流量记为Mbps，可能就会有M的情况出现。

对于SIB、寻呼、RAR、TPC、集群组呼这些共享信道对应的PDCCH，需要在公共空间进行CCE的调度，其它的则在UE专用的搜索空间中调度。

（3）对于CCE起始位置索引，协议规定，某个PDCCH信道的起始位置索引，必须能整除CCE聚合等级。比如某个PDCCH信道的CCE聚合等级是4，那么这个PDCCH信道的CCE起始位置索引可能是0、4、8、...等等，不能是2、3、5这种不能整除4的值。如下图所示。

参考文献：

（1）3GPP TS 36.211 V9.1.0 (2010-03) Physical Channels and Modulation

（2）http://lteuniversity.com/get_trained/expert_opinion1/b/hongyanlei/archive/2011/05/20/pdcch-construction.aspx

（3）3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

（4）《4G LTE/LTE-Advanced for Mobile Broadband》

（5）http://www.sharetechnote.com/html/Handbook_LTE_ResourceAllocation_ManagementUnit.html