LTE-HARQ协议解读

HARQ基本原理
LTE HARQ
快速重传，只涉及到L2/L1层，重传合并产生合并增益
N-process Stop-And-Wait
DL:
自适应异步HARQ
UL ACK/NAK 在PUCCH/PUSCH发送
PDCCH 携带 HARQ 进程号
重传总是通过PDCCH调度，这是因为它采用异步自适应HARQ
UL:
同步HARQ，相对于第一次传输，会在固定的地方重传
最大传输次数是针对UE的而不是RB
在PHICH 发送DL ACK/NAK
概述
增量冗余HARQ
除了传统的Chase合并的HARQ技术，LTE还采用了增量冗余（IR）HARQ，既通过第一次传输发送信息bit和一部分的冗余bit，而通过重重发送额外的冗余bit，如果第一次传输没有成功解码，则可以通过重传更多的冗余bit降低信道的编码率，从而实现更高的解码成功率。

如果加上重重的冗余bit仍无法正确解码，则进行再次重传，随着重重次数的增加，冗余bit不断积累，信道编码率不断降低，从而可以获得更好的解码效果。

HARQ正对每个传输块进行重传。

进程实现模式
下行HARQ采用多进程的“停止-等待”HARQ实现方式，即对于某一个HARQ进程，在等待ACK/NACK反馈之前，此进程暂时中止传输，当收到反馈后，再根据反馈的是ACK还是NACK 选择发送新的数据还是重传。

同步/异步HARQ
按照重传发生的时刻来区分，可以将HARQ可以分为同步和异步两类。

这也是目前在3G LTE中讨论比较多的话题之一。

同步HARQ是指一个HARQ进程的传输(重传)是发生在固定的时刻，由于接收端预先已知传输的发生时刻，因此不需要额外的信令开销来标示HARQ进程的序号，此时的HARQ进程的序号可以从子帧号获得；
异步HARQ是指一个HARQ进程的传输可以发生在任何时刻，接收端预先不知道传输的发生时刻，因此HARQ进程的处理序号需要连同数据一起发送。

由于同步HARQ的重传发生在固定时刻，在没有附加进程序号的同步HARQ在某一时刻只能支持一个HARQ进程。

实际上HARQ操作应该在一个时刻可以同时支持多个HARQ进程的发生，此时同步HARQ需要额外的信令开销来标示HARQ的进程序号，而异步HARQ本身可以支
持传输多个进程。

另外，在同步HARQ方案中，发送端不能充分利用重传的所有时刻，例如为了支持优先级较高的HARQ进程，则必须中止预先分配给该时刻的进程，那么此时仍需要额外的信令信息。

自适应/非自适应HARQ
根据重传时的数据特征是否发生变化又可将HARQ分为非自适应和自适应两种，其中传输的数据特征包括资源块的分配、调制方式、传输块的长度、传输的持续时间。

自适应传输是指在每一次重传过程中，发送端可以根据实际的信道状态信息改变部分的传输参数，因此，在每次传输的过程中包含传输参数的控制信令信息要一并发送。

可改变的传输参数包括调制方式、资源单元的分配和传输的持续时间等。

在非自适应系统中，这些传输参数相对于接收端而言都是预先已知的，因此，包含传输参数的控制信令信息在非自适应系统中是不需要被传输的。

在重传的过程中，可以根据信道环境自适应地改变重传包格式和重传的时刻的传输方式，可以称为基于IR类型的异步自适应HARQ方案。

这种方案可以根据时变信道环境的特性有效地分配资源，但是具有灵活性的同时也带来了更多的系统复杂性。

在每次重传过程中包含传输参数的控制信令信息必须与数据包一起发送，这样就会造成额外的信令开销。

而同步HARQ 在每次重传过程中的重传包格式，重传时刻都是预先已知的，因此不需要额外的信令信息。

与异步HARQ相比较，同步HARQ具有以下的优势：
1.控制信令开销小，在每次传输过程中的参数都是预先已知的，不需要标示HARQ的进程
序号。

2.在非自适应系统中接收端操作复杂度低。

3.提高了控制信道的可靠性，在非自适应系统中，有些情况下，控制信道的信令信息在重
传时与初始传输是相同的，这样就可以在接收端进行软信息合并从而提高控制信道的性能。

根据层一/层二的实际需求，异步HARQ具有以下的优势：
1.如果采用完全自适应的HARQ技术，同时在资源分配时，可以采用离散、连续的子载波
分配方式，调度将会具有很大的灵活性。

