LTE学习笔记--MAC--HARQ_redundancy version-程序员宅基地

技术标签: 通信  LTE  

LTE中存在两种级别的重传机制:MAC层的HARQ,以及RLC层的ARQ(AM模式)。起主要作用的是MAC层的HARQ,而RLC的ARQ是作为一种补充手段而存在的。
Ps: HARQ 机制的目标在于实现非常快速的重传,其反馈出错率大概在 1%左右。对于某些业务,如TCP 传输(要求丢包率小于10-6),HARQ 反馈的出错率显然过高了。对于这类业务, RLC 层的重传处理能进一步降低反馈出错率。与 HARQ 相比,RLC 状态报告并不会频繁传输,因此获得甚至更低丢包率的可靠性开销并不大。
HARQ(Hybrid Automatic Repeat Request),混合式自动重传请求,是一种结合 FEC(Forward Error Correction)与 ARQ(Automatic Repeat reQuest)方法的技术。FEC 通过添加冗余信息,使得接收端能够纠正一部分错误,从而减少重传的次数。
FEC是一种数据编码技术,在FEC方式中,接收端不但可以发现差错,而且可以确定二进制马元发生错误的位置,从而加以纠正。FEC方式必须使用纠错码。发现错误无须通知发送方重发。前向纠错是指信号在被传输之前预先对其进行按一定的格式处理,在接收端则按规定的算法进行解码以达到找出错码并纠错的目的。
根据重传内容的不同,在3GPP标准和建议中主要有3种混合自动重传请求机制,包括HARQ-I、HARQ-II和HARQ-III等。
(1)HARQ-I型:FEC前向纠错+重传
HARQ-I即为传统HARQ方案,它仅在ARQ的基础上引入了纠错编码,即对发送数据包增加循环冗余校验(CRC)比特并进行FEC编码。接收端对接收的数据进行FEC译码和CRC校验,如果有错则放弃错误分组的数据,并向发送端反馈NACK信息请求重传与上一帧相同的数据包。一般来说,物理层设有最大重发次数的限制,防止由于信道长期处于恶劣的慢衰落而导致某个用户的数据包不断地重发,从而浪费信道资源。如果达到最大的重传次数时,接收端仍不能正确译码,则确定该数据包传输错误并丢弃该包,然后通知发送端发送新的数据包。这种HARQ方案对错误数据包采取了简单的丢弃,而没有充分利用错误数据包中存在的有用信息。所以,HARQ-I型的性能主要依赖于FEC的纠错能力。
(2)HARQ-II型:FEC前向纠错+重传+组合译码
HARQ-II也称作完全增量冗余方案。在这种方案下,信息比特经过编码后,将编码后的校验比特按照一定的周期打孔,根据码率兼容原则依次发送给接收端。收端对已传的错误分组并不丢弃,而是与接收到的重传分组组合进行译码;其中重传数据并不是已传数据的简单复制,而是附加了冗余信息。接收端每次都进行组合译码,将之前接收的所有比特组合形成更低码率的码字,从而可以获得更大的编码增益,达到递增冗余的目的。每一次重传的冗余量是不同的,而且重传数据不能单独译码,通常只能与先前传的数据合并后才能被解码。
(3)HARQ-III型:FEC前向纠错+重传+互补删除
HARQ-III型是完全递增冗余重传机制的改进。对于每次发送的数据包采用互补删除方式,各个数据包既可以单独译码,也可以合成一个具有更大冗余信息的编码包进行合并译码。另外根据重传的冗余版本不同,HARQ-III又可进一步分为两种:一种是只具有一个冗余版本的HARQ-III,各次重传冗余版本均与第一次传输相同,即重传分组的格式和内容与第一次传输的相同,接收端的解码器根据接收到的信噪比(SNR)加权组合这些发送分组的拷贝,这样,可以获得时间分集增益。另一种是具有多个冗余版本的HARQ-III,各次重传的冗余版本不相同,编码后的冗余比特的删除方式是经过精心设计的,使得删除的码字是互补等效的。所以,合并后的码字能够覆盖FEC编码中的比特位,使译码信息变得更全面,更利于正确译码。目前LTE采用这种
HARQ 协议在时域上分为同步(synchronous)和异步(asynchronous)两类;在频域上分为自适应(adaptive)和非自适应(non-adaptive)两类。
####1 增量冗余(incremental redundancy
在IR(Incremental redundancy)中,每一次重传的bit内容并不一定需要与第一次传输相同。IR机制会根据同一份Info生成多个不同bit集合(但携带的信息相同)。每次重传发送一份RV版本,但多份可以组合解码。由于在重传的时候一般会携带额外的奇偶校验bits(parity bit),所以重传的误码率会降低。
Ps:这里需要注意的是CRC是在HARQ的上层,判断一个info是否正确传输的依据在于CRC校验是否成功。第一次的奇偶校验bits一般具有更高的效率,所以在信号特别不好的时候,有时候重传RV#1能获得更好的结果,因此最终的NACK可能是NACK和DTX(重传RV#1)。HARQ 功能同时跨越物理层和 MAC 层。其中发送端生成不同的冗余版本以及接收端进行软合并、CRC 校验是由物理层负责的。在接收端,HARQbuffer 通常位于物理层中,这是因为物理层需要对接收到的数据进行软合并和解码处理。而发送端RV 版本的选择是在MAC 层告诉物理层的)

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316094810736%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-29qbr7mF-1703121232303)

