LTE下行物理层传输机制(4)-CCE

在之前的博文中已经讲到,小区专用参考信号的基本映射单位是RE(参考博文《LTE下行物理层传输机制(1)-天线端口Antenna Port和小区特定参考信号CRS》),PCFICH信道的基本映射单位是REG(参考博文《LTE下行物理层传输机制(2)-PCFICH信道和资源组REG》),PHICH信道的基本映射单位也是REG(参考博文《LTE下行物理层传输机制(3)-PHICH信道》),而本文所提到的PDCCH信道,它的基本映射单位则是CCE

1.CCE的组成

CCE,全称Control Channel Elements,是PDCCH(physical downlink control channel)信道的基本组成单位,每个CCE由9个REG组成(参考下文中的示意图)。CCE只用作PDCCH信道的映射,不用于小区参考信号、PCFICH信道和PHICH信道的映射,因此,组成CCE的REG或RE是包括小区参考信号、PCFICH信道和PHICH信道等已经占用的RE或REG的

如果用N_REG变量来表示除去PCFICH、PHICH信道占用之后还剩下的REG个数,那么每个下行子帧CCE的个数N_CCE=floor(N_REG/9)。比如某个子帧控制区域总的REG个数等于88,其中PCFICH信道占了4个REG,PHICH信道占了6个REG,那么用于PDCCH的CCE个数=(88-4-6)/9=8.67=8个(向下取整)。

2.CCE的REG在物理上不连续

组成一个PDCCH信道的CCE个数,一般称为聚合等级aggregation level )。聚合等级有4种值,分别是CCE_lv=1、2、4、8,即如果某个PDCCH信道的聚合等级CCE_lv=4,则意味着该PDCCH信道由4个索引连续的CCE组成。这里所谓的“索引连续”是指逻辑意义上的连续,而不是物理REG上的连续,如下图所示。



上图列出了6个PDCCH信道,分别是:

CCE索引为0的CCE组成了一个聚合等级=1的PDCCH信道;CCE索引为2-3的CCE组成了一个聚合等级=2的PDCCH信道;CCE索引为16-17的CCE组成了一个聚合等级=2的PDCCH信道;CCE索引为4-7的CCE组成了一个聚合等级=4的PDCCH信道;CCE索引为20-23的CCE组成了一个聚合等级=4的PDCCH信道;CCE索引为8-15的CCE组成了一个聚合等级=8的PDCCH信道。

这些组成PDCCH信道的CCE,它的索引在逻辑上是连续的,但是单独展开某个特定的CCE,如上图中的CCE_index=8的CCE,组成它的9个REG在物理资源上并不是连续的,这9个REG可以分布在时域上的3个OFDM符号中。每个CCE与它的REG的映射关系,可以参考36211协议中的相关公式。因此,控制区域中PCFICH信道、PHICH信道、PDCCH信道的位置可能如下图所示。

这这个例子中,eNB首先为参考信号预留RE,然后为PCFICH分配4个REG,再为PHICH分配3个REG,最后剩余的REG组成相应的CCE,映射到2个不同的PDCCH信道中:CCE0和CCE1组成PDCCH信道1,因此PDCCH信道1的聚合等级是2;CCE4组成PDCCH信道2,因此PDCCH信道2的聚合等级是1。


一般来说,eNB侧的MAC层负责PDCCH信道的CCE聚合等级和起始位置索引的调度分配,而物理层则负责CCE位置到物理REG的映射。

3.CCE的盲检测和搜索空间

如前文所示,在LTE里,每个PDCCH信道会映射到不同聚合等级(或不同个数)的CCE中。在标识PDCCH信道的时候,除了使用聚合等级这个参数外,还需要CCE的起始位置索引这个参数。由于下行或上行资源的动态调度是在eNB侧进行的,聚合等级和起始位置都由eNB侧分配,因此在某个下行子帧里,终端事先无法确切的知道PDCCH占用的CCE的聚合等级是多少,以及CCE的起始位置索引在哪里。所以,对于终端来说,每次都是通过盲检测来获取PDCCH信道即CCE的位置的,而盲检测所消耗的时间是比较多的,因此协议也做了一些降低盲检测时间的约定:

(1)对于聚合等级,前文已经有描述,协议只约定了4种CCE聚合等级,即1、2、4、8,降低了盲检的可能性。

(2)对于不同的搜索空间(search space),允许使用的CCE聚合等级不同,候选位置(Number of PDCCH candidates)也是有限的,具体见下表所示。


对于UE专用空间(UE-specific search space),可以使用1、2、4、8这四种聚合等级,而在公共空间(common search spaces),综合考虑抗干扰和盲检测处理时间,只使用4、8这两种聚合等级。