2.可以支持一个子帧的多个HARQ进程
3.重传调度的灵活性
LTE下行链路系统中将采用异步自适应的HARQ技术。

因为相对于同步非自适应HARQ技术而言，异步HARQ更能充分利用信道的状态信息，从而提高系统的吞吐量，另一方面异步HARQ可以避免重传时资源分配发生冲突从而造成性能损失。

例如：在同步HARQ中，如果优先级较高的进程需要被调度，但是该时刻的资源已被分配给某一个HARQ进程，那么资源分配就会发生冲突；而异步HARQ的重传不是发生在固定时刻，可以有效地避免这个问题。

同时，LTE系统将在上行链路采用同步非自适应HARQ技术。

虽然异步自适应HARQ技术相比较同步非自适应技术而言，在调度方面的灵活性更高，但是后者所需的信令开销更少。

由于上行链路的复杂性，来自其他小区用户的干扰是不确定的，因此基站无法精确估测出各个用户实际的信干比(SINR)值。

在自适应调制编码系统中，一方面自适应调制编码(AMC)根据信道的质量情况，选择合适的调制和编码方式，能够提供粗略的数据速率的选择；另一方面HARQ基于信道条件提供精确的编码速率调节，由于SINR值的不准确性导致上行链路对于调制编码模式(MCS)的选择不够精确，所以更多地依赖HARQ技术来保证系统的性能。

因此，上
行链路的平均传输次数会高于下行链路。

所以，考虑到控制信令的开销问题，在上行链路确定使用同步非自适应HARQ技术。

下行HARQ流程
下行异步HARQ操作是通过上行ACK/NACK信令传输、新数据指示、下行资源分配信令传输和下行数据的重传来完成的。

每次重传的信道编码冗余版本是预定义好的，不需要额外的信令支持。

RV的设计，由于下行HARQ重传的信道编码率已经确定，因此不进行完全的MCS的选择，但仍可以进行调制方式的选择。

调制方式的变化会同时造成rB数的不同，因此需要通过下行的信令资源分配指示给UE，另外，还需要通过一个比特的新数据指示符（NDI）指示此次传输是新数据还是重传。

下行HARQ流程的时序实例如下图所示，
图3.4.5-1 下行HARQ时序图
假设下行跟上行是子帧同步，接收发送之间没有时延（实际上也不可能，只是便于理解）首先eNB在时刻0的PDSCH信道发送了一份下行数据，UE首先监听到后，进行解码，发现解码失败，它将在时刻4的上行控制信道（PUCCH）向eNB反馈上次传输的NACK信息， eNB 对PUCCH中的NACK信息进行解调和处理，然后根据下行资源分配情况对重传数据进行调度，此时的调度时间并没有规定，eNB根据情况来调度，这里假设在时刻6在PDSCH上发送重传，如果此时UE成功解码，那么它就在时刻10发送确认，那么一个传输就结束了。

上行HARQ流程
上行同步HARQ操作是通过下行ACK。

NACK信令传输，NDI和上行数据的重传来完成的，每次重传的信道编码RV和传输格式是预定义好的，不需要额外的信令支持，只需通过NDI 指示是新数据的传输还是重传。

上行HARQ流程的时序如下图所示，
图3.4.5-2 上行HARQ 时序图
这里不对下行实例进行详细说明，大家仔细对比两个图就会发现，相对应下行来说，反馈跟重传的位置都是固定的按照n+4来处理，而下行重传时并没有规定好重传的时刻，eNB 可以根据情况来调度下行重传。

因此这也就是为什么上行叫同步HARQ ，而下行叫异步HARQ 的原因。

HARQ 的进程数量
对于“停止-等待”HARQ ，在一个harq 进程中，一次传输发出后，需要等待的长度为RTT 才能决定一下次传输是传输新数据，还是进行旧数据的重传。

在这段时间内，eNB/UE 当然不能停止传输而白白地等待。

因此，必须发起其它的并行HARQ 进程，以充分利用时域资源。

从前面两个图可以看出，HARQ 的进程数量跟RTT ，也就是传输延迟和UE/eNB 的处理时间相关的，RTT 愈大，需要支持的并行HARQ 进程数量以填满RTT ，HARQ 进程的数量约等于RTT/TTI 。

对于FDD 系统上下行都是采用8个进程的。

TDD 有很大的不同，不在本系列之中讲解。