由于Scrambling和Modulation是在HARQ的更下层完成的,因此,每个RV的这两个都可以不一样。而Rate Matching则与HARQ组合解码时所用的RV的个数有关。

####2 HARQ Process
由于数据发送后接收端的NACK/ACK是有好几个SF的延迟的,而HARQ使用的又是停等协议来发送数据,为了充分利用这之间的SF,LTE使用8个HARQ Process构成HARQ Process entity来处理。在在载波聚合中一个中UE可以有多个HARQ entity。
每个HARQ process在一个TTI只处理一个TB。每个HARQ process在接收端都有一个对应的HARQ buffer对相应的数据进行软合并。空分复用在一个TTI中传输2个TB,使用不同的HARQ process处理,此时有16个HARQ process。

####3 上行HARQ
只有在UL-SCH(PUSCH)上才会存在上行HARQ。而对于上行的物理信道PUSCH,其支持两种传输模式:TM1(单天线)和TM2(支持空分复用)。上行HARQ是同步非自适应的(开销比较小,当然也可以是自适应的)。这也即意味着,某个SF使用的HARQ Process是固定的。对于FDD TM1需要使用8个HARQ Process。而对于TDD,需要根据上下行配置确定HARQ Process的数量,如下表所示。需要注意的是TDD由于存在TTI Bundling HARQ的数量可以更少。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095003463%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-pD23xnwV-1703121232305)

上行HARQ和下行HARQ一个很大的不同点是上行HARQ有专有的通道PHICH发送ACK/NACK。对于空分复用,PHICH数量是非空分复用时的两倍。
至于数据重发的最大次数,由UE参数RACH-ConfigCommon.maxHARQ-Msg3Tx(msg3)和MAC-MainConfig.maxHARQ-Tx(others)指定。eNB用一个PHICH资源发送对应一个上行TB的ACK/NACK信息。
上行HARQ同步意味着,根据Timing关系可以推断出使用的是哪一个HARQ Process,而无需向下行HARQ一样以一个DCI字段指明HARQ Process number,并且重发的时间也是固定的;而非自适应意味着重发所使用的资源(PRB+MCS)和传输时相同的,这就无须额外的PDCCH资源(注意这里的PDCCH负责的是上行调度,不含PDSCH)。有时上行HARQ为了避免分割上行频域资源或避免与随机接入的资源发生冲突也会使用自适应的重传,此时eNB不仅会发送PHICH,还会有PDCCH(DCI0/4)以指明重传的PRB+MCS资源。
eNB侧根据接收到的UL Data的CRC校验结果决定发送ACK/NACK(自适应情况下是否包含PDCCH?)。UE侧的每个HARQ Process维护一个NDI参数,当接收到NACK,NDI不翻转,表示重传,否则表示新传。这里可以推断出,除了UL Grant,PHICH的NACK也可以触发非自适应的PUSCH发送。
一个需要指出的问题是Msg3的HARQ与其他数据的HARQ稍有不一样。因为msg3对应UL Grant在msg2(RAR)里,对应的是RA-RNTI,如果第一次传输msg3失败,RAR需要重传,此时RNTI为Temp-RNTI!简单的说就是RA-RNTI对应新传而Temp-RNTI对应重传,此时Temp-RNTI加扰的PDCCH中的NDI不用于判断Msg3的新传和重传。而如果UE只收到了PHICH中的NACK而没有对应的PDCCH(判断为非自适应),则Msg3重传。
对于半静态调度SPS:
1, 如果 UE 在 PCell 上收到使用 SPS C-RNTI 加扰的指示上行 SPS 激活的 PDCCH,且该DCI携带的NDI字段为0,则认为对应HARQ process的NDI发生翻转,且对应的PUSCH 传输是新传;
2, 如果 UE 在 PCell 上收到使用 SPS C-RNTI 加扰的指示上行 SPS 激活的 PDCCH,且该 DCI携带的 NDI 字段为 1,则认为对应 HARQ process 的 NDI 没有翻转,且对应的 PUSCH 传输是自适应重传;
3, 如果是上行 SPS 激活后的周期性 PUSCH 传输,则认为对应 HARQ process 的 NDI 发生翻转,该 PUSCH 传输是新传;
4, 如果 UE 收到使用 C-RNTI 加扰的 PDCCH,且同一 HARQ process 的前一次收到的 PDCCH是使用 SPS C-RNTI 加扰的(即前面介绍的 3 种情况),则认为对应 HARQ process 的 NDI发生翻转(此时会忽略使用 C-RNTI 加扰的 PDCCH 中携带的 NDI 字段的值),且对应的PUSCH 传输是新传;
5, 如果 UE 只收到一个 PHICH 且指示为 NACK,则对应的 PUSCH 传输是非自适应重传。
对于普通的动态调度:
1, 如果 UE 收到使用 C-RNTI 加扰的 PDCCH,且该 DCI 携带的 NDI 字段与对应 HARQ process 的前一次传输相比发生了翻转,则对应的 PUSCH 传输是新传;
2, 如果 UE 收到使用 C-RNTI 加扰的 PDCCH,且该 DCI 携带的 NDI 字段与对应 HARQ process 的前一次传输相比没有翻转,则对应的 PUSCH 传输是自适应重传;
3, 如果 UE 收到使用 C-RNTI 加扰的 PDCCH,且对应的 HARQ process 的 HARQ buffer 是空的(即第一次使用该 HARQ process 来传输),则对应的 PUSCH 传输是新传;
4, 如果 UE 只收到一个 PHICH 且指示为 NACK,则对应的 PUSCH 传输是非自适应重传。
上行PUSCH的数据的重传一般发生在固定或指定的位置,这里会存在集中比较特殊的情况:
1,UE发送上行数据后受到NACK但NDI发生翻转(猜测是达到最大重传次数),此时需要新传。
2,UE发送上行数据后受到ACK,但没有收到指示上行传输的PDCCH。我们知道UE收到ACK在正常情况是需要新传的,但由于没有PDCCH,也即NDI是否翻转并不知道,此时UE侧可判断为需要重传,但要延时重传。此时ACK被当作NACK处理。这种情况一般是由于需要重传PUSCH但eNB当前无法分配对应的上行资源给此UE。UE会在一个合适的时候给此UE分配上行资源,进行自适应的重传(此时只能是自适应)。(这个根据实现可能不一样)。eNB在接下来的PDCCH中如果翻转NDI,表示接下来是新传PUSCH。如果不翻转NDI,表示PUSCH重传。
由此可以看出,决定新传和重传的并不是ACK/NACK,而是NDI!
TM1下UE在一个TTI只发送一个TB,而在TM2(空分复用)下可以发送2个TB,但并不是任何时候都发送两个TB:1,UE接收到的是DCI format 0,UE在transportblock0上发送数据,而transportblock1被去使能;2,UE接收到DCI format 4,此时对应IMCS=0&&NPRB>1或IMCS=28&&NPRB=1的transportblock被去使能。如果仅有一个被去使能,则使能的transportblock只对应codeword 0。
#####3.1 FDD
对于FDD的上行HARQ,由于存在UL grant过程,因此整个HARQ的过程较下行HARQ长。如果UE在n-4#SF中收到PDCCH解出的是DCI0/4,UE将会在n#SF发送PUSCH,然后在n+4#SF收到ACK/NACK,如果是NACK+no UL grant(非自适应重传)或NACK+UL grant(自适应重传)则在n+8#SF进行PUSCH重传;如果是ACK+ no PDCCH则是延迟重传,可能新传也可能重传由之后的NDI是否翻转决定,如果是ACK+UL grant则新传。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095212516%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-LMXmSERM-1703121232305)

