1. 寻呼目的
在36.331中寻呼的目的描述如下：
- 发送核心网发起的寻呼消息给RRC_IDLE或RRC_INACTIVE状态的UE；
- 发送接入网发起的寻呼消息给RRC_INACTIVE状态的UE；
- 通知RRC_IDLE、RRC_INACTIVE或RRC_CONNECTED状态下的UE系统消息变更；
- 通知RRC_IDLE、RRC_INACTIVE或RRC_CONNECTED状态的UE关于ETWS主通知、ETWS辅助通知的信息；
- 通知RRC_IDLE、RRC_INACTIVE或RRC_CONNECTED状态的UE关于CMAS通知的信息；
- 通知RRC_IDLE状态的UE或者连接到5GC的UE，EAB参数修改；
- 通知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是最重要的位。
Bit |
Short Message |
1 |
systemInfoModification 如果设置为1：指示除SIB6，SIB7和SIB8之外的BCCH修改。 |
2 |
etwsAndCmasIndication 如果设置为1：指示ETWS主通知、ETWS次要通知或CMAS通知。 |
3 – 8 |
当前使用，如果收到，UE将忽略它。 |
2. 寻呼分类
按照消息来源分，寻呼可以分为：
- 5GC寻呼，来自于5GC，RRC_IDLE状态下，RRC_IDLE状态UE有下行数据到达时，5GC通过Paging寻呼消息通知UE；
- 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”。
