第三章LTEMAC协议解读---HARQ

[转载]第三章LTEMAC协议解读---HARQ(2012-01-1010:09:11)[删除]标签：转载原文地址：第三章LTEMAC协议解读---HARQ作者：LTE通信人家3.4.5HARQ基本原理3.4.5.1LTEHARQ1.快速重传，只涉及到L2/L1层，重传合并产生合并增益2.N-processStop-And-Wait3.DL:a.自适应异步HARQb.ULACK/NAK在PUCCH/PUSCH发送c.PDCCH携带HARQ进程号d.重传总是通过PDCCH调度，这是因为它采用异步自适应HARQ4.UL:a.同步HARQ，相对于第一次传输，会在固定的地方重传b.最大传输次数是针对UE的而不是RBc.在PHICH发送DLACK/NAK3.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进程的序号可以从子帧号获得；异步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下行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上行HARQ流程上行同步HARQ操作室通过下行ACK。NACK信令传输，NDI和上行数据的重传来完成的，每次重传的信道编码RV和传输格式是预定义好的，不需要额外的信令支持，只需通过NDI指示是新数据的传输还是重传。上行HARQ流程的时序如下图所示，图3.4.5-2上行HARQ时序图这里不对下行实例进行详细说明，大家仔细对比两个图就会发现，相对应下行来说，反馈跟重传的位置都是固定的按照n+4来处理，而下行重传时并没有规定好重传的时刻，eNB可以根据情况来调度下行重传。因此这也就是为什么上行叫同步HARQ，而下行叫异步HARQ的原因。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-SCH数据传输为了便于说明与理解，暂且只讨论动态调度的情况，对于半静态部分暂且不说明。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.3.1HARQ实体在UE端有一个HARQ实体，它可以维护一定数量的并行HARQ进程，每一个进程有一个标识，HARQ实体会把HARQ信息以及在DL-SCH上收到的传输块(TB)送到相应的HARQ进程；如果在物理层定义了空间分集，那么在一个子帧内，可以收到一个或者二个传输块(TB)，它们都和一个HARQ进程相关。如果在这个TTI内已经确认了有下行的分配信息，那么就把从物理层接收到的传输块以及相应的HARQ信息发送到对应的HARQ进程；如果指示的是发送到广播HARQ进程的，UE就把收到的传输块送到广播HARQ进程。3.4.5.3.2HARQ进程如果在一个子帧内有数据传输到一个HARQ进程，那么这个进程就会从HARQ实体收到一个或两个TB以及相应的HARQ信息。对于收到的TB以及相应的HARQ信息，HARQ进程将做如下处理：如果对应这个TB的NDI相对于上一次传输发送了变化；或者这个TB是发送到广播HARQ进程的并且通过RRC消