转自:http://blog.sina.com.cn/s/blog_927cff0101017tew.html
三、UE盲检过程:(见《3GEvolution》的16.4.8节)
DCI有多种format,但UE事先并不知道接收到的PDCCH携带的是什么format的DCI,因此UE必须盲检DCIformat。
![LTE:CCE介绍(三) LTE:CCE介绍(三)](https://i-blog.csdnimg.cn/blog_migrate/184a60cf07817e7ac2625b8096932198.jpeg)
第一步,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。
![LTE:CCE介绍(三) LTE:CCE介绍(三)](https://i-blog.csdnimg.cn/blog_migrate/54bad7cbf6d4db555db3cd2a7eb242ba.jpeg)
虽然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》