phich讲解.docx

phich讲解.docx

《phich讲解.docx》由会员分享，可在线阅读，更多相关《phich讲解.docx（8页珍藏版）》请在冰豆网上搜索。

phich讲解

PHICH

     PHICH用于对PUSCH传输的数据回应HARQACK/NACK。

每个TTI中的每个上行TB对应一个PHICH，也就是说，当UE在某小区配置了上行空分复用时，需要2个PHICH。

一、PHICH资源介绍

     小区是通过MasterInformationBlock的phich-Config字段来配置PHICH的。

图1：

PHICH-Config

    Phich-Duration指定了是使用controlregion中的1个symbol还是3（或2）个symbol来发送PHICH，对应36.211的Table6.9.3-1。

     通常会配置只使用第一个OFDMsymbol来发送PHICH，这样即使PCFICH解码失败了，也不影响PHICH的解码。

但在某些场景下，比如系统带宽较小的小区（如1.4MHz，总共只有6个RB），其频域分集的增益要比系统带宽较大的小区（如20MHz）的小区要低。

通过使用extendedPHICHduration，能提高时间分集的增益，从而提高PHICH的性能。

    注：

TDD中，PSS随着子帧1和6的第三个symbol传输（在DwPTS中），所以在extendedPHICHduration下，只能使用2个symbol来发送PHICH。

     PHICHduration的配置限制了CFI取值范围的下限，也就是说，限制了controlregion至少需要占用的symbol数。

对于下行系统带宽

的小区而言，如果配置了extendedPHICHduration，UE会认为CFI的值等于PHICHduration，此时UE可以忽略PCFICH的值；对于下行系统带宽

的小区而言，由于CFI指定的可用于controlregion的symbol数可以为4（见36.212的5.3.4节），大于PHICHduration可配置的最大值3，如果此时配置了extendedPHICHduration，UE还是要使用PCFICH指定的配置。

即“CFI和extendedPHICHduration相比较，取其大者”。

（见36.213的9.1.3节和[1]）

    phich-Resource指定了controlregion中预留给PHICH的资源数，它决定了PHICHgroup的数目。

     多个PHICH可以映射到相同的RE集合中发送，这些PHICH组成了一个PHICHgroup，即多个PHICH可以复用到同一个PHICHgroup中。

同一个PHICHgroup中的PHICH通过不同的orthogonalsequence来区分。

即一个二元组

唯一指定一个PHICH资源，其中

为PHICHgroup索引，

为该PHICHgroup内的orthogonalsequence索引。

     一个小区内可用的PHICHgroup数的计算方式如图2所示。

图2：

如何计算PHICHgroup的个数

     注意：

的场景只出现在TDD0这种配置下，此时对应子帧所需的PHICHgroup数量是

时的2倍。

这是因为只有在TDD0配置下，一个系统帧内的下行子帧数少于上行子帧数，此时同一个下行子帧可能需要反馈2个上行子帧的ACK/NACK信息，所以需要2倍的PHICH资源。

     从图2可以看出：

对于FDD而言，PHICHgroup数仅与phich-Resource的配置相关；而对于TDD而言，PHICHgroup数不仅与phich-Resource的配置相关，还与uplink-downlinkconfiguration以及子帧号相关。

越大，可复用的UE数越多，支持调度的上行UE数也就越多，但码间干扰也就越大，解调性能也就越差。

与此同时，controlregion内可用于PDCCH的资源数就越少。

     一个PHICHgroup可用的orthogonalsequence数见36.211的Table6.9.1-2。

可以看出，对NormalCP而言，一个PHICHgroup支持8个orthogonalsequence，即支持8个PHICH复用；对ExtendedCP而言，一个PHICHgroup支持4个orthogonalsequence，即支持4个PHICH复用。

     通过上面的介绍，我们可以计算出一个小区在某个下行子帧所包含的PHICH资源数：

对应NormalCP，其值为

；对应ExtendedCP，其值为

。

（我们可以认为：

在FDD下，

）

     一个小区真正所需的PHICH资源总数取决于：

（1）系统带宽；

（2）每个TTI能够调度的上行UE数（只有被调度的上行UE才需要PHICH）；

（2）UE是否支持空分复用（2个上行TB就对应2个PHICH）等。

     PHICH配置必须在MIB中发送的原因在于：

SIB是在PDSCH中发送的，PDSCH资源是通过PDCCH来指示的，PDCCH的盲检又与PHICH资源数的配置相关（详见《LTE：

CCE介绍》系列），因此UE需要提前知道PHICH配置以便成功解码SIB。

     对于FDD而言，接收到MIB就可以计算出预留给PHICH的资源。

     对于TDD而言，UE仅仅接收到MIB是不够的，UE还需要知道uplink-downlinkconfiguration和子帧号。

通过小区搜索过程，UE已经知道了当前子帧号（见《LTE：

