LTE中PDCCH支持的四种格式是代表什么含义

发布网友 发布时间：2022-04-18 14:42

我来回答

共2个回答

懂视网 时间：2022-04-18 19:04

pdsch信道格式有六种。其中， format 2a，format 2b只支持正常的CP。对于同一个UE，在一个子帧内不能同时传输PUCCH和PUSCH，在一个子帧中预留给PUCCH的资源块是半静态配置的。在同一子帧内，PUCCH前后两个时系的PRB资源分别位于可用的频谱资源的两端。将PUCCH放在可用资源的两端，将中间的整块频谱资源用来传送PUSCH，有利于既能有效的利用频谱资源又能保持上行传输的单载波特性。同时，可以较好地获得PUCCH不同时系之间的频率分集增益。

　　LTE物理下行信道中的一种，是LTE承载主要用户数据的下行链路通道，所有的用户数据都可以使用，还包括没有在PBCH中传输的系统广播消息和寻呼消息-LTE中没有特定的物理层寻呼信道。

热心网友 时间：2022-04-18 16:12

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，如下图所示：

PDCCH format
Number of CCEs
Number of resource-element groups
Number of PDCCH bits

0
1
9
72

1
2
18
144

2
4
36
288

3
8
72
576

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).....如此下去

参见下图：

4bbcda6d494c2781a0a5a.jpg (32.02 KB)
2011-12-27 13:15

上述的复用，其实是各个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对应上了，后面资源映射，先时域后频域。详见http://bbs.c114.net/viewthread.php?tid=585503