5G DRX

NR的DRX需要增强，以支持具有不同要求和numerology的多种服务，MAC实体可以在任何给定时间处于一个DRX状态（即单个开/关时间）。当MAC实体唤醒时，它监视“PDCCH”。

在LTE中，C-DRX（连接模式DRX）被应用来节省功耗，UE通过on-duration timer 和 DRX inactivity timer唤醒并监视下行链路控制信道（PDCCH）。由RRC信令指示的传统DRX配置是UE特定的。当支持多个服务时，UE特定的DRX配置在时延减少和功率节省方面可能无法胜任。例如，UE可以在电影下载期间的一段时间内从eNB接收调度，在这种情况下，UE应该使用相对长的DRX不活动定时器以防止PDCCH丢失；另一方面，对于URLLC中的服务，例如V2X服务将生成时延敏感分组数据，short DRX inactivity timer更合适，因为eNB在下一个分组到达之前不会发送PDCCH，并且一旦接收到V2X分组，UE就可以入睡。

对于NR，为支持DRX中的多种服务。网络可以基于不同服务的要求或numerology来配置不同的DRX参数。在现实生活中，不同的服务可能在不同的时间发生。例如，在网络浏览期间可能会有电话呼叫，因此，如果要针对当前运行的服务配置DRX参数设置，这将是有益的。然而，如果gNB在每次服务改变时都用理想的DRX配置重新配置UE，则会引入高信令开销。

在LTE DRX中，UE基于由RRC信令配置的onDurationTimer和DRX-InactiveTimer唤醒。然而，如果在on duration期间网络未调度UE，则UE仍需要监视PDCCH，从UE的角度来看，这不是节能的。为了更省电，UE可以从网络接收信令，以在处于on duration时动态切换到DRX关闭状态。该动态信令可以在PDCCH上或者甚至作为PDSCH中的一种MAC CE来发送。由网络决定是否发送该动态信令，例如，当网络处于高负载时，并且UE将不会在on duration内被调度。

在LTE中的C-DRX的情况下，为了成功地接收和解码PDCCH，UE在开启持续时间之前执行时间/频率同步和小区识别过程。

在NR多波束部署中，除了上面讨论的基于LTE的部署之外，考虑到具有波束赋形的DRX，UE应该保持与网络的波束同步。然而，最佳下行RX波束可能由于UE移动而改变。对于这种情况，当UE进入持续时间周期时，UE必须确保能够成功接收和解码PDCCH的最佳下行RX波束。UE可能需要长的on duration来保证波束选择过程（测量/报告/切换/恢复）可以完成。

应考虑如何节省波束选择时间。例如，用于接收和解码PDCCH的波束可能不是最佳波束。一旦波束满足接收和解码PDCCH的阈值/要求，就可以停止波束选择。如果gNB和UE中存在大量波束，则可以通过选择均匀间隔的波束来减少要测量的波束数量。另一方面，旨在选择最佳波束的参考信号应与DRX周期的起点（开启持续时间）对齐。

如图1所示，波束选择的参考信号间隔可能与DRX周期的开始不匹配，这意味着当UE进入开启持续时间时，波束选择不会立即发生。由于波束选择时间延迟，成功的下行信号接收和解码将被延迟。一种可能的方法是将参考信号周期与DRX周期的长度相关联，例如DRX cycle=n*reference signal period。在此假设下，UE可以在每个DRX周期开始时接收用于波束选择的参考信号。

空闲模式DRX机制是UE减少功耗并由此延长电池寿命的手段。这通过允许UE以预定间隔不连续地监视服务小区中的寻呼信道来实现。

UE监视寻呼信道的时间间隔由网络配置，并作为系统信息的一部分用信号通知给UE。UE可以在附着和TAU过程期间请求专用DRX周期。如果UE没有请求专用DRX周期，则应应用服务小区中定义的默认DRX周期。

DRX周期被配置为UE可以从网络接收寻呼的寻呼帧之间的无线帧的数量。该概念基于系统帧号（SFN），即在每个小区中广播的10比特（系统信息（MIB）中的8比特和UE在P-BCH解码中隐式获取的2比特）。在LTE中，最初支持四个DRX周期，从320毫秒到寻呼时间之间的最大2.56秒。

