LTE：CCE介绍

CCE介绍
本文主要介绍LTE中如何计算、分配CCE以及UE盲检PDCCH过程。

未涉及载波聚合下的CCE计算和盲检过程，这部分会在后面介绍载波聚合时涉及。

一、下行CCE计算
每个下行子帧（不是上行子帧，也不是针对slot）被分成2部分：control region和data region。

Control region主要用于传输L1/L2 control signaling。

1、Control Region的组成以及相应资源的分布
Control Region由PCFICH + PHICH + PDCCH + Reference Symbols组成。

映射顺序：先映射Reference Symbol，接着映射PCFICH和PHICH，映射的位置与小区配置有关，原则是尽量配置到不同符号不同载波上。

对剩下的RE将重新格式化，划分REG、 CCE，最后映射PDCCH。

（1）Reference Symbols和同步信号（见36.211的6.10、6.11节）
Downlink cell-specific reference signal：频域上间隔6个子载波，时域上位于每个slot 的第1个和倒数第3个OFDM symbol上。

Downlink ue-specific reference signal：不在antenna port 0~3中传输，只随data part 一起传输，且不插入cell-specific reference signals所位于的OFDM symbols中，因此不占用control region的资源。

PSS和SSS：（见36.211的6.11节）
FDD中，PSS和SSS都随着子帧0和5的第一个slot传输，其中PSS位于该slot的最后一个symbol，SSS位于该slot的倒数第二个symbol；
TDD中，PSS随着子帧1和6的第三个symbol传输（在DwPTS中），SSS随着子帧0和5的最后一个symbol传输。

（2）PCFICH：（见36.211的6.7节）
PCFICH用于通知UE control region的大小（1或2或3个OFDM symbols，即CFI=1, 2 or 3），每个小区有且仅有一个PCFICH。

PCFICH位于子帧的第1个OFDM Symbol中，共占4个REG。

4个REG在频域上的位置由physical-layer cell identity决定。

系统带宽时，DCI跨度为1，2 or 3；系统带宽时，DCI跨度为2，3 or 4（即CFI+1）。

信道编码后的CFI codeword（见36.212的5.3.4.1节）
（3）PHICH：
通过读取PBCH确定其资源分布（从UE角度上看）。

每个PHICH group映射到3个REG，且REG间相隔近似1/3的下行系统带宽。

通常位于第1个OFDM symbol中传输，但也可在semi-statically configure中配置PHICH在3个OFDM symbol中的分布。

【PHICH的分布由PBCH确定。

PBCH用1bit指示PHICH是只位于1个symbol还是跨越3个symbol；并用另外2个bit指示control region中给PHICH预留的资源数（见36.331的6.3.2节的PHICH-Config）】
1 PHICH group = 8 PHICHs (Normal CP)
1 PHICH group = 4 PHICHs (Extended CP)
（4）PDCCH：
主要用于传输下行控制信息（以便正确接收PDSCH）和UL Grant（为PUSCH分配上行资源）。

其分配以CCE为单位。

2、REG总数的计算
（1）通过读取PCFICH获取control region所占的symbol数（即CFI）（见36.211的6.7节）。

（2）两根天线意味着第1个OFDM symbol中有1/3的RE被用于参考信号（12个子载波情况下，一个RB内的一个symbol共有3个REG，而此时只剩下2个REG）。

（3）对于TDD而言，1和6号子帧的control region最多只能有2个OFDM symbols，因为在这些子帧中，PSS要占据第三个OFDM symbol。

（4）小区带宽内可用的REG总数为，其中表示下行带宽，以频域上的RB数为单位。

例：
10M带宽共有50个RB，除去reference symbol后，可用的REG总数为(2+(cfi-1)*3)*50。

20M带宽共有100个RB，除去reference symbol后，可用的REG总数为
(2+(cfi-1)*3)*100。

