LTE-TDD HARQ（1）-上行HARQ时序

LTE-TDD的时序不同于LTE-FDD，并不是固定的n+4的关系，而是与上下行子帧配置UL/DL config参数相关，该参数由SIB1中的tdd-Config字段下发到UE。

1.上行HARQ时序需要考虑的地方

本文主要从时序方面分析上行HARQ过程，主要包括以下几个时序：

（1）eNB收到RA/SR/BSR后分配UL_GRANT，UE使用该UL_GRANT在PUSCH中发送数据的时序；

（2）eNB在PHICH中发送NACK，UE接收PHICH的时序；

（3）UE执行上行重传的同步时序。

下面从时序角度具体分析各个过程。

2.eNB调度ULSCH资源，UE使用分配的UL_GRANT发送UL_DATA的时序

这里需要分两种情况讨论：

（1）UE通过随机接入过程，向eNB发送MSG1（随机接入过程内容较多，以后专门另开博文介绍）。eNB在RAR中配置MSG3将要使用的UL_GRANT，后续UE在UL_GRANT指定的资源中发送MSG3。具体流程如下。

因为MSG1发出后的第3个子帧，UE才开始接收RAR，因此上图中标注的下行时间是（>=t+3），具体时间需要依赖于eNB实际调度。RAR的格式如下图所示。

其中UL_GRANT占用20个bits，具体内容是：

- Hopping flag – 1 bit

- Fixed size resource block assignment – 10 bits

- Truncated modulation and coding scheme – 4 bits

- TPC command for scheduled PUSCH – 3 bits

- UL delay – 1 bit

- CQI request – 1 bit

UL_delay字段表示MSG3使用哪个时刻的PUSCH资源。如果UL_delay=0，那么MSG3将在（m+p）的第一个上行子帧发送，p>=6，如果UL_delay=1，那么MSG3将在（m+p）的第一个上行子帧的下一个上行子帧发送。比如当前上下行子帧配置是1（2、3、7、8号子帧是上行子帧），RAR在1号子帧下发，那么如果UL_delay=0，则MSG3将在（m+p）=(1+6)=7号子帧中发送；如果UL_delay=1，则MSG3将在（m+p）=(1+6)=7号子帧的下一个上行子帧，即8号子帧中发送。

（2）eNB收到SR/BSR后分配UL_GRANT。协议36213中Table8-2规定了其中一种时序关系（下图。注：上行自适应重传也要用到这个表），这种关系可以简单称之为（n+k）的关系。

即：n表示下行携带UL_GRANT（DCI0）的子帧号，k表示子帧时延，也就是上图中二维表格中的焦点值，（n+k）%10的值表示UE需要在哪个子帧的PUSCH上发送数据。比如上下行子帧配置1模式，eNB在1#子帧给UE下发了DCI0，UE将在（1+6）=7#子帧中上传数据，而eNB也会在这个时刻点去解码来自该UE的数据。 

特殊的，如果是上下行子帧配置0，除了支持（n+k）的关系外，还支持（n+7）的关系。因为上下行子帧配置0中有6个上行子帧，而下行子帧只有4个，那么如果按照（n+k）的规则，势必会浪费2个上行子帧。因此这里引入了一个新的规则，就是（n+7）的规则。

在上下行子帧配置0的情况下，一个DCI0的资源既可以在（n+k）中使用，也可以在（n+7）中使用。比如UE在0号子帧收到了DCI0，那么UE和eNB怎么协商这种对应关系？UE怎么知道它当前是需要使用（n+k）的资源还是需要使用（n+7）的资源？既然这种关系是不确定的，因此就没有办法在协议中事先规定好，只能通过唯一的途径即DCI0来解决。因此，协议在DCI0中引入了一个叫UL_INDEX的字段。UL_INDEX字段只有2个bits，具体含义是：

高比特（MSB）=1、低比特（LSB）=0，表示交互双方需要使用（n+k）的规则；

高比特（MSB）=0、低比特（LSB）=1，表示交互双方需要使用（n+7）的规则；

高比特（MSB）=1、低比特（LSB）=1，表示交互双方同时需要使用（n+k）以及（n+7）的规则，此时就是1个DCI0同时调度2个PUSCH的资源。另外，正如下图描绘的，SR/BSR到UL_GRANT（DCI0）之间的时延，协议并没有明确说明，因此由eNB侧的实现决定。

3.eNB在PHICH中发送NACK，UE接收PHICH的时序

eNB解码数据之后，需要向UE回复ACK或NACK。这个ACK/NACK信息被封装在PHICH的特定位置（以后会有博文详细介绍PHICH中怎么回复ACK/NACK）。既然eNB要发送PHICH，UE要接收PHICH，那么双方就需要事先知道PHICH发送的时刻。这里协议也给我们规定了这种时序关系，即（n+k）的关系。n是UE发送PUSCH数据的上行子帧号，k是二维表格中的焦点值，如下图所示。需要说明的是，这里不再有（n+7）的关系了。

