第三章 LTE MAC协议解读HARQ.docx

1、第三章 LTE MAC协议解读 HARQ第三章LTEMAC协议解读-HARQ(2010-03-20 16:46:56) 转载标签： ltemac协议解读harqit分类： LTE协议 3.4.5 HARQ基本原理3.4.5.1 LTE HARQ1. 快速重传，只涉及到L2/L1层，重传合并产生合并增益2. N-process Stop-And-Wait3. DL: a. 自适应异步HARQ b.UL ACK/NAK 在PUCCH/PUSCH发送c.PDCCH 携带 HARQ 进程号 d.重传总是通过PDCCH调度，这是因为它采用异步自适应HARQ 4.UL: a.同步HARQ，相对于第一次传输

2、，会在固定的地方重传 b.最大传输次数是针对UE的而不是RB c.在PHICH 发送DL ACK/NAK3.4.5.1.1 概述 除了传统的Chase合并的HARQ技术，LTE还采用了增量冗余（IR）HARQ，既通过第一次传输发送信息bit和一部分的冗余bit，而通过重重发送额外的冗余bit，如果第一次传输没有成功解码，则可以通过重传更多的冗余bit降低信道的编码率，从而实现更高的解码成功率。如果加上重重的冗余bit仍无法正确解码，则进行再次重传，随着重重次数的增加，冗余bit不断积累，信道编码率不断降低，从而可以获得更好的解码效果。HARQ正对每个传输块进行重传。 下行HARQ采用多进程的“

3、停止-等待”HARQ实现方式，即对于某一个HARQ进程，在等待ACK/NACK反馈之前，此进程暂时中止传输，当收到反馈后，再根据反馈的是ACK还是NACK选择发送新的数据还是重传。 按照重传发生的时刻来区分，可以将HARQ可以分为同步和异步两类。这也是目前在3G LTE中讨论比较多的话题之一。同步HARQ是指一个HARQ进程的传输(重传)是发生在固定的时刻，由于接收端预先已知传输的发生时刻，因此不需要额外的信令开销来标示HARQ进程的序号，此时的HARQ进程的序号可以从子帧号获得；异步HARQ是指一个HARQ进程的传输可以发生在任何时刻，接收端预先不知道传输的发生时刻，因此HARQ进程的处理序

4、号需要连同数据一起发送。 由于同步HARQ的重传发生在固定时刻，在没有附加进程序号的同步HARQ在某一时刻只能支持一个HARQ进程。实际上HARQ操作应该在一个时刻可以同时支持多个HARQ进程的发生，此时同步HARQ需要额外的信令开销来标示HARQ的进程序号，而异步HARQ本身可以支持传输多个进程。另外，在同步HARQ方案中，发送端不能充分利用重传的所有时刻，例如为了支持优先级较高的HARQ进程，则必须中止预先分配给该时刻的进程，那么此时仍需要额外的信令信息。 根据重传时的数据特征是否发生变化又可将HARQ分为非自适应和自适应两种，其中传输的数据特征包括资源块的分配、调制方式、传输块的长度、传

5、输的持续时间。自适应传输是指在每一次重传过程中，发送端可以根据实际的信道状态信息改变部分的传输参数，因此，在每次传输的过程中包含传输参数的控制信令信息要一并发送。可改变的传输参数包括调制方式、资源单元的分配和传输的持续时间等。在非自适应系统中，这些传输参数相对于接收端而言都是预先已知的，因此，包含传输参数的控制信令信息在非自适应系统中是不需要被传输的。 在重传的过程中，可以根据信道环境自适应地改变重传包格式和重传的时刻的传输方式，可以称为基于IR类型的异步自适应HARQ方案。这种方案可以根据时变信道环境的特性有效地分配资源，但是具有灵活性的同时也带来了更多的系统复杂性。在每次重传过程中包含传输

6、参数的控制信令信息必须与数据包一起发送，这样就会造成额外的信令开销。而同步HARQ在每次重传过程中的重传包格式，重传时刻都是预先已知的，因此不需要额外的信令信息。 与异步HARQ相比较，同步HARQ具有以下的优势： (1)控制信令开销小，在每次传输过程中的参数都是预先已知的，不需要标示HARQ的进程序号。 (2)在非自适应系统中接收端操作复杂度低。 (3)提高了控制信道的可靠性，在非自适应系统中，有些情况下，控制信道的信令信息在重传时与初始传输是相同的，这样就可以在接收端进行软信息合并从而提高控制信道的性能。 根据层一/层二的实际需求，异步HARQ具有以下的优势： (1)如果采用完全自适应的H