需要指出的是重传新传ACK/NACK都是在同一HARQ process number上的。而上行HARQ为同步HARQ,因此由上图的时序可以推断出FDD需要8个上行 HARQ process。空分复用时加倍。
#####3.2 TDD
TDD由于存在上下行配比,情况极为复杂,暂不叙述。
####4 下行HARQ
下行HARQ操作通过上行ACK/NACK信令传输、新数据指示、下行资源分配信令传输和下行数据的重传来完成的。每次重传的信道编码冗余版本(Redundancy Version,RV)是预定义好的,不需要额外的信令支持(从这里看出LTE的HARQ采用的是HARQ-III型的非重传相同包)。由于下行HARQ重传的信道编码率已经确定,因此不进行完全的MCS的选择,但仍可进行调制方式的选择。调制方式的变化同时造成RB数量的调整,因此需要下行信令资源分配信令指示给UE。另外,还需要通过1bit的新数据指示符(NDI)指示此次传输是新数据的首次传输,还是旧数据的重传。下行HARQ流程的时序如下图所示。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F2018031609540830%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-RqyOVa8B-1703121232306)

UE首先通过PUCCH/PUSCH向eNB反馈上次传输的ACK/NACK信息(当然这里会存在一定的延时)。eNB对PUCCH/PUSCH中的ACK/NACK信息进行解调和处理,并根据ACK/NACK信息和下行资源分配情况对重传数据进行调度。然后PDSCH按照下行调度的时频位置发送重传数据,并经过一定的下行传输延迟到达UE端。UE经过一定的处理延迟对下行重传完成处理,并通过PUCCH/PUSCH再次反馈针对此次重传的ACK/NACK信息。一个下行HARQ RTT到此结束。
对于下行 HARQ,UE 可在不同的物理信道上传输ACK/NACK:
1、 UE 有动态调度的 PUSCH 资源:如果在当前需要反馈 ACK/NACK 的上行子帧,UE 被动态地分配了上行 PUSCH 资源,则 ACK/NACK 会在 PUSCH 上传输。该 PUSCH 有对应的 DCI format0/4。
2、 无 PUSCH 资源:如果在当前需要反馈 ACK/NACK 的上行子帧, UE 没有上行调度,即不发送 PUSCH,则 UE 会在 PUCCH 上传输 ACK/NACK。
3、 SPS 调度的上行传输:分为以下 2 种情况:a,如果 UE 在当前子帧上发送的 PUSCH 对应一个指示上行 SPS 激活的 DCI format 0/4(可能是新传也可能是重传),且需要在该子帧上反馈 ACK/NACK,则 UE 会在 PUSCH 上传输ACK/NACK。 这种情况与动态调度的情况类似;b,如果UE在配置的周期性 SPS 子帧上发送PUSCH,且需要在该子帧上反馈 ACK/NACK,
则 UE 会在 PUSCH 上传输 ACK/NACK。
说白了就是如果有PUSCH就用PUSCH,否则用PUCCH。需要指出的是空分复用时所用的PUCCH format与非空分复用时的是不一样的,ACK/NACK占的bit数量也是不同的,因此可以同时反馈两个TB的ACK/NACK消息。而非像上行HARQ那样增多PHICH资源。
下行 HARQ 使用的是异步自适应的方式,这也即意味着重传可能发生在任意时刻和频域上的任意位置。这必然需要通过PDCCH调度重传,可以避免与SI和MBSFN发生冲突。
TDD特殊子帧的 DwPTS 可用于发送 PCFICH/PHICH/PDCCH 和 PDSCH。这也意味着,特殊子帧可用于发送 UL grant和对应PUSCH数据的ACK/NACK(在 PHICH 上传输)等(特殊子帧0、5由于DwPTS太短除外)。下行 DCI 中包含了 Redundancy version 字段,用于直接指示下行传输的 RV,这与上行HARQ用MCS(29-31)指明RV的做法是不一样的。
#####4.1 FDD
FDD的下行 HARQ相对比较简单,ACK /NACK信息固定在n+4的位置上发送,而重传由于是自适应的,完全由PDCCH调度。
#####4.2 FDD
TDD的ACK/NACK由于存在上下行配比,与FDD固定的4个SF延迟不同,TDD是在第四个以后(包括第四,但不一定是第四个后的第一个)可用的UL SF发送ACK/NACK。下图是UL/DL configuration=1的情况。这里一定要注意SF编号是从0开始的!

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095554907%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-b6cz6i3T-1703121232306) ![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095652652%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-vwgrm1Hy-1703121232306) ![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095703252%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-ZeZYVRIN-1703121232307)

