URLLC中如何提高RRC_CONNECTED UE的可靠性

码本/PUCCH-config 分离

UE可配置为生成单独的HARQ-ACK码本，对应于单播的不同优先级，包括Rel-16中规定的Type-1和Type-2码本。支持多播的UE也可配置为分别为单播和多播生成单独的码本，对于Type-2 HARQ码本。

一般来说，组播调度针对一组UE进行接收，但单播调度可能只考虑单个给定的UE。因此，从网络的角度来看，授权网络独立管理单播调度和多播调度是有利的。假设HARQ-ACK反馈可能影响后续调度，则网络可相应地请求UE独立地生成HARQ-ACK码本，而不考虑相同或不同的优先级，例如，通过为多播配置单独的PUCCH-Config。

为相同优先级生成单独码本的另一个好处是，它可以简化基于时隙的多播PUCCH和基于sub-slot的单播PUCCH的问题。具体地说，当UE被配置为具有与单播和基于时隙的PUCCH和基于sub-slot的PUCCH不同的用于多播的单独PUCCH-Config时，其中，如图1所示，如果用于单播和多播的HARQ-ACK比特具有相同的优先级，如果仅支持复用HARQ-ACK比特以生成具有相同优先级的单个码本，则需要针对图1中的这种情况定义如何复用HARQ-ACK比特，该情况需要考虑UE处理时间线，并且由于预期了如此多的规范工作。相反，尽管优先级相同，但生成两个单独的代码本可以简化此问题，并且可以重用URLLC中为不同优先级指定的机制。具体地说，只要资源不重叠，就可以传输两个码本，否则会传输其中一个码本。

关于单独的HARQ-ACK码本是否仅适用于单独的PUCCH传输，如果码本具有不同的优先级，单独的码本应仅在本阶段适用于单独的PUCCH传输，因为将具有不同优先级的码本复用到一个PUCCH传输中的特性仍在Rel-17 URLLC主题中讨论。

Type-1 HARQ码本的FDM/TDM调度

对于TDM-ed复用，Type-1码本基于单播和多播的PDSCH TDRA集的并集。对于FDM-ed多路复用，通过将用于单播的HARQ-ACK子码本与用于多播的子码本串联在一起来构造Type-1码本。

Type-1 HARQ-ACK码本大小由较高层配置（例如TDRA Set、K1 set）半静态地确定，而不是由物理层动态调度确定。然而，单播和多播是以TDM-ed还是FDM-ed方式复用，通常取决于网络动态调度。因此，为了保持Type-1码本大小独立于调度，UE需要知道复用方式。例如，仅当UE被配置为通过“FDM-ed”方式生成Type-1码本时，UE才这样做。否则，UE将不期望在FDM中调度单播和多播。

“fallback”的优先级指示

关于用于动态调度的HARQ-ACK码本的优先级，优先级索引（0或1）可以包含在调度group-common PDSCH的DCI格式中。

为多播引入了两个优先级索引，其中

• Index0表示低优先级，Index1表示高优先级。

• 优先级索引可以包括在调度 group-common PDSCH的DCI格式中。

鉴于多播接收需要UE预先获得RRC_连接状态下的必要配置，DCI格式的字段可以取决于配置。如果需要“fallback  DCI”，而DCI格式的某些字段不应依赖于可变的高层配置，那么如何指示优先级索引是一个问题。采用“default”值应该是一个简单的解决方案，并且可以在配置G-RNTI和相应配置时配置默认值。

基于NACK-only的HARQ-ACK反馈

从UE的角度来看，一个次要的规范影响方式是保持最大资源集数量和每个资源集的最大资源数量不变。如果NACK-only和ACK/NACK的资源是共享的，并且例如与相同的PUCCH资源ID相关联，则当ACK/NACK比特和NACK-only反馈都可在相同的PUCCH资源上传输时，要么NACK-only被转换为基于ACK/NACK的，要么始终丢弃NACK-only，或者不排除其他方式。从这个意义上讲，NACK-only的PUCCH资源不一定专用。或者，网络可以为所有UE配置专用PUCCH资源，以便在解码PDSCH失败时反馈NACK。总的来说，它可能取决于网络的正确配置。

从NACK只能有利于降低UE功耗和资源开销的意义上讲，它可以应用于低优先级和高优先级服务。因此，为NACK-only反馈的低优先级和高优先级配置不同的PUCCH资源是有意义的。

当在同一PUCCH时隙中，有多个NACK-only的反馈需要传输时，如何仅传输NACK？这里有一些备选方案，如下所示：

当在同一PUCCH时隙中有多个基于NACK-only的反馈可用于传输时，从以下备选方案中向下选择：

• Alt1：支持多路复用HARQ-ACK位。

• Alt2：支持UE在基于PUCCH的同一时隙中传输多个PUCCH。

• Alt3：NACK-only捆绑

• Alt4：支持基于sub-slot的PUCCH，用于基于NACK-only的反馈。

此外，当用于NACK-only的PUCCH资源与其他PUCCH或PUSCH传输重叠时，还需要考虑NACK-only的传输方式。由于根据优先级索引指示，NACK只能具有低优先级或高优先级，因此直接的解决方案是，如果NACK-only反馈具有低优先级，则将丢弃该反馈。如果NACK-only具有高优先级，则如上所述，可能有多个备选方案值得考虑。

总的来说，比较所有这些备选方案，Alt1是有利的，因为它看起来最简单，可以解决所有这些问题，同时对规范的影响最小。

基于NACK-only的HARQ-ACK反馈支持PUCCH format0和format1。这两种格式都支持1或2个HARQ-ACK位，并在一个PRB上传输。PUCCH format0占用一个或两个符号，但PUCCH format1可以通过四个或更多符号传输，以实现更好的覆盖。这两种格式的常见问题是两位还是仅一位用于NACK-only反馈，以及循环移位用于表示NACK的内容。

次要规范影响方式支持NACK-only的一个HARQ-ACK位，前提是当在同一PUCCH时隙中有多个基于NACK的反馈可用于传输时，或者在同一PUCCH资源上有其他UCI反馈可用于NACK-only的反馈时，NACK-only可转换为基于ACK/NACK的反馈，或者根据以上部分的讨论，PUCCH资源与PUSCH传输重叠。因此，只能将NACK的序列循环移位硬编码为mcs=0。

启用/禁用HARQ反馈

关于启用/禁用HARQ反馈，有以下假设：

对于通过动态 group-common PDSCH接收多播的 RRC_CONNECTED的UE，启用/禁用基于ACK/NACK的HARQ-ACK反馈：

• RRC信令配置group-common DCI的启用/禁用功能，指示基于HARQ-ACK反馈的启用/禁用ACK/NACK。

1. 如果RRC信令配置基于group-common  DCI的指示功能，group-common  DCI指示（显式或隐式）是否启用/禁用基于ACK/NACK的HARQ-ACK反馈

2. 另外，通过RRC信令配置启用/禁用基于ACK/NACK的HARQ-ACK反馈。

由于RRC配置是每个UE的信令，因此UE可以独立地配置为对DCI指示作出反应或不作出反应，因为由于group-common DCI，DCI格式或大小需要是唯一的。

从UE的角度来看，当RRC配置指示功能的group-common时，UE对DCI指示作出反应以启用或禁用反馈。否则，RRC可以将UE配置为始终启用或禁用反馈，并且不对来自DCI的潜在指示作出反应，因为网络可以将其他UE配置为侦听DCI指示。