CCE（3）

转自：http://blog.sina.com.cn/s/blog_927cff0101017tew.html

三、UE盲检过程：（见《3GEvolution》的16.4.8节）

       DCI有多种format，但UE事先并不知道接收到的PDCCH携带的是什么format的DCI，因此UE必须盲检DCIformat。

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

       UE通过PSS/SSS，确定了物理层cellID和frametiming（说得通俗一点，就是subframe number#0所在的位置，但此时还不知道system framenumber）（见《3GEvolution》的18.1节）。因为cell-specificreference signal（RS）以及frequencyshift（指定RS的位置）与物理层cellID一一对应，所以间接确定了cell-specificreference signal及其在RB中的位置（见《3GEvolution》的16.3节）。

       接着就可以进行信道估计并进一步解调PBCH，从而获取system framenumber、PHICH占用的资源分布和天线端口数（见《3GEvolution》的18.2.1节）。再通过解调PCFICH获取CFI，就知道了controlregion占用的symbol数。

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

       第二步，盲检DCI。

       虽然UE事先并不知道接收到的PDCCH携带的是什么format的DCI，也不知道需要的信息在哪个位置，但UE知道自己处于何种状态以及在该状态下期待收到的DCI信息。例如在IDLE态时UE期待收到PagingSI；在发起RandomAccess后UE期待的是RACHResponse；在有上行数据待发送时期待ULGrant；在TM3模式下期待format 1A或format 2A的DCI等。

       UE知道自己的SearchSpace，因此知道DCI可能分布在哪些CCE上。对于不同的期望信息，UE用相应的X-RNTI与属于自己的SearchSpace内的CCE做CRC校验，如果CRC校验成功，那么UE就知道这个信息是自己需要的，也知道相应的DCIformat和调制方式，从而进一步解出DCI内容。

        UE一般不知道应该使用哪种AggregationLevel，所以UE会把所有可能性都尝试一遍。例如对于CommonSearch Space，UE需要分别按AggregationLevel = 4和AggregationLevel = 8来搜索。当按AL=4搜索时，16个CCE需要搜索4次，也就是有4个ControlChannel Candidates；当按AL=8搜索时，16个CCE需要搜索2次，也就是有2个CCHCandidates；那么对于公共空间一共有4+2=6个CCHCandidates。

       UE在PDCCHSearch Space进行盲检时，只需对可能出现的DCIformat进行尝试解码，并不需要对所有的DCIformat进行匹配。可能出现的DCIformat取决于UE期望接收什么信息以及传输模式（见36.213的7.1节和8.0节）。例如：如果UE期待接收DL-SCH并使用传输模式1，当UE对使用C-RNTI扰码的PDCCH进行解码时，只会对DCIformat 1A和DCIformat 1进行尝试解码。如果同时该UE期望在该子帧内接收ULGrant，则会使用DCIformat 0进行尝试解码。

       Common Search Space是所有UE都需要监听的空间，通常用来发送与SystemInformation、PagingMessage、RAR以及power-controlcommands for a group of UEs等相关的控制信息。但是当UE-SpecificSearch Space没有足够的可用资源时，CommonSearch Space也可以用于传输属于某个特定UE的控制信息。CommonSearch Space只能使用最小的DCIformat 0/1A/3/3A/1C。

       Common Search Space和UE-specificsearch space可能重叠，属于不同UE的UE-specificsearch space也可能重叠。如果重叠的区域被一个UE占用，那么其它UE将不能再使用这些CCE资源。

       在成功解码PDCCH之前，UE会在每一个可能的PDCCHcandidate上尝试解码。一旦解码成功则停止解码过程。

【问题】

       （1）为什么UE进行PDCCH盲检的总次数不超过44次？

       从36.213的Table9.1.1-1可以看出，对于某种DCIformat进行盲检时，可能的candidate有22个。

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

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

       需要注意的是，在一个下行子帧内，UE实际盲检的次数可能超过44次。如果在一个下行子帧内，UE期望同时接收下行数据、ULGrant和系统信息。则对每一种信息，都会使用对应的X-RNTI在SearchSpace内对相应的DCIformat尝试解调。

 

【Reference】

[1]      《3GEvolution HSPA and LTE for Mobile Broadband, 2nd》

[2]      《4GLTE/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 layerprocedures".           V10.3.0

[5]       3GPP TS36.321, “Evolved Universal Terrestrial Radio Access(E-UTRA); Medium Access Control (MAC) protocol specification”V10.3.0

[6]       《PDCCH Construction》