UE根据接收到的PDCCH来决定下行PDSCH传输的HARQ处理。涉及到HARQ的可能的DCI包括DCI format 1/1A/1B/1C/1D/2/2A/2B/2C。与HARQ有关的DCI字段有HARQ process number、Modulation and coding scheme(MCS)、New data indicator(NDI)、Redundancy Version(RV)等。当然不同的DCI可能只包含其中的部分字段。下面对这些字段逐一进行阐述:
MCS
与上行MCS(29-31)隐含RV不同,下行DCI的MCS并不能查到重传RV,因此在DCI中有额外的RV字段指明DL重传的RV。此时(MCS={29-31}),下行重传是用与前一次相同的TBS,而Modulation Order是可变的。如果重传的TBS发生变化,则用重传的TBS覆盖掉原TBS。
HARQ process number
下行DCI之所以包含HARQ process number 字段是因为下行HARQ是异步的,重传的时间和调用HARQ process的顺序是任意的,eNB需要向UE明确指出打钱HARQ process。这里需要注意的是,同一TB的HARQ process应该是一样的,所不同的是同步HARQ可以依据SFN+SF number算的HARQ process,而异步HARQ则必须指定。
NDI
NDI通过是否翻转决定收到的数据是新传还是重传。每一个HARQ process都维护一个NDI,因此翻转是指同一HARQ process的翻转。eNB端通过ACK/NACK来决定NDI是否翻转。具体流程如下图所示。(注意第一次传输NDI有特殊处理逻辑)

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095808126%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-jQLvCvsa-1703121232307)

从之前对UE回发ACK/NACK的位置可以看出,对于FDD,ACK/NACK在编号为n+4的SF发送,但eNB重发下行数据的时间是自适应的,由PDCCH调度。而对于TDD,ACK/NACK的回发位置也是固定的(虽然比较乱。。),并且一个SF内可能包含多个PDSCH SF的ACK/NACK。TDD有两种模式处理这样的一对多的ACK/NACK关系:HARQ bundling 和 HARQ multiplexing。(通过PUCCH-ConfigDedicated.tddAckNackFeedbackMode字段来配置)。
其中HARQ multiplexing模式则实现了复用,在同一个SF内可以包含多个ACK/NACK消息。这些消息彼此独立。
HARQ bundling的处理逻辑是:UE对多个SF的的数据继续CRC校验,如果全过则回ACK,只要有一个CRC校验失败则回复NACK,eNB将重传此ACK/NACK SF对应的所有的SF数据。HARQ bundling实际上是对同一codeword 对应的所有SF的ACK/NACK 做逻辑与运算。载波聚合下并不使用 HARQ bundling,HARQ bundling只用于单个 cell的处理。非空分复用时HARQ bundling ACK/NACK占1bit,空分复用时ACK/NACK占2bits。以下是非空分复用时的两种情况。(1Bit怎么代表ACK/NACK/DTX?DTX 以无回复标识)

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316095948273%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-DoSBFRqE-1703121232307)

