LTE PUCCH

LTE中的PDCCH(转载) 
PDCCH中承载的是DCI(Downlink Control Information),包含一个或多个UE上的资源分配和其他的控制信息。在LTE中上下行的资源调度信息(MCS, Resource allocation等等的信息)都是由PDCCH来承载的。一般来说,在一个子帧内,可以有多个PDCCH。UE需要首先解调PDCCH中的DCI,然后才能够在相应的资源位置上解调属于UE自己的PDSCH(包括广播消息,寻呼,UE的数据等) 
前面提到过,LTE中PDCCH在一个子帧内(注意,不是时系)占用的符号个数,是由PCFICH中定义的CFI所确定的。UE通过主,辅同步信道,确定了小区的物理ID PCI,通过读取PBCH,确定了PHICH占用的资源分布,系统的天线端口等内容。UE就可以进一步读取PCFICH,了解PDCCH等控制信道所占用的符号数目。在PDCCH所占用的符号中,除了PDCCH,还包含有PCFICH,PHICH,RS等内容。其中PCFICH的内容已经解调,PHICH的分布由PBCH确定,RS的分布取决于PBCH中广播的天线端口数目。至此,(全部的)PDCCH在一个子帧内所能够占用的RE就得以确定了。 
由于PDCCH的传输带宽内可以同时包含多个PDCCH,为了更有效地配置 PDCCH和其他下行控制信道的时频资源,LTE定义了两个专用的控制信道资源单位:RE组(RE Group,REG)和控制信道单元(Control Channel Element,CCE)。1个REG由位于同一OFDM符号上的4个或6个相邻的RE组成,但其中可用的RE数目只有4个,6个RE组成的REG中包含了两个参考信号,而参考信号RS所占用的RE是不能被控制信道的REG使用的。协议中(36.211)还特别规定,对于只有一个小区专用参考信号的情况,从REG中RE映射的角度,要假定存在两个天线端口,所以存在一个REG中包含4个或6个RE两种情况。一个CCE由9个REG构成。定义REG这样的资源单位,主要是为了有效地支持 PCFICH、PHICH等数据率很小的控制信道的资源分配,也就是说,PCFICH,PHICH的资源分配是以REG为单位的;而定义相对较大的CCE,是为了用于数据量相对较大的PDCCH的资源分配。 

PDCCH在一个或多个连续的CCE上传输, LTE中支持4中不同类型的PDCCH,如下图所示


LTE中,CCE的编号和分配是连续的。如果系统分配了PCFICH和PHICH后剩余REG的数量为NREG,那么PDCCH可用的CCE的数目为NCCE=NREG/9向下取整。CCE的编号为从0开始到NCCE-1。 
PDCCH所占用的CCE数目取决于UE所处的下行信道环境,对于下行信道环境好的UE,eNodeB可能只需分配一个CCE,对于下行信道环境较差的UE,eNodeB可能需要为之分配多达8个的CCE。为了简化UE在解码PDCCH时的复杂度,LTE中还规定CCE数目为N的PDCCH,其起始位置的CCE号,必须是N的整数倍。 
每个PDCCH中,包含16bit的CRC校验,UE用来验证接收到的PDCCH是否正确,并且CRC使用和UE相关的Identity进行扰码,使得UE能够确定哪些PDCCH是自己需要接收的,哪些是发送给其他UE的。可以同来进行扰码的UE Identity包括有:C-RNTI, SPS-RNTI,以及公用的SI-RNTI, P-RNTI和RA-RNTI等。 每个PDCCH,经过CRC校验后,进行TBCC信道编码和速率匹配。eNodeB可以根据UE上报上来的CQI(Channel Quality Indicator)进行速率匹配。此时,对于每个PDCCH,就可以确定其占用的CCE数目的大小。 
前面已经提到过,可用的CCE的编号是从0到NCCE-1。可以将CCE看作是逻辑的资源,顺序排列,为所有的PDCCH所共享。eNodeB 根据每个PDCCH上CCE起始位置的限制,将每个PDCCH放置在合适的位置。这时可能出现有的CCE没有被占用的情况,标准中规定需要插入NIL,NIL对应的RE上面的发送功率为-Inf,也就是0。 
 
此后,CCE上的数据比特经过于小区物理ID相关的扰码,QPSK调制,层映射和预编码,所得到的符号按照四元组为单位(Symbol Quadruplet,每个四元组映射到一个REG上)进行交织和循环移位,最后映射到相应的物理资源REG上去。 
物理资源REG首先分配给PCFICH和PHICH,剩余的分配给PDCCH,按照先时域后频域的原则进行REG的映射。这样做的目的是为了避免PDCCH符号之间的不均衡。 1、一个子帧中可以传好几个PDCCH。这里的所谓的一个PDCCH指的是一个DCI,它有相应的format,加了16bit的CRC,然后用记加扰X-RNTI,然后tail biting,rate match出来一个比特序列。 
一个PDCCH按长度来分有4中format,分别对应1、2、4、8个CCE。一个DCI信息占用多少个CCE是eNB端根据UE的下行信道质量决定的,信道条件好就传较短的PDCCH,差就传长的。    
2、好几个PDCCh复用,就是把上述的bit连起来。 b1(0),b1(1),...,b1(M1),b2(0),b2(1).....如此下去 参见下图


上述的复用,其实是各个PDCCH到reg number这个虚拟资源的映射,中间可能会有inf(零)。  
1、PDCCH的整个流程简述,其实前面已经写过,只是现在觉得不透彻
 
各路DCI的CRC Attachment(通常也有人管一个DCI叫做一个PDCCH) ----》 RNTI加扰(神马类型的RNTI取决于UE现在想干什么,需要什么,或者说取决于DCI传的是什么) ----》 TailBiting Convolutional Encoder ----》RateMach ----》PDCCH复用  (之后插入NIL)----》比特加扰  ---》 QPSK调制 ---》 LayerMapping & Precoding ----》 交织 ---》小区间相关加扰(就一个循环移位) ---》 资源映射。 
2、关于NIL的插入。由于PDCCH占用的是除了CRS,PCFICH,PHICH之外的REG,其数目可以记为Nreg,但是PDCCH资源分配的单位是CCE,是9个REG。所以 Ncce = floor(Nreg/9),那这些个不能被整除的REG就要用NIL来填充,其实就是-Inf,也就是0。在PDCCH复用的时候在尾部插入。 
还有就是为了满足PDCCH的聚合等级对齐,也要插入NIL,这些个东西都是复用模块该搞定的问题。 
一般的DCI都30来个bit,可是一个CCE可以传72bit,而一个PDCCH占几个CCE是MAC告诉PHY的,也就是说这个问题是通过RateMatch来解决的。总之,PDCCH是把除了除了CRS,PCFICH,PHICH之外的资源占光的,这个很合理,留了也没用。 
3、关于PDCCH盲检测的搜索空间,公共的不用说,UE Specify的搜索空间36.213里面有详细的讨论,它的M(L)个candidates对应m从0到M(L)-1.期间Yk对一个子帧的PDCCH来说是个定值。 
4、从交织器读出来的调制symbol数目占光所有的RE,复用其实已经相当于把DCI和逻辑的CCE number对应上了,后面资源映射,先时域后频域

你可能感兴趣的:(C/C++,通信,LTE-4G)