上行HARQ

      图1是关于上行数据传输的一个示意图（除了SR外，不包含PUCCH）。本文主要介绍其中的上行HARQ处理。

http://s6/mw690/927cff01gd8790c990475&690

图1：上行流程

      eNodeB使用PHICH来告诉UE是否成功接收PUSCH，一个上行TB对应一个PHICH。关于PHICH的介绍，可以参见我的博文《LTE：PHICH（一）》和《LTE：PHICH（二）》。

     上行支持2中传输模式：TM 1（只支持单天线传输）和 TM2（支持空分复用）。

      对于FDD而言，如果上行传输模式为TM1，则有8个上行HARQ process；如果上行传输模式为TM2，则有上行HARQ process数将翻倍，为16个，此时每个子帧有2个HARQ process。

      对于TDD而言，如果上行传输模式为TM1，则不同的TDD上下行配置对应的上行HARQ process数见36.213的Table 8-1所示（如下图）；如果上行传输模式为TM2，则有上行HARQ process数将翻倍，此时每个子帧有2个HARQ process。

      这里我们不考虑子帧绑定（subframe bundling）的场景。

Table 8-1: Number of synchronous UL HARQ processes for TDD

      每个UE（而不是每个无线承载）会被配置一个最大传输次数。Msg 3的最大传输次数是通过RACH-ConfigCommon的maxHARQ-Msg3Tx字段来配置的；而除Msg3外的其它上行HARQ process允许的最大传输次数是通过MAC-MainConfig的maxHARQ-Tx字段来配置的。

      前面已经介绍过，在LTE中，上行使用同步HARQ，但重传可以是自适应的，也可以是非自适应的。

      上行HARQ使用同步（synchronous）、非自适应（non-adaptive）的目的是为了降低开销。由于上行重传总是发生在可预知的子帧上（例如：在FDD下，重传总是发生在前一次传输的8个子帧之后；TDD见后续介绍），所以根据timing关系可以直接推导出使用的HARQ process。并且在非自适应重传时，重传与与前一次传输（注意：不是“新传”，这可以在36.300的9.1节和36.321的5.4.2.2节得到答案）使用相同的PRB资源和MCS。因此下行只需要PHICH这一种控制信令，而不需要PDCCH（UL grant），从而降低了开销。

      而上行HARQ有时使用自适应（adaptive）重传是为了避免分割上行频域资源或避免与随机接入的资源发生碰撞。此时eNodeB不仅会发送PHICH，还会发送PDCCH（UL grant）以指示重传所使用的新的PRB资源和MCS。

      如果上行同时支持自适应和非自适应HARQ，则要求对应同一上行子帧的PHICH和PDCCH拥有相同的timing，即在同一子帧中发送。如果不满足该条件，则UE不知道是该听从PHICH还是该等待UL grant而不管PHICH，实现的复杂度会大增。

图2：上行HARQ处理（参见36.300的9.1节）

      上行HARQ处理见图2，这对FDD和TDD是一样的。可以看出：

      （1）给定某个HARQ process，即使接收到的PHICH指示为ACK，也不会清空HARQ缓存区。此时，还需要通过在当前子帧或后续子帧中接收到的UL grant中的NDI来决定是进行重传（NDI没有反转），还是进行新传（NDI反转，此时会清空HARQ缓存区）。也即，是否清空HARQ缓存区是由UL grant的NDI来决定的。假如UE收到了ACK，之后要进行重传，只能进行自适应重传、而不能进行非自适应重传！（见36.300的9.1节）

      （2）给定某个HARQ process，无论收到的PHICH指示的是ACK还是NACK，只要同时还收到UL grant，则UE会忽略PHICH而使用UL grant来决定如何进行下一次传输（新传还是重传）。

      （3）如果在某个子帧只收到PHICH（NACK），则使用非自适应重传。

      前面已经介绍了UE如何确定是新传还是重传，现在我们来介绍UE如何确定重传的冗余版本RV。

      如果是非自适应重传，UE只会收到PHICH中指示的ACK/NACK信息，而不会显式地收到RV信息。上行HARQ是同步的，RV遵循一个固定的顺序：0, 2, 3, 1（注意：这个顺序只对“非自适应重传”有意义）。新传使用的RV由UL grant指定，值为0；若之后UE收到NACK，则会使用前一次传输对应的下一个RV版本（对应0，下一个RV值为 2；对应2，下一个RV值为 3）来发起重传，依此类推。

      如果是自适应重传，则UE不仅会收到PHICH，还会收到PDCCH（UL grant）。如果需要重传，UE会根据UL grant的指示来选择RV（见36.213的Table 8.6.1-1），但不一定是0, 2, 3, 1的顺序。如果UL grant中指示的MCS index为0~28，则RV = 0并使用Table 8.6.1-1中指示的真正的MCS。如果UL grant中指示的MCS index为29~31，RV版本见Table 8.6.1-1，并且从表中可以看出，这3个MCS index是预留的，不携带真正的MCS信息，因此如果MCS index为29~31，其MCS遵循前一次传输使用的MCS（TB size和调制方式都与前一次传输，或者说，最近一次接收到的MCS index为0~28的UL grant相同）。（见36.213的Table 8.6.1-1）

      在UL grant调度的重传中使用哪种RV需要在增量冗余增益和稳定性之间取得平衡。从增量冗余的角度上看，改变重传之间的RV值有益于充分利用来自增量冗余的增益。但如果丢失了第一次传输的UL grant信息，则意味着需要使用RV=0的冗余版本，以便显式地指示MCS信息。

      关于上行HARQ中，如何确定重传的Modulation Order、RV版本、TB size，还可参见36.213的8.6节。