7、ARQ技术，同时在资源分配时，可以采用离散、连续的子载波分配方式，调度将会具有很大的灵活性。 (2)可以支持一个子帧的多个HARQ进程 (3)重传调度的灵活性LTE下行链路系统中将采用异步自适应的HARQ技术。因为相对于同步非自适应HARQ技术而言，异步HARQ更能充分利用信道的状态信息，从而提高系统的吞吐量，另一方面异步HARQ可以避免重传时资源分配发生冲突从而造成性能损失。例如：在同步HARQ中，如果优先级较高的进程需要被调度，但是该时刻的资源已被分配给某一个HARQ进程，那么资源分配就会发生冲突；而异步HARQ的重传不是发生在固定时刻，可以有效地避免这个问题。 同时，LTE系统将在上行链

8、路采用同步非自适应HARQ技术。虽然异步自适应HARQ技术相比较同步非自适应技术而言，在调度方面的灵活性更高，但是后者所需的信令开销更少。由于上行链路的复杂性，来自其他小区用户的干扰是不确定的，因此基站无法精确估测出各个用户实际的信干比(SINR)值。在自适应调制编码系统中，一方面自适应调制编码(AMC)根据信道的质量情况，选择合适的调制和编码方式，能够提供粗略的数据速率的选择；另一方面HARQ基于信道条件提供精确的编码速率调节，由于SINR值的不准确性导致上行链路对于调制编码模式(MCS)的选择不够精确，所以更多地依赖HARQ技术来保证系统的性能。因此，上行链路的平均传输次数会高于下行链路。

9、所以，考虑到控制信令的开销问题，在上行链路确定使用同步非自适应HARQ技术。3.4.5.1.2 下行HARQ流程 下行异步HARQ操作是通过上行ACK/NACK信令传输、新数据指示、下行资源分配信令传输和下行数据的重传来完成的。每次重传的信道编码冗余版本是预定义好的，不需要额外的信令支持。RV的设计，由于下行HARQ重传的信道编码率已经确定，因此不进行完全的MCS的选择，但仍可以进行调制方式的选择。调制方式的变化会同时造成rB数的不同，因此需要通过下行的信令资源分配指示给UE，另外，还需要通过一个比特的新数据指示符（NDI）指示此次传输是新数据还是重传。下行HARQ流程的时序实例如下图所示，图

10、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 上行HARQ流程上行同步HARQ操作室通

11、过下行ACK。NACK信令传输，NDI和上行数据的重传来完成的，每次重传的信道编码RV和传输格式是预定义好的，不需要额外的信令支持，只需通过NDI指示是新数据的传输还是重传。上行HARQ流程的时序如下图所示，图3.4.5-2 上行HARQ时序图这里不对下行实例进行详细说明，大家仔细对比两个图就会发现，相对应下行来说，反馈跟重传的位置都是固定的按照n+4来处理，而下行重传时并没有规定好重传的时刻，eNB可以根据情况来调度下行重传。因此这也就是为什么上行叫同步HARQ，而下行叫异步HARQ的原因。3.4.5.1.4 HARQ的进程数量 对于“停止-等待”HARQ，在一个harq进程中，一次传输发出

12、后，需要等待的长度为RTT才能决定一下次传输是传输新数据，还是进行旧数据的重传。在这段时间内，eNB/UE当然不能停止传输而白白地等待。因此，必须发起其它的并行HARQ进程，以充分利用时域资源。从前面两个图可以看出，HARQ的进程数量跟RTT，也就是传输延迟和UE/eNB的处理时间相关的，RTT愈大，需要支持的并行HARQ进程数量以填满RTT，HARQ进程的数量约等于RTT/TTI。对于FDD系统上下行都是采用8个进程的。TDD有很大的不同，不在本系列之中讲解。UE和eNB的处理时延很大程度跟具体实现有关的，另外还要考虑传输时延，因此8个TTI是一个比较折中的数据。前面主要讨论了HARQ的基本