对于空分复用ACK/NACK占2bits,不同bit代表了空分复用的不同TB的ACK/NACK,因此大致逻辑也是一样的。如下图所示。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316100019731%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-H80tbY6h-1703121232308)

HARQ bundling处理逻辑的一个重要前提是UE必须知道在某个DL SF上是否存在数据。如果存在,则此SF要参与bundling,否则不参与bundling。这里存在一种特殊情况,eNB在某DL SF上确实发送了数据,但是UE完全接受不到(PDCCH+PDSCH),按之前的逻辑,UE会认为这个DL SF没有数据传输,而不将该SF纳入bundling。因此LTE还需另外一个字段指明某DL SF是否有数据传输,可以想到的是,此字段UE必须接受到!
如果将空分复用时的多个SF看成1维,将空分复用的2个codeword看作另一维,则所要ACK/NACK所要处理的平面如下:

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316100044672%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-5bYqjeZ6-1703121232308)

ACK/NACK的回复方法可以是横向作&运算形成2bits的ACK/NACK,这就是HARQ bundling,此时由于ACK/NACK代表了同一codeword的多个SF,如果收到NACK,则这多个SF需要重传。而如果纵向做&运算则形成不固定bits的ACK/NACK,当收到的ACK/NACK为11011时,两个codeword中的第3个SF都需要重传,这就是HARQ multiplexing。关于HARQ multiplexing的具体内容暂不叙述。
需要注意的是即使PUCCH-ConfigDedicated.tddAckNackFeedbackMode设置为multiplexing,但如果用于反馈ACK/NACK的上行SF对应的M值为1(反馈窗口),即一个DL SF对应一个UL SF。此时如果是空分复用,ACK/NACK需要2bits,如果虽然配置的是multiplexing,但由于multiplexing只能携带 1 比特的信息,反而不如使用 HARQ bundling将2比特的信息都反馈给 eNodeB(使用 PUCCH format 1b)。
在HARQ bundling且UE配置为TM3/4/8/9,如果此时ACK/NACK在PUSCH上传输,UE总是假定codeword 0/1总是存在,如果UE只在一个codeword 0上检测到PDSCH传输,UE会认为codeword2也是有传输数据的,但丢失,因此生成NACK。
前面提到, LTE需另外一个字段指明某DL SF是否有数据传输,而且此字段UE必须接收到!这个字段就是PDCCH 中的 Downlink Assignment Index (DAI)字段,用于告诉 UE在 HARQ 反馈窗口内有多少个子帧包含下行传输。UE通过此字段可以检测 DCI是否丢失。
在 FDD和TDD 0 中,一个系统帧内的上行子帧数与下行子帧数有一一对应的关系,因此没有 DAI 的概念。只有ACK/NACK存在一对多的情况是DAI才有意义。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F2018031610015776%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-YX0WlOh1-1703121232308)

V D A I U L V^{UL}_{DAI} VDAIUL V D A I D L V^{DL}_{DAI} VDAIDL表示所有n-k子帧集合(也就是HARQ反馈窗口)内发送的PDSCH子帧数目,和指示下行SPS释放的PDCCH的子帧数目。Table 7.3-Y 和 Table 10.1.3.1-1 是存在关系的,Table 7.3-Y 指明的DCI format 0/4 发送时所在的下行子帧一定对应Table 10.1.3.1-1 中的 HARQ 反馈窗口里的最后一个下行子帧,或者比该下行子帧还要靠后。也就是说,eNB 发送 DCI format 0/4 时,HARQ反馈窗口发送PDSCH的数目已经知道了。注意到Table 7.3-Y中k>=4,所以ACK/NACK的发送是不会被拖后的。
LTE对于TDD DL HARQ bundling的处理极为复杂(事实上TDD DL multiplexing更为复杂)。事实上在每一个DL SF的DCI中都隐含了用于TDD DL HARQ的有关信息。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316100431830%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-uQIupiOl-1703121232309) (此图来自金辉)

