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的格式如下图所示。

LTE-TDD HARQ(1)-上行HARQ时序_第1张图片

其中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号子帧中发送。

LTE-TDD HARQ(1)-上行HARQ时序_第2张图片

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

LTE-TDD HARQ(1)-上行HARQ时序_第3张图片

即: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侧的实现决定。

LTE-TDD HARQ(1)-上行HARQ时序_第4张图片

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)的关系了。

LTE-TDD HARQ(1)-上行HARQ时序_第5张图片

以配置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信息。

LTE-TDD HARQ(1)-上行HARQ时序_第6张图片

进一步分析子帧配置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(其他配置的时序关系类似,不再给出)

LTE-TDD HARQ(1)-上行HARQ时序_第7张图片

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传输。

LTE-TDD HARQ(1)-上行HARQ时序_第8张图片

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

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

LTE-TDD HARQ(1)-上行HARQ时序_第9张图片

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


你可能感兴趣的:(LTE-TDD HARQ(1)-上行HARQ时序)