從LTE開始，無線網(wǎng)絡(luò)的目標是允許UE保持在“始終連接”模式，這有效地涵蓋了許多場景，例如初始建立連接或過渡到UE可以開始與網(wǎng)絡(luò)交換數(shù)據(jù)的狀態(tài)。在RAN2#98會議期間，NR引入了INACTIVE狀態(tài)，該狀態(tài)被建模為獨立的RRC狀態(tài)。其實在層2還考慮了許多狀態(tài)轉(zhuǎn)換案例，并就如何實現(xiàn)這些案例做出了決定。如何準確地引用INACTIVE狀態(tài)以及CONNECTED是否引用特定RRC狀態(tài)或是否應(yīng)該有一種方法來指示UE具有AS上下文，而不管其處于何種RRC狀態(tài)。

在3G時代，也就是UMTS系統(tǒng)中引入了不同的RRC狀態(tài)。參考TS 25.331，從NAS層的角度來看，UE可以處于空閑模式或連接模式，因此連接模式包括另外四種不同的RRC狀態(tài)：URA_PCH、CELL_PCH、CellL_FACH和CELL_DCH。當準確的RRC狀態(tài)不重要時，這種方法允許區(qū)分IDLE和CONNECTED模式，但更重要的是強調(diào)UE具有AS上下文。同時，可以參考特定RRC狀態(tài)，例如CELL_DCH。

對于NR系統(tǒng)，可能會出現(xiàn)與UMTS中完全相同的術(shù)語問題：有時需要指示UE處于CONNECTED模式，這意味著它具有as上下文，而有時需要參考特定的RRC狀態(tài)（例如，INACTIVE或ACTIVE/CONNECTED）?？紤]到NR第2階段和第3階段規(guī)范已經(jīng)將RRC狀態(tài)稱為RRC_IDLE、RRC_INACTIVE和RRC_CONNECTED，可以通過如下圖2所示區(qū)分特定的RRC狀態(tài)和“模式”。該方法的另一個優(yōu)點是它與LTE技術(shù)（只有IDLE和CONNECTED）在邏輯上一致，并且當連接到5G CN時也可能具有INACTIVE狀態(tài)。

避免術(shù)語歧義的一種更激進的方法是將RRC_CONNECTED狀態(tài)重命名為RRC_ACTIVE，如圖3所示。換句話說，CONNECTED模式將包含兩種RRC狀態(tài)：RRC_INACTIVE和RRC_ACTIVE。優(yōu)點是CONNECTED模式將明確地指代AS模式，并且不會與圖2所示的相應(yīng)RRC狀態(tài)混淆。這種方法的缺點是，即使NR RRC_ACTIVE將直接對應(yīng)于LTE CONNECTED，名稱也會不同。

圖4提供了NR RRC狀態(tài)機的高級概述，以及RRC狀態(tài)之間的可能轉(zhuǎn)換。INACTIVE被建模為獨立的RRC狀態(tài)，因此可以設(shè)想以下狀態(tài)轉(zhuǎn)換情況：

• 從IDLE到CONNECTED以及從CONNECTED到IDLE；

• 從已連接到未激活，以及從未激活到已連接；

• 從停用到空閑。

關(guān)于從INACTIVE狀態(tài)到IDLE狀態(tài)的狀態(tài)轉(zhuǎn)換，可能存在各種錯誤情況，因此UE丟失其上下文或重新排序以重新建立其RRC連接和AS上下文。除此之外，還有由網(wǎng)絡(luò)內(nèi)部RRM機制觸發(fā)的正常RRC連接釋放過程。即使可以假設(shè)沒有用戶面活動的UE將長時間保持在INACTIVE狀態(tài)，但不能假設(shè)網(wǎng)絡(luò)將無限地保持UE處于該狀態(tài)；也不能強制執(zhí)行這種網(wǎng)絡(luò)行為。此外，即使網(wǎng)絡(luò)原則上可以在不通知UE的情況下刪除UE上下文，并在下一次連接嘗試時要求其建立新連接，但這不是運行整個系統(tǒng)的最有效方式，因為UE將需要更多時間來恢復(fù)其連接。除此之外，某些潛在特征的功能，例如INACTIVE中的數(shù)據(jù)傳輸，將要求網(wǎng)絡(luò)保持UE上下文，結(jié)果，網(wǎng)絡(luò)仍將尋求發(fā)送明確指示以釋放UE RRC連接。

用于將UE從INACTIVE重新配置為IDLE的基線過程是使得網(wǎng)絡(luò)首先將UE帶到CONNECTED模式，從該模式可以將其連接釋放到IDLE。然而，如圖5所示，它將涉及在gNB和UE之間交換的大量RRC消息，因為前者必須尋呼UE（1條消息），確保其已進入CONNECTED模式（3條消息用于基線恢復(fù)過程），并最終釋放連接（1條信息）。當網(wǎng)絡(luò)確實有理由將UE移動到CONNECTED狀態(tài)之后，可以將其釋放到IDLE時，該動作序列更適用于這種情況。

減少RRC消息數(shù)量的最簡單方法之一是允許網(wǎng)絡(luò)響應(yīng)請求消息發(fā)送消息（例如RRCConnectionRelease）。相應(yīng)的一組消息如下圖5所示，涉及UE和網(wǎng)絡(luò)之間交換的3個RRC消息。響應(yīng)消息是否應(yīng)該始終加密并通過SRB1發(fā)送，以便UE可以信任它，或者是否也允許通過SRB0發(fā)送響應(yīng)消息。

從圖5中可以看出，仍需要3個RRC消息將UE從INACTIVE移動到IDLE，可以認為，將UE從一個功率有效狀態(tài)移動到另一個功率高效狀態(tài)是一個簡單操作的巨大信令開銷。進一步最小化RRC消息數(shù)量的解決方案之一是對RRC尋呼消息采用新的原因值，這將指示UE釋放其連接。如圖6所示，一旦UE從網(wǎng)絡(luò)接收到尋呼+釋放指示，它將向網(wǎng)絡(luò)發(fā)送“完成”消息，確認接收到該尋呼指示符。如果網(wǎng)絡(luò)從UE接收到響應(yīng)，則它將知道UE已經(jīng)接收到尋呼并且將釋放其連接；否則網(wǎng)絡(luò)可以考慮重新發(fā)送尋呼消息。

作為圖6所示解決方案的進一步優(yōu)化，可以考慮從UE中刪除“完整”消息。此解決方案已經(jīng)存在于UMTS規(guī)范中，但由于沒有來自UE的“響應(yīng)”，因此有些不可靠。換言之，當網(wǎng)絡(luò)發(fā)出帶有“釋放”命令的尋呼消息時，后者不知道UE是否接收到該尋呼消息，因此不知道如何到達該尋呼消息。另一方面，處于INACTIVE狀態(tài)的UE也可以接收CN尋呼消息，這意味著即使UE錯過了RAN級尋呼，它仍將對網(wǎng)絡(luò)稍后可能發(fā)送的CN尋呼采取行動。