CN和RAN寻呼

驻留在INACTIVE状态的UE不连续地监听下行信道，而是周期性地监听由DRX寻呼周期控制的寻呼信道。因此，除非UE具有移动发起的活动，否则网络必须使用下行寻呼来到达UE，要求后者采取某些动作。

RAN寻呼

由于UE INACTIVE状态对核心网不可见，并且核心网假设UE处于ECM_CONNECTED状态，因此最常见的使用情况是RAN网络向UE发起下行寻呼。RAN网络发送下行寻呼的最常见的触发是下行数据到达gNB，对于gNB，UE最期望的动作是唤醒并向网络发送“Request”消息：如果UE确实知道网络意图是发送下行数据，则UE响应于下行寻呼发送“Request”消息是合乎逻辑的。然而，网络将向UE发送寻呼消息（这不一定要求UE发送“Request”消息）可能有多种原因和情形：

• RAN寻呼不会触发UE发送“Request”消息的场景和用例之一是通过寻呼释放RRC连接。代替唤醒UE并通过显式RRC信令释放其RRC连接，可以考虑当网络将要求UE释放AS上下文并移动到IDLE时的方法。

• 另一个有点类似的场景是Rel-13中为LTE引入的E-UTRAN异频重新分配功能。同样，网络可以简单地通过寻呼命令采取相应的动作，而不是唤醒UE并交换明确的RRC消息（因此UE甚至会保持在INACTIVE状态）。

当然，NR第一阶段可能只有一个主要用例，即“mobile-terminated call”，NR规范将指示UE启动“resume”过程。然而，由于很难预测其他场景可能是什么，而且NR适合于解决不同的用例，因此有一个统一的框架来支持各种场景似乎是有益的。

CN寻呼

当UE保持在RRC INACTIVE模式时，从核心网的角度来看，它被认为处于ECM_CONNECTED模式，这在大多数情况下不需要任何CN发起的寻呼。可能存在各种错误或状态失配情况，之后，核心网可以通过寻呼更大的跟踪区域来到达UE。

根据业内的初步观点，如果处于INACTIVE状态的UE接收到CN寻呼，则其应放弃As上下文（即逻辑上移动到IDLE状态）并发起新的RRC连接请求。即使这可能是最预期和最常见的动作模式（类似于具有RAN寻呼的移动终端呼叫），也值得注意的是，根据网络内的根本原因和确切故障类型，UE可以采取不同的动作。

• 如果存在RAN无法到达UE并请求CN协助的移动端接呼叫，则指示UE建立新的RRC连接确实更合理。

• 如果存在网络侧故障（例如，gNB崩溃或UE上下文丢失），则CN寻呼意图将仅仅是让UE知道它将放弃AS上下文并移动到IDLE，而无需任何进一步的动作。

尽管可能有一个主要的用例，但与在RAN寻呼中所做的考虑大致相同，这不应排除NR框架来解决其他场景。结果，CN发起的寻呼理想地应该具有在接收到相应寻呼消息之后控制UE动作的原因值。