如上图(TDD 2),下行SF 4,5,6,8的ACK/NACK信息都在下一RF的上行SF2上回复。假设SF4没有数据传输,SF5,6,8有下行数据传输。但SF6的下行DCI丢失。则按理UE应该在SF2上回复NACK,但是如果没有其他信息,UE根本不知道SF6上有数据传输,从而仅仅支队SF5,8上的HARQ结果作bundling,从而可能回复ACK倒是SF6的数据丢失。事实上UE此时也无法知道SF4上没有数据传输。因此LTE TDD在每个DL SF中都携带了DAI信息。
对于case1:HARQ反馈窗口的最后一个DCI被接收到,但之前的某些DL_SF丢失,此时UE端通过计算判断出有数据丢失,直接把bundling的结果设置为NACK。
对于case2:所有下行DCL都被接收到,但是SPS对应的PDSCH丢失。此时计算的结果显示没有丢失下行DCI,但是由于SPS无需对应的下行DCI,所以还需要通过SPS的配置和激活时间判断某下行帧(SF6)上是否应该有SPS数据,依次决定反馈结果。
对于case3:UE在反馈窗口的最后一个下行DCI并没有拿到。因此,UE通过计算无法知道有多少个DL SF有数据,也就判断不出来DCI丢失。此时UE可能会回复错误的ACK。但是由于UE和eNB端对于发送此ACK的PUCCH1资源计算结果不同(因为UE丢失信息,以致计算得到一个错误的PUCCH 1资源),eNB无法在正确的PUCCH1资源上得到HARQ信息,因此会认为UE回复的是DTX,导致重传。如果是PUSCH上反馈ACK/NACK,UE和eNB的加扰和解扰将不一致,导致eNB无法解析出PUSCH,从而得到DTX重传。(PUSCH的数据咋办?丢失,然后重传?)
(2)HARQ multiplexing
HARQ multiplexing所回发的ACK/NACK bit的数目是根据M(反馈窗口大小)来决定的。这里有一点需要提出,对于空分复用,如果同一SF时间,对应都没有数据发送,如下图所示。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316100548573%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-juxlsfTx-1703121232309) (此图来自金辉)

如图所示,反馈的ACK/ANCK信息可能是011也可能是0101。
如果ACK/NACK在PUSCH上传输,且PUSCH是由DCI format 0/4(动态调度或上行SPS激活的PDCCH对应的PUSCH),此时由于在HARQ反馈窗口内收到了 V D A I D L V^{DL}_{DAI} VDAIDL,则UE只需反馈 A A C K = V D A I D L A^{ACK}=V^{DL}_{DAI} AACK=VDAIDL(此时,eNB和UE都知道有多少个DL SF有效,并且知道有效DL SF的位置)个bits的ACK/NACK。其内部的Bit对应SF方式:
如果在下行子帧 n - k 发送的 PDSCH 有一个对应的 PDCCH,或发送的是指示下行 SPS 释放的PDCCH,则该子帧对应的 ACK/NACK 在比特 O D A I ( k ) − 1 A C K O^{ACK}_{DAI(k)-1} ODAI(k)1ACK上反馈(反的?),其中 DAI(k)是 UE 在下行子帧 n – k检测到的 DCI format 1A/1B/1D/2/2A/2B/2C 上携带的DAI值。
HARQ Multiplexing是通过 Pucch format 1b with channel selection来传输ACK/NAC/DTX的,常规的format 1b最多只能携带2 bits的信息,而multiplexing最多支持4 bits的ACK/NACK信息。具体的做法是以pucch format 1b所在的位置隐藏另外两个bits的信息。在UE和eNB都知道ACK/NACK厚选的pucch format 1b位置的条件下,eNB盲检测pucch format 1b,出现的位置就是另外的bits信息。这里需要注意的是最终拿到的ack/nack/dtx 的4个字节的顺序与dl SF的先后顺序是不一致的。因此解析某个DL SF的ack nack信息,除了查表外,还需要通过表213.10.1.3.1-1才能拿到。
#####4.3 HARQ ACK Repetetion
eNB可以将UE配置成在多个连续的上行子帧上重复发送对应同一个TB的 ACK/NACK。这样做有益于保证位于小区边界的功率受限的 UE 的 ACK/NACK 信号的可靠性。这个特性称为HARQ-ACK Repetition(又称为 ACK/NACK Repetition)。HARQ ACK Repetition只适用于使用PUCCH 反馈ACK/NACK的场景。通过配置UE-Specific参数ackNackRepetition可以开启HARQ ACK Repetion功能。如下。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316101209577%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-FoKiA80h-1703121232309)

RepetitionFactor指明ACK/NACK的重复次数,而n1Pucch-an-rep表示在HARQ ACK Repetition中天线端口0上用于恢复ACK/NACK的PUCCH1资源。n1Pucch-an-repP1则表示在天线端口1上的PUCCH1资源。
如果UE接收到的是周期性的PDSCH(不带PDCCH),UE会使用配置给SPS的PUCCH1资源来发送ACK/NACK。SPS被DCI激活,则该激活DCI中有一字段TPC command for PUCCH将指示从4个PUCCH1资源中选择一个(双天线时是1对)。该指定资源用于恢复ACK/NACK。而4个可选的PUCCH1资源是被SPS-ConfigDL的n1PUCCH-AN-PersistentList配置,如果双天线则第二个4个PUCCH1资源通过n1PUCCH-AN-PersistentListP1-r10配置。
如果UE接收到的是带PDCCH的PDSCH(或一个指示下行SPS释放的PDCCH),则ACK/NACK初传使用的资源会基于对应PDCCH的first CCE index计算得到(36.213.10.1.2和10.1.3)。重复ACK/NACK的资源是通过n1PUCCH-AN-PersistentList和n1PUCCH-AN-PersistentListP1-r10来配置的。
需要指明的是HARQ ACK Repetition不支持载波聚合(CA假定不存在传输功率不足的问题,加入HARQ ACK Repetition反而会影响性能)。并且在TDD情况下,值适用于HARQ bundling。
对于FDD,HARQ固定在n+4的SF上发送ACK。配置HARQ ACK Repetition,UE会在n+4,n+5……连续的RepetitionFactor个SF上重复发送ACK/NACK,并且UE在此期间不会发送任何其他的信号。
这里存在一个问题,由于存在ACK/NACK Repetition复,如果当前(n)DL SF在n+4,n+5……连续的RepetitionFactor个SF上重复发送ACK/NACK,那么下一个DL SF(即n+1)的正常ACK/NACK就没有UL SF可用了。此时LTE的做法比较简单:对下一个DL SF(即n+1)不作HARQ ACK Repetition处理,而仅仅在n+5 的位置上发送正常的 ACK/NACK。如下图所示。总结起来就两句话:先到先得,保证初传。