UE 和eNB 的处理时延很大程度跟具体实现有关的，另外还要考虑传输时延，因此8个TTI 是一个比较折中的数据。

Ue Rx
Ue Tx eNB eNB
前面主要讨论了HARQ的基本知识，以及在LTE实现中的考虑，下面我们基于MAC协议来分析上下行处理的原则：
DL-SCH数据传输
为了便于说明与理解，暂且只讨论动态调度的情况，对于半静态部分暂且不说明。

DL assignment接收
在PDCCH上发送下行分配信息，用于指示在DL-SCH上的下行数据的
如果DL-SCH上有数据发送，则相应的DL assignment 会在PDCCH上发送，UE就需要监听PDCCH获得必要的信息用于解码DL-SCH数据。

而当UE得到C-RNTI，它就能够监听PDCCH信道（除了DRX情况），当这个TTI内有DL assignment发送给这个UE的C-RNTI：
如果对于这个HARQ 进程，它的上一个DL assignment是给SPS调度或者是配置好的下行分配，那么无论NDI的值是否改变，那么认为这是一个新的传输。

而此时，则可以确认在这个TTI内有一个下行分配信息，并把HARQ相关信息发送到HARQ 实体。

对于SPS的过程稍微复杂一点，因为涉及到周期性资源的配置问题、释放与重传的问题，因此要稍微麻烦一点。

并且因为它的资源分配好以后不需要PDCCH来指示，因此UE必须自己推到相应的信息，例如HARQ进程ID。

特殊下行任务
LTE中还有一个很有意思的HARQ进程就是BCH的HARQ进程，它专门来处理广播消息，我们知道广播消息不应该有反馈的。

但是这并不妨碍它可以使用HARQ重传的合并增益相同的原理，通过不同发送机会发送不同版本的广播消息，在接收端，如果第一个版本解码失败，它可以继续接收下一个版本，然后把他们进行合并，从而获得合并增益。

当UE需要读取BCCH，UE可能会根据RRC的指示调度信息来读取
如果在PDCCH上监听到这个TTI内针对SI-RNTI的下行分配信息：
那么，就把这个TTI内的DL-assignment以及RV送到特定的广播HARQ进程。

虽然上面的公式显得比较复杂，但是计算下来它的顺序都是0，2，3，1，因此广播的HARQ进程可以根据TTI来判断此时到底是哪一个版本，然后据此解码。

HARQ操作
HARQ实体
在UE端有一个HARQ实体，它可以维护一定数量的并行HARQ进程，每一个进程有一个标识，HARQ实体会把HARQ信息以及在DL-SCH上收到的传输块(TB)送到相应的HARQ进程；如果在物理层定义了空间分集，那么在一个子帧内，可以收到一个或者二个传输块(TB)，它们都和一个HARQ进程相关。

如果在这个TTI内已经确认了有下行的分配信息，那么就把从物理层接收到的传输块以及相应的HARQ信息发送到对应的HARQ进程；
如果指示的是发送到广播HARQ进程的，UE就把收到的传输块送到广播HARQ进程。

HARQ进程
如果在一个子帧内有数据传输到一个HARQ进程，
那么这个进程就会从HARQ实体收到一个或两个TB以及相应的HARQ信息。

对于收到的TB以及相应的HARQ信息，HARQ进程将做如下处理：
如果：
1.对应这个TB的NDI相对于上一次传输发送了变化。

2.这个TB是发送到广播HARQ进程的并且通过RRC消息的调度信息知道这是第一个收到
的广播消息传输块。

3.这是收到的第一个收到的传输块。

那么
就认为这是一个新的传输；否则，就认为是重传；
UE根据上面的判断进行处理，
如果这是一个新的传输
那么就把当前soft buffer里的数据替换成收到的数据，
如果这是一个重传，并且这个数据还没有成功解码，
那么把这个传输块收到的数据和soft buffer的数据合并；如果收到的数据跟soft buffer里的数据大小不一致，需要那么就把当前soft buffer里的数据替换成收到的数据。

判断过后
尝试解码这个TB的soft buffer里的数据。

如果解码成功
那么，就要看这个进程是哪一个，然后做相应的处理，假如，这个HARQ进程是广播HARQ 进程，则把数据送到上层协议层，因为广播消息在整个层2都是透明传输的，也就是不需要做额外处理，直接发送到RRC层处理，此时不需要产生确认。

