921-下行HARQ反馈的资源分配.docx

《921-下行HARQ反馈的资源分配.docx》由会员分享，可在线阅读，更多相关《921-下行HARQ反馈的资源分配.docx（2页珍藏版）》请在优知文库上搜索。

1、下行HARQ反馈的资源分配在LTE中，用于下行传输的报告HARQ反馈发生在预定时频资源上的固定延迟之后，其中报告延迟通常由UE处理传输块（TB）和相关CRC的能力限定。UE隐式地报告在PUeCH上的HARQ反馈，而不需要调度，或者报告PUSCH上的部分用户控制信息（IJCI）,其中下行HARQ反馈与DCI指示的时频资源上的上行数据一起复用。在NR中，默认情况下可以保持相同的行为，因为它减少了控制信道上的调度开销。UE可以根据配置的反馈报告延迟（Kl时隙）和上行控制资源可用性，确定传输资源以隐式地报告下行HARQ反馈。在需要动态自适应来报告HARQ反馈的情况下，可以在NR-PUSCH上动态地调度

2、下行HARQ反馈的资源分配。在这种情况下，动态分配给下行HARQ反馈的资源将覆盖用于报告HARQ反馈的默认隐式资源。当UE需要报告大的HARQ反馈有效负载或反馈报告延迟改变时，动态资源自适应实现了所需的额外灵活性。对于基于CBG的HARQ,UE提供多位HARQ反馈，以指示需要在TB内重新传输Cb的子集。HARQ反馈资源的动态分配有助于避免在高负载条件下对PUCCH的额外干扰。当配置基于CBG的HARQ时，当HARQ反馈有效载荷具有多于一个比特时，这尤其如此。反馈资源的动态分配还为gNB提供了更大的灵活性，以控制UE在PUSeH上的传输功率。在信道条件差的情况下（例如，高BLER或低CQI）,U

3、E抑制HARQ反馈可能是有利的，直到执行了一定数量的重传。这在上行控制信道上以低开销成本实现了改进的覆盖和可靠性，因为下行HARQ反馈仅在第X次重传之后发送。将X配置为零会导致与LTE中相同的行为。图1显示了x=2时的反馈抑制。当HARQ工作点可能产生失败的初始传输次数，并且信道正在缓慢变化（例如低移动性UE）时，可以使用HARQ反馈抑制。在这种情况下，抑制下行HARQ反馈直到TB可能已经成功的传输号码在上行控制信道上产生较少的不必要的nack.对于小区边缘条件下的UE、以毫米波频率服务的经历高路径损耗的UE,以及信道条件较差的MTCUE,可以设想这样的场景。在未经许可的部署的情况下，还可以使

4、用HARQ抑制来减少UE执行的先听后说（LBT：Listen-Before-Talk）的次数，直到知道上行资源可用为止。Downlink图1:对x=2的HARQ反馈压缩的说明此外，当每CB多位HARQ反馈用于报告TB的哪些部分失败时，UE应该能够抑制每TBHARQ反馈。在这种情况下，将X设置为大值（或无穷大）可以被视为禁用给定HARQ实体的隐式每TB反馈。或者，当不再需要多比特HARQ反馈时，可以将X设置为传输号码。如果在几次重传后认为一位反馈足够，这是适用的，因为在多次重传后，剩余BLER和重传的CB数量减少。X的值可以针对每个HARQ实体进行配置，从而在Ue具有在不同HARQ操作点的HAR

5、Q实体上配置的不同服务时实现额外的灵活性。由于X的值对L3的影响有限，并且可能根据某个HARQ实体的HARQ状态而频繁改变，因此最好让MAC调度器在DCl中为使用中的每个HARQ实体分配X。为了在每个UE的基础上为初始反馈报告实例实现额外的灵活性，gNB调度器应该能够覆盖HARQ反馈抑制，该抑制是通过在NR-PDCCH信道上向UE分配的调度信息中发信号来配置的。这将有可能覆盖小于第X次传输的TB传输的下行HARQ反馈抑制，从而提供请求反馈的能力。通过请求UE报告所使用的每个HARQ实体的所有HARQ过程的HARQ状态，可以促进gNB调度器的这种决定。这里的一个例子是，当X被配置为一个大数字时，

6、尽管UE己经成功地从几个传输中解码了TB。在这种情况下，报告的HARQ状态可用于改变X的值或终止该UE的反馈抑制。为gNB同时提供URLLC和WBB数据的要求导致eMBB数据被URLLC数据屏蔽的可能性。为了帮助受害UE接收屏蔽数据提高成功解码的概率，已经同意gNB可以动态地通知UE下行数据已被屏蔽的事实。多位HARQ-ACK反馈的部分动机是eMBB传输可能不时被屏蔽。对于接收UE,使下行数据的一部分被屏蔽相当于在被屏蔽的时频资源处经历强突发干扰。因此，对于UE来说，将损坏的代码块指示回gNB,并且让gNB仅重新传输所指示的代码块是合理的方法。支持多位HARQ-ACK的另一个动机是NR系统中的

7、代码块数量大幅增加。NR系统中的代码块数可能达到70。这将与LTE/LTE-a系统中略高于10的最大数量进行比较。由于只有一个代码块解码失败，显然不需要重新传输所有代码块。根据当前的工作假设，一个CBG只能包含一个CB。这意味着，在极端情况下，如果使用位图，UE必须向gNB反馈70多位，以指示解码结果。这显然给上行反馈信道带来了太多负担。此外，更高的CBG指示粒度会降低资源利用效率。因此，值得研究的是，是否应支持普通位图以外的信令方案，和/或在所有情况下都应允许全范围CBG大小。如前所述，支持多HARQAeK方案的动机至少包括被低延迟叮IlC数据刺穿的可能性，以及大幅增加的代码块数量。可以说，这种动机也适用于上行传输。通过在上行方向上启用基于CBG的传输，也可以获得类似的资源分配效率提升。然而，与下行情况不同，CBG指示必须在ULgrant中传输，因为NR将支持异步自适应上行HARQo