![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=%2F%2Fimg-blog.csdn.net%2F20180316101308523%3Fwatermark%2F2%2Ftext%2FLy9ibG9nLmNzZG4ubmV0L2EzNDE0MDk3NA%3D%3D%2Ffont%2F5a6L5L2T%2Ffontsize%2F400%2Ffill%2FI0JBQkFCMA%3D%3D%2Fdissolve%2F70&pos_id=img-9k0hQMva-1703121232309)

对于这个问题TDD的处理方式也是类似,只是时序上更为复杂,这里就不予以叙述了。
#####4.4 载波聚合下对DL HARQ的影响
对于ACK/NACK在PUCCH上发送的场景,由于载波聚合(CA),UE只能在Pcell上对所有的载波单元(CC)作回应。这将导致Pcell的PUCCH资源要携带更多的Bit信息。Rel-10为了支持载波聚合,新增加了2中PUCCH的ACK/NACK反馈方式:
1, PUCCH format 1b with channel selection,这种格式再TDD的multiplexing中已经进行了阐述。主要的思想是用PUCCH的位置信息代表额外的bit。这种格式支持的最大bit数为4bits,并且ServingCell 不能超过两个;
2, PUCCH format 3,这种格式的PUCCH支持最多5个Serving Cell。
某种场景下,具体使用PUCCH format 1b with channel selection和PUCCH format 3中的哪一种取决于eNB的配置参数PUCCH-ConfigDedicated-v1020.pucch-Format-r10。当然超过4Bit或多于2个Serving cell的情况只能用PUCCH format 3了。
(1) PUCCH format 1b with channel selection
PUCCH format 1b with channel selection最多计算出4个PUCCH 1资源,这样4选1的模式提供了额外的两个ACK/NACK Bit位。
对于FDD,其ACK/NACK是上下帧对应的。再加上MIMO,一个小区最多需要2个Bits用于回复ACK/NACK信息。4个bit刚好可以满足FDD HARQ的2 Serving Cell情况。
然而,对于TDD,其ACK/NACK不是上下帧意义对应的。多个TDD DL SF的ACK/NACK信息需要在同一个UL SF发送。因此如果TDD中需要反馈的ACK/NACK bits数大于4,则同意Serving Cell在同一DL SF的两个CW对应的ACK/ANCK bits需要作Spatial Bundling。如果spatial bundling处理后的ACK/NACK bit数依然大于4,则还需要作时域上的Bundling(这种情况只可能在TDD5下存在)。
(2) PUCCH format 3
这种方式也是以channel selection隐含额外bits信息。
#####4.5 广播HARQ
通常来讲,广播消息是不需要回发确认消息的。但在LTE中,属于广播消息(虽然在PDSCH中传输,但其在传输层属于BCH)却存在HARQ机制。SI HARQ使用专门的广播HARQ Process。和普通的DL HARQ不同,SI HARQ不存在ACK/NACK和NDI。SI消息通过 DCI format 1A/1C以SI-RNTI加扰,如果是DCI format 1A则表明该DCI携带了RV信息,UE在解SI时可以直接使用RV信息(指明了RV版本)进行解码;如果是DCI format 1C则表明该DCI不携带RV信息,此时需要根据一定的规则来确定下传的SI是哪一个RV,规则如下: R V k = c e i l i n g ( 3 / 2 ∗ k ) % 4 RV_k=ceiling(3/2*k)\%4 RVk=ceiling(3/2k)%4
如果是SIB1则 k = ( S F N / 2 ) % 4 k=(SFN/2)\%4 k=SFN/2%4,如果是其他SI消息 k = i % 4 k=i\%4 k=i%4 i ∈ { 0 , 1 , … , n _ s _ w − 1 } i∈\{0,1,…,n\_s\_w-1\} i{ 01,n_s_w1},i为SI窗口n_s_w-1内的子帧号码
SI之所以存在HARQ是因为RV联合解码,MIB同样也可以联合解码(4个TTI内),但MIB(PBCH)的编码方式(卷积码而非Turbo码)与SI不同,不需要RV的概念,因此就不存在HARQ。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/a34140974/article/details/79577942

智能推荐

Docker 快速上手学习入门教程_docker菜鸟教程-程序员宅基地

文章浏览阅读2.5w次,点赞6次,收藏50次。官方解释是,docker 容器是机器上的沙盒进程,它与主机上的所有其他进程隔离。所以容器只是操作系统中被隔离开来的一个进程,所谓的容器化,其实也只是对操作系统进行欺骗的一种语法糖。_docker菜鸟教程

