​

 1. 寻呼目的

 在 36.331 中寻呼的目的描述如下：

1. 发送核心网发起的寻呼消息给 RRC_IDLE 或 RRC_INACTIVE 状态的 UE；

2. 发送接入网发起的寻呼消息给 RRC_INACTIVE 状态的 UE；

3. 通知 RRC_IDLE、RRC_INACTIVE 或 RRC_CONNECTED 状态下的 UE 系统消息变更；

4. 通知 RRC_IDLE、RRC_INACTIVE 或 RRC_CONNECTED 状态的 UE 关于 ETWS 主通知、ETWS 辅助通知的信息；

5. 通知 RRC_IDLE、RRC_INACTIVE 或 RRC_CONNECTED 状态的 UE 关于 CMAS 通知的信息；

6. 通知 RRC_IDLE 状态的 UE 或者连接到 5GC 的 UE，EAB 参数修改；

7. 通知 RRC_IDLE 状态或 RRC_INACTIVE 状态的 UE，执行 E-UTRAN 频间重配程序。

在 38.331 寻呼的目的描述为：

        发送寻呼消息给 RRC_IDLE 或 RRC_INACTIVE 状态的 UE；

      对于两者的不同，实际上 5G 区别于 4G 的地方在于，5G 使用 DCI format 1_0 中的 Short Message 字段的相关来指示系统消息变更和 ETWS 通知（参见 TS 38.212 [17]，第 7.3.1.2.1 节）。

        下表定义了 Short Message,Bit 1 是最重要的位。

2. 寻呼分类

按照消息来源分，寻呼可以分为：

1. 5GC 寻呼，来自于 5GC，RRC_IDLE 状态下，RRC_IDLE 状态 UE 有下行数据到达时，5GC 通过 Paging 寻呼消息通知 UE；

2. RAN 寻呼，来自于 gNB，RRC_INACTIVE 状态 UE 有下行数据到达时，gNB 通过 RAN Paging 寻呼消息通知 UE 启动数传；

最终的寻呼消息下发都是由 gNB 通过空口下发给 UE 的。

3. 寻呼发送

3.1 寻呼信道

        寻呼消息由 PCCH 逻辑信道承载，PCCH 逻辑信道的数据块又是由 PCH 传输信道来承载，而 PCH 传输信道的数据块又是由 PDSCH 物理信道来承载的。由于 PDSCH 是下行共享物理信道，所以其上除了可以承载 PCH 传输信道之外，还可以承载 DL-SCH 传输信道。因此在接收寻呼消息之前，终端需要先去监听 PDCCH 物理信道，然后根据 PDCCH 物理信道上是否有携带 P-RNTI，来判断网络在本次寻呼周期是否有发送寻呼消息给自己。

 3.2 寻呼时机

        为了降低 RRC_IDLE/RRC_INACTIVE 状态下 UE 的功耗，UE 使用非连续接收方式（DRX）接收寻呼消息。一个 DRX cycle 内有若干个 PF，一个 PF 对应若干个 PO，UE 在一个 DRX cycle 内只醒来一次监测一个 PO.UE 监视每个 DRX 周期的一个寻呼时机（PO）。 PO 是一组 PDCCH 监视时机，并且可以包括可以发送寻呼 DCI 的多个时隙（例如，子帧或 OFDM 符号）（TS 38.213 [4]）。一个寻呼帧（PF）是一个无线电帧，并且可以包含一个或多个 PO 或 PO 的起始点。

        DRX cycle 就表示 UE 检测 Paging 的周期，PF 表示检测 Paging 的系统帧，PO 表示检测 paging 的具体 PDCCH monitoring occasions，i_s 就表示 PF 所对应 PO 的 index，计算方式如下：4G 和 5G 计算 PF 和 i_s 的公式相同：        PF： (SFN + PF_offset) mod T = (T div N)*(UE_ID mod N)        I_s： i_s = floor (UE_ID/N) mod Ns        其中的参数解释如下：

• T:就是 DRX cycle

  
  

  系统消息中会有一个小区级别的指示 Tc，同时 RRC 也有可能会有 UE 级别的指示 Tue，如果没有指示 Tue，则 T=Tc，如果指示了 Tue，则 T=min(Tc,Tue)。

• N: T 中的 PF 总数

• Ns: 一个 PF 对应的 PO 数量

• PF_offset:PF 的偏移

        UE_ID: 5G-S-TMSI mod 1024

        TMSI 是 UE 的临时移动用户识别码 Temporary Mobile Subscriber Identify，可以用于唯一区分不同的 UE，这个在随机接入的 Msg3 中也会用到。当 UE 还没有 TMSI 时，默认 UE_ID = 0。

3.3 接受寻呼消息

当 UE 收到寻呼消息后：

1>当 UE 处于 RRC_IDLE，如果 PagingRecord 中包含的 ue-Identity 与上层分配的 UE identity 匹配，将 ue-Identity 和 accessType（如果存在）转发到上层;

1>当 UE 处于 RRC_INACTIVE，

        2>如果 PagingRecord 中包含的 ue-Identity 与 UE 存储的 fullI-RNTI 匹配：

                3>如果 UE 由具有访问标识 1 的上层配置：

                        4>根据 5.3.13 启动 RRC 连接恢复过程，resumeCause 设置为 mps-PriorityAccess；

                3>否则，如果 UE 由具有访问标识 2 的上层配置：

                        4>根据 5.3.13 启动 RRC 连接恢复过程，resumeCause 设置为 mcs-PriorityAccess;

                3>否则如果 UE 由上层配置，其中一个或多个接入标识等于 11-15：

                        4>根据 5.3.13 启动 RRC 连接恢复过程，resumeCause 设置为 highPriorityAccess;

                3> else:

                        4>根据 5.3.13 启动 RRC 连接恢复过程，并将 resumeCause 设置为 mt-Access;

        2>否则，如果 PagingRecord 中包含的 ue-Identity 与上层分配的 UE 标识匹配：

                3>将 ue-Identity 转发到上层，将 accessType（如果存在）转发到上层;

                3>按照 5.3.11 中的规定进入 RRC_IDLE 并执行释放原因“other”。

​