917-上行传输异步HARQ.docx

《917-上行传输异步HARQ.docx》由会员分享，可在线阅读，更多相关《917-上行传输异步HARQ.docx（3页珍藏版）》请在优知文库上搜索。

1、上行传输异步HARQ对于ImSTTl缩短处理，支持通过SearChSPaCe回退到传统处理时间n+4,即处理时间n+3的DCl在PDCCH的USS中进行，处理时间n+4的DCl在PDCCH的CSS中进行。 对于PDSeH,n+3ImsTTI和n+4ImsTTl的HARQ进程是共享的 在n+3ImsTTIn+4ImsTTl之间共享可能的PUSCHHARQ进程上行的非PHICH异步HARQ用于InlSTTL处理时间缩短。对于FSl和FS2,需要在适用的DCl消息中定义位字段，以指示HARQprocessesID和RV。RV可以由2位的独立bit字段表示，或者在使用RV#1#3时，可以由5位的调制和

2、编码方案表示，但有一些限制。如果RV由独立的位字段指示，其中2位为DClformatO,则DClformatlA将增加填充位，以确保有效负载大小等于fonatO的大小。对于上行TM2,DCIformat4将增加4位以指示RV,因为每个TB需要一个RV字段。对于上行HARQprocessesID,FDD有6个上行HARQ进程编号，最小定时k=3。TDD的最大上行HARQprocesses数为7,最小定时k=3。因此，需要3位来指示上行HARQ进程数。如果上行HARQ进程号由DCIformat。中的独立3位字段表示，DClformatIA将增加填充位，以确保有效负载大小等于format。的大小。为

3、了不增加DClformatO/lA的大小，可以考虑其他一些方法。例如，格式为0的DM-RS和OCC索引的3位循环移位可以用作上行HARQ进程的号码指示。然后，可以通过具有一些限制的RRC信令来配置用于DM-RS和用于UE的OeC的循环移位。DCIformatO/lA如表1所示，在系统带宽相同的情况下,format。的大小比formatIA小1位。format。中添加了1个填充位，以确保两种格式的大小相同。当考虑异步ULTIARQ时，UL-HARQ进程ID和RV被独立指示，额外的5位被添加到format。中。然后需要在formatlA中添加4个填充位，并计算大约10%的开销。表1:DCIForm

4、at0/1AFonnat0FonnatIA字段信息Bit位数字段信息Bit位数CRC16CRC16CIF3CIF3UL/DLgrantflag1UL/DLgrantflag1Resourceallocation6-14Resourceallocation6-14MCSandRV5MCS5NDI1RV2CSandOCC3NDI1TPCforPUSCH2HARQprocess3CSIrequest1TPCforPUCCH2Total38-46Total39-47如图1所示，当不同Ue的不同下行子帧中的相同CCE索引用于PUCCH资源确定时，具有不同HARQ时间线的不同Ue之间可能会发生PUCCH资

5、源冲突。给定DClformatIA无论如何都会被加长以匹配格式0的大小，当与处理定时（n+3）一起使用时，可以将2位ARO（如EPDCCH情况中的）附加到fonatlA,以解决图1所示的冲突问题。当ULHARQ进程ID和RV被独立指示时，fonatlA只需要附加2个填充位。图1:PUCCH冲突如果支持在n+3ImsTn和n+4ImsTTl之间共享PUSCHHARQ进程，则可以启用在不同定时之间切换的HARQ进程，并且可以避免在改变定时后丢弃用于重传的缓冲区中的数据。对于n+4到n+3的情况，只有在RRC重配的情况下，才会发生HARQ进程切换。对于n+3到n+4的情况，当RRC重配或动态回退时会

6、发生这种情况。但是需要注意的是，预计eNB不会经常在n+3和n+4调度定时之间改变。因此，PUSCHTARQ过程共享的好处可能不会经常获得。只有当PUSCHHARQ过程在不同的定时之间共享时，只需要很少的规范工作，这是可以接受的。同步HARQ用于ReI-8到ReI-14中PUSeH的n+4定时。如果异步HARQ用于n+4定时，那么可以通过ULgrant中的HARQ进程指示轻松实现HARQ进程共享，因为异步HARQ已被同意用于n+3定时。但似乎没有必要改变这种罕见案例的传统机制。如果为n+4定时保持同步HARQ,则应引入一种机制来确定具有n+4定时的PUSCH的HARQ过程索引。然后，相同的HA

7、RQ过程可以在n+3ImsTTI和n+4ImsTTI之间切换，而不会产生歧义。一种可能的方法是，以与TS36.321中规定的SPSHARQ进程索引确定类似的方式确定具有n+4定时的PUSCH的HARQ过程索引。如果这可能会引入其他规范问题，那么最好不要支持PUSeHHARQ进程共享。如何处理使用传统n+4定时的同步ULHARQ和使用n+3定时的异步HARQ之间的交互？存在两种解决方案，要么使用单独的ULHARQ过程，要么引入联合UL-HARQ过程。前一种解决方案很简单，但代价是在该重配时间间隔期间增加了延迟，因为eNB只能使用n+4调度定时，直到挂起的同步HARQ过程完成。限制的严重程度取决于UE以n+3或n+4定时重配的频率。后一种解决方案可以通过使用n+3定时来重新传输正在进行的同步HARQ进程来减少延迟，但需要额外的标准化和测试工作来为每个同步HARQ进程生成HARQprocessID。因此，它允许使用异步HARQ来重新传输挂起的同步HARQ进程，以减少处理时间。n+3和n+4之间的调度定时变化预计将是相当罕见的行为，因为n+3定时通常会针对UE进行配置，以便根据UE能力最小化总体分组延迟。n+4定时很可能在初始接入目标小区时被限制在初始阶段，而n+3定时将在随后获得相应的UE能力时被配置。