HARQ调度增强
Rel-16在URLLC场景支持无序HARQ（OoO-HARQ：Out-of-Order-HARQ），即对于具有不同HARQ进程ID的两个PDSCH，可以在较早PDSCH的HARQ-ACK之前发送稍后PDSCH的HARQ-ACK。针对两个PDSCH的UE处理协议提出了三种情况的解决方案：
Case0：同一载波中支持无序HARQ-ACK操作，且具有单一处理时间能力。
Case1：当将不同的最小处理时间线能力配置为同一载波上的PDSCH时，跨具有不同最小处理时间线能力的PDSCH支持无序HAQ-ACK操作。
Case2：当在同一载波上同时配置额外DMRS和PDSCH处理时间能力#2，且带有附加DMRS的PDSCH遵循最小PDSCH处理时间能力#1时，不同处理时间线能力的PDSCH支持无序HAQ-ACK操作。
针对无序HARQ，协议规定如下：
如果支持Case0，且UE支持无序HARQ操作，并且如果pdsch在时域中不重叠：
UE处理所有PDSCH而不丢弃，以下情况除外：
1. Rel-15支持UE回退到capability #1，并支持报告pdsch-ProcessingType2-Limited的UE丢弃行为。
2. 在Case0下，不能在给定的载波上同时配置额外的DMRS和capability 2。
如果支持Case1或Case2，并且如果UE在某些条件下不能处理所有pdsch，并且如果pdsch在时域中不重叠，则：
UE始终处理与capability 2相关的PDSCH
如果在与capability 2相关联的PDSCH开始之前，UE的最后一个符号至少N1个符号，则UE处理与capability 1相关联的PDSCH。
1. N1是capability 1的最小处理时间线。
一、处理非重叠PDSCH
Case0，其中OoO在同一载波中具有单一处理能力
在Rel-15中支持相同处理时间的HARQ-ACK。因此，图1中所示的两个场景是支持的。
在Rel-15中，支持具有相同处理时间线的背靠背调度。因此，对于Rel-15 UE，只要所有pdsch遵循相同的处理时间线，就不应该存在流水线问题。
因此，从Rel-15到支持无序调度和处理两个pdsch（当它们遵循相同的处理能力时）仅仅是非常小的一步。处理单元中的流水线不受影响。
此外，如果Rel-15 UE报告pdsch-ProcessingType2-Limited，则UE丢弃行为可以考虑不同SCS的Rel-15定义。然后，当使用超过136个PRB调度PDSCH时，UE将应用capability#1处理时间，即使为小区配置了capability#2。调度不超过136个PRB的后续PDSCH仍将使用capability#2处理时间进行处理。在这种情况下，将发生流水线问题。当UE处理单元应该开始处理较后的capability#2 PDSCH时，它们仍将被占用来处理较早的capability#1 PDSCH。为了解决这些流水线问题，对于30khz SCS，当UE的最后一个符号距离下面的capability#2处理时间PDSCH的开始时间小于10 OS时，允许UE丢弃第一个PDSCH。
Case1，当同一运营商上配置了不同的最小处理时间线能力时，OoO跨不同最小处理时间线能力的PDSCH
这样做主要动机是为了省电。如果eMBB PDSCH可以遵循较慢的处理时间，那么就有一些降低功耗的空间。
当允许更宽松的UE处理能力时，时钟速率可以降低。然而，目前还没有证据表明时钟频率的降低是可能的，如果可能的话，能节省多少电也没有答案。即使降低时钟频率可以降低峰值功耗，也不清楚它会在多大程度上降低平均功耗。原因是，在较低的时钟频率下，芯片组需要运行更长的时间，消耗的能量可能仍然相同。
Case2，当在同一载波上同时配置附加DMRS和PDSCH处理时间capability#2时，OOO跨具有不同处理时间线能力的PDSCH，并且具有附加DMRS的PDSCH遵循最小PDSCH处理时间capability#1
在高速场景中eMBB/URLLC复用的情况下，eMBB PDSCH将具有额外的dmrs以改进信道估计性能。URLLC将遵循capability2的处理时间，而eMBB有一个额外的DMRS，并遵循capability1的处理时间。额外的DMRS和UE PDSCH处理capability2可以在同一载波上同时配置，以确保eMBB和URLLC的良好性能。
在同一载波上不需要两个可配置UE处理能力，就可以支持上述Case2。如果附加dmrs将与UE处理capability2一起配置在同一小区上，则可以基于PDSCH持续时间来决定是应用capability1处理时间还是应用capability2处理时间。带有额外DMRS的长PDSCH将遵循capability1处理时间，短PDSCH将遵循capability1处理时间。
1） FFS是否受Rel-15限制
在Rel-15中，对于具有使用30kHz SCS的调度限制的UE处理capability2，如果调度的RB分配超过136 RB，则UE默认为capability1处理时间。另一方面，对于没有调度限制的UE处理capability2，即使调度的RB分配超过136 RB，UE仍然使用capability2处理时间。
PDSCH处理capability2触发以跳过一些PDSCH处理capability1的情况类似于无序HARQ，即有限的UE能力将导致跳过一些PDSCH的解码。因此，Rel-15中定义的PDSCH跳过的RB数也可以作为OOO处理的条件。
2） 是否包括与capability2相关联的PDSCH在与capability1相关联的PDSCH之前的情况
考虑到URLLC传输的低时延要求，后面的URLLC PDSCH应该使用处理capability2时间表。如果URLLC使用PDSCH处理capability1，eMBB没有动机与capability2关联，因为eMBB HARQ-ACK并不比URLLC HARQ-ACK更紧急。所以，这种情况很少发生。此外，gNB的实现也可以避免这种情况，例如gNB表示eMBB流量的HARQ反馈时间较大。
3） UE可以跳过对与capability1相关联的PDSCH的解码。
当与capability1相关联的PDSCH的UE行为不确定时，gNB可以假设最坏情况。因此，在这种情况下，UE应该跳过对与capability1相关联的PDSCH的解码，并且报告PDSCH的HARQ以用于gNB重传。
此外，如果UE总是丢弃与capability1相关联的整个PDSCH，则eMBB PDSCH性能损失太大。因此，作为增强，可以考虑仅丢弃与capability1相关联的第一个PDSCH的一些CBG，而不是丢弃整个TB。这可以避免不必要的CBG重传并提高系统效率。这一概念如下图2所示。
如上图2所示，当PDSCH1的结束和PDSCH2的开始之间的时间间隔小于N1个符号时。因此，整个PDSCH 1不能被解码，但是在一些CB的结束和PDSCH 2的开始之间的时间间隔足够大以处理这些剩余的CB。这些剩余的CB仍然可以被解码。解码后的CB可以提高重传性能和系统效率。
二、处理重叠资源
Rel-16 NR中，应引入以下UE能力来处理两个单播pdsch之间的冲突：
Capability A：在场景1-1中，UE处理两个PDSCH的能力
Capability B：在场景1-2下，UE处理两个PDSCH的能力
1. 关于信令能力的细节进一步讨论
2. 在场景1-2中，描述UE在频域中处理重叠资源的行为。
Capability C：UE始终处理高优先级PDSCH的能力。在某些调度条件下，UE只处理低优先级PDSCH。
对于URLLC来说，对重叠资源的调度是有意义的，无论是对于相同的还是对于不同的能力处理时间线。因此，此功能与能力处理时间线无关。例如，eMBB PDSCH传输可以由紧随任何功能的紧急URLLC PDSCH传输抢占。在这种重叠的PDSCH场景中，处理高优先级信道将带来良好的性能。
对于场景1-2，gNB通常一次只在同一PRB上发送一个PDSCH。在相同频率资源上，两个PDSCH不存在传输，例如，两个PDSCH都可以在不同的层上。然后对于Capability B UE，处理重叠PDSCH的UE行为将与UE的能力相同。不必区分这两种能力。
对于Capability C UE，如果资源重叠，UE信道中将发生冲突。这应该以与OoO HARQ场景中的流水线冲突相同的方式处理。因此，应该丢弃低优先级信道。
在资源重叠的情况下，特别是对于重叠的PRB，不需要支持处理低优先级信道。因此，更倾向不考虑Capability C UE的调度条件，并且UE总是跳过低优先级PDSCH的译码。
重叠PDCCH和PDSCH
目前的讨论主要集中在PDSCH与PDSCH的重叠上。另一个重要的场景是，后面的PDCCH与前面的PDSCH重叠。在Rel-15中，RMI可以在DCI中使用，DCI正在调度PDSCH以指示特定资源（包括CORESET）周围的速率匹配。URLLC的监视时机的周期性可以很小，以确保短的时延，并且CORESET还可以占用许多频域资源以确保足够的可靠性。因此，需要为URLLC 的CORESET保留大量资源，如下面的图4所示。早期计划的eMBB-PDSCH将围绕CORESET进行速率匹配。它不能利用所有可用的资源，即使大多数监控场合都是空的，并且不用于实际传输PDCCH。这可以用“绿色” 下面图3的示例中的PDSCH。
如果UE监视URLLC DCI并同时处理相同资源上的eMBB数据，如下面的图4所示，则可以避免通过CORESET周围的速率匹配造成的资源浪费，而是在整个资源矩形上传输eMBB PDSCH（如下面的图4中的绿色所示）。gNB可以在包括预配置的URLLC CORESET的资源上调度eMBB数据。如果URLLC数据到达，则通过屏蔽eMBB数据资源来传输URLLC DCI（DCI2）。
在UE侧，在每个配置的监视时刻监视DCI。如果未检测到DCI，则PDSCH将正常解码。如果检测到DCI，UE知道相应的资源被屏蔽（图5中DCI#2的资源），并且它可以尝试解码eMBB分组的未受影响部分或丢弃它。
增强下行 PI
在38.213中，给出接收到PI时的UE行为：“如果UE从所配置的一组服务小区中检测到服务小区的DCI Format2_1，则UE可以假设在PRB和符号中、从一组PRB和上一监视周期的一组符号中不存在到UE的传输。”因此，UE可以忽略整个指示区域。Rel-15期间已经讨论过的一个问题是URLLC流量的潜在“self-flushing”。如果UE监视下行PI，则它可以用INT-RNTI刷新DCI指示的资源，即使这些刷新的资源被分配给该UE的URLLC通信量。
在Rel-16中，如果在物理层中引入URLLC/eMBB标识，则应该考虑DL PI增强，因为DL PI可以配置到支持多个服务的UE是至关重要的。如果UE接收到调度的URLLC流量，则可以跳过监视PI或不刷新与URLLC流量相关的缓冲区。如果UE接收到调度的eMBB业务，它可以监视PI并遵循PI指示Rel-15。
BWP切换时的无序操作
根据38.213，当活动BWP被调度DCI切换时，UE不需要发送或接收，直到包含调度传输的时隙开始。这对UL和DL都有效。当激活BWP切换时，指定开关延迟。在该开关延迟期间，UE不需要发送UL信号或接收DL信号。开关延迟以时隙单位定义：
PDSCH的K0或PUSCH的K2值指示的间隙可以大于BWP开关延迟。对于K0=5时隙的PDSCH，如下图5所示。如果BWP开关延迟是例如2个时隙，那么当BWP开关在时隙“n”中启动时，根据当前Rel-15规则，在时隙n+3和n+4中预期没有传输或接收，即使它们在BWP开关延迟之后。然后，这些时隙将被阻止用于紧急URLLC通信。一个可能的Rel-15解决这个问题的方法是限制K0，使其不能接受大于BWP开关延迟的值。但这严重制约了eMBB调度的灵活性。
因此，对于Rel-16，建议UE可以期望在BWP交换机延迟之后直接在时隙的开始接收和发送（至少用于高优先级服务数据调度）。
