5G NR DRX 增强快速响应
在LTE中使用DRX特性以通过允许UE不连续地监视PDCCH来节电。这在许多情况下都很重要，对于活动可能很少的UE（例如mMTC中的设备），以及对于具有频繁流量的UE（如eMBB）。在NR中，仍然期望系统具有允许UE降低其能耗的机制，并且重要的是决定如何设计和增强DRX，同时仍然有效地支持NR的不同服务。
在LTE中的连接模式中，UE可以配置有两个DRX级别或周期。具有两个级别的原因是为了适应UE活动的级别。当UE最近接收到数据时，使用短的DRX周期。当UE在“更长”的时间段内没有接收到数据时，使用长的DRX周期。
支持不同的服务、服务混合、不同的L1和不同的numerology可以触发重新接入和增强LTE中发现的机制，以减少UE能耗。
虽然连接模式DRX可能需要一些增强以帮助UE降低其能耗，但需要考虑的是，改进不能仅关注UE功耗。DRX框架应在不同的关键方面（如功耗、延迟、UE和网络复杂性或网络资源管理）之间实现公平的权衡。
不同的服务可能需要不同长度的DRX周期。例如，对于语音业务，UE需要频繁唤醒以满足语音业务的时延要求。但是在发送/接收语音分组之后，UE可以快速入睡，因为在下一个语音分组到达之前。另一方面，FTP流量不像语音那样对时延敏感，长的DRX周期更好地允许UE尽可能多地睡眠。但是，当FTP流量处于活动状态时，最好在一段时间后保持清醒，看看是否应该传输更多数据，例如TCP ACK或其他文件传输等。所以不希望在发送FTP流量后让UE快速休眠，因为在这种情况下，TCP-ACK可能会延迟整个DRX周期，这会影响TCP吞吐量。
当UE有几种类型的业务活动时，事情变得有点复杂。例如，如果UE同时具有FTP流量和正在进行的语音流量，则“语音DRX”或“FTP DRX”可能都不合适。下图显示了三种不同DRX设置的FTP比特率；
无DRX：UE持续活动
FTP DRX：长DRX周期，长时间不活动
语音DRX：短DRX周期，短时间不活动
DRX配置对FTP比特率有很大影响。当然，完全没有DRX可以提供最高的吞吐量，但功耗会受到影响，因此这不是优选的。对于“FTP DRX”，吞吐量大致相同，但现在UE可以休眠，从而省电。使用“语音DRX”可显著降低FTP比特率。这样做的原因是在一些分组被发送到UE之后，UE太快地移动到睡眠状态。
综上所述，仅基于哪种承载可用来选择DRX模式可能不是一个好主意，因为合适的DRX模式取决于哪种业务对于UE是活动的。例如，当UE同时进行语音呼叫和FTP传输时，配置为适合语音的DRX或配置为适合FTP的DRX都不是最佳选择。
在一些情况下，例如当UE在切换过程期间发送了测量报告时，重要的是UE不要太快入睡，因为它可能会错过潜在的切换命令。在这种情况下，UE应该配置有相对长的不活动定时器。另一方面，如果UE已经发送了例如语音分组，则很可能希望UE快速入睡以省电，因为在期望下一个语音分组之前不期望有更多的数据。因此，UE应该配置有相对较短的不活动定时器。
UE应该应用多长时间的不活动定时器取决于UE有哪些业务可用。确保UE苏醒以接收对上行链路传输的响应的一种方式是始终为UE配置长不活动定时器值，但这在UE有语音要发送的情况下浪费了UE功率。因此，根据流量配置不活动计时器将是有益的。
很明显，不同的流量或不同的流量混合将需要不同的DRX配置，以允许优化的DRX行为。因此，如果可以根据当前运行的流量配置不同的DRX参数设置，这将是有益的。eNB然后可以在不同的可用DRX配置中选择对于当前业务组合最为最佳的配置，并相应地配置UE。如果业务的特性改变，eNB可以用新的DRX参数重新配置UE。
实现这一点有多种方式。定时器的配置通常是RRC信令的一部分。当前业务组合可能会快速变化，这表明此类命令应由MAC CE处理，这反过来又表明UE通过RRC预先配置了一组DRX配置，然后可以由MAC“激活”。
在LTE中，UE可以配置有两个DRX周期或周期。具有两个周期性的原因是，如果UE最近传输了数据，则UE很快将传输更多数据的概率较高。因此，如果UE最近是活动的，则可选地使用一个短的DRX周期，这确保如果更多数据到达，则发送该数据的时延将很低。但是如果UE在更长时间内没有发送数据，而UE可以应用更长的周期性。
假设在NR中应采用相同的方法，其中应支持一个以上的周期性，但问题是协议是否应以两个DRX周期解决，或者当前框架是否应通用化，以允许两个以上的C-DRX周期？
然而，没有提出任何有用的论据或有效的用例来支持NR中两个以上的C-DRX循环，现有的配置可能性似乎即使对于NR也是足够的。
因此，建议在LTE中可以使用与NR相同的框架，即给UE一个周期性和一个定时器，该定时器在期满时触发UE开始应用较低级别的周期性，并且在NR中使用两个C-DRX周期就足够了。