以配置1为例，eNB在2#子帧收到了PUSCH数据后，需要在（2+4）=6#子帧下发PHICH（含ACK或NACK）。那么，除了这个规则，UE和eNB之间的交互就没有其它需要考虑的问题了吗？不妨再看看配置0的情况。

对于配置0来说，就稍微复杂些。比如eNB在3#和4#上行子帧都收到了PUSCH数据，按照上面表格中的（n+k）规则，都需要在0#下发PHICH。也就是说，eNB需要在同个子帧发送两个不同的PHICH序列，那么UE怎么来区分到底哪个是我3#子帧发送的应答，哪个是4#子帧发送的应答呢？毕竟eNB可能在3#子帧解码数据失败，而在4#子帧解码数据成功，那么两个PHICH序列，其中1个携带的可能是NACK信息，而另一个则是ACK信息。

进一步分析子帧配置0会发现，这种2个不同PUSCH子帧对应同1个PHICH子帧的场景，只出现在子帧3、4之间，以及子帧8、9之间，如上图所示。基于此，在计算PHICH位置的时候，协议巧妙的引入一个参数I_PHICH。当PHICH是反馈子帧4或子帧9的时候，I_PHICH等于1，否则等于0。由于这个I_PHICH参数是计算PHICH位置的（后面会有博文详细介绍这个I_PHICH参数），不同的子帧和资源位置，能得到不同的PHICH序列，也就能区分指定的ACK/NACK信息了。

总结如下：

（1）上下行子帧配置0

（2）上下行子帧配置1（其他配置的时序关系类似，不再给出）

4.UE执行上行重传的同步时序

若eNB解码PUSCH失败，可能向UE反馈NACK。如果UE解码到了NACK且没有达到HARQ最大次数，就需要重传PUSCH数据。无论是自适应重传还是非自适应重传，上行都是执行同步时序，即重传的时机与新传的时机存在着固定的时序关系。那么协议怎么来规定PUSCH数据重传的时机问题呢？

对于上下行子帧配置不等于0的场景，上行新传与重传的子帧号始终是相同的，比如UE在3#子帧新传了某个数据，那么重传将会在下个系统帧的3#子帧进行，如下图所示。

对于子帧配置0来说，UE可能会在0子帧（或5子帧）收到2个不同的PHICH序列，分别对应上一次3#、4#子帧（或8#、9#子帧）的PUSCH数据应答，如果两个子帧的PUSCH数据都需要重传，那么就需要在不同子帧的PUSCH上分别重传3#、4#子帧（或8#、9#子帧）的PUSCH数据。

协议36213规定了：

如果0、5子帧收到的PHICH，对应的I_PHICH参数=0（即分别对应3、8子帧的PUSCH数据应答），那么就按照Table 8-2表，按（n+k）的时序重传，n是下行PHICH子帧号，k是表格中的焦点值。

如果0、5子帧收到的PHICH，对应的I_PHICH参数=1（即分别对应4、9子帧的PUSCH数据应答），那么就按照（n+7）的时序重传，n是下行PHICH子帧号。

另外，如果是1、6子帧收到的PHICH，采用的也是（n+7）的时序重传。下图给出了0、6子帧PHICH与HARQ重传的时序示意图。从图中可以得到，在上下行子帧配置0的情况下，上行重传的子帧号是前次传输的子帧的下一个上行子帧。如图中所示的，前次传输的子帧是4号子帧，那么重传的子帧号是4号子帧的下一个上行子帧，即7号子帧。

本段开头提到，eNB解码PUSCH失败，可能返回的是NACK，这里意味着eNB也可能返回ACK。这种场景比较特殊，如资源碰撞导致。比如上下行子帧配置1，eNB在7#子帧有来自UE1的PUSCH数据，该PUSCH的PHICH需要在下个系统帧的1#下发。此时eNB可能有另一个UE2的MSG3资源需要调度。基于MSG3的（n+6）的规则，调度的是下个系统帧7#子帧的PUSCH资源，而这块ULRB资源可能占用了UE1的非自适应重传资源位置，如果此时UE1的PUSCH解码失败，且没有其他的ULRB分配给UE1，那么eNB必须向UE1发送ACK，以便阻止UE1的非自适应重传，从而避免影响UE2的MSG3传输。

为了继续让该UE1重传PUSCH，后续需要执行上行HARQ的自适应重传过程。比如在1#给UE1下发DCI0（NDI不翻转），重新在7#子帧分配PUSCH资源。

不用担心eNB向UE反馈ACK导致PUSCH数据丢失的问题。因为协议36300中已经明确了（下表），如果UE只是收到了ACK，是不会丢弃数据的。

5.后文

在我们实际测试中发现，Aeroflex公司生产的TM500仪器，并没有很好的测试子帧配置0的流程。如果有该公司的同事，希望可以私下交流下。

6.参考文献

（1）3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

（2）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification

（3）3GPP TS 36.300 V9.10.0 (2012-12) Overall description

（4）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)

（5）http://www.sharetechnote.com