为了支持UE的不同服务类型，需在一个时隙内用于HARQ-ACK传输的多于一个PUCCH，同时需构造至少两个HARQ-ACK码本。

以下选项被列为支持时隙内多个PUCCH用于HARQ-ACK的候选选项：

1. Option1： 基于子时隙的HARQ-ACK反馈过程

2. Option2： PDSCH分组

• Option2a：具有显式指示符的PDSCH分组（例如，在DCI或RRC信令中）

• Option2b：基于L1参数的隐式PDSCH分组，例如PRI、PDSCH类型

• Option2c：基于RRC参数的隐式PDSCH分组（K1 set、SLIV、CC set等）

• Option2d：基于PUCCH资源配置和处理时间线的隐式PDSCH分组（用于type I和type II码本）

• Option2e：基于DCI格式或RNTI的隐式PDSCH分组

3. Option3： Opt1和Opt2的组合（用于区分eMBB/URLLC HARQ-ACK码本的PDSCH分组）

4. Option4： “Codebook-less HARQ”

在一个时隙内支持用于HARQ-ACK传输的多个PUCCH的原始动机是为URLLC启用快速HARQ-ACK反馈，即避免位于时隙开始处的HARQ-ACK被迫与位于时隙结束处的HARQ-ACK复用，主要是为了降低时延。为此，最直接的方法是启用每个子时隙的HARQ-ACK复用和反馈。如下文所分析的，PDSCH分组方法更适合于不同服务的单独HARQ-ACK反馈，因此依赖于服务区分的方法设计，而基于子时隙的方法简单，甚至适用于纯URLLC UE。因此，Option 1 即更精细的K1指示，是优选的。

如果采用基于子时隙的方法，则URLC HARQ-ACK反馈应支持type 1和type 2码本类型。type 1码本可以为DCI未检测提供鲁棒性，如果有必要减少反馈冗余，可以配置一个小的K1集，或者在必要时依赖回退部署，即通过在主小区上使用Fallback DCI并将DAI_counter设置为1来调度数据。此外，基于子时隙的方法适用于type 1和type 2码本。对于type 2码本，可以简单地重用当前DAI机制，并以子时隙为单位指示PDSCH到HARQ ACK定时，然后将指向同一子时隙的所有HARQ ACK复用并联合反馈。但对于type 1码本，SLIV分割，即如何将可用的SLIV分割成不同的组以生成ACK/NACK反馈的候选时机，应该进一步研究。首先将配置的SLIV分配给每个子时隙，然后实现每个子时隙的SLIV拆分。该方法简单。或者，对于一个时隙中的子时隙，可以将其SLIV拆分在一起。这种联合分裂方法在某些情况下可以减少生成的候选机会。如图1所示，如果使用每个子时隙SLIV拆分，则属于第一个子时隙的SLIV｛#0、#1、355｝将被拆分为两个组，即，对应于2个候选时隙的 group {#0,#5} 和group {#1}和属于第二子时隙的SLIV {#2,#3,#4,#6,#7}。时隙将被分为四个组，即组｛#6｝、组｛2、#7｝、和组｝，组｛#3｝和组｛4｝对应于4个候选时机，导致6个候选时机和6比特ACK/NACK。如果使用每时隙SLIV分割，则仅生成五个组，即group {#6}, group {#2,#7}, group {#3} 和group {#4} 。与每子时隙SLIV分割类似，需要根据配置的K1集确定复用窗口。显然，不应考虑其结束符号不位于复用窗口中的SLIV。区别仅在于我们是独立地为每个子时隙执行SLIV拆分，还是一起执行属于一个时隙内的多个相关子时隙的SLIV拆分。

当同时构造至少两个HARQ-ACK码本以支持UE的不同服务类型时，可以基于一些PHY指示/属性来识别HARQ-ACK码书。

关于潜在的PHY指示/属性，可以考虑Opt2。一般而言，列出的五个子选项可分为两类，动态分组（包括Opt2a、2b、2e）和半静态分组（包括Opt.2c、2d）。显然，动态分组方法更适合于Type 2码本，这为eMBB和URLLC的单独HARQ-ACK反馈提供了最大的灵活性。我们可以将URLLC和eMBB的PDSCH分为两组，如果需要，甚至可以将具有不同可靠性要求的URLLC PDSCH分成两组。相比之下，半静态分组方法对于Type 1码本是有用的。在Type 1码本中，K1集、SLIV集和CC集对于确定候选时机和生成码本是必不可少的。因此，不必为半静态码本引入动态分组指示（显式或隐式）。此外，分割K1集、SLIV集或CC集可以减少每组中的码本大小，因此有利于减少类型1码本中的反馈冗余。最后，基于SLIV分裂的方法可用于启用UE内DL MUX和同时ACK/NACK反馈，用于紧急调度的URLC PDSCH（例如，PDSCH#9）和抢占的eMBB PDSCH，如图2所示。