如果不是广播HARQ进程，则把MAC PDU发送到disassembly and demultiplexing 【分段与解复用】实体，并且对这个TB的数据产生一个成功接收确认（ACK）吗，并且指示物理层产生ACK。

如果解码失败，并且这个HARQ进程是一个广播HARQ进程或者在传输HARQ反馈时存在一个测量间隔(measurement gap)，
那么不指示物理层产生ACK或者NACK，（在测量期间，UE是无法处理跟服务eNB直接的消息与业务的，因此也不会发送ACK或NACK），否则指示物理层产生ACK或者NACK。

UL-SCH 数据传输
UL 授权接收
为了在UL-SCH发送数据，UE必须有一个合法的上行授权（除了非自适应的HARQ重传，因为它会在初始传输的资源上发送重传，而自适应重传必须有PDCCH指示用于重传的资源等），这个上行授权可能动态的从PDCCH获得，或者在随机接入响应消息里（RAR），或者是SPS半静态调度里预先配置好的。

当请求传输时，MAC层从物理层收到相应的HARQ信息。

当timeAlignmentTimer正在运行时（如果不在运行，那只有两种可能：UE跟基站失步了或者还没有起来），并且具有CRNTI，临时C-RNTI或者SPS-C-RNTI，在每一个TTI，UE 都需要根据以下条件来工作：
如果在这个TTI收到一个发送到UE的C-RNTI或者临时C-RNTI的上行授权或者这个上行授权是携带在随机接入响应消息里（RAR），
那么
如果这个上行授权发给UE的C-RNTI，但是，在此之前的一个上行授权是发送到SPS C-RNTI或者配置好的上行授权，并且跟当前授权是使用同一个HARQ进程，
那么无论NDI值是什么，都认为这是一个新的传输（NDI toggled的，也就是NDI值发生了变化），注：为什么这样处理呢?其实SPS的传输方式跟普通的动态调度是不一样的，他没有显性的PDCCH授权指示，当然在需要重传的时候，就会发送，但是处理方式也是不一样。

另外从HARQ进程的特性来看，如果这次是发送到动态的C-RNTI的话，也可以认为之前的SPS调度已经完成了，因此这一次肯定是新的传输。

然后，把这个TTI的上行授权以及相关的HARQ信息传给HARQ实体，为什么要传给HARQ 实体，我们在之前的下行HARQ时已经提到，HARQ实体类似于一个转发中心，它负责调度所有的HARQ进程，因此从物理层收到的HARQ相关信息都是先发给HARQ实体，然后由HARQ实体分配到相应的HARQ进程。

如果在PDCCH上收到的这个TTI的上行授权是发给UE的SPS C-RNTI：
那么
如果收到NDI为1，
那么就认为NDI值没有变化，需要重传，并把这个TTI的上行授权以及相关的HARQ
信息传给HARQ实体；
否则，如果NDI值为0的话，
如果PDCCH的内容指示释放SPS，
那么清除配置的上行授权（也就是之前SPS调度配置好的上行授权，
它周期性的获得），
否则
保存收到的上行授权以及相关HARQ信息，作为配置的上行授权
初始化（没有激活的话）或者重新初始化（如果已经激活）配置的上
行授权，然后从当前的TTI开始算起，之后的周期性授权调度参考SPS
调度相关内容
认为NDI值发生了变化（相当于第一次发送）；把这个TTI的上行授权
以及相关的HARQ信息传给HARQ实体。

否则，如果这个TTI的上行授权是已经配置好的（也就是说这个TTI没有收到相应的PDCCH，并且有SPS调度发生）：那么就认为NDI值发生了变化，开始一个新的传输；把这个TTI的上行授权以及相关的HARQ信息传给HARQ实体。

注：如果UE在一个TTI里面存在多个上行授权，比如RAR携带的，或者针对C-RNTI 的，或者SPS调度配置好的上行授权，UE可以选择任意一个发送新的数据（虽然是任意一个授权，但是其内容要跟授权匹配，而不能发送其它授权对应的信息）。

HARQ 操作
HARQ 实体
在UE侧，只有一个HARQ实体，用于维护一些平行的HARQ进程，它能够保证可以进行连续的传输，并且可以等待针对之前传输的成功或者不成功的HARQ反馈，HARQ进程数跟帧格式有关，FDD固定为8个，而TDD不同的帧配置下有所不同。