3、PCFICH所占的REG计算：（见36.211的6.7.4节）
固定占4个REG
4、PHICH所占的REG计算：（见36.211的6.9节）
PHICH携带HARQ ACK/NAK信息。

多个PHICH可以匹配到同一个PHICH group中，且同一PHICH group中的PHICHs通过不同的orthogonal sequences区分。

因此，一个PHICH resource资源可以通过唯一标记。

其中表示PHICH group索引，表示该group中的orthogonal sequence索引。

（1）一个PHICH group占3个REG。

（2）control region中不一定包含PHICH（=0的情况）。

（3）对于FDD的帧结构而言，每个子帧中PHICH group的总数通过如下公式计算
其中，由上层提供。

对于TDD的帧结构而言，不同的下行子帧的PHICH group总数是不同的，并通过计算。

其中通过上面的公式获取，而通过下表获取：
因此，PHICH 所占的REG 个数为（对于FDD 而言，为0或1）。

5、PDCCH 可用的CCE 数：（见36.211的6.8节）
1 CCE = 9 REG = 36 RE = 7
2 bits
PDCCH 可用的CCE 数，其中=（PDCCH 的OFDM Symbols
中总的REG 数 - PCFICH 占用的REG 数（固定为4）- PHICH 占用的REG 数（不一定存在）。

二、PDCCH 分配（调度）过程（见36.213的9.1
节）
一个子帧中可以同时传输多个PDCCH 。

一个PDCCH 由n 个连续的CCE 组成，起始的CCE 索引i 必须满足
且i 的范围为
，其中
为子帧k 中所有
供PDCCH 使用的CCE 数。

即CCE 数目为n 的PDCCH ，其起始位置的CCE
号，必须为n 的整数倍。

PDCCH 有4种format (格式) {0，1，2，3}，分别对应Aggregation Level （聚合等级）{1，2，4，8}。

Aggregation Level 表示一个PDCCH 占用的连续的CCE 个数，即前面提到的n 。

PDCCH 的格式如下表所示
调度时，eNodeB会针对每个待调度的UE，从PDCCH Search Space中选择一个可用的PDCCH资源，如果能分配到就调度，否则就不调度。

UE会在non-DRX子帧监听PDCCH candidates集合（根据所监听的DCI format来进行解码），该集合又定义为该UE的Search Space（搜索空间）。

在汇聚级别上的Search Space 定义为PDCCH candidates的集合。

Search Space 中PDCCH candidate m的CCEs通过如下公式计算
其中且。

（为Search Space的PDCCH candidate数）
Search Space（搜索空间）分为Common空间和UE-Specific空间，Common空间用于传输与Paging、RA Response、BCCH等相关的控制信息，UE-Specific空间用于传输与DL-SCH、UL-SCH等相关的控制信息。

Common空间从CCE 0开始；UE-Specific空间的起始位置可以通过上面给出的HASH函数计算（i= 0）。

从下表可以看出，对于某种DCI format，可能的candidate有22个。

Number
Search space
Aggregation level
candidates
Table 9.1.1-1: PDCCH candidates monitored by a UE.
对于common空间，为0。

对于UE-specific空间（汇聚级别为L），定义为
其中并且，为一个帧中的slot号（取值0~19）。

从上面的公式可以看出，Search Space与RNTI、子帧号相关。

Search Space如下图所示：
根据上述说明，eNodeB就知道可以把DCI放在哪（Find First CCE），UE就知道DCI 可能放在哪（Blind Decoding）。

注意：在36.213的10.1.3.1节，还介绍了TDD模式在某些特殊DCI format下对first CCE 的限制。

三、UE盲检过程：（见《3G Evolution》的16.4.8节）
DCI有多种format，但UE事先并不知道接收到的PDCCH携带的是什么format的DCI，因此UE必须盲检DCI format。

第一步，UE需要计算用于PDCCH的CCE数。

UE通过PSS/SSS，确定了物理层cell ID和frame timing（说得通俗一点，就是subframe number #0所在的位置，但此时还不知道system frame number）（见《3G Evolution》的18.1节）。