为了进一步降低以移动端业务为特征的应用的UE功耗，而无需严格的时延要求，Rel-13扩展DRX（eDRX）功能使UE能够将其DRX周期进一步延长至44分钟（2621.44秒）。为了能够将DRX周期延长到10.24秒以上，引入了超SFN（H-SFN）概念。H-SFN 10比特在系统信息（SIB1）中广播，并且每次SFN环绕时递增1。

UE选择的（e）DRX周期在附着和TAU过程中与核心网协商，并在S1AP寻呼消息中提供给eNB。随着光连接概念的引入，在建立CN-RAN连接时（即作为UE上下文设置信息的一部分），UE选择的DRX周期也被提供给RAN，以启用RAN寻呼。

此外，在NR中，预计各种类型的UE将对功率节省和时延有不同的要求，因此从NR部署的第一天起，可能需要大范围的DRX间隔。因此，NR规范应允许与至少完整LTE（e）DRX周期范围（包括为NB-IoT引入的DRX值范围）相对应的DRX周期的范围，从而可以基于时延和功率节省等的要求为每个UE选择合适的间隔。

NR最小系统信息中包括帧号（对应于LTE SFN），留下帧号字段的大小以供进一步研究。在LTE中，SFN由10位、MIB中包含的8位和物理层隐含携带的2位组成，允许10.24秒的最大DRX周期。通过超SFN概念（SIB1中提供的由10位组成的位串），可以支持更长的DRX周期，最长可达2.91小时。

鉴于NR应支持与LTE中相同的DRX周期范围的提议，需要在NR系统信息中定义并向UE提供与LTE中定义的相似的帧号结构（SFN扩展为H-SFN）。假设NR无线帧将与LTE无线帧一样长，那么在NR中定义与LTE中相同的帧号值范围似乎是可行的。

假设大多数UE（虽然不是在所有部署中）将选择服务小区中提供的默认DRX周期，则NR-MIB中提供的10比特帧号值范围将很可能服务于驻留在小区中的大多数UE。然而，考虑到为E-UTRAN定义的最长的Rel-13前DRX周期是2.56秒（即LTE小区中可以提供的最长默认DRX周期），大多数UE甚至有可能通过读取NR-MIB中提供的8位“SFN”来持续保持与网络的同步。帧编号的剩余12位可以包括在例如NR-SIB1中。

在支持更长的DRX周期的情况下，UE不监视寻呼信道的时间间隔可能相当长，在最大情况下可达近3小时。因此，如果网络由于某种原因不能在其寻呼时刻到达UE，则网络必须等待完整的DRX周期，然后才能再次尝试到达UE。这可能会对需要与UE通信的应用程序/功能产生影响，当然也会对UE产生影响。

在LTE中，这个问题通过寻呼时间窗口（PTW：Paging Time Window）来解决，PTW是UE监视寻呼信道的时间间隔。UE知道帧号和它必须监视寻呼信道的帧号内的时间间隔。随着NR中较长DRX周期的定义，NR也需要与LTE PTW类似的概念。

在每个NR小区的系统信息中提供默认DRX周期。如果服务小区中的默认DRX周期不满足例如UE功率节省要求，则UE可以请求更长DRX周期。

同样，如果服务小区中的默认DRX周期不是最短定义的DRX周期，并且默认DRX循环不满足例如UE等待时间要求，则UE可以请求更短的DRX循环。

在与附着请求和跟踪区域更新请求消息相对应的NAS消息中向CN发送针对单个DRX周期的UE请求。然后在寻呼消息中以及在建立CN-RAN连接时（例如作为UE上下文设置信息的一部分）将UE选择的DRX周期提供给RAN，以在UE处于RRC_INACTIVE状态时启用RAN寻呼。

当UE特定的DRX周期长于系统信息修改周期时，UE需要在建立RRC连接之前验证存储的系统信息是否保持有效。如在LTE中，寻呼消息可以包含向UE通知系统信息的改变的指示符。更准确地，寻呼消息可以包括以配置有比系统信息修改周期更长的DRX周期的UE为目标的显式指示符。

具有这种DRX配置的UE应（至少）在下一个DRX获取周期边界处获取更新的系统信息。