LTE：CCE介绍参考模板

1、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 Symbo

2、l，接着映射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 03中传输，只随data part一起传输，且不插入cell-s

3、pecific 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 sy

4、mbols，即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

5、中传输，但也可在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

6、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总数为，其中表示下行带宽，以

7、频域上的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个REG4、PHICH所占的REG计算：（见36.211的6.9节） PHICH携带HARQ ACK/NAK信息。多个PHICH可以匹配到同一个PHICH group中，且同一PHICH group中的PHICHs通过不同的orthogonal sequ

8、ences区分。因此，一个PHICH resource资源可以通过唯一标记。其中表示PHICH group索引，表示该group中的orthogonal sequence索引。 （1）一个PHICH group占3个REG。 （2）control region中不一定包含PHICH（=0的情况）。 （3）对于FDD的帧结构而言，每个子帧中PHICH group的总数通过如下公式计算其中，由上层提供。 对于TDD的帧结构而言，不同的下行子帧的PHICH group总数是不同的，并通过计算。其中通过上面的公式获取，而通过下表获取：Uplink-downlinkconfigurationSubfra

9、me number i0123456789021-21-101-101-1200-1000-10310-00011400-000011500-0000010611-11-1 因此，PHICH所占的REG个数为（对于FDD而言，为0或1）。5、PDCCH可用的CCE数：（见36.211的6.8节） 1 CCE = 9 REG = 36 RE = 72 bits PDCCH可用的CCE数，其中=（PDCCH的OFDM Symbols中总的REG数- PCFICH占用的REG数（固定为4）- PHICH占用的REG数（不一定存在）。二、PDCCH分配（调度）过程（见36.213的9.1节） 一个子帧

10、中可以同时传输多个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的格式如下表所示PDCCH formatNumber of CCEsNumber of resource-element groupsNumbe

11、r of PDCCH bits01972121814424362883872576 调度时，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通过如下公式计算 其中且。（为Sea

12、rch 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个。Search spaceNumber of PDCCH candidatesTypeA

13、ggregation levelSize in CCEsUE-specific16621264828162Common41648162Table 9.1.1-1: PDCCH candidates monitored by a UE. 对于common空间，为0。 对于UE-specific空间（汇聚级别为L），定义为 其中并且，为一个帧中的slot号（取值019）。 从上面的公式可以看出，Search Space与RNTI、子帧号相关。 Search Space如下图所示： 根据上述说明，eNodeB就知道可以把DCI放在哪（Find First CCE），UE就知道DCI可能放在哪（Bli

14、nd 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）（见

15、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数

16、。 至此，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 1

17、A或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来搜索。当

18、按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扰

19、码的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的

20、控制信息。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节可以看出，在某种传输模式或状态下（如随机接