13、知识，以及在LTE实现中的考虑，下面我们基于MAC协议来分析上下行处理的原则。3.4.5.2 DL-SCH数据传输 为了便于说明与理解，暂且只讨论动态调度的情况，对于半静态部分暂且不说明。3.4.5.2.1 DL assignment接收 在PDCCH上发送下行分配信息，用于指示在DL-SCH上的下行数据的。如果DL-SCH上有数据发送，则相应的DL assignment 会在PDCCH上发送，UE就会监听PDCCH获得必要的信息用于解码DL-SCH数据，有当UE具有C-RNTI，它就需要监听PDCCH信道，除了DRX情况，如果在这个TTI内有DL assignment发送给这个UE的C-RN

14、TI， 如果对于这个HARQ 进程，它的上一个DL assignment是给SPS调度或者是配置好的下行分配，那么无论NDI的值是否改变，那么认为这是一个新的传输；此时可以确认在这个TTI内有一个下行分配信息，并把HARQ相关信息发送到HARQ实体。对于SPS的过程稍微复杂一点，因为涉及到周期性资源的配置问题、释放与重传的问题，因此要稍微麻烦一点。并且因为它的资源分配好以后不需要PDCCH来指示，因此UE必须自己推到相应的信息，例如HARQ进程ID。 LTE中还有一个很有意思的HARQ进程就是BCH的HARQ进程，它专门来处理广播消息，我们知道广播消息不应该有反馈的。但是这并不妨碍它可以使用H

15、ARQ重传的合并增益相同的原理，通过不同发送机会发送不同版本的广播消息，在接收端，如果第一个版本解码失败，它可以继续接收下一个版本，然后把他们进行合并，从而获得合并增益。 当UE需要读取BCCH，UE可能会根据RRC的指示调度信息来读取，如果在PDCCH上监听到这个TTI内针对SI-RNTI的下行分配信息， 1. RV(冗余版本)：RVK = ceiling(3/2*k) modulo 4, k依赖于系统信息类型 SystemInformationBlockType1 消息, k = (SFN/2) modulo 4, 对于SystemInformation 消息，k=i modulo 4,

16、i =0,1, nsw-1, i就是SI窗口nsw内的子帧数目 2. 把这个TTI内的DL-assignment以及RV送到特定的广播HARQ进程虽然上面的公式显得比较复杂，但是计算下来它的顺序都是0，2，3，1，因此广播的HARQ进程可以根据TTI来判断此时到底是哪一个版本，然后据此解码。3.4.5.3 HARQ操作3.4.5.3.1 HARQ实体 在UE端有一个HARQ实体，它可以维护一定数量的并行HARQ进程，每一个进程有一个标识，HARQ实体会把HARQ信息以及在DL-SCH上收到的传输块(TB)送到相应的HARQ进程；如果在物理层定义了空间分集，那么在一个子帧内，可以收到一个或者二个

17、传输块(TB)，它们都和一个HARQ进程相关。 如果在这个TTI内已经确认了有下行的分配信息，那么就把从物理层接收到的传输块以及相应的HARQ信息发送到对应的HARQ进程； 如果指示的是发送到广播HARQ进程的，UE就把收到的传输块送到广播HARQ进程。3.4.5.3.2 HARQ进程 如果在一个子帧内有数据传输到一个HARQ进程，那么这个进程就会从HARQ实体收到一个或两个TB以及相应的HARQ信息。对于收到的TB以及相应的HARQ信息，HARQ进程将做如下处理：如果对应这个TB的NDI相对于上一次传输发送了变化；或者这个TB是发送到广播HARQ进程的并且通过RRC消息的调度信息指导这是第一

18、个收到的广播消息传输块；或者这是收到的第一个收到的传输块，那么就认为这是一个新的传输；否则，就认为是重传；UE根据上面的判断进行处理， 如果这是一个新的传输，那么就把当前soft buffer里的数据替换成收到的数据， 如果这是一个重传，并且这个数据还没有成功解码，那么把这个传输块收到的数据和soft buffer的数据合并；如果收到的数据跟soft buffer里的数据大小不一致，需要那么就把当前soft buffer里的数据替换成收到的数据。 然后尝试解码这个TB的soft buffer里的数据，如果解码成功，就要看这个进程是哪一个，然后做相应的处理，假如，这个HARQ进程是广播HARQ进

19、程，则把数据送到上层协议层，因为广播消息在整个层2都是透明传输的，也就是不需要做额外处理，直接发送到RRC层处理，此时不需要产生确认。如果不是广播HARQ进程，则把MAC PDU发送到disassembly and demultiplexing 实体，并且对这个TB的数据产生一个成功接收确认（ACK）吗，并且指示物理层产生ACK。 如果解码失败，并且这个HARQ进程是一个广播HARQ进程或者在传输HARQ反馈时存在一个测量间隔(measurement gap)，则不指示物理层产生ACK或者NACK，（在测量期间，UE是无法处理跟服务eNB直接的消息与业务的，因此也不会发送ACK或NACK），否

