5g 波束数量（5G波束管理的维护）
这篇文章对波束管理和波束故障恢复的剩余问题进行了分析特别是多载波情况下的PDSCH默认QCL假设、RRC重构和MAC-CE重激活之间的PDCCH/PUCCH默认空间滤波器假设以及波束故障恢复后的上行默认波束，下面我们就来聊聊关于5g 波束数量?接下来我们就一起去了解一下吧!
5g 波束数量
这篇文章对波束管理和波束故障恢复的剩余问题进行了分析。特别是多载波情况下的PDSCH默认QCL假设、RRC重构和MAC-CE重激活之间的PDCCH/PUCCH默认空间滤波器假设以及波束故障恢复后的上行默认波束。
多载波场景下PDSCH默认sQCL
当接收下行DCI和相应PDSCH之间的偏移小于Threshold-Sched-Offset 时，PDSCH的默认空间QCL假设同意遵循“lowest CORESET-ID”。然而，用于确定“lowest CORESET-ID”的CORESET空间并不明确。在单个CC情况下取得了进展，其中“lowest CORESET-ID”是通过只考虑活动BWP中的CORESET来确定的。对于多个CC案例，问题仍然悬而未决。
尽管CORESET是按照BWP配置的，但只监视活动BWP。因此，在单CC情况下，“lowest CORESET-ID”是特定于BWP的。在多CC情况下，可能有多个具有CORESET配置的活动BWP。由于CORESET的索引是特定CC的，因此多个CC的CORESET ID可以相同。需要打破平局的规则。
在多CC情况下，RLM在SpCell上执行。因此，SpCell控制信道的鲁棒性比其他SCELL更为重要。将SpCell上CORESET的sQCL作为默认PDSCH sQCL进行优先级排序是明智的。另一方面，在具有LF HF CC的CA场景中（低频 高频场景），PCell很可能位于LF中，而SCELL位于HF中。由于LF PCell可能没有sQCL假设，因此该解决方案不太适用。
另一个简单的替代方法是在每CC的基础上确定“lowest CORESET-ID”。例如，CC#x上的PDSCH仅根据CC#x上的激活BWP确定lowest CORESET-ID。在跨载波调度的情况下，“lowest CORESET-ID”基于调度小区的激活BWP。在这种情况下，要求调度小区能够根据CORESET配置提供空间QCL假设。
当前控制信道（PDCCH/PUCCH）空间滤波器指示遵循两级机制。两级机制通过引入MAC-CE作为指示信令的一部分，实现了灵活的波束调整，并且仍然确保了鲁棒性。然而，只有当RRC配置和MAC-CE指示都被成功接收和应用时，PDCCH/PUCCH空间滤波器指示才被认为是完整的。每当RRC重配TCI-StatesPDCCH / PUCCH-SpatialRelationInfo时，或当原始上下行波束对链路上由于RLF/handover/beam failure recovery等原因出现中断时，PDCCH/PUCCH波束不清晰的时间会很短。
对于PUCCH-SpatialRelationInfo重配的情况，通过假设最新指示的PUCCH空间QCL假设来执行用于确认具有RRC重配的相应PDSCH的传输。显然，这意味着最新的PUCCH空间关系假设仍然可行。因此，在接收和应用基于重新配置的PUCCH-SpatialRelationInfo的进一步MAC-CE指示之前，UE自然会进行空间关系假设。
对于TCI-StatesPDCCH 重配的情况，通过假设最新指示的PDCCH空间QCL假设来执行RRC重配延迟之前的下行接收（即，在网络之前确保UE知道存在并已解密RRC重配消息）。显然，假设最新的PDCCH空间QCL假设仍然可行。因此，在接收和应用基于重配的TCI-StatesPDCCH的进一步MAC-CE指示之前，UE自然会进行空间QCL假设。
对于 RLF/handover/beam failure recovery的情况，在TCI-StatesPDCCH / PUCCH-SpatialRelationInfo中的一个空间滤波器假设的MAC-CE激活之前，有一个伴随的RACH过程。在成功恢复 RLF/handover/beam failure recovery后，为附带的RACH程序所做的空间滤波器假设必须可操作。在接收到新空间滤波器的进一步MAC-CE激活之前，对RACH过程应用相同的空间滤波器假设显然是可行的。
In RAN1#94 meeting, the following agreement is made [1]:
Agreement
在RAN1#94bis中的以下两个备选方案中向下选择
Downselect among the following two alternatives in RAN1#94bis
2）Note: The latency of RRC or MAC CE configuration is included as part of time duration for applying the same spatial filter as the PRACH transmission
1）FFS: value of K
1）FFS: value of K
2）Note: The latency of RRC or MAC CE configuration is included as part of time duration for applying the same spatial filter as the PRACH transmission
对于下行接收，当前无竞争BFR过程指定，在gNB响应接收之后，UE假设与所选候选波束相同的天线端口QCL参数，直到UE通过高层接收到TCI-StatesPDCCH-ToAddlist 或 TCI-StatesPDCCH-ToReleaseList.中的任何参数。SearchSpace-BFR上的下行接收在BFR后得到保护。同时，具有先前发信号的PUCCH-SpatialRelationInfo的上行传输可能工作，也可能不工作。要恢复上行传输，网络可以为所有配置的PUCCH资源重配或重新激活PUCCH-Spatialrelationinfo。这会带来RRC重配或MAC-CE延迟。在时间间隔期间，不保证PUCCH传输。由于PDSCH传输不能可靠地进行HARQ ACK/NACK，因此不保证恢复网络和UE之间的链路连接。
显然，在接收到gNB响应后，用于相应PRACH传输的UE TX波束是唯一可以确保用于与上行中的网络通信的手段。由于PUCCH资源的总量可以高达maxnroffucch-resources=128，因此覆盖所有PUCCH资源的激活PUCCH-spacerelationinfo之后可能会导致重配/重新激活它们的巨大信令开销。这里有两个备选方案。
对两个备选方案的利弊分析总结如下：
方案1：与PRACH传输相同的空间过滤器应用于所有配置的PUCCH资源
1. 网络不需要对其PUCCH-SpatialRelationInfo被覆盖的PUCCH资源进行复写。
1. 并非所有配置的PUCCH资源都需要覆盖其PUCCH-SpatialRelationInfo。一种可能的实现方式是，故意使用不同的SpatialRelationInfo激活PUCCH资源，并且在一个特定的持续时间内，仅使用PUCCH资源的子集。这样，网络就可以在特定的传输持续时间内简单地向PUCCH资源发送具有有效空间关系信息的信号。很少需要重新激活PUCCH资源的SpatialRelationInfo。
方案4：将与PRACH传输相同的空间滤波器应用于PUCCH资源，用于从SearchSpace BFR调度的相应下行PDSCH的HARQ ACK/NACK反馈
1. 如方案1的缺点所述，由于仅覆盖PUCCH资源的SpatialRelationInfo的子集，因此可以显著减少PUCCH-SpatialRelationInfo的重新激活开销。
2. 从UE的角度来看，UE不需要覆盖所有PUCCH资源的空间关系信息。许多覆盖可能是不必要的，因为它们稍后将被重新激活到其他SpatialRelationInfo。
1. 网络需要对其活动PUCCH-SpatialRelationInfo被覆盖的PUCCH资源进行登记。
免责声明：本文仅代表文章作者的个人观点，与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺，请读者仅作参考，并自行核实相关内容。文章投诉邮箱：anhduc.ph@yahoo.com
