LTE中的HARQ原理应用doctypedoc.docx
《LTE中的HARQ原理应用doctypedoc.docx》由会员分享,可在线阅读,更多相关《LTE中的HARQ原理应用doctypedoc.docx(15页珍藏版)》请在冰豆网上搜索。
![LTE中的HARQ原理应用doctypedoc.docx](https://file1.bdocx.com/fileroot1/2023-6/2/aafe9676-416f-4ddc-a113-d7e27b9636b6/aafe9676-416f-4ddc-a113-d7e27b9636b61.gif)
LTE中的HARQ原理应用doctypedoc
3.4.5HARQ
3.4.5HARQ3.4.5HARQ
3.4.5HARQ基本原理
基本原理基本原理
基本原理
3.4.5.1LTEHARQ
3.4.5.1LTEHARQ3.4.5.1LTEHARQ
3.4.5.1LTEHARQ
1.快速重传,只涉及到L2/L1层,重传合并产生合并增益
2.N-processStop-And-Wait
3.DL:
a.自适应异步HARQ
b.ULACK/NAK在PUCCH/PUSCH发送
c.PDCCH携带HARQ进程号
d.重传总是通过PDCCH调度,这是因为它采用异步自适应HARQ
4.UL:
a.同步HARQ,相对于第一次传输,会在固定的地方重传
b.最大传输次数是针对UE的而不是RB
c.在PHICH发送DLACK/NAK
3.4.5.1.1
3.4.5.1.13.4.5.1.1
3.4.5.1.1概述
概述概述
概述
除了传统的Chase合并的HARQ技术,LTE还采用了增量冗余(IR)HARQ,
既通过第一次传输发送信息bit和一部分的冗余bit,而通过重重发送额外的冗
余bit,如果第一次传输没有成功解码,则可以通过重传更多的冗余bit降低信
道的编码率,从而实现更高的解码成功率。
如果加上重重的冗余bit仍无法正确
解码,则进行再次重传,随着重重次数的增加,冗余bit不断积累,信道编码率
不断降低,从而可以获得更好的解码效果。
HARQ正对每个传输块进行重传。
下行HARQ采用多进程的“停止-等待”HARQ实现方式,即对于某一个HARQ
进程,在等待ACK/NACK反馈之前,此进程暂时中止传输,当收到反馈后,再根
据反馈的是ACK还是NACK选择发送新的数据还是重传。
按照重传发生的时刻来区分,可以将HARQ可以分为同步和异步两类。
这也
是目前在3GLTE中讨论比较多的话题之一。
同步HARQ是指一个HARQ进程的传
输(重传)是发生在固定的时刻,由于接收端预先已知传输的发生时刻,因此不需
要额外的信令开销来标示HARQ进程的序号,此时的HARQ进程的序号可以从子帧8_绀泥o#_O@H啇?
_号获得;异步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技术。
3.4.5.1.2
3.4.5.1.23.4.5.1.2
3.4.5.1.2下行
下行下行
下行HARQ
HARQHARQ
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发送确认,那么一个传输就结束了。
3.4.5.1.3
3.4.5.1.33.4.5.1.3
3.4.5.1.3上行
上行上行
上行HARQ
HARQHARQ
HARQ流程
流程流程
流程
上行同步HARQ操作室通过下行ACK。
NACK信令传输,NDI和上行数据的重传来
完成的,每次重传的信道编码RV和传输格式是预定义好的,不需要额外的信令
支持,只需通过NDI指示是新数据的传输还是重传。
上行HARQ流程的时序如下
图所示,;
图3.4.5-2上行HARQ时序图
这里不对下行实例进行详细说明,大家仔细对比两个图就会发现,相对应下行来
说,反馈跟重传的位置都是固定的按照n+4来处理,而下行重传时并没有规定好
重传的时刻,eNB可以根据情况来调度下行重传。
因此这也就是为什么上行叫同
步HARQ,而下行叫异步HARQ的原因。
3.4.5.1.4HARQ
3.4.5.1.4HARQ3.4.5.1.4HARQ
3.4.5.1.4HARQ的进程数量
的进程数量的进程数量
的进程数量
对于“停止-等待”HARQ,在一个harq进程中,一次传输发出后,需要等待
的长度为RTT才能决定一下次传输是传输新数据,还是进行旧数据的重传。
在这
段时间内,eNB/UE当然不能停止传输而白白地等待。
因此,必须发起其它的并
行HARQ进程,以充分利用时域资源。
从前面两个图可以看出,HARQ的进程数量
跟RTT,也就是传输延迟和UE/eNB的处理时间相关的,RTT愈大,需要支持的并
行HARQ进程数量以填满RTT,HARQ进程的数量约等于RTT/TTI。
对于FDD系统
上下行都是采用8个进程的。
TDD有很大的不同,不在本系列之中讲解。
UE和eNB的处理时延很大程度跟具体实现有关的,另外还要考虑传输时延,因
此8个TTI是一个比较折中的数据。
前面主要讨论了HARQ的基本知识,以及在LTE实现中的考虑,下面我们基于MAC
协议来分析上下行处理的原则。
3.4.5.2DL
3.4.5.2DL3.4.5.2DL
3.4.5.2DL-
--
-SCH
SCHSCH
SCH数据传输
数据传输数据传输
数据传输
鞒塘鞒?
流程
下行异步HAR9为了便于说明与理解,暂且只讨论动态调度的情况,对于半静态部分暂且不
说明。
3.4.5.2.1DLassignment
3.4.5.2.1DLassignment3.4.5.2.1DLassignment
3.4.5.2.1DLassignment接收
接收接收
接收
在PDCCH上发送下行分配信息,用于指示在DL-SCH上的下行数据的。
如
果DL-SCH上有数据发送,则相应的DLassignment会在PDCCH上发送,UE就会
监听PDCCH获得必要的信息用于解码DL-SCH数据,有当UE具有C-RNTI,它就
需要监听PDCCH信道,除了DRX情况,如果在这个TTI内有DLassignment发送
给这个UE的C-RNTI,?
如果对于这个HARQ进程,它的上一个DLassignment是给SPS调度或
者是配置好的下行分配,那么无论NDI的值是否改变,那么认为这是一
个新的传输;此时可以确认在这个TTI内有一个下行分配信息,并把HARQ
相关信息发送到HARQ实体。
对于SPS的过程稍微复杂一点,因为涉及到周期性资源的配置问题、释放与重传
的问题,因此要稍微麻烦一点。
并且因为它的资源分配好以后不需要PDCCH来指
示,因此UE必须自己推到相应的信息,例如HARQ进程ID。
LTE中还有一个很有意思的HARQ进程就是BCH的HARQ进程,它专门来处理
广播消息,我们知道广播消息不应该有反馈的。
但是这并不妨碍它可以使用HARQ
重传的合并增益相同的原理,通过不同发送机会发送不同版本的广播消息,在接
收端,如果第一个版本解码失败,它可以继续接收下一个版本,然后把他们进行
合并,从而获得合并增益。
当UE需要读取BCCH,UE可能会根据RRC的指示调度信息来读取,如果在
PDCCH上监听到这个TTI内针对SI-RNTI的下行分配信息,
1.RV(冗余版本):
RVK=ceiling(3/2*k)modulo4,k依赖于系统信息类
型?
SystemInformationBlockType1消息,k=(SFN/2)modulo4,?
对于SystemInformation消息,k=imodulo4,i=0,1,…,nsw-1,i
就是SI窗口nsw内的子帧数目
2.把这个TTI内的DL-assignment以及RV送到特定的广播HARQ进程
虽然上面的公式显得比较复杂,但是计算下来它的顺序都是0,2,3,1,因此
广播的HARQ进程可以根据TTI来判断此时到底是哪一个版本,然后据此解码。
3.4.5.3HARQ
3.4.5.3HARQ3.4.5.3HARQ
3.4.5.3HARQ操作
操作操作
操作
一/层二的实际需求,异步HARQ具有以下的优势:
(13.4.5.3.1HARQ
3.4.5.3.1HARQ3.4.5.3.1HARQ
3.4.5.3.1HARQ实体
实体实体
实体
在UE端有一个HARQ实体,它可以维护一定数量的并行HARQ进程,每一个
进程有一个标识,HARQ实体会把HARQ信息以及在DL-SCH上收到的传输块(TB)
送到相应的HARQ进程;如果在物理层定义了空间分集,那么在一个子帧内,可
以收到一个或者二个传输块(TB),它们都和一个HARQ进程相关。
?
如果在这个TTI内已经确认了有下行的分配信息,那么就把从物理层接收
到的传输块以及相应的HARQ信息发送到对应的HARQ进程;?
如果指示的是发送到广播HARQ进程的,UE就把收到的传输块送到广播
HARQ进程。
3.4.5.3.2HARQ
3.4.5.3.2HARQ3.4.5.3.2HARQ
3.4.5.3.2HARQ进程
进程进程
进程
如果在一个子帧内有数据传输到一个HARQ进程,那么这个进程就会从HARQ
实体收到一个或两个TB以及相应的HARQ信息。
对于收到的TB以及相应的HARQ
信息,HARQ进程将做如下处理:
如果对应这个TB的NDI相对于上一次传输发送了变化;或者这个TB是发送到广
播HARQ进程的并且通过RRC消息的调度信息指导这是第一个收到的广播消息传
输块;或者这是收到的第一个收到的传输块,那么就认为这是一个新的传输;否
则,就认为是重传;
UE根据上面的判断进行处理,?
如果这是一个新的传输,那么就把当前softbuffer里的数据替换成收到
的数据,?
如果这是一个重传,并且这个数据还没有成功解码,那么把这个传输块收
到的数据和softbuffer的数据合并;如果收到的数据跟softbuffer
里的数据大小不一致,需要那么就把当前softbuffer里的数据替换成
收到的数据。
?
然后尝试解码这个TB的softbuffer里的数据,如果解码成功,就要看
这个进程是哪一个,然后做相应的处理,假如,这个HARQ进程是广播
HARQ进程,则把数据送到上层协议层,因为广播消息在整个层2都是透
明传输的,也就是不需要做额外处理,直接发送到RRC层处理,此时不
需要产生确认。
如果不是广播HARQ进程,则把MACPDU发送到
disassemblyanddemultiplexing实体,并且对这个TB的数据产生一
个成功接收确认(ACK)吗,并且指示物理层产生ACK。
?
如果解码失败,并且这个HARQ进程是一个广播HARQ进程或者在传输HARQ
反馈时存在一个测量间隔(measurementgap),则不指示物理层产生ACK
或者NACK,(在测量期间,UE是无法处理跟服务eNB直接的消息与业
务的,因此也不会发送ACK或NACK),否则指示物理层产生ACK或者
NACK。
厤鏂瑰紡锛岃皟搴﹀皢浼氬叿鏈夊緢澶х殑鐏垫椿鎬с€?