PHICH.docx_第1页
PHICH.docx_第2页
PHICH.docx_第3页
PHICH.docx_第4页
PHICH.docx_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

PHICHPHICH用于对PUSCH传输的数据回应HARQ ACK/NACK。每个TTI中的每个上行TB对应一个PHICH,也就是说,当UE在某小区配置了上行空分复用时,需要2个PHICH。一、PHICH资源介绍小区是通过MasterInformationBlock的phich-Config字段来配置PHICH的。图1:PHICH-ConfigPhich-Duration指定了是使用control region中的1个symbol还是3(或2)个symbol来发送PHICH,对应36.211的Table 6.9.3-1。通常会配置只使用第一个OFDM symbol来发送PHICH,这样即使PCFICH解码失败了,也不影响PHICH的解码。但在某些场景下,比如系统带宽较小的小区(如1.4MHz,总共只有6个RB),其频域分集的增益要比系统带宽较大的小区(如20MHz)的小区要低。通过使用extended PHICH duration,能提高时间分集的增益,从而提高PHICH的性能。注:TDD中,PSS随着子帧1和6的第三个symbol传输(在DwPTS中),所以在extended PHICH duration下,只能使用2个symbol来发送PHICH。PHICH duration的配置限制了CFI取值范围的下限,也就是说,限制了control region至少需要占用的symbol数。对于下行系统带宽的小区而言,如果配置了extended PHICH duration,UE会认为CFI的值等于PHICH duration,此时UE可以忽略PCFICH的值;对于下行系统带宽的小区而言,由于CFI指定的可用于control region的symbol数可以为4(见36.212的5.3.4节),大于PHICH duration可配置的最大值3,如果此时配置了extended PHICH duration,UE还是要使用PCFICH指定的配置。即“CFI和extended PHICH duration相比较,取其大者”。(见36.213的9.1.3节和1)phich-Resource指定了control region中预留给PHICH的资源数,它决定了PHICH group的数目。多个PHICH可以映射到相同的RE集合中发送,这些PHICH组成了一个PHICH group,即多个PHICH可以复用到同一个PHICH group中。同一个PHICH group中的PHICH通过不同的orthogonal sequence来区分。即一个二元组唯一指定一个PHICH资源,其中为PHICH group索引,为该PHICH group内的orthogonal sequence索引。一个小区内可用的PHICH group数的计算方式如图2所示。图2:如何计算PHICH group的个数注意:的场景只出现在TDD 0这种配置下,此时对应子帧所需的PHICH group数量是时的2倍。这是因为只有在TDD 0配置下,一个系统帧内的下行子帧数少于上行子帧数,此时同一个下行子帧可能需要反馈2个上行子帧的ACK/NACK信息,所以需要2倍的PHICH资源。从图2可以看出:对于FDD而言,PHICH group数仅与phich-Resource的配置相关;而对于TDD而言,PHICH group数不仅与phich-Resource的配置相关,还与uplink-downlink configuration以及子帧号相关。越大,可复用的UE数越多,支持调度的上行UE数也就越多,但码间干扰也就越大,解调性能也就越差。与此同时,control region内可用于PDCCH的资源数就越少。一个PHICH group可用的orthogonal sequence数见36.211的Table 6.9.1-2。可以看出,对Normal CP而言,一个PHICH group支持8个orthogonal sequence,即支持8个PHICH复用;对Extended CP而言,一个PHICH group支持4个orthogonal sequence,即支持4个PHICH复用。通过上面的介绍,我们可以计算出一个小区在某个下行子帧所包含的PHICH资源数:对应Normal CP,其值为;对应Extended CP,其值为。(我们可以认为:在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-downlink configuration和子帧号。通过小区搜索过程,UE已经知道了当前子帧号(见LTE:小区搜索过程(cellsearchprocedure);而UE需要接收到SIB1后,通过SystemInformationBlockType1的tdd-Config的subframeAssignment字段才能知道uplink-downlink configuration。问题来了:SIB1在PDSCH中发送,需要先解码PDCCH,且PDCCH的解码与PHICH资源数的计算相关;而PHICH资源数的计算又依赖于SIB1中指定的uplink-downlink configuration,这就形成了死锁。解决的方法是,UE在接收SIB1时,会使用不同的值(02,见图2)去尝试盲检,直到成功解码出SIB1为止,从而得到uplink-downlink configuration。二、PHICH物理层处理每个HARQ确认信息(1 bit:对应一个上行TB)先重复3遍(见36.212的5.3.5节),接着使用BPSK调制和使用一个长为4(对于Extended CP而言,长为2)的orthogonal sequence进行扩频,再使用小区特定的搅扰序列进行加扰后,就得到12个加扰symbol(见36.211的6.9.1节)。多个PHICH映射同一个PHICH group时,是将多个PHICH的映射到同一个RE的symbol相加来实现的。(对应36.211的6.9.3节中的公式)每个PHICH group会映射到3个REG中,这3个REG是分开的,彼此间隔1/3下行系统带宽。12个symbol如何映射到对应的REG、层匹配、预编码、以及如何映射到RE,详见36.211的6.9.2节和6.9.3节。图3:PHICH结构在control region的第一个OFDM symbol,资源首先会分配给PCFICH,PHICH只能映射到没有被PCFICH使用的那些RE上。同一个PHICH group中的所有PHICH映射到相同的RE集合上;不同的PHICH group使用的RE集合是不同的。三、UE如何确定其使用的PHICH资源UE如何确定eNodeB使用哪个PHICH资源来回应其上行数据的ACK/NACK呢?在时域上,如果UE在子帧n发送PUSCH,则UE会在子帧检测对应的PHICH。对于FDD而言,总是等于4;对于TDD而言,是通过36.213的Table 9.1.2-1得到。在子帧绑定(subframe bundling)操作中,PHICH资源是与所有绑定在一起的子帧中的最后一个子帧相对应的。在确定了在哪个子帧上接收对应的PHICH后,UE需要确定所使用的PHICH资源,即确定二元组。该二元组与DCI 0指定的上行资源分配和DMRS cyclic shift相关,计算公式如下:其中,:DCI 0中有一个字段叫Cyclic shift for DM RS and OCC index(见36.212的5.3.3.1.1节),通过该字段查36.213的Table 9.1.2-2,就得到对应的值。当然,此DCI 0必须是最新的用于指示对应PHICH相关的TB所在的PUSCH资源的。如果同一TB没有相应的DCI 0,并且以下两个条件满足其一,的值将为0:同一TB的初始PUSCH传输是半静态调度的;同一TB的初始PUSCH传输是通过RAR调度的。:是用于PHICH调制的spreading factor的大小。对于Normal CP,其值为4;对于Extended CP,其值为2。(见36.211的6.9.1节):如果是PUSCH传输的第一个TB,其值为;如果是PUSCH传输的第二个TB,其值为。其中,为对应的PUSCH传输在第一个slot的最低PRB索引。:PHICH group的个数,见之前的介绍。:当TDD的uplink-downlink configuration为0且PUSCH在子帧4或9(对应回应ACK/NACK的下行子帧为0或5,其,此时2个不同的上行子帧发送的PUSCH需要在同一个下行子帧回应ACK/NACK)上发送时,其值为1;其它情况下,其值为0。还有就是,PHICH与PBCH使用相同的天线端口集合来发送。四、载波聚合对PHICH的影响在载波聚合中,PHICH与对应的上行PUSCH数据传输的UL Grant在同一个下行载波单元(Component Carrier,CC)上传输。这样做的原因在于异构网络的部署可能使得一些CC的control region受到较高的inter-cell干扰,这时候使用跨承载调度(cross-carrier scheduling)将某些CC的PDCCH(此时对应DCI 0)在信道质量较好的其它CC上发送,能提高了PDCCH的解码效率。假如将CC 1的DCI 0放在CC 2的control region上发送,可以认为CC 2的信道质量较好,这时把CC 1的PHICH也放在CC 2发送,相应地也能提高PHICH的解码效率。因此,当配置了跨承载调度时,一个下行CC可能需要携带多个上行CC的PHICH,从而增加了PHICH冲突的可能性(因为PHICH资源与对应PUSCH传输的起始PRB相关,多个上行CC可能使用相同的起始PRB)。为了降低冲突,可以将在相同下行CC的control region上传输的不同上行CC的DMRS的cyclic shift(即)配置成不同的值;与此同时,eNodeB调度器也可以在调度时为不同CC选择起始PRB不同的上行PUSCH资源。注:建议大家看看参考资料的几篇文章,对大家理解PHICH会有帮助的。【参考资料】14G LTE/LTE-Advanced for Mobile Broadband的10.4.2节2LTE - The UMTS Long Term Evolution, 2nd Edition的9.3.4节和28.3.1.3节3TS 36.211的6.9节HARQ indicator (HI)4TS 36.212的5.3.5节Physical hybrid ARQindicator channel5TS 36.213的9.1.2节PHICH Assignment Procedure6T

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论