在一个特定TTI，收到一个上行授权，HARQ实体能够确认到底是哪一个进程需要发送数据，它就会把收到的相关的HARQ反馈，MCS和资源，发到相应的HARQ进程。

（省略了关于TTI绑定的描述）。

对于每一个TTI，HARQ实体需要:
确认哪一个HARQ进程跟这个TTI相关，也就是那一个HARQ进程会发送数据或者接收一些相关的HARQ信息；
如果已经确认这个TTI有一个上行授权，
如果这个上行授权不是发给临时C-RNTI并且NDI值相对于上一次传输发生了变化
（这个进程的上一次传输）；
如果上行授权是发给C-RNTI的，并且这个HARQ进程对应的HARQ缓冲区是空
的
如果这个上行授权是在RAR消息里的
如果有一个MAC PDU在消息3的缓冲区里，
那么就从这个消息3的缓冲区里面取MAC PDU用于发送
否则，就从"Multiplexing and assembly"实体取MAC PDU用于发送；
把这个MAC PDU，上行授权以及相关的HARQ信息发送到相应的HARQ
进程，并指示这个HARQ进程触发一个新的传输。

否则，把上行授权以及相关的HARQ信息（冗余版本）发送到相应的HARQ
进程；并指示这个HARQ进程产生一个自适应的重传（因为此时收到了相
应的PDCCH指示重传，因此此时的重传是一个自适应的重传而不是非自
适应的）。

否则，如果这个TTI对应的HARQ进程的缓冲区不为空那么指示HARQ进程产
（注：应该说此时已经收到的HARQ反馈，也即是NACK，生一个非自适应的重传。

但是没有收到显性的PDCCH消息，那么就默认为是非自适应的重传）
HARQ 进程
每一个HARQ进程都跟一个缓冲区进行关联，每一个HARQ进程维护一个状态变量CURRENT_TX_NB，用于指示在缓冲区的当前MAC PDU发生了多少次传输，还有一个状态变量HARQ_FEEDBACK，用于指示当前在缓冲区的MAC PDU的HARQ反馈。

当HARQ进程建立时，CURRENT_TX_NB要初始化为0。

上行HARQ的冗余版本按照固定的顺序产生（0，2，3，1）。

变量CURRENT_IRV用于指示当前的冗余版本，按照模除4进行更新。

新的传输按照PDCCH或者RAR指示的MCS以及资源上传输，自适应的重传类似。

而非自适应的重传，使用上一次的资源以及MCS发送。

UE最大的重传的次数由RRC配置，maxHARQ-Tx 和maxHARQ-Msg3Tx。

当收到这个TB的HARQ反馈，HARQ进程把状态变量HARQ_FEEDBACK设置为收到的值。

如果HARQ实体请求一个新的传输，这个HARQ进程需要做到：
1.把 CURRENT_TX_NB 设为0;
2.把CURRENT_IRV 设为 0;
3.把这个MAC PDU放到相应的HARQ缓冲区
4.保存从HARQ实体收到的这个上行授权
5.把HARQ_FEEDBACK设置NACK，（这有个好处就是，如果没有收到反馈，那么就默认重传）;
如果HARQ实体要求重传，那么这个HARQ进程需要：
1.把CURRENT_TX_NB加1（增加当前传输块的发送次数，这样就可以检验是否达到最大次数）如果HARQ实体请求的是自适应的重传
1.把从HARQ实体收到的上行授权保存起来
2.设置CURRENT_IRV为收到的HARQ信息里的冗余版本索引
3.设置HARQ_FEEDBACK to NACK;
4.把HARQ_FEEDBACK设为NACK
如果HARQ进程请求的是一个非自适应的重传：
如果HARQ HARQ_FEEDBACK = NACK，
为了产生一个传输，HARQ进程需要
如果这个MAC PDU是从消息3的缓冲区里获得的，
如果在当前传输时不需要测量（在做切换时的，对临小区的测量等），万一是重传，这个重传指示物理层根据保存的上行授权以及由CURRENT_IRV值指示的冗余版本产生一个传输
那么，把CURRENT_IRV加1。

如果在接收HARQ反馈时，存在测量，并且这个MAC PDU不是从消息3的缓冲区获得的，
那么，在接收HARQ反馈的时候把HARQ_FEEDBACK置为ACK。

当完成上面的操作，HARQ进程检查CURRENT_TX_NB是否等于最大传输次数减1（也就是达到最大传输次数），如果是，则清空HARQ缓冲区。