小区搜索过程（cell search procedure）》）；而UE需要接收到SIB1后，通过SystemInformationBlockType1的tdd-Config的subframeAssignment字段才能知道uplink-downlinkconfiguration。

问题来了：

SIB1在PDSCH中发送，需要先解码PDCCH，且PDCCH的解码与PHICH资源数的计算相关；而PHICH资源数的计算又依赖于SIB1中指定的uplink-downlinkconfiguration，这就形成了死锁。

解决的方法是，UE在接收SIB1时，会使用不同的

值（0~2，见图2）去尝试盲检，直到成功解码出SIB1为止，从而得到uplink-downlinkconfiguration。

二、PHICH物理层处理

     每个HARQ确认信息（1bit：

对应一个上行TB）先重复3遍（见36.212的5.3.5节），接着使用BPSK调制和使用一个长为4（对于ExtendedCP而言，长为2）的orthogonalsequence进行扩频，再使用小区特定的搅扰序列进行加扰后，就得到12个加扰symbol（见36.211的6.9.1节）。

     多个PHICH映射同一个PHICHgroup时，是将多个PHICH的映射到同一个RE的symbol相加来实现的。

（对应36.211的6.9.3节中的公式

）

     每个PHICHgroup会映射到3个REG中，这3个REG是分开的，彼此间隔1/3下行系统带宽。

12个symbol如何映射到对应的REG、层匹配、预编码、以及如何映射到RE，详见36.211的6.9.2节和6.9.3节。

图3：

PHICH结构

     在controlregion的第一个OFDMsymbol，资源首先会分配给PCFICH，PHICH只能映射到没有被PCFICH使用的那些RE上。

同一个PHICHgroup中的所有PHICH映射到相同的RE集合上；不同的PHICHgroup使用的RE集合是不同的。

PHICH：

物理混合重传指示信道（PhysicalHybrid-ARQIndicatorChannel）

参考：

下行ThePhysicalHybrid-ARQIndicatorChannel（PHICH）承载上行数据传输的HybridARQ确认信息，位于每个子帧的第一个OFDM符号上（注：

FDD为基础，在正常的PHICH周期）。

PHICH在多个REG上传输（resourceElementGroup），多个PHICH可以分享一组REG，由正交数组区分。

同一个资源上的PHICH称为一个PHICH组，一个单独的PHICH由两个参数决定：

PHICH组号，组内的正交序列号。

一个PHICH需要多少REG？

计算方式简单明了。

ACK是111，NACK是000，都是3比特，PHICH使用BPSK调制，每个ACK/NACK需要3个调制符号。

然后这3个调制符号用正交码复用，选用扩频因子为4的常规循环前缀，得到12个符号。

每个REG包含4个RE（resourceelement），每个RE承载一个调制符号，所以一个单独的PHICH需要3个REG。

下图显示了PHICH是如何映射到物理资源上的，用到三个PHICH组。

3个REG用于支持PHICH组，他们均匀的分布在系统带宽上，以备频率分集。

（图中第一个符号也包含PCFICH（PhysicalControlFormatIndicatorChannel）信息，无论系统带宽多少PCFICH总是占用4个REG，均匀的分布在系统带宽中。

）

每个PHICH组可以包含几个PHICH？

（3GPPTS36.211Table6.9.1-2）定义了8个正交序列，所以每组可以最多携带8个PHICH。

系统能支持多少PHICH？

结果跟具体的帧结构相关。

PHICH的数量由下行系统带宽和参数Ng决定，这两个参数都在MIB消息中广播（MasterInformationBlock）。

计算公式是在3GPPTS36.211章节6.9中定义的。

假设下行带宽是10HMz，Ng=1则可供使用的PHICH组有7个，PHICH的总数是7个PHICH组x每组8个PHICH共计56个PHICH。

需要的RE（resourceelements）数是7PHICH组x每组需要3个REGx4个RE每REG，共计84个RE。

上行数据传输的HARQACK/NACK装在每个PHICH中，用户怎么知道查哪个PHICH找自己的ACK/NACK信息呢？

在时域，上行数据传输发生在子帧#n，相应的PHICH就会出现在子帧#n+4。

频域上，它由上行资源分配的DCIformat0指示，PHICH（组号和组内的正交序列号）是由上行传输第一个时隙上最低的PRBindex和DMRS循环前缀决定的，具体算法参见3GPPTS36.213章节9.1.2.。

为什么MIB中要有Ng?

为什么不把它放在SIB系统消息里？

这就是鸡生蛋/蛋生鸡的问题，UE在系统消息获取阶段就要知道PHICH配置。

一方面，UE解码PDCCH以获取SIB在PDSCH上的位置；另一方面，PDCCH、PHICH、PCFICH共享子帧中控制单元的资源，可用的PDCCH资源数取决于PHICH的配置（PCFICH资源已知且固定）。