增强型多TRP和多面板传输

对于来自不同TRP的多个PDSCH的时域资源部分或全部重叠的情况，双方同意UE只能在一个BWP内同时接收这些PDSCH。按照Rel-15的规定，每个CC只能为一个UE激活一个BWP。为了确保多个TRP传输的PDSCH具有相同的激活BWP，协议提出了四个备选方案：

• 方案1： 不允许动态BWP切换。

• 方案2： 不希望通过多个PDCCH在不同的BWP中同时调度UE与PDSCH。

• 方案3： 只有一个CORESET中的BWP指标对两个PDSCH有效。

• 方案4： 当UE通过多个PDCCH在不同的BWP中同时调度PDSCH时，只应用一个PDCCH/PDSCH，而丢弃另一个PDCC/PDSCH。

对于方案1，对于支持多TRP/面板传输的UE，禁用BWP指示的限制太多。由于传输是一种UE能力，并且PDSCH传输使用的是单个还是多个TRP对UE来说是透明的，因此很难通知UE是否允许动态BWP切换。

对于方案2，gNB确保了单个有源BWP。对于具有非理想回程的部署场景，这可能不可行。如果多个TRP之间的回程不理想，则TRP之间无法进行动态协调。考虑到BWP切换可以通过DCI进行动态切换，仍然有可能在不同的BWP中同时调度PDSCH。当这种情况发生时，UE会将其视为错误情况，并相应地丢弃两个PDSCH。

对于方案3，BWP仅由多个PDCCH中的一个预定义PDCCH表示。辅助CORESET调度的PDSCH应遵循初始CORESET调度的PDSCH的BWP。在这种替代方案中，gNB应确保两个PDSCH在同一个单一的激活BWP中传输。否则，UE可能会在错误的BWP中检测到辅助CORESET调度的PDSCH。

对于方案4，如果PDSCH在不同的BWP中调度，但在时域中发生冲突，则需要在PDSCH之间定义优先级。当TRP之间的回程不理想时，可能会发生这种情况。首选此替代方案，因为与方案1和方案2相比，至少可以解码优先级较高的PDSCH。在大多数情况下，gNB可以避免冲突，以便UE可以解码两个PDSCH。

• PDCCH/CORESET configuration

针对多TRP传输的RRC参数时，对HigherLayerIndexPerCORESET的值有不同的看法。一些公司建议引入除{0,1}以外的更多候选值。在当前协议中，对于多TRP传输，假设只有两个TRP。例如，CORESET和PDSCH加扰的数量仅考虑两个TRP的用例，而HARQ-ACK传输和多路复用（例如，DCI计数协议、HARQ_ACK资源分配协议）也仅考虑从两个TRP发送的PDSCH的HARQ/ACK。如果引入了更多值，例如，来自TRP0和TRP1的PDCCH调度在一个时隙中，来自TRP1和TRP2的PDCC调度在另一个时隙，则当前协议无法支持相应的PDSCH/HARQ-ACK传输。因此，HigherLayerIndexPerCORESET的候选值应该只包括0和1。

目前，还不清楚在没有配置每个CORESET的高层索引时UE的行为。如果未配置索引，则可以直接假设所有传输都来自同一TRP，并且UE行为应回退到Rel-15中指定的行为。如果规范仅指定了UE行为，并且为CORESET配置了索引，则不需要对当前规范产生影响。在这种情况下，不需要针对不同TRP（不同载波除外）的多个dataScramblingIdentityPDSCH和多个CRS模式，因此，它们不应由gNB配置，或者如果指示多个配置，UE将使用默认模式。当为所有配置的CORESET指示相同索引时，同样的UE行为也可以应用于这种情况。

另一个问题是，是否支持为某些CORESET配置了高层索引，但没有为其他一些CORESET进行配置的情况。gNB最好避免这种情况，因为这种配置的用例不明确，并且会导致UE行为不明确。

• PDSCH configuration

不同TRP的多个CRS模式可以配置为具有多个TRP传输的UE。一个PDSCH是应用所有配置的模式，还是仅应用与调度PDSCH的CORESET中配置的索引相关联的CRS模式，这需要进一步论证。在Rel-15中，只有传输PDSCH的TRP的LTE CRS模式将应用于调度的PDSCH，相邻小区的模式将不会配置到UE以进行速率匹配。对于多TRP传输，要求UE对两个TRP的CRS模式进行速率匹配是不合理的。如果NC-JT的增益不够显著，或者当UE动态切换到单TRP传输时，所有配置的CRS模式上的速率匹配可能会导致比Rel-15中的单TRP发送更差的性能。因此，应引入CRS模式与高层索引（方案2）之间的关联。通常，可以考虑使用两种方法配置关联：

