LTE HARQ问题和改进方案

在每个服务小区,MAC实体处存在一个HARQ实体,维持多个并行HARQ过程,允许在等待先前传输的成功或不成功接收的HARQ反馈的同时连续地进行传输。

当物理层被配置用于上行链路空间复用时,存在与给定TTI相关联的两个HARQ处理。否则,存在与给定TTI相关联的一个HARQ过程。

在给定的TTI处,如果为TTI指示上行许可,则HARQ实体标识应当进行传输的HARQ过程。它还将接收到的HARQ反馈(ACK/NACK信息)、MCS和由物理层中继的资源路由到适当的HARQ处理。

在异步HARQ中,HARQ过程基于接收到的UL授权与TTI相关联,RAR中的UL授权除外。每个异步HARQ进程都与HARQ进程标识符相关联。对于RAR中具有UL授权的UL传输,使用HARQ进程标识符0。HARQ反馈不适用于异步上行HARQ。

配置TTI捆绑时,参数TTI_BUNDLE_SIZE提供TTI捆绑的TTI数。TTI绑定依赖于HARQ实体为属于相同绑定的每个传输调用相同的HARQ过程。在绑定内,HARQ重传是非自适应的,并且根据TTI_BUNDLE_SIZE在不等待来自先前传输的反馈的情况下触发。捆绑的HARQ反馈仅针对捆绑的最后TTI接收(即,与TTI_BUNDLE_SIZE相对应的TTI),而不管该TTI中是否发生传输(例如,当发生测量GAP时)。TTI bundle 的重传也是TTI bundle 。当MAC实体配置了一个或多个SCells并配置了上行链路时,不支持TTI绑定。

上行HARQ操作对于BL UE或增强覆盖中的UE是异步的,除了bundle 内的重复。

对于增强覆盖中的BL UE或YE,参数UL_REPETITION_NUMBER提供bundle 内的传输重复次数。对于每个bundle,UL_REPETITION_NUMBER设置为低层提供的值。绑定操作依赖于HARQ实体为每个传输调用相同的HARQ进程,该传输是consequective子帧中相同绑定的一部分。在bundle内,HARQ重传是非自适应的,并且根据UL_REPETITION_NUMBER在不等待来自先前传输的反馈的情况下被触发。对应于捆绑的新传输或重传的上行许可仅在捆绑的最后一次重复之后接收。对于与E-UTRAN结合RN子帧配置的RN通信,不支持TTI捆绑。

对于随机接入期间的Msg3传输,TTI bundling 不适用。对于BL UE或增强覆盖中的UE,上行重复捆绑用于Msg3的传输。

对于每个TTI,HARQ实体应:

  • 识别与该TTI相关联的HARQ过程,并且对于每个识别的HARQ过程:
  • 如果已为此进程和此TTI指示上行许可:

1. 如果接收到的授权没有发往PDCCH上的临时C-RNTI,并且如果在相关HARQ信息中提供的NDI已经与该HARQ过程的先前传输中的值相比被切换;

2. 如果在PDCCH上接收到用于C-RNTI的上行链路许可,并且所识别的进程的HARQ缓冲器为空;

3. 如果在随机接入响应中接收到上行链路许可:

① 如果在Msg3缓冲器中存在MAC PDU并且在随机接入响应中接收到上行链路许可:

1) 从Msg3缓冲区获取要传输的MAC PDU。

② 否则:

1) 从“复用和组装”实体获取要传输的MAC PDU;

③ 将MAC PDU和上行链路授权以及HARQ信息传送到所识别的HARQ进程;

④ 指示已识别的HARQ进程触发新的传输。

4. 否则

⑤ 将上行链路授权和HARQ信息(冗余版本)传递给所标识的HARQ进程;

⑥ 指示所识别的HARQ过程生成自适应重传。

  • 否则,如果此HARQ进程的HARQ缓冲区不为空:

1. 指示所识别的HARQ过程生成非自适应重传。

当确定与先前传输中的值相比,NDI是否被置换时,MAC实体应忽略PDCCH上所有上行授权中接收到的用于其临时C-RNTI的NDI。

为短TTI中调度的PUSCH支持PHICH-less异步UL HARQ(即sPUSCH)。但是,在TTI长度重配中,HARQ会出现哪些问题呢?

