LTE 中的PDCCH盲检

来源:互联网 发布:vb while循环语句 编辑:程序博客网 时间:2024/06/08 09:23
 

PDCCH中承载的是各种各样的控制信息。由于系统部署和运行过程中的多样性,控制信息的内容也是非常多样的。为了简化起见,LTE中将DCI分成如下几种类型:

 LTE <wbr>中的PDCCH盲检

 

UE一般不知道当前PDCCH占用的CCE的数目大小,传送的是什么DCI format的信息,也不知道自己需要的信息在哪个位置。但是UE知道自己当前在期待什么信息,例如在Idle态UE期待的信息是paging, SI;发起Random Access后期待的是RACH Response;在有上行数据等待发送的时候期待UL Grant等。对于不同的期望信息UE用相应的X-RNTI去和CCE信息做CRC校验,如果CRC校验成功,那么UE就知道这个信息是自己需要的,也可以进一步知道相应的DCI format,调制方式,从而解出DCI内容。这就是所谓的盲检过程。

如果UE按照CCE的顺序依次搜索过去,那么UE侧的计算量是相当可观的,尤其是对于带宽比较大,CCE数目比较多的系统。为此协议中定义了搜索空间的概念,对系统中不同格式的PDCCH可能的摆放位置进行了一些限制,降低了UE进行盲检的复杂度。每个不同格式的PDCCH,对应不同的搜索空间。前面我们已经提到过,对于CCE数目为N的PDCCH,其起始位置的CCE号必须是N的整数倍。而且对于不同大小的PDCCH,其搜索空间的大小(定义为搜索需要覆盖的CCE数目,也就是可能的搜索位置数目与PDCCH格式对应的CCE数目之积)并不相同。更进一步,LTE中还划分了公共搜索空间(Common Search Space)和UE特定搜索空间(UE-Specific Search Space)。如下图所示:

 

类型

PDCCH类型[in CCEs]

搜索空间大小 [in CCEs]

可能的PDCCH数目

UE-specific

1

6

6

2

12

6

4

8

2

8

16

2

Common

4

16

4

8

16

2

 

所谓公共搜索区间是指所有UE都需要监听的区间,通常用来发送寻呼,RAR,系统消息,以及部分UE公用的上行功率控制消息等。公共搜索区间占据从0开始到最大数目为16的CCE,公共搜索区间内的PDCCH只有4CCE和8CCE两种类型的大小,UE需要在公共搜索区间内,从0开始,按CCE粒度为8进行搜索2次,按CCE粒度为4搜索4次,至多需要进行6次PDCCH的搜索。

LTE系统中,可用于PDCCH的CCE数目取决于系统带宽,PHICH配置,天线端口数,PCFICH配置等。上述因素确定后,PDCCH的CCE数目就可以确定,公共搜索区间就可以随之确定,从0开始占据至多16个CCE。公共搜索区间不随子帧的变化而变化。UE特定的搜索区间则不同,UE特定的搜索空间的起始点取决于UE的ID(C-RNTI),子帧号,以及PDCCH的类型,因而,随着子帧的不同,UE特定的搜索空间也有所不同。而且UE特定的搜索空间和公共的搜索空间有可能是重叠的。对于大小为N的PDCCH,在某一子帧内,对应某UE的特定搜索区间的起点就可以确定(起点可能落入公共搜索区间的范围内),UE从起始位置开始,依次进行对应大小PDCCH的盲检(也就是满足大小为N的PDCCH,其起始点的CCE号必须为N的整数倍),至多进行的盲检数目如上图所示,此时如果到了CCE的末端,UE特定的搜索空间有可能从CCE 0 开始,继续进行。从上图还可以看到,在UE特定的搜索区间内,UE需要进行的搜索次数至多为16。

对于公共搜索区间和UE特定搜索区间重叠的情形,如果UE已经在公共搜索区间成功检测,那么UE可以跳过重叠部分对应的特定搜索区间。

UE在PDCCH搜索空间进行盲检时,只需对可能出现的DCI进行尝试解码,并不需要对所有的DCI格式进行匹配。UE进行PDCCH盲检的总次数不超过44次。