• 方案2.1：隐式关联，其中每个配置的CRS模式都与一个固定索引相关联。例如，如果配置了两个模式，则第一个配置的模式与index=0关联，而第二个模式与index=1关联。

• 方案2.2：显式关联，其中与每个CRS模式关联的索引由gNB配置。例如，可以为每个模式配置两位以指示关联索引，其中“01”表示它与索引=1关联，“11”表示它同时与两个索引关联。

考虑到配置灵活性，方案2.2略为可取。方案Alt2.2，甚至可以通过gNB配置支持方案1。

• ACK/NACK feedback

在Rel-15中，PRI指示基于时隙粒度的k1。对于多TRP传输，双方同意单独的ACK/NACK反馈可以是一个时隙内的TDMed。那么，如何确定TDMed ACK/NACK反馈时隙内的时域资源将是一个问题。一种解决方案是重用URLLC中的机制，以子时隙的粒度指示k1。然而，NC-JT和URLLC的子时隙功能和要求不同。对于URLLC，可以向UE指示多个子时隙配置中的一个，其持续时间至少可以是“2-symbol*7”和“7-symbol*2”。对于NC-JT，由于两个TRP只支持两个TDMed PUCCH，可以是两个长PUCCH、两个短PUCCH或长PUCCH+短PUCCH。那么，子时隙持续时间为“2-symbol*7”和“7-symbol*2”的URLLC设计无法支持eMBB中商定的设计。对于NC-JT，TDMed PUCCH在一个时隙内最多需要两个子时隙，持续时间应该更灵活，例如2+2、2+7、4+4等。为了支持非理想回程，可以通过高层信令配置两个子时隙的持续时间，并分别半统计地分配给不同TRP的ACK/NACK传输。UE可以根据为与ACK/NACK反馈相关联的CORESET配置的高层索引来确定发送ACK/NAK的子时隙，例如，索引为0的TRP的第一个子时隙，索引为1的TRP第二个子时隙。在这种情况下，Rel-15中k1和PRI的指示机制可以完全重用。

对于非理想回程，gNB只配置单独的ACK/NACK反馈。为了避免ACK/NACK反馈之间的资源冲突，一个简单的解决方案可以是半静态资源预留，以确保不同TRP之间的TDMed PUCCH资源。然而，考虑到可以在单个和多个TRP传输之间进行动态切换，资源效率将非常低。例如，很难为每个TRP预先分配资源，因为TRP具有意外的信道状态。另一种解决方案是使用TDM作为ACK/NACK资源分配的主要方法，而当PUCCH资源发生冲突时，UE会根据一些预定义的优先级规则丢弃其中一个优先级较低的ACK/NAC反馈。该解决方案将放宽对TDMed PUCCH资源的要求，提高资源效率。删除规则可以基于CORESET/DCI调度相应的PDSCH或关联的PDSCH/PUCCH资源等。

对于非理想回程，ACK/NACK和其他类型的CSI或PUSCH之间也可能发生冲突。如果它们来自同一个TRP，Rel-15中的复用机制可以重用。否则，ACK/NACK应以更高优先级传输，并且应丢弃另一个TRP的UCI/PUSCH。

• CSI feedback

为了支持DL非相干JT，应向gNB报告多个TRP/面板的CSI。与LTE中配置多个CSI进程以支持CoMP传输的方法类似，可以向UE配置多个SCSI报告配置，每个配置都与一个TRP关联。一个TRP的CSI报告配置包括从该TRP传输的用于CSI测量的RS。每个TRP可以分别触发不同资源中的CSI报告以进行PDSCH传输。每个TRP的波束报告也可以通过该机制得到支持。当前CSI报告机制足以支持单独的CSI报告。

没有理由支持CSI联合报告。一个TRP的CSI报告有效载荷通常较大，如果使用联合CSI报告，预计CSI报告的有效载荷会较大。不需要通过单个CSI报告配置将不同TRP的CSI合并为一个CSI报告。对于具有理想回程的多TRP，与单独的CSI报告相比，联合CSI报告没有带来任何好处，但由于更大的有效负载大小，在CSI传输中引入了额外的规范工作和可能的性能损失。对于具有非理想回程的多TRP，联合CSI报告根本不起作用。一些公司认为，联合CSI报告对于等级限制是必要的，因为如果使用单独的CSI报告，多个报告等级的总和可能超过UE支持的最大层数。然而，多TRP传输仅对小区边缘UE有益，对于这些UE，在每个CSI报告中只会报告低秩（例如秩1/2）。考虑到至少在FR1中支持4层传输是强制性的，报告的列数超过支持的层数的情况非常罕见。即使在这种情况下，gNB仍然可以调度单个TRP传输，或者通过调度实现为其中一个TRP使用较小的秩。