一般情况下,一旦空闲的UE得到服务,UE就会向eNB发起随机接入过程。然后,eNB将通过RRC信令或PHY信令来配置UE资源,其中TTI长度也配置给UE。如果承载中的业务是实时应用,则TTI长度可以是sTTI,反之,如果业务不是那么紧急或sTTI资源有限,则可以推断可以使用1ms正常 TTI。由于UE的承载和sTTI资源都能够变化,UE可能将TTI长度从1ms TTI重新配置为sTTI,或者从sTTI重新配置为1ms TTI。

为了支持灵活的业务时延需求,实现合理的资源利用率,可以在sTTI和1ms TTI(半静态或动态)之间重配TTI长度。

那现在就存在两种情况:

1. 情况1:TTI长度从sTTI重配为1ms TTI

2. 情况2:TTI长度从1ms TTI新配为sTTI

对于DL HARQ,如图1所示,eNB在TTI n处向UE发送TB,UE在TTI n+k处给出HARQ反馈(k在1ms TTI和sTTI中可能不同),如果反馈是NACK,eNB将重传TB。

无论使用特定于小区的重配还是特定于UE的重配,应用重配的TTI长度的重新配置边界都将位于TTI中。通常,多个HARQ进程将在UE中运行,对于一个HARQ进程,重配边界将位于UE准备发送HARQ反馈的TTI中,对于另一个HARQ进程,重配边界将位于UE准备接收TB重传的相同TTI中。由于HARQ重传是异步的,UE可以在重配的TTI中接收TB重传,因此,重配对TB重传没有影响。然而,在情况1(sTTI到1ms TTI)和情况2(1ms TTI到sTTI)中,用于UE HARQ反馈的TTI必须改变,细节如图2和图3所示,UE HARQ反馈将可能位于具有重配的长度的新TTI位置。


LTE HARQ问题和改进方案


LTE HARQ问题和改进方案

在图2和图3中,UE中存在多个HARQ进程。HARQ反馈的sTTI被1ms TTI替换,或者HARQ反馈的1ms TTI被sTTI替换,问题是两种情况下的HARQ反馈都需要重新考虑。基本上,有两种方法来处理这种HARQ反馈,一种方法是禁用HARQ过程,解决方案可以是,例如,在eNB实现中应用类似的计时器。(如果UE中仍然存在HARQ进程,UE的默认行为是一旦eNB重配TTI就清除其进程)。另一种方法是继续HARQ过程,解决方案可以是,例如,UE将重定向到新TTI以进行HARQ反馈。

所以,当TTI长度改变时,应确保DL HARQ。

对于UL HARQ,如图4中的步骤1,UE将接收用于TB传输的UL授权,步骤2,UE将在该UL授权上传输TB,步骤3,UE将接收eNB HARQ反馈(UL授权),步骤4,UE将在其UL授权上重新传输TB。

无论使用特定于小区的重配还是特定于UE的重配,应用重配的TTI长度的重配边界都将位于TTI中。通常,多个HARQ过程将在UE中运行,对于一个HARQ过程,重配边界将位于UE准备(重新)传输TB的TTI中,对于另一个HARQ过程,重配边界将位于UE准备从eNB接收HARQ反馈(UL grant)的同一TTI中。

在这里,将传输和重传总结在一个图中,如情况1(sTTI到1ms TTI)和情况2(1ms TTI到sTTI),TTI长度重配改变了UE在UL授权接收时UL数据(重传)传输的TTI,详情如图5和图6所示,因此UE TB(重传)传输定时需要重新考虑。

对于HARQ反馈,在情况1(sTTI到1ms TTI)中,PHICH的1ms TTI将覆盖多个具有HARQ ACK的sTTI,HARQ反馈也需要重新考虑。这里可以看到一个问题,当TTI从sTTI变为1ms TTI时,需要考虑来自eNB的HARQ反馈。然而,在情况2(1ms TTI到sTTI)中,考虑到sTTI中使用PHICH异步UL HARQ,UE将在PHICH less信道中接收UL HARQ反馈,因此,情况2(1ms TTI到sTTI)的重配对UL HARQ反馈没有影响

LTE HARQ问题和改进方案


LTE HARQ问题和改进方案

