《927-基于Code Block Group 的 HARQ-ACK 反馈.docx》由会员分享，可在线阅读，更多相关《927-基于Code Block Group 的 HARQ-ACK 反馈.docx（2页珍藏版）》请在第壹文秘上搜索。
1、基于COdeBlockGroup的HARQ-ACK反馈基于CBG的HARQ-ACK反馈设计的动机是存在Short-duration干扰。这种类型的干扰可以通过抢占HIBB数据传输或来自小区的Short-duration传输以URLLCeMBB复用的形式出现。为了促进接收机硬件的快速流水线处理，人们希望编码数据位先在频域分布，然后在时域分布。对于具有高数据速率传输的链路，传输块中的多个代码块可经历实质上不同的性能。然而，对于数据速率较低或无线资源分配较小的链路，ShOrt-duration干扰对性能的影响较小。基于CBG的HARQ-ACK反馈的使用将增加上行控制信道的负载，并需要更多资源。如果S
2、hOrLduration干扰没有以足够高的频率出现，依赖传统的单位反馈可能会更有效。基于上述分析，可以得出结论，并非所有场景都需要基于CBG的HARQ-ACK反馈。对于特定场景，并非所有UE都需要它。此外，UE可以受益于用于下行的CBGHARQ-ACK反馈过程，但对于上行不一定如此。应该由gNB实现决定何时将其用于UE的正确场景。作为UE的CBGHARQ-ACK配置的一部分，提供CBgroup的大小。这可以通过RRC信令来半静态地配置每个UE。由于CBG大小是半静态配置的，所以组大小适用于特定PDSCH或PUSCH链路的所有传输。对于任何给定的传输，CB的实际数量由分配的无线资源、MlMO层的
3、数量以及调制和码率(MCS)确定。这些CB应根据固定规则组织成配置数量的CBG,以便发射机和接收机能够正确地为CBG交换HARQ-ACK。例如，如果一个UE配置了3个CBG,并且PDSCH包含8个CB,那么固定规则可以将3个CBG组织为CBG#g(CB#0,CB#1,CB#2),CBGttl=(CB#3,CB#4,CB#5)和CBG#2二(CB#6,CB#7)o针对CBG是否需要引入额外的CRC?应根据相对于CB级CRC的益处以及对高效接收器硬件实现的影响来分析。基于CBG的HARQ-ACK反馈的有用性是因为不同CB的性能可能不同。由于仅当传输块大小超过8192位时才存在多个cb,因此每个Cb
4、具有数千位。进一步注意，LDPC码具有固有的错误检测能力，这也在信道编码设计中讨论。对于这些大型LDPCCB,固有的错误检测能力可能会漏掉block错误，概率不高于10%随着CRC比特数的增加，CB级CRC的可靠性可以成倍提高。由于CB的大小大约为数千位，添加几个CRC位会导致吞吐量损失可以忽略不计。显式CB级CRC的实际数量可能很小，但仍能实现较高的错误检测可靠性。另一方面，CBG级CRC不是也不能集成为LDPC解码过程/硬件的一部分。因此，它会导致额外的硬件/处理，并导致额外的延迟。由于其检错能力不能与LDPC码的检错能力相结合，因此需要足够长的CBG级CRe连接，以满足CBG检错要求。为
5、了满足NR的高数据速率和严格的低延迟要求，gNB和UE侧的接收机架构都需要通过并行化和流水线硬件设计进行优化，如图1所示。CB级CRC校验通常可以集成在解码硬件中，以实现高效率或帮助提前停止迭代解码。软值和解码位的路由也被优化，以最小化缓冲存储器的使用。从高吞吐量和低延迟硬件设计的角度来看，这种CBG级CRC可能会对实现产生重大的负面影响。由于CBGHARQ-ACK流程并不总是有用或使用的，因此并不总是需要计算额外的CBG级CRCo进一步注意，不同的CBG可以包含不同数量的CB。为了支持所有这些不同的可能性，实现需要将位的有条件重新路由添加到复杂设计的并行和流水线硬件中。这可能会造成进程锁定以
6、及额外的缓冲内存需求。CB M2CBMlOeCOanOCBW-ISlan TB reception图1: NR接收器的并行处理和信道处理重传的安排方式与原始传输的安排方式类似。因此，在接收到NACK（用于下行数据传输）或检测到错误接收的上行数据（用于上行数据传输）时，gNodeB需要调度重传。HARQ过程的数量取决于总往返时间。对于下行数据传输，这包括用于生成确认的UE处理时间、用于调度重传的网络侧处理时间，以及在使用远程无线单元将基带处理与实际传输站点分离的情况下的前端传输延迟。光纤中的光速约为2-IO*m/s。因此，对于15km的距离，双向延迟为150Us0调度延迟可以在类似的范围内，这取
7、决于实现、网络负载、服务质量处理方面的调度复杂性、信道条件的利用、多用户MRK）方面，作为比较，假设14个符号时隙和120kHz子载波间隔，时隙长度为125So从上面的简化讨论可以看出，从传输到重传的时间可以是几个时隙的顺序，从而激发了多个HARQ流程。同时，保持HARQ进程的数量较小是有益的。此外，支持不同numerology的不同数量的混合ARQ过程将使整体结构复杂化，最好使用单个numerology。因此，建议在NR中支持8个HARQ进程,即在DCl中使用3位作为HARQ进程编号。UE中的软缓冲存储器的量随着往返时间的增加而增加。UE中所需的存储器量可以基于比HARQ处理数中的比特数所给
8、出的最大可能值更小的HARQ处理数来确定。这将允许在以减少增量冗余增益为代价的情况下，使用更多进程进行操作。对于IJL和DL,都使用异步HARQ,因此DCl消息需要指示调度的相应HARQ进程。为了限制DCl开销，应根据最大限度支持的HARQ进程设计DCI消息。出于调度目的，可以在特定的载波上调度时隙或迷你时隙。假设一个Inini时隙所需的相应处理时间随着时间长度的增加而缩短。有一些恒定因素可能会使处理时间稍长，包括可能提前的最大计时。作为起点，可以假设时隙和迷你时隙的HARQ进程数量相同。为了在单个载波内实现调度的完全灵活性，将相同的HARQ进程同时适用于迷你时隙和时隙将更有意义。这将支持在迷你时隙和基于时隙的传输之间切换调度。需要考虑的另一个方面是单个HARQ进程是否可以跨组件载波移动。可以注意到，已经针对LTE讨论了这一方面，而没有在这里介绍。这个话题有多个方面需要考虑。首先，如何解决Ll上的HARQ进程以及该进程的MAC处理。同时，该功能本身的具体增益也不直接清楚，尽管因此可能实现更高的频率分集增益。需要进一步注意的是，如果该特性在LI和MAC上不受支持，那么它将在RLC级别上受支持。