电脑技巧:Windows系统原版纯净软件必备的两个网站_msdn我告诉你-程序员宅基地

文章浏览阅读5.7k次,点赞3次,收藏14次。该如何避免的,今天小编给大家推荐两个下载Windows系统官方软件的资源网站,可以杜绝软件捆绑等行为。该站提供了丰富的Windows官方技术资源,比较重要的有MSDN技术资源文档库、官方工具和资源、应用程序、开发人员工具(Visual Studio 、SQLServer等等)、系统镜像、设计人员工具等。总的来说,这两个都是非常优秀的Windows系统镜像资源站,提供了丰富的Windows系统镜像资源,并且保证了资源的纯净和安全性,有需要的朋友可以去了解一下。这个非常实用的资源网站的创建者是国内的一个网友。_msdn我告诉你

vue2封装对话框el-dialog组件_<el-dialog 封装成组件 vue2-程序员宅基地

文章浏览阅读1.2k次。vue2封装对话框el-dialog组件_

MFC 文本框换行_c++ mfc同一框内输入二行怎么换行-程序员宅基地

文章浏览阅读4.7k次,点赞5次,收藏6次。MFC 文本框换行 标签: it mfc 文本框1.将Multiline属性设置为True2.换行是使用"\r\n" (宽字符串为L"\r\n")3.如果需要编辑并且按Enter键换行,还要将 Want Return 设置为 True4.如果需要垂直滚动条的话将Vertical Scroll属性设置为True,需要水平滚动条的话将Horizontal Scroll属性设_c++ mfc同一框内输入二行怎么换行

redis-desktop-manager无法连接redis-server的解决方法_redis-server doesn't support auth command or ismis-程序员宅基地

文章浏览阅读832次。检查Linux是否是否开启所需端口,默认为6379,若未打开,将其开启:以root用户执行iptables -I INPUT -p tcp --dport 6379 -j ACCEPT如果还是未能解决,修改redis.conf,修改主机地址:bind 192.168.85.**;然后使用该配置文件,重新启动Redis服务./redis-server redis.conf..._redis-server doesn't support auth command or ismisconfigured. try

实验四 数据选择器及其应用-程序员宅基地

文章浏览阅读4.9k次。济大数电实验报告_数据选择器及其应用

随便推点

灰色预测模型matlab_MATLAB实战|基于灰色预测河南省社会消费品零售总额预测-程序员宅基地

文章浏览阅读236次。1研究内容消费在生产中占据十分重要的地位,是生产的最终目的和动力,是保持省内经济稳定快速发展的核心要素。预测河南省社会消费品零售总额,是进行宏观经济调控和消费体制改变创新的基础,是河南省内人民对美好的全面和谐社会的追求的要求,保持河南省经济稳定和可持续发展具有重要意义。本文建立灰色预测模型,利用MATLAB软件,预测出2019年~2023年河南省社会消费品零售总额预测值分别为21881...._灰色预测模型用什么软件

log4qt-程序员宅基地

文章浏览阅读1.2k次。12.4-在Qt中使用Log4Qt输出Log文件,看这一篇就足够了一、为啥要使用第三方Log库,而不用平台自带的Log库二、Log4j系列库的功能介绍与基本概念三、Log4Qt库的基本介绍四、将Log4qt组装成为一个单独模块五、使用配置文件的方式配置Log4Qt六、使用代码的方式配置Log4Qt七、在Qt工程中引入Log4Qt库模块的方法八、获取示例中的源代码一、为啥要使用第三方Log库,而不用平台自带的Log库首先要说明的是,在平时开发和调试中开发平台自带的“打印输出”已经足够了。但_log4qt

100种思维模型之全局观思维模型-67_计算机中对于全局观的-程序员宅基地

文章浏览阅读786次。全局观思维模型,一个教我们由点到线,由线到面,再由面到体,不断的放大格局去思考问题的思维模型。_计算机中对于全局观的

线程间控制之CountDownLatch和CyclicBarrier使用介绍_countdownluach于cyclicbarrier的用法-程序员宅基地

文章浏览阅读330次。一、CountDownLatch介绍CountDownLatch采用减法计算;是一个同步辅助工具类和CyclicBarrier类功能类似,允许一个或多个线程等待,直到在其他线程中执行的一组操作完成。二、CountDownLatch俩种应用场景: 场景一:所有线程在等待开始信号(startSignal.await()),主流程发出开始信号通知,既执行startSignal.countDown()方法后;所有线程才开始执行;每个线程执行完发出做完信号,既执行do..._countdownluach于cyclicbarrier的用法

自动化监控系统Prometheus&Grafana_-自动化监控系统prometheus&grafana实战-程序员宅基地

文章浏览阅读508次。Prometheus 算是一个全能型选手,原生支持容器监控,当然监控传统应用也不是吃干饭的,所以就是容器和非容器他都支持,所有的监控系统都具备这个流程,_-自动化监控系统prometheus&grafana实战

React 组件封装之 Search 搜索_react search-程序员宅基地

文章浏览阅读4.7k次。输入关键字,可以通过键盘的搜索按钮完成搜索功能。_react search