WUS（wake-up signal）流程

gNB在DRX打开之前进行offset，向UE“指示”激活时间以外的节能信号/信道的监视场合，“指示“指通过更高层信令或通过CORESET/search space隐式的显式。

PS_offset定义了WUS监视窗口/掩码的开始，WUS监视窗口的持续时间（即“范围”）是基于搜索空间IE中的现有参数（如duration 和monitoringSymbolsWithinSlot）导出的，没有任何更改。如图1所示，WUS监视窗口从时间位置开始，该时间位置在ON duration之前是PS_offsest，并且从搜索空间集的现有参数派生的所有PDCCH监视场合都将被监视，直到从duration/monitoringSymbolsWithinSlot派生的范围结束。

UE需要一些时间来从WUS DCI监视状态唤醒到检测正常PDCCH/PDSCH的全部能力。因此，需要注意的是，确保了在DRX上进行PDCCH监控的准备工作。

在Rel-15中，UE可以同时使用长DRX周期或短DRX周期。UE可以根据以下规则在短DRX周期和长DRX周期之间进行切换：

• 如果接收到DRX命令MAC-CE，则UE使用短DRX周期（如果已配置）。

• 如果接收到长DRX命令MAC-CE或者DRX ShortCycleTimer过期，则UE需要使用长DRX周期。

长DRX周期基于PDCCH的节电信号，短DRX周期不配置基于PDCCH的节电信号。在这种情况下，WUS也应该应用于短DRX周期以获得节电增益。如果短DRX周期不支持WUS，UE必须监视短DRX周期的每个接通持续时间。在最坏的情况下，数据很少到达，但不幸的是drx-ShortCycleTimer没有过期。在这种情况下，UE应该在短DRX周期内长时间工作，然而，对于大多数接通持续时间，根本没有PDCCH传输。由于缺少WUS，UE将遭受不必要的功率消耗。

配置WUS时的后台处理

如果PDCCH-WUS指示UE不启动drx-onDurationTimer，则向RAN1发出LS[3]，询问RAN1对P/SP SR和CSI报告行为的意见。因此，本节将讨论PDCCH-WUS对P/SP SRS和CSI报告的影响。

如果遵循Rel-15规范中规定的相同行为，如果ON duration Timer没有由DCI format 3_0触发，则UE不应执行 periodic/semi-persistent CSI报告。UE不应长时间测量和报告CSI，这将是连续的DRX循环数。因此，UE的信道质量将在gNB上过时，这将降低PDSCH和PDCCH-WUS性能。在最坏的情况下，例如在高移动性场景中，gNB可能丢失UE的WUS波束，并且这可能导致UE触发链路故障恢复过程，这增加了业务延迟并消耗更多UE功率。

此外，在Rel-15 38.214规范中，规定最近的CSI测量时机发生在DRX活动时间，以便报告CSI。

38.214 5.1.6.1 CSI-RS reception procedure:If the UE is configured with DRX, the most recent CSI measurement occasion occurs in DRX active time for CSI to be reported.

因此，当UE从长时间睡眠中醒来后，第一次报告的CSI测量实际上是基于上一个活动时间的测量时刻，即之前的若干DRX周期。报告的CSI测量值与当前信道条件不匹配。过时的CSI报告将是无用的，并且不必要地消耗UE功率。此外，由于不准确的信道质量，UE可能被调度为PDSCH/PUSCH性能降低，这将导致更长的发送/接收时间，从而导致更多的功率消耗。

为了使UE在持续时间唤醒时能够报告最新的CSI，建议允许要报告的CSI的最近CSI测量时刻在活动时间之外。一种简单的方法是，将UE配置为每N个DRX周期在ON duration内执行一次CSI测量，而不管持续时间是否被触发。通过这种方法，即使UE跳过了多个DRX周期并且在下一个持续时间唤醒，在持续时间中要报告的CSI的最近的CSI测量时刻也可以是活动时间之外的最后时刻，其足够接近持续时间。值N可以被配置为在性能和UE功耗之间进行权衡。

关于WUS DCI对P/SP SRS报告的影响，也存在一些类似的问题。基于Rel-15行为，如果在长时间未检测到唤醒指示时UE不发送P/SP SRS，则网络不能获取UE的最新信道状态。上行链路同步也可能丢失，这将降低上行链路性能。在TDD场景中，基于SRS报告可以导出下行链路CSI，问题可能更严重。

当DCI format3_0的监视时机无效时，假设UE遵循遗留DRX操作，其中无效WUS时机至少包括活动BWP未配置DCI format3_0的情况。

1） case1：与基于计时器的BWP切换冲突

在图2中，展示了一个基于计时器的BWP切换案例。如果激活的BWP不是默认的BWP，并且BWP-InactivityTimer在默认BWP的激活时间之前过期，那么在默认BWP中配置的WUS监控时机可能会与BWP切换延迟发生冲突。因此，UE在BWP切换时间期间不能检测到DCI format3_0，其中UE不期望接收/发送任何信号。

2） case2：WUS监控窗口中没有有效的WUS监控时机

作为PS_offset，WUS监视窗口/掩码的开始，独立于CDRX配置配置为UE。从Ps_ offset派生的时隙可能正好跟在为DCI format 3_0设置的搜索空间的一个持续时间之后，如果“range”小于搜索空间集的周期，则Ps_offset派生的窗口和“range”中可能没有有效的监视时机，如图2所示。在这种情况下，UE无法检测到DCI format 3_0，应采用Rel-15中的传统DRX操作。

3） case3：与TDD 上下行配置或SFI冲突

有效的搜索空间集监视周期不能完全匹配有效的CDRX周期。要在规范中匹配它们需要做大量的工作，这也导致了gNB实现的复杂性。为了解决这个问题，引入了一个“监视窗口”用于DCI format 3_0监视。

出于类似的原因，TDD-DL-UL配置（或SFI）从搜索空间集配置和CDRX配置独立地配置（或指示）到UE。WUS监控场合可能与UL符号部分或完全重叠。在这种情况下，UE不能检测DCI format 3_0，因为DCI format 3_0只能在DL符号中传输。WUS监测时机应视为无效WUS时机。

UE能力报告和UE协助信息

一般认为UE至少需要一些时间来解码DCI format 3_0，但是解码速度和唤醒速度对UE的实现有很大的依赖性，因此UE向gNB报告相关信息是合理的。由于恢复之前所需的时间不依赖于通信量，因此最好通过UE能力而不是UE辅助信息来报告它。

值得注意的是，尽管在恢复之前所需的“时间”不取决于通信量，但它取决于功能或DRX配置。众所周知，睡眠类型主要取决于可用睡眠持续时间，可用睡眠持续时间进一步由DRX周期长度确定。因此，“ending offset”的值也可能受到DRX周期长度的影响。另一方面，由于这两种情况在UE内需要不同的内部任务，所以对于仅指示“唤醒”的情况和同时指示“唤醒”和“休眠”的情况，所需的时间显然应该是不同的。然而，UE通常在RRC配置之前报告其能力，这意味着当UE报告其优选的“ending offset”值时，UE不知道gNB将在WUS结束偏移期间配置哪些任务。因此，UE可以报告多个值，其中每个值用于不同的CDRX/功能配置。