如图5和图6所示,UE中存在多个HARQ进程。用于UE TB(重传)的sTTI被1ms TTI替换,或者用于UE TB(重传)的1ms TTI被sTTI替换,可以看出在这两种情况下UE TB(重传)的一个问题需要重新考虑。基本上,有两种方法来处理此UE TB(重)传输,一种方法是禁用此HARQ过程,解决方案可以是,与下行类似。另一种方法是继续此HARQ过程,解决方案可以是,例如,UE TB(重传)传输将重定向到新TTI。

还有另外一种情,针对TDD上行容量受限,协议提出了一种增强上行容量的方法,在UpPTS特殊子帧中进行调度和HARQ反馈。有两种传输方案:

1. 独立传输块可以在UpPTS中传输。

2. UpPTS可以与随后的UL子帧捆绑在一起,传输一个传输块。

所以,1被称为独立TB传输,2被称为捆绑TB传输。

在Rel-8中,TDD的UL HARQ时机是基于以下原则设计的:

  • 原则1:ACK/NACK的开销应为相同往返时间内所有子帧的平均开销;
  • 原则2:上行HARQ模式应该是特定于子帧的;
  • 原则3:ACK/NACK引起的特殊子帧开销应最小化;
  • 原则4:从向UE可利用的位置发送信号的资源授予的最小延迟。

上述原则考虑了下行和特殊子帧中控制区域的吞吐量、非对称的上下行资源、用于上行同步HARQ和调度灵活性等因素。作为示例,TDD UL/DL配置0/3的HARQ定时分别在图7中示出。


LTE HARQ问题和改进方案

对于UpPTS中的PUSCH,Rel-8 UL HARQ时机的因素仍然存在。因此,UpPTS中PUSCH的HARQ时机设计也应遵循同样的原则。

对于捆绑传输块传输,UpPTS和随后的UL子帧必须一起被调度和确认。因此,具有最小标准影响的简单方法是对相应的上行链路子帧重新使用调度和HARQ定时。然而,有两个问题需要考虑。

一个问题是PDCCH/EPDCCH/PHICH和(重)传输之间的间隔可能小于3ms,这对处理能力施加了新的限制。例如,在图7的TDD UL/DL配置3中,上行链路子帧2由前一帧的子帧8中的PDCCH/EPDCCH/PHICH触发,它们之间的间隔为3ms。如果在前一帧的子帧#8中同时触发特殊子帧#1和上行子帧#2中的UpPTS,则它们之间的间隔小于2.5ms。然而,通过设置缩短的TTI和处理时间,可以在一定程度上放松该约束。

另一个问题是UpPTS+UL子帧中的传输可能不会在下一个UpPTS+UL子帧中重新传输,而是在正常的上行链路子帧中重新传输,图8中给出了一个示例。如果复用当前HARQ定时,由于总传输中使用的符号数不同,会对rBLER产生影响。这个问题可以由eNB通过适当的MCS选择来解决,在iBLER和rBLER之间进行权衡。另一种方法是通过自适应HARQ调整重传的PRB。

LTE HARQ问题和改进方案

对于独立的TB传输,需要指定调度和HARQ时机,并且HARQ进程的数目相应地增加。

在UL/DL配置1~5中,下行加特殊子帧多于上行加特殊子帧,因此,在每个下行或特殊子帧中不配置多于一个PUSCH传输。在这种情况下,UpPTS中的PUSCH的调度和HARQ定时可以根据Rel-8 TDD HARQ定时原则来添加。一个例子如由表1和表2所示,其中配置1~5的修改用红色标记。作为示例,TDD配置3的增加HARQ过程如图9所示。

LTE HARQ问题和改进方案


LTE HARQ问题和改进方案

对于UL/DL配置0/6,上行链路加UpPTS子帧多于下行加DwPTS子帧,因此,有必要调度或确认来自单个下行子帧的多个PUSCH传输。表1和表2中给出了一个示例设计。

LTE HARQ问题和改进方案

通过上述设计,可以增加用于TDD的HARQ过程的数量,如表3所示。

所以,建议支持UL/DL配置2/3的TTI捆绑,因为UpPTS中有4个子帧包含上行资源和PUSCH。在捆绑大小为4(与Rel-8 TTI捆绑相同)的情况下,优选在初始传输和重传之间包含上行资源的子帧的数目是4的倍数。这样,包含上行资源的上行子帧都可以在不同HARQ处理之间利用。

原文链接:,转发请注明来源!
「LTE HARQ问题和改进方案」评论列表

发表评论