在完全連線的UE與完全空閒的UE之間，5G引入了一種從使用者側看似安靜、但在NG-RAN內部仍具有重要技術意義的狀態，這就是RRC非活動態。5G連線管理加入這一狀態，是為了解決一個實際問題：許多裝置需要迅速恢復資料傳輸，但如果所有裝置始終保持在RRC連線態，將浪費信令資源、無線電資源和電池電力。
智慧型手機可能會檢查背景訊息，感測器可能會發送短時資料，應用程式也可能在長時間靜默後短暫喚醒。這些流量模式並不總是值得先完全返回空閒態，再執行完整的連線建立流程。RRC非活動態提供了一個中間層。UE可以降低活動程度、保留關鍵上下文，並在出現上行或下行資料時更快恢復連線。
需要注意的是，RRC非活動態並不等同於RRC空閒態。在RRC空閒態下，從核心網路角度看UE也處於CM-IDLE。在RRC非活動態下，UE仍處於CM-CONNECTED，只是RRC層暫停了主動連線操作。gNodeB保留UE上下文，UE保留AS上下文，網路可透過恢復流程讓UE返回RRC連線態，而無需從頭開始建立所有內容。
為什麼5G需要這種狀態
5G連線管理必須同時服務多種流量類型。有些業務需要高吞吐量和持續連線，有些只需要短時、偶發的資料交換，還有一些終端會長時間靜默，但在網路或應用程式需要時必須快速回應。如果所有UE都保持在RRC連線態，網路將承擔不必要的控制開銷；如果所有非活動UE都被徹底轉入RRC空閒態，連線恢復會變慢並產生更多信令。
RRC非活動態縮小了兩者之間的差距。UE可以停止RRC連線態意義上的主動資料處理，但不會丟棄重要的存取層上下文，因此後續恢復流程能夠更快重建連線。從使用者體驗看，裝置仍可保持較快回應；從網路角度看，系統無需讓主動資源佔用時間超過實際需要。
這種設計特別適合頻繁喚醒但不維持長時間連線的應用程式。訊息服務、背景同步、間歇性感測器上報、小規模上行資料突發和短時下行通知，都可從這種能夠更快返回連線態的狀態中受益。
從網路架構角度看，RRC非活動態還把部分移動性管理和尋呼責任下沉到NG-RAN。AMF無需把本地RAN通知區域內的每一次移動都視為核心網路移動性事件，gNodeB可以更高效地管理UE上下文和本地尋呼行為。
這種狀態如何定義
RRC非活動態具有多個關鍵特徵。首先，UE仍被視為處於CM-CONNECTED。這是它與RRC空閒態的重要區別，因為RRC空閒態下UE同時處於CM-IDLE。儘管RRC連線沒有主動承載常規連線態資料，5G核心網路的連線關係仍然保留。
其次，該狀態對核心網路大體透明。在正常運作中，AMF不需要像NG-RAN那樣直接管理RRC非活動態。最後為UE提供服務的gNodeB會保留UE上下文，並知道UE所屬的RAN通知區域。正是這種上下文保留，使快速恢復成為可能。
第三，UE與gNodeB都會保留AS層上下文。由於存取層上下文被保留，業務恢復時UE無需執行全新的完整建立流程，而可透過RRC Resume流程返回RRC連線態。
進入RRC非活動態是透過攜帶暫停設定的RRC Release訊息達成的。因此，該狀態通常與暫停和恢復流程一起討論。網路釋放活動的RRC連線，但會指示UE暫停上下文，而不是徹底丟棄上下文。
當再次需要活動時，UE可從RRC非活動態轉入RRC連線態。這可能發生在UE有上行資料需要發送時，也可能發生在UE因下行資料收到RAN尋呼時。如果非活動狀態持續時間過長，gNodeB的UE非活動計時器最終可能觸發N2釋放，使UE轉向RRC空閒態和CM-IDLE。
UE仍然可以執行哪些操作
RRC非活動態並不意味着UE被凍結。即使UE沒有主動處於RRC連線態，仍可執行多種流程。UE可以進行PLMN選擇、接收系統資訊廣播、執行小區重選，並回應RAN發起的尋呼。這些功能使UE無需維持完全活動的RRC連線，也能維持可達。
網路端也會以特定方式保持活動。NG-RAN管理RAN通知區域，為RAN尋呼設定DRX，並保留UE的AS上下文。gNodeB知道UE屬於哪個RNA，因此當資料或信令要求UE恢復時，可以確定本地尋呼範圍。
另一個重要點是，在這種運作模式下，UE的N2和N3連線上下文可以繼續保留。這在下行資料到達時十分關鍵。UPF仍可能知道gNodeB地址，並將下行資料轉發至最後為UE提供服務的gNodeB。隨後，gNodeB會在已設定的RNA內觸發尋呼，而不是從頭發起核心網路尋呼流程。
這些保留的要素說明了RRC非活動態為何有用，同時也說明它比簡單空閒行為更複雜。網路必須保留足夠的上下文以便快速恢復，但又不能保留過多主動資源，使其變得與RRC連線態無異。該狀態的價值就在於這種設計平衡。
RNA如何控制移動性
RNA表示RAN通知區域，是面向RRC非活動態UE的RAN側通知區域。一個RNA由多個小區組成，通常位於同一追蹤區域內。當UE在已分配的RNA內移動時，無需每次更換小區都通知網路端，從而避免UE僅在本地區域移動時產生不必要的信令。
RNA透過RNA ID標識。該標識由TAC和RAN區域碼組成，RAN區域碼的取值範圍為0至255。實際上，這使NG-RAN能夠以緊湊方式定義本地區域，讓非活動UE在其中移動而無需頻繁更新。
最後為UE提供服務的gNodeB透過RRC Release訊息中的暫停設定分配RNA ID。這一點很重要，因為最後為UE提供服務的gNodeB需要負責掌握UE的RNA上下文。如果之後出現下行資料，該gNodeB便可決定如何在正確區域內尋呼UE。
在特定條件下，UE仍必須更新網路。如果週期性RNA更新計時器到期，或UE離開已設定的RNA，就應啟動RNA更新流程。這樣既能防止NG-RAN失去對UE本地區域的有效掌握，又能避免UE在RNA內正常移動時產生過多信令。
RNA設計會影響尋呼效率。RNA過小，UE移動時可能頻繁更新；RNA過大，下行資料到達時可能需要尋呼更多小區，從而增加尋呼開銷。因此，良好規劃需要結合使用者移動模式、小區佈局、gNodeB邊界和預期業務行為。
下行資料如何送達
下行資料處理是說明RRC非活動態存在價值的最直觀示例之一。當UE處於RRC非活動態時，如果下行資料從UPF到達，資料可被發送至最後為UE提供服務的gNodeB。由於該gNodeB知道UE處於非活動態，但仍可透過RAN級尋呼在本地觸達，因此會在RNA內發起尋呼。
如果RNA內所有小區都屬於最後為UE提供服務的gNodeB，流程相對直接。gNodeB會在相關小區尋呼UE。UE收到RAN尋呼訊息後啟動RRC Resume流程並返回RRC連線態。恢復完成後，UE即可接收下行資料。
如果RNA包含由相鄰gNodeB服務的小區，最後為UE提供服務的gNodeB可能使用Xn信令。它可以向相鄰gNodeB發送XnAP RAN Paging訊息，使這些小區也能執行尋呼。這樣，尋呼範圍可以跟隨RNA，而不是僅限於最後提供服務的gNodeB自身的小區。
當來自AMF的下行UE關聯信令到達時，也適用相同的總體思路，但UE Context Release Command等情況會採用不同的處理流程。關鍵在於，NG-RAN可以為非活動UE管理尋呼流程，而無需立即把它當作完整空閒模式下的核心網路尋呼場景。
從業務角度看，使用者體驗取決於UE接收尋呼並完成恢復的速度；從網路角度看，系統透過複用上下文並將信令處理本地化而獲得收益。
恢復轉換如何工作
RRC非活動態可從UE側或網路端返回RRC連線態。當UE有上行資料或信令需求時，會發生UE觸發的轉換。UE向gNodeB發送RRC Resume Request。如果當前gNodeB不是最後為UE提供服務的gNodeB，在完成恢復前可能需要從最後提供服務的gNodeB取回UE上下文。
典型的UE觸發流程可能包括RRC Resume Request、Retrieve UE Context Request、Retrieve UE Context Response、RRC Resume和RRC Resume Complete。如果目前服務的gNodeB發生變化，還可能需要額外流程，例如Xn-U Address Indication以及向AMF發送Path Switch Request。路徑切換完成後，可在適當情況下釋放舊上下文。
網路觸發的轉換起點不同。最後為UE提供服務的gNodeB收到下行資料或相關信令後觸發RAN尋呼，並在RNA內尋呼UE。UE收到尋呼後從RRC非活動態恢復並返回RRC連線態，從而處理待傳輸的資料或信令。
這些轉換比從空閒態執行完整連線建立更輕量，但並不代表流程簡單。正確運作依賴已保存的上下文、gNodeB之間的協調、必要時AMF側的路徑切換，以及新服務路徑建立後的規範上下文釋放。
計時器路徑同樣重要。如果UE保持非活動態的時間超過gNodeB的UE非活動計時器策略，網路可將UE轉向RRC空閒態。這通常涉及N2釋放，並把核心網路狀態變為CM-IDLE。此時，RRC非活動態的快速恢復優勢將不再適用。
AMF如何接收狀態報告
RRC非活動態常被描述為對核心網路透明，但這一說法需要準確理解。通常情況下，AMF不會像NG-RAN那樣直接控制UE的RRC狀態。不過，AMF可以透過NGAP信令請求上報RRC狀態轉換。
AMF可在Initial Context Setup Request或UE Context Modification Request等訊息中包含RRC Inactive Transition Report Request參數。當該請求設定為後續狀態轉換報告時，gNodeB應在UE進入或離開RRC非活動態時上報。
發生狀態變化時，gNodeB會向AMF發送RRC Inactive Transition Report。該報告包含RRC State值，例如Inactive或Connected。該機制使AMF在提出請求後獲得可見性，同時不改變RRC非活動態主要由NG-RAN管理這一基本事實。
這種報告能力有助於網路協同、政策感知和運作監控，也說明不能簡單地把RRC非活動態描述為對核心網路完全不可見。更準確的理解是：該狀態主要由RAN管理，而AMF可在指定條件下獲取狀態轉換資訊。
在工程分析中，這一區別非常重要。如果流程失敗，故障排查可能需要同時檢查RAN行為和NGAP報告行為。UE狀態、gNodeB上下文、RNA設定、RAN尋呼、AMF報告請求以及路徑切換處理，都可能影響最終結果。
常見問題
為什麼RRC非活動態不等同於RRC空閒態？
RRC非活動態使UE保持在CM-Connected並保留存取層上下文，而RRC空閒態對應核心網路空閒關係，恢復連線需要執行更重的流程。
什麼會觸發UE從RRC非活動態恢復？
恢復可能由UE的上行資料、UE的信令需求，或由下行資料及受支援下行信令引發的RAN尋呼觸發。
為什麼RNA可以減少信令？
RNA允許UE在規定的RAN通知區域內移動，無需每次小區變化都通知網路，從而減少不必要的本地移動性信令。
如果UE離開其RNA會怎樣？
UE應啟動RNA更新流程，使NG-RAN能夠更新用於本地尋呼和非活動態可達性的區域資訊。
為什麼尋呼可能涉及相鄰gNodeB？
如果RNA包含由相鄰gNodeB服務的小區，最後為UE提供服務的gNodeB可發送XnAP RAN Paging，使這些相鄰小區也能尋呼UE。
AMF何時獲知RRC狀態變化？
當AMF透過受支援NGAP流程中的RRC Inactive Transition Report Request參數提出請求後，就可以接收狀態轉換報告。
RRC非活動態是5G連線管理中最實用的改進之一。它保留足夠的上下文以實現快速恢復，減少不必要的活動連線資源佔用，透過RNA支持本地移動，並使NG-RAN能夠更高效地處理尋呼。它的價值來自平衡：比從完全空閒態恢復更快，比持續保持完全連線更輕量，同時又足夠靈活，可適應現代移動流量模式。
