针对URLLC的PDCCH
协议规定对于最大数量的非重叠CCE和至少一个SCS，应支持PDCCH监控。
在Rel15中，每个时隙的非重叠CCE和BD的最大数量取决于子载波间隔。对于15、30、60kHz和120kHz，UE可以对每个时隙的{56、56、48、32}个CCE执行信道估计，并对{44、36、22、20}个PDCCH候选进行盲解码。超过这个数量仅适用于PCell。因此，在任何给定时隙中，UE必须分析search space配置是否会导致用于信道估计的CCE需要更多和用于候选检测的BD是否支持超过这个数量。如果出现这种情况，则UE必须根据预定义的规则执行PDCCH丢弃，直到所需的BD和CCE都在其限制内。
为了评估PDCCH候选丢弃的必要性，时隙期间的BD和CCE计数对于UE来说是一个复杂的功能，它需要检查所有search space set、所有aggregations level、搜索空间的所有潜在不同起始符号等。例如，在某些情况下，两个PDCCH候选将被视为一个盲解码，而在其他情况下，它们将被计数为两个。
为了计算信道估计所需的盲解码（BD：blind decode）和CCE的数量，UE必须执行以下比较：
在对盲解码进行计数时，两个候选将被视为一个BD，条件是：
他们在同一个CORESET中
它们映射到相同的CCE
用加扰序列对它们进行加扰
其他人的DCI大小相同
在计算CCE时，两个CCE将被计算为信道估计的一个CCE，条件是：
属于同一CORESET
他们使用相同的起始符号占用相同的CCE
Rel-15的PDCCH丢弃规则是CSS优先于USS，如果超过最大#BD或最大CCE，则至少会丢弃USS中的PDCCH候选。一旦其任何PDCCH候选无法映射，整个USS集将被丢弃。在Rel-15中，在USS搜索空间集中删除所有PDCCH候选对于实现来说似乎很简单，但对URLLC并不是这样，因为可能会丢失监控机会，从而增加URLLC时延。下图1中的示例对此进行了说明。配置了两个CC，对于CSS#0，在symbol #0和symbol #7中需要7个BD。对于CSS#1，在symbol #0中需要两个BD。在同一symbol #0，也需要监控USS1，这需要16个BD。USS2每个监控时机需要2个BD，但在时隙中有7个机会，因此USS2需要14个BD。USS2的配置可以被视为URLC的典型配置，时隙中具有多个时机，以确保低时延，并且每个时机中只有少数候选，因为很可能会使用高聚合级别来保证可靠的PDCCH检测。在本例中，BD的总数总计为46个，超过了44个BD的限制。因此，整个USS2需要被丢弃，并且URLLC服务的所有监视时机都将丢失。在该丢弃之后，UE仅需要在该时隙期间执行46-14＝32个BD，即，它远低于其能力。
为了保证URLLC所需的低时延，在一个时隙中将有多个监控时机。因此，计算所需BD和非重叠CCE数量，UE需要在一个时隙中执行多次，每个时隙一次，而不是Rel-15的情况下的每个时隙。这会增加UE的复杂性。
另一方面，如果CCE/BD的数量与Rel-15相比有所增加，则为每个跨度设置一些限制也是有用的。原因是UE仍然需要满足N1（PDSCH到HARQ）和N2（DCI到PUSCH）的处理时间要求。例如，在Rel-15中，UE必须在一个跨度期间支持56个非重叠CCE（对于SCS 15kHz），并且仍然能够及时解码DCI，以便在N2个符号之后发送PUSCH。当与Rel15相比，非重叠CCE的最大数量将增加到更高的值，并且UE应该能够在一个跨度期间对所有CCE执行信道估计时，那么满足UE处理时间要求就很困难。可能影响处理时间的另一个问题是PDCCH监视和PDSCH处理之间的潜在冲突。
扩展非重叠CCE的最大数量可以提高PDCCH监控的粒度，并有助于减少URLLC时延。对于UE实现来说，增加UE在每个时隙使用更多CCE中执行信道估计的能力是很困难的。在Rel-15中，每个分量载波定义了信道估计的最大CCE数。因此，与Re-15相比，还应为每个载波定义增加的数目。为了保持UE的复杂性可管理，应限制UE可同时服务的CC的数量。
首先，一些UE可以在一个监视时刻通过调度特定于UE的数据来仅监视一个DCI大小。并且至少对于仅支持一种服务类型的UE，可能只需要在时隙的开始处监视多个DCI大小。因此，也就是说，对于某些UE，BD的数量可以等于Rel-15中的数量，并且配置可以保证BD的数目小于其限制。
其次，为了保证URLLC的可靠性，大部分较高的AL（例如16、8、4）将用于这些UE。并且没有那么多的候选者可以为这些AL配置以适合CORESET。如果可能时应使用小AL来减少阻塞，则只需配置这些额外候选者中的极少数。不同的UE可以具有用于小AL的不同候选位置。
对于Rel-16 NR URLLC的DCI调度，已同意支持某些字段的大小可配置，虽然最大DCI大小可以大于Rel-15 Fallback DCI，最小DCI大小的目标是比Rel-14 Fallback DCI的DCI format size小10~16位，但还应考虑与Rel-15 Fallback DCI的大小对齐的可能性。
Potential compressed DCI fields
为了使最小DCI大小比Rel-15 Fallback DCI的小10~16位，可以潜在地压缩传统DCI format1_0中的以下一些位字段以减小DCI大小。应注意的是，该“free”空间也可用于新字段，与Rel-15 Fallback DCI相比，这些字段可以在不增加总DCI大小的情况下添加。
Header：仍然需要1个报头位来区分DL和UL DCI。
Frequency domain resource allocation：对于URLLC，它可以在保证可靠性的情况下及时传输。在这种情况下，资源分配的灵活性变得不那么关键，可以采用更粗的频率粒度。关于资源分配类型，可以考虑修改的资源分配type1，其中最小单元基于RBG。type0的RBG表设计可用于修改后的资源分配type1，type0的RBG大小配置也可重复使用。
Time domain resource allocation：对于URLLC应用，配置的时域资源分配表可以更小。例如，4行就足够了，因此对于PDSCH时域资源分配，在紧凑DCI中不需要多于2位。为了减少时延和减少时域资源分配比特字段，可以支持使用PDCCH区域的边界（例如PDCCH结束符号或开始符号）作为紧凑DCI的参考点。这可以压缩SLIV字段的位数，而不会对定时指示灵活性造成严重影响。
HARQ process number, NDI, RV and MCS/TBS：DCI中只需要保留一组｛NDI、HARQ process numbe、MCS｝位字段，因为根据协议，只能调度一个TB。考虑到一个UE的SINR统计可能不覆盖大范围的值，可以考虑具有较少比特数（例如4比特）的UE特定MCS指示。此外，给定信道状态可能变化不快，可以考虑RRC配置和DCI指示的组合以保证UE的精确MCS值。在Rel-15中，对于HARQ process numbe，对于Fallback DCI和non-fallback DCI，4位都是固定的。对于URLLC，这是不必要的，并且可以根据由更高层配置的HARQ进程的数量来设置比特数。假设支持多达8个HARQ进程，在紧凑DCI中3比特就足够了。NDI字段和RV字段可以保持不变，以保证重传的性能。
HARQ-ACK timing:对于Rel-15，同意使用3位来指示正常DCI中的K1时隙定时。对于URLLC，需要快速HARQ RTT，2比特可能就足够了。更积极的选择是完全删除HARQ-ACK定时指示字段，并让A/N定时由PDSCH位置和UE能力隐式指示。
PUCCH resource allocation：在Rel-15中，同意使用3位来指示8（最多32）个PUCCH。对于URLLC，这是不需要的，并且可以减少该字段。PUCCH的起始符号可以与HARQ-ACK定时一起被隐式指示。对于具有相同起始符号的PUCCH资源，1比特指示符足以指示PUCCH。
TPC fields：该字段可以与DCI format1_x相同，以保证PUCCH的可靠性。
Other DCI fields：为了保持较小的DCI大小，DCI format1_0的其他字段可以配置为低至0位，例如DAI和VRB到PRB的映射。
而对于上行DCI字段呢？
Potential compressed DCI fields
可以潜在地压缩传统DCI format0_ 0中的以下位字段以减小DCI大小或为潜在添加的字段生成空间。
可以使用与DL DCI相同的原理来设计一些公共字段，例如报头、频域/时域资源分配、HARQ进程号、NDI、RV、MCS/TBS、TPC命令。其他领域的注意事项如下：
Frequency hopping flag：为了保证PUSCH的可靠性，应支持跳频，UL compact DCI中应包含1位跳频标志。
UL/SUL indicator：该字段可以配置为0位，以节省开销。