因为cell-specific reference signal（RS）以及frequency shift（指定RS的位置）与物理层cell ID一一对应，所以间接确定了cell-specific reference signal及其在RB中的位置（见《3G Evolution》的16.3节）。

接着就可以进行信道估计并进一步解调PBCH，从而获取system frame number、PHICH 占用的资源分布和天线端口数（见《3G Evolution》的18.2.1节）。

再通过解调PCFICH获取CFI，就知道了control region占用的symbol数。

至此，PCFICH的内容已经解调，PHICH的分布由PBCH确定，Reference Signal分布取决于物理小区ID和PBCH中广播的天线端口数，从而PDCCH在一个子帧内所能占用的CCE 数就可以确定了。

第二步，盲检DCI。

虽然UE事先并不知道接收到的PDCCH携带的是什么format的DCI，也不知道需要的信息在哪个位置，但UE知道自己处于何种状态以及在该状态下期待收到的DCI信息。

例如在IDLE 态时UE期待收到Paging SI；在发起Random Access后UE期待的是RACH Response；在有上行数据待发送时期待UL Grant；在TM3模式下期待format 1A或format 2A的DCI等。

UE知道自己的Search Space，因此知道DCI可能分布在哪些CCE上。

对于不同的期望信息，UE用相应的X-RNTI与属于自己的Search Space内的CCE做CRC校验，如果CRC校
验成功，那么UE就知道这个信息是自己需要的，也知道相应的DCI format和调制方式，从而进一步解出DCI内容。

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在PDCCH Search Space进行盲检时，只需对可能出现的DCI format进行尝试解码，并不需要对所有的DCI format进行匹配。

可能出现的DCI format取决于UE期望接收什么信息以及传输模式（见36.213的7.1节和8.0节）。

例如：如果UE期待接收DL-SCH并使用传输模式1，当UE对使用C-RNTI扰码的PDCCH进行解码时，只会对DCI format 1A和DCI format 1进行尝试解码。

如果同时该UE期望在该子帧内接收UL Grant，则会使用DCI format 0进行尝试解码。

Common Search Space是所有UE都需要监听的空间，通常用来发送与System Information、Paging Message、RAR以及power-control commands for a group of UEs等相关的控制信息。

但是当UE-Specific Search Space没有足够的可用资源时，Common Search Space也可以用于传输属于某个特定UE的控制信息。

Common Search Space只能使用最小的DCI format 0/1A/3/3A/1C。

Common Search Space和UE-specific search space可能重叠，属于不同UE的
UE-specific search space也可能重叠。

如果重叠的区域被一个UE占用，那么其它UE将不能再使用这些CCE资源。

在成功解码PDCCH之前，UE会在每一个可能的PDCCH candidate上尝试解码。

一旦解码成功则停止解码过程。

【问题】
（1）为什么UE进行PDCCH盲检的总次数不超过44次？
从36.213的Table 9.1.1-1可以看出，对于某种DCI format进行盲检时，可能的candidate 有22个。

从36.213的7.1节和8.0节可以看出，在某种传输模式或状态下（如随机接入时使用RA-RNTI）解码时，可能的DCI format最多有2种。

因此UE进行PDCCH盲检的总次数不超过44（22 * 2）次。

需要注意的是，在一个下行子帧内，UE实际盲检的次数可能超过44次。

如果在一个下行子帧内，UE期望同时接收下行数据、UL Grant和系统信息。

则对每一种信息，都会使用对应的X-RNTI在Search Space内对相应的DCI format尝试解调。

【Reference】
[1] 《3G Evolution HSPA and LTE for Mobile Broadband, 2nd》
[2] 《4G LTE/LTE-Advanced for Mobile Broadband》
[3] 3GPP TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation". V10.3.0
[4] 3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures". V10.3.0
[5] 3GPP TS36.321, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol spe cification” V10.3.0
[6] 《PDCCH Construction》。