TS38.300-i20学习-16（Paging）

9.2.5 寻呼

寻呼允许网络通过寻呼消息触达处于RRC_IDLE和RRC_INACTIVE状态的UE，并通过短消息通知处于RRC_IDLE、RRC_INACTIVE和RRC_CONNECTED状态的UE系统信息变化（见第7.3.3节）和ETWS/CMAS指示（见第16.4节）。寻呼消息和短消息都通过PDCCH上的P-RNTI进行寻址，但前者通过PCCH发送，后者则直接通过PDCCH发送（见TS 38.331的第6.5节）。

当处于RRC_IDLE状态时，UE监控CN发起的寻呼信道。当处于RRC_INACTIVE状态且没有正在进行的SDT过程时（见第18.0节），UE监控RAN发起的寻呼和CN发起的寻呼信道。UE不需要连续监控寻呼信道；寻呼DRX定义了UE在RRC_IDLE或RRC_INACTIVE状态下在每个DRX周期内只需在一个寻呼时机（PO）内监控寻呼信道（见TS 38.304）。寻呼DRX周期由网络配置：
对于CN发起的寻呼，默认周期在系统信息中广播；
对于CN发起的寻呼，可以通过NAS信令配置UE特定周期；
对于RAN发起的寻呼，可以通过RRC信令配置UE特定周期；
UE使用适用DRX周期中的最短周期，即处于RRC_IDLE状态的UE使用前两个周期中最短的周期，而处于RRC_INACTIVE状态的UE使用这三个周期中最短的周期。
CN发起和RAN发起的寻呼的UE的PO基于相同的UE ID，从而导致两者的PO重叠。DRX周期中不同PO的数量可以通过系统信息进行配置，网络可以根据UE的ID将UE分配到这些PO。
当处于RRC_CONNECTED状态和正在进行SDT过程的RRC_INACTIVE状态时，UE在系统信息中信令的任何PO中监控寻呼信道以获取SI变化指示和PWS通知。在带宽部分适配的情况下，处于RRC_CONNECTED状态的UE只监控在具有公共搜索空间的活动BWP上的寻呼信道。
在共享频谱信道接入的操作中，可以为UE配置其PO中额外数量的PDCCH监控时机以监控寻呼。然而，当UE在其PO内检测到P-RNTI寻址的PDCCH传输时，UE不需要监控该PO内的后续PDCCH监控时机。
如果寻呼消息中包含寻呼原因，处于RRC_IDLE或RRC_INACTIVE状态的UE可以根据TS 23.501使用寻呼原因。
对CM_IDLE状态下UE的寻呼优化：在UE上下文释放时，NG-RAN节点可以向AMF提供推荐的小区和NG-RAN节点列表，作为后续寻呼的辅助信息。AMF还可以提供寻呼尝试信息，包括寻呼尝试计数和预期的寻呼尝试次数，并可以包括下一个寻呼区域范围。如果寻呼消息中包含寻呼尝试信息，则在一次寻呼尝试期间，每个被寻呼的NG-RAN节点都会接收到相同的信息。每次新的寻呼尝试时，寻呼尝试计数应增加1。如果存在下一个寻呼区域范围，它表示AMF是否计划在下一次寻呼尝试时修改当前选择的寻呼区域。如果UE的状态已更改为CM_CONNECTED，则寻呼尝试计数将重置。
对RRC_INACTIVE状态下UE的寻呼优化：在RAN寻呼中，服务NG-RAN节点提供RAN寻呼区域信息。服务NG-RAN节点还可以提供RAN寻呼尝试信息。在一次寻呼尝试期间，每个被寻呼的NG-RAN节点都会接收到相同的RAN寻呼尝试信息，其内容包括：寻呼尝试计数、预期的寻呼尝试次数和下一个寻呼区域范围。每次新的寻呼尝试时，寻呼尝试计数应增加1。如果存在下一个寻呼区域范围，它表示服务NG-RAN节点是否计划在下一次寻呼尝试时修改当前选择的RAN寻呼区域。如果UE离开RRC_INACTIVE状态，寻呼尝试计数将重置。

UE寻呼监控的省电：为了减少由于错误寻呼警报而导致的UE功耗，监控同一PO的一组UE可以进一步划分为多个子组。使用子分组时，UE应在其PO中监控PDCCH的寻呼，如果通过相关的PEI指示寻呼了UE所属的子组。如果UE无法在某个小区中找到其子组ID或无法监控与其PO对应的相关PEI时机，则应在其PO中监控寻呼。
这些子组具有以下特点：
它们基于CN控制子分组或UE ID控制子分组进行形成；
如果AMF未提供CN控制的子组ID，则如果UE和网络支持，使用UE ID控制子分组；
RRC状态（RRC_IDLE或RRC_INACTIVE状态）不影响UE所属的子组；
小区支持的子分组广播在系统信息中，以以下三种形式之一：仅支持CN控制子分组、仅支持UE ID控制子分组或同时支持CN控制子分组和UE ID控制子分组；
小区中允许的子组总数最多为8个，代表网络配置的CN控制子分组和UE ID控制子分组的总和；
配置了CN控制子组ID的UE，如果小区支持CN控制子分组，则应用CN控制子组ID；否则，如果小区仅支持UE ID控制子分组，则推导出UE ID控制子组ID。
与子组相关联的PEI具有以下特点：
如果UE支持PEI，则至少应支持基于UE ID的子分组方法；
PEI监控可以通过系统信息限制在最后使用的小区（即UE最近接收RRCRelease的那个小区，且未指示PEI的最后使用小区不应更新）；
支持PEI的UE应存储其最后使用的小区信息；
支持PEI监控到最后使用小区功能的gNB，在NG-AP UE上下文释放完成消息中将该UE的最后使用小区信息提供给AMF，如TS 38.413所述；
期待MBS组通知的UE应忽略PEI，并应在其PO中监控寻呼。
CN控制子分组：对于CN控制的子分组，AMF负责为UE分配子组ID。CN控制子分组的总数可以配置，例如通过OAM，最多为8个。假设CN控制子分组支持在RNA中是同质的。
以下图示描述了CN控制子分组的过程：

UE通过NAS信令表明其对CN控制子分组的支持。
如果UE支持CN控制子分组，AMF确定UE的子组ID分配。
AMF通过NAS信令将子组ID发送给UE。
AMF通知gNB CN分配的子组ID，以便在RRC_IDLE/RRC_INACTIVE状态下寻呼UE。
当gNB接收到来自CN的UE寻呼消息或由gNB生成的消息时，gNB确定UE的PO和相关的PEI时机。
在UE在PO中被寻呼之前，gNB传输相关PEI，并指示将在PEI中被寻呼的UE对应的CN控制子组。
基于UE ID的子分组：对于基于UE ID的子分组，gNB和UE可以根据UE ID和小区中基于UE ID的子分组的总数来确定子组ID。基于UE ID的子分组的总数由gNB为每个小区决定，并且在不同的小区中可能不同。以下图示描述了基于UE ID的子分组过程：

Figure 9.2.5-2: Procedure for UE ID based subgrouping
gNB确定小区中基于UE ID的子分组的总数。
gNB在小区中广播基于UE ID的子分组的总数。
UE确定其在小区中的子组。
当gNB接收到来自CN的PEI支持UE的寻呼消息或由gNB生成的消息时，gNB确定UE的PO和相关的PEI时机。
在UE在PO中被寻呼之前，gNB传输相关PEI，并指示在PEI中被寻呼的UE的UE ID子组。