20、则指示物理层产生ACK或者NACK。分享 0顶阅读(1377) 评论 (12) 收藏(0) 转载(0) 顶 打印举报 已投稿到：排行榜 圈子 转载列表： 转载 转载是分享博文的一种常用方式.前一篇：第三章LTEMAC协议解读-缓冲区状态报告（BSR）后一篇：第三章LTEMAC协议解读-UL-SCH数据传输评论重要提示：警惕虚假中奖信息，点击查看详情全新育儿博客温馨上线关注每日最热门博客发评论 新浪网友2010-03-24 09:52:41举报博主你好，看你的文章真的受益匪浅。请教你一个问题，异步HARQ最多处理8个Process，意味着第一个TTI传输的TB块，第9个TTI才确定是否重传（其实

21、已经确定了），只是在第9个TTI重传而已，我的理解是否正确？在前8个TTI中，第一个TTI有数据发送，但是后面有一两个TTI，这个UE没有分配到资源，即8个Process没有用满，那么到第9个TTI还是去传输第一个TTI是否重传的数据？博主回复：2010-03-24 11:49:54你说的应该是同步（上行）。没错，你可以参考上面的例子。针对你说情况，第5个TTI上就已经收到eNB的ACK/NACK，如果是NACK，那么它一定会在第9个TTI重传，如果第九个TTI没有资源重传，那么它就要再延后8个TTI，也就是（9+8=17），这就是同步的限制。如果是异步，那么它的重传可以根据情况选择马上重传还

22、是稍后，这取决于实现。至于第二个问题，跟前面是关联的，一个HARQ进程在没有处理完前面的传输块，是不会处理新的传输块的。由于上行的HARQ进程跟TTI是一一对应的，所以在第九个TTI时自然无法处理新的数据。 新浪网友2010-03-24 14:46:06举报感谢博主在百忙之中及时回复我的疑问，异步HARQ并不是跟TTI一一对应，图3.4.5-1下行HARQ时序图中，在n=6时，重传，那么之间就只有7个process，意思是不一定是8个，最多是8个。也可以是6个、5个，只要大于4小于8就行？这个是根据系统自己设置的。而且这个可以变（5、6、7、8），一般系统会依据小区半径（或者场景）进行设置一个

23、定值？我是这样理解的。博主回复：2010-03-25 12:47:27你理解有道理，不过实际上还要考虑处理时间的，一般一个TTI是处理不完的，所以一般是23个TTI，另外小区半径有一些影响，但是相对较小。因此8是一个比较好的选择。FDD里定义最多是8个。但是实际上可以大于8，这取决于RTT的时间，比如TDD里面就有大于8的。 yubingz2010-04-09 17:30:46举报请问TDD大于8的时序是怎么来的？能不能举个例子说明，我看标准头大了！谢谢！博主回复：2010-04-09 17:57:00其实选择多少个就看采用这个值的时候能否覆盖所有的子帧，例如fdd上行8，我们可以看到它在上行

24、授权后4个tti发送数据，再过4个tti确认，这就意味着一个Harq进程从传输到确认需要8个tti，期间这个进程是不能够工作的，那么为了充分的利用空口资源那么必须还要有其它的harq进程来填补。例如配置2，只有2个上行子帧，它要反馈8个下行子帧，那么有些子帧反馈确认的时间就比较长了，因为要填补这里的空缺就需要增加harq进程，这里指下行的 新浪网友2010-04-30 11:30:24举报博主，看了之后收获挺大最近才开始注意到HARQ这一部分，很多问题存在疑问。我想请教你几个问题，对于你所举的下行HARQ流程，是不是RTT=10？这个情况下eNB端的下行调度的时域位置应该结合FDD/TDD帧结

25、构来确定重传位置吧？还是说你所画的示意图均是针对相同物理信道上的不同HARQ进程？望赐教.博主回复：2010-04-30 20:21:15下行HARQ的，RTT=8，至于重传位置跟上下行是否同步有关，同步的话是确定的。对于RTT=10这个是针对TDD的上行HARQ来说的。它的位置也是确定的，但是对于SPS业务有点特别，它会跳变，从而尽量避免跟SPS新数据传输冲突。 新浪网友2010-07-19 21:36:58举报就楼主说的TDD中RTT=10的，是不是图3.4.5-2中的每隔4和TTI改为每隔5个TTI了。那么它理论上所支持的最大HARQ进程数就为10了？RRT的意思是不是数据发出去到下一次