此外，可以针对不同的ACK/NACK组分别配置不同的参数。例如，为eMBB HARQ-ACK反馈配置的PUCCH资源集应主要包含长持续时间的PUCCH资源，而为URLLC HARQ-ACK反馈而配置的PUSCH资源集则应主要包含不同时间位置上的短持续时间的PUCCH资源，以实现快速反馈。类似地，可以为URLLC HARQ-ACK反馈和eMBB HARQ-ACK反馈配置不同的最大编码速率，以提供不同的传输可靠性。

如果两个PUCCH都携带eMBB UCI，我们可以简单地重用R15 MUX规则。这里主要讨论以下两种情况：URLLC UCI与URLLC UCI重叠，以及URLLC-UCI与eMBB UCI重叠。显然，以下讨论的前提是如何确定不同服务的优先级，或者如何判断UCI是用于URLLC服务还是用于eMBB服务。

在R15中，定义了时间线，并且仅当时间线满足重叠PUCCH时，才执行UCI MUX。重叠PUCCH不满足时间线的情况被视为错误情况，并且不指定UE行为。然而，R15中的所有错误情况在R16中都是不可避免的，因为URLLC UCI，特别是URLLC HARQ-ACK，将被紧急调度，导致与非常接近相应PDSCH的其他UCI重叠，如图3所示。

URLLC UCI与URLLC UCSI重叠

如果两个PUCCH都携带URLLC UCI，即具有高优先级的UCI，那么我们还可以重用R15中的MUX规则。一个额外的考虑是如何处理两个包括不同URLLC HARQ-ACK码本在时间上重叠的PUCCH。一个候选方案是将两个HARQ-ACK码本级联并联合编码。但是，将这两个HARQ-ACK码本串联在一起将在Type 1码本下引起相当大的反馈冗余。

URLLC UCI与eMBB UCI重叠

协议有以下两个选项来解决URLLC UCI和eMBB UCI的冲突。

• Option1： 优先考虑URLLC UCI传输并丢弃eMBB UCI；

• Option 2： 如果满足时间线，则MUX；否则，优先考虑URLLC UCI传输并放弃eMBB UCI。

尽管eMBB UCI的优先级低于URLLC UCI，但这并不意味着eMBB-UCI，特别是eMBB HARQ-ACK并不重要。总是丢弃eMBB UCI将导致大量重传，从而在URLLC流量频繁到达时对eMBB性能造成严重影响。另一方面，始终采用Option2可能从延迟和可靠性的角度对URLLC UCI造成负面影响。

一种组合方式是决定eMBB UCI是否与URLLC UCI进行复用，还是应将其丢弃，这取决于复用是否会延迟URLCUCI传输或增加URLLC UCI的编码速率。如果是，则不应执行多路复用，应丢弃eMBB UCI。

类似地，如果eMBB UCI与eMBB数据重叠，我们可以重用R15 MUX方法。

URLLC PUCCH与eMBB PUSCH重叠

如果两者的时间线都满足，则应考虑是否执行MUX以及如何保证URLLC UCI的低延迟和高可靠性。一种增强是在eMBB PUSCH启用跳频（FH）的情况下，仅在第一跳上映射URLLC UCI以减少延迟。另一个示例是为URLLC UCI和eMBB UCI配置不同的贝塔偏移值，以实现不同的有效码率，从而产生不同的可靠性保证。

eMBB PUCCH与URLLC PUSCH重叠

简单的解决方案是丢弃UCI并仅发送高优先级URLLC PUSCH。然而，eMBB UCI可能具有小的有效载荷，例如ACK/NACK，并且背负该UCI不会消耗太多资源。则期望以可忽略的数据可靠性降级来传送ACK/NACK和URLLC数据。此外，UCI甚至可能是URLLC UCI，因此无论UCI有效载荷和/或UCI类型如何，直接丢弃UCI都很困难。可以通过DCI中的指示来设计动态启用/禁用机制，以指示UE不在PUSCH上搭载UCI。

同时，假设UCI背负是强制性的，我们可以通过灵活选择β偏移值来调整UCI和数据之间的资源分配。 例如，我们可以扩展当前beta-offset值的范围，以至少包括beta-offset<1。请注意，如果beta-offset=0是可行的，那么我们可以使用beta-offset直接禁用UCI。

URLC PUCCH与URLC PUSCH重叠

对于URLC PUCCH与URLC PUSCH重叠的情况，如果满足时间线，则应执行UCI。否则，如果不满足时间线，则UE应优先考虑一个上行链路传输并丢弃另一个。简单地，UE可以将动态调度的上行链路信道优先于配置的信道或将稍后调度的信道优先于早期调度的信道。