CCE聚合等级最大是8,而可以使用的CCE总个数有可能比较多,比如可用CCE总个数N_CCE可以等于88这种值,因此聚合等级为8的PDCCH信道在CCE可用个数为88的控制区域中,存在着很多的可能性位置,这些可能的位置,我们称之为“候选位置集(set of PDCCH candidates)”。为了降低终端的盲检测时间,这些“候选位置”个数也是有限的,如上表所示,比如在公共搜索空间中,聚合等级为8的PDCCH信道,候选的位置只有2个。如果终端在所有的候选位置经过盲检测,都没有找到PDCCH信道,则退出该盲检侧过程。CCE候选位置在CCE空间中的位置如下图所示。

组成PDCCH信道的所有候选位置的每个CCE位置,都可以通过下面的公式计算得出(图中有个错误,应该是i的取值范围,而不是m的取值范围,感谢傲天-18)。从公式中可以看到,某个PDCCH信道的所有候选位置的CCE位置,与该PDCCH信道的聚合等级、搜索空间类型、子帧号、可用CCE总个数、RNTI等参数有关


比如,某个PDCCH信道的聚合等级是4、属于公共空间、N_CCE=88、子帧号=0,从上文的表Table9.1.1-1中可以看到,此PDCCH信道的候选位置有4个,因此可以得到参数:L=4,Yk=0,m=0~3,N_CCE=88,i=0~3。通过上面的公式可以计算得到:

PDCCH候选位置1的CCE位置(m=0时的情况):第一个CCE位置:4*[0 mod (88/4)]+0=0;第二个CCE位置:4*[0 mod (88/4)]+1=1;第三个CCE位置:4*[0 mod (88/4)]+2=2;第四个CCE位置:4*[0 mod (88/4)]+3=3

PDCCH候选位置2的CCE位置(m=1时的情况):第一个CCE位置:4*[1 mod (88/4)]+0=4;第二个CCE位置:4*[1 mod (88/4)]+1=5;第三个CCE位置:4*[1 mod (88/4)]+2=6;第四个CCE位置:4*[1 mod (88/4)]+3=7

PDCCH候选位置3的CCE位置(m=2时的情况):第一个CCE位置:4*[2 mod (88/4)]+0=8;第二个CCE位置:4*[2 mod (88/4)]+1=9;第三个CCE位置:4*[2 mod (88/4)]+2=10;第四个CCE位置:4*[2 mod (88/4)]+3=11

PDCCH候选位置4的CCE位置(m=3时的情况):第一个CCE位置:4*[3 mod (88/4)]+0=12;第二个CCE位置:4*[3 mod (88/4)]+1=13;第三个CCE位置:4*[3 mod (88/4)]+2=14;第四个CCE位置:4*[3 mod (88/4)]+3=15

需要注意的是,根据上面的公式可以得到,公共空间的CCE范围是0~15,但UE专用空间的范围也可以落在0~15中,因此公共搜索空间和UE专用搜索空间是可以互相重叠的在同个子帧时刻,一旦某个CCE已经被分配,则不能再分配给其他用户。以下图为例,在同个子帧,如果终端A分配的CCE范围是16~23,那么eNB就不能给终端B分配16~23这个范围的CCE。


正是由于在相同子帧里CCE位置的不可复用,或者说独占性,因此当小区中有多个UE需要传输数据,此时即便RB资源足够多,也可能会因PDCCH信道的CCE位置冲突而导致无法调度某个或某些UE。比如说,某个系统的业务总流量可以达到Pbps,现有10个UE进行数据传输业务,每个UE的业务量占用的RB均较少,此时10个UE总的流量记为Mbps,可能就会有M<P的情况出现。

对于SIB、寻呼、RAR、TPC、集群组呼这些共享信道对应的PDCCH,需要在公共空间进行CCE的调度,其它的则在UE专用的搜索空间中调度。

(3)对于CCE起始位置索引,协议规定,某个PDCCH信道的起始位置索引,必须能整除CCE聚合等级。比如某个PDCCH信道的CCE聚合等级是4,那么这个PDCCH信道的CCE起始位置索引可能是0、4、8、...等等,不能是2、3、5这种不能整除4的值。如下图所示。


参考文献:

(1)3GPP TS 36.211 V9.1.0 (2010-03) Physical Channels and Modulation

(2)http://lteuniversity.com/get_trained/expert_opinion1/b/hongyanlei/archive/2011/05/20/pdcch-construction.aspx

(3)3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

(4)《4G LTE/LTE-Advanced for Mobile Broadband》

(5)http://www.sharetechnote.com/html/Handbook_LTE_ResourceAllocation_ManagementUnit.html

猜你喜欢

转载自blog.csdn.net/m_052148/article/details/51594861