26、数据重传的时间间隔？比如图3.4.5-1的RRT为6个TTI。不知道我的理解对不对，谢谢指教。博主回复：2010-07-19 22:13:22差不多了，不过不完全是4个改为5个TTI，而是因为TDD里面上下行不对称，所以完整地看来就是10个TTI的RTT。但是它是否需要十个HARQ进程呢？其实不是这样的，我们看看36.213就明白，所谓需要多少个进程，是看需要多少个进程来涵盖所有的空口资源，对于TDD，在配置1下，上行4个HARQ进程就够了，而下行就不一样了。 fishbone2010-07-20 15:27:20举报博主，还有个NDI的问题想请教。协议里说NDI是在PDCCH上传下来的，那也

27、就是说UE发送新数据的都是由网络端来控制的？这不合理啊，网络端可以通过NDI告诉UE它接收的数据是新数据还是重传数据，但网络端怎么能控制UE发不发送新数据呢？UE发送新数据应该不完全是受网络端的控制吧。还有，比如说，UE发送数据给网络端，网络端回ACK/NACK，同时PDCCH上传NDI下来，UE根据NDI是否改变以及ACK/NACK来判断重传还是传新数据，那么我的问题是这里ACK/NACK和NDI的功能是重复的啊。UE只需判断其中一个就能知道下一次是要重传还是传新数据了啊。望指教。博主回复：2010-07-21 20:02:09你能这么想，对协议还是比较认真去读的，很多人读过就过来按照协议来

28、做就行。你说的ACK/NACK有确认的功能，没错，NDI也有类似的功能。我们可以想想，假如接收端没有收到ACK或者把ACK解释成NACK，反之依然。会有什么样的后果呢？ fishbone2010-07-22 09:28:04举报现在问题是PDCCH和PHICH是绑定在一起传输的。接收端在收到ACK/NACK时也会受到PDCCH上的NDI。这样即使我没有收到ACK/NACK也可以根据NDI来判断我接下来是新数据还是重传。而且看协议好像NDI的优先级比ACK/NACK高。谢谢博主的指导。博主回复：2010-07-22 10:18:51其实是NDI更加可靠，不过不是所有的都需要NDI的，比如SPS调

29、度时，就不是那么回事，所以这两者是配合使用的。 小马夫的故事2010-08-19 22:49:52举报博主，我有个问题想请教下，就是TDD-LTE下行的一个子帧里对应于单独的一个UE的PHICH数目是怎么得知的？一个PHICH组包含8个PHICH，一个子帧根据子帧配置可以有若干个PHICH组（与上下行配置，系统带宽有关），但是对于每个UE应该最大包含多少个PHICH组又如何得知呢？望赐教！博主回复：2010-08-19 23:01:11广播消息里面会携带的。 新浪网友2010-08-26 12:02:11举报你在文中提到“异步HARQ，可以支持一个子帧的多个HARQ进程”，请问这里一个子帧的多

30、个进程是指广播进程和动态调度的进程、SPS进程这样的组合，还是多个动态调度进程？这个结论是标准支持的吗？在R8已经支持了？谢谢！博主回复：2010-08-27 08:00:40理论上是如此，但实际怎么做，可能有不同的理解。比如说广播进程也属于一个。另外多个动态进程理论也是可行的，没有明确说不能多个DLgrant 新浪网友2010-08-27 09:44:00举报感谢答复，先提个建议，能把这些评论置成首页可见的吗？这样就不用逐片博文去找你给的回复了。另外，提醒我在MAC那篇博文还提了上行逻辑信道优先级的问题，谢谢！根据你的答复，我还是有问题，如果多个动态进程可以在同一个子帧被调度，那是不是跟最初定义进程数的想法相悖了？博主回复：2010-08-27 20:07:27你说的很有道理，只是说异步它提供了这个可能性。而实际上却是存在多个进程，只是不是相同的UE专属的。另外评论实际上是在首页的，在首页左侧面 新浪网友2010-08-30 09:52:13举报谢谢！ 新浪网友2010-08-30 10:42:37举报谢谢！