駐留在INACTIVE狀態(tài)的UE不連續(xù)地監(jiān)聽下行信道，而是周期性地監(jiān)聽由DRX尋呼周期控制的尋呼信道。因此，除非UE具有移動發(fā)起的活動，否則網(wǎng)絡(luò)必須使用下行尋呼來到達(dá)UE，要求后者采取某些動作。

RAN尋呼

由于UE INACTIVE狀態(tài)對核心網(wǎng)不可見，并且核心網(wǎng)假設(shè)UE處于ECM_CONNECTED狀態(tài)，因此最常見的使用情況是RAN網(wǎng)絡(luò)向UE發(fā)起下行尋呼。RAN網(wǎng)絡(luò)發(fā)送下行尋呼的最常見的觸發(fā)是下行數(shù)據(jù)到達(dá)gNB，對于gNB，UE最期望的動作是喚醒并向網(wǎng)絡(luò)發(fā)送“Request”消息：如果UE確實(shí)知道網(wǎng)絡(luò)意圖是發(fā)送下行數(shù)據(jù)，則UE響應(yīng)于下行尋呼發(fā)送“Request”消息是合乎邏輯的。然而，網(wǎng)絡(luò)將向UE發(fā)送尋呼消息（這不一定要求UE發(fā)送“Request”消息）可能有多種原因和情形：

• RAN尋呼不會觸發(fā)UE發(fā)送“Request”消息的場景和用例之一是通過尋呼釋放RRC連接。代替喚醒UE并通過顯式RRC信令釋放其RRC連接，可以考慮當(dāng)網(wǎng)絡(luò)將要求UE釋放AS上下文并移動到IDLE時(shí)的方法。

• 另一個(gè)有點(diǎn)類似的場景是Rel-13中為LTE引入的E-UTRAN異頻重新分配功能。同樣，網(wǎng)絡(luò)可以簡單地通過尋呼命令采取相應(yīng)的動作，而不是喚醒UE并交換明確的RRC消息（因此UE甚至?xí)３衷贗NACTIVE狀態(tài)）。

當(dāng)然，NR第一階段可能只有一個(gè)主要用例，即“mobile-terminated call”，NR規(guī)范將指示UE啟動“resume”過程。然而，由于很難預(yù)測其他場景可能是什么，而且NR適合于解決不同的用例，因此有一個(gè)統(tǒng)一的框架來支持各種場景似乎是有益的。

CN尋呼

當(dāng)UE保持在RRC INACTIVE模式時(shí)，從核心網(wǎng)的角度來看，它被認(rèn)為處于ECM_CONNECTED模式，這在大多數(shù)情況下不需要任何CN發(fā)起的尋呼。可能存在各種錯(cuò)誤或狀態(tài)失配情況，之后，核心網(wǎng)可以通過尋呼更大的跟蹤區(qū)域來到達(dá)UE。

根據(jù)業(yè)內(nèi)的初步觀點(diǎn)，如果處于INACTIVE狀態(tài)的UE接收到CN尋呼，則其應(yīng)放棄As上下文（即邏輯上移動到IDLE狀態(tài)）并發(fā)起新的RRC連接請求。即使這可能是最預(yù)期和最常見的動作模式（類似于具有RAN尋呼的移動終端呼叫），也值得注意的是，根據(jù)網(wǎng)絡(luò)內(nèi)的根本原因和確切故障類型，UE可以采取不同的動作。

• 如果存在RAN無法到達(dá)UE并請求CN協(xié)助的移動端接呼叫，則指示UE建立新的RRC連接確實(shí)更合理。

• 如果存在網(wǎng)絡(luò)側(cè)故障（例如，gNB崩潰或UE上下文丟失），則CN尋呼意圖將僅僅是讓UE知道它將放棄AS上下文并移動到IDLE，而無需任何進(jìn)一步的動作。

盡管可能有一個(gè)主要的用例，但與在RAN尋呼中所做的考慮大致相同，這不應(yīng)排除NR框架來解決其他場景。結(jié)果，CN發(fā)起的尋呼理想地應(yīng)該具有在接收到相應(yīng)尋呼消息之后控制UE動作的原因值。