凌晨3點，一台5G工業閘道器向AMF傳送Registration Request。它的TAI與上次註冊時相同，5G-GUTI沒有變化，服務AMF也沒有改變，而且裝置可能已經數小時沒有傳送任何上行資料。僅從移動性管理角度看，這次請求沒有攜帶新的位置資訊，看起來甚至像一次重複註冊。但註冊類型欄位明確表示這是一次週期性註冊更新。AMF此時需要確認的並不是UE移動到了哪裡，而是更基礎的問題：UE是否仍然存在、是否仍應被視為可透過尋呼到達，以及現有註冊上下文是否應繼續保留。
在5GC註冊管理中，移動性註冊更新與週期性註冊更新解決的是兩個不同的問題。前者由移動行為觸發，重點是位置和路由資訊更新；後者由T3512到期觸發，重點是定期確認註冊狀態和UE可達性。即使UE一直停留在同一註冊區域、仍由同一服務AMF管理且位置沒有變化，只要它長期處於CM-IDLE，T3512到期後仍可能需要與網路互動。透過這次互動，網路可以刷新對UE可達性的判斷；如果UE持續缺席，還可以透過隱式解除註冊逐步釋放陳舊的註冊上下文。因此，理解週期性註冊更新的關鍵並不在於Registration Request是否攜帶了新位置，而在於T3512如何管理、UE如何在CM-IDLE中觸發該流程、AMF如何解釋註冊類型和UE上下文，以及網路如何處理未按時更新的UE。
UE沒有移動，為什麼仍需要週期性註冊？
完成初始註冊後，UE進入5GS Registered狀態。但“Registered”並不意味著UE始終與AMF保持NAS信令連線。許多智慧型手機、IoT裝置和低流量終端在沒有活動資料或信令時會進入CM-IDLE，以減少無線側和核心網路資源消耗。
從UE角度看，長時間保持空閒可以節省資源；但從5GC角度看，這會產生一個重要問題：AMF上一次確認UE可用，可能已經是幾十分鐘前甚至幾小時前。此後UE可能已經關機、失去覆蓋或電池耗盡，也可能只是正常駐留在網路中而沒有產生任何業務。
如果核心網路無限期保留UE註冊，就可能一直儲存已經無法到達裝置的陳舊上下文；如果過於積極地清理上下文，又可能迫使仍正常註冊的UE不必要地重新建立註冊。
週期性註冊更新用於協調這兩種需求。網路透過 T3512 告知UE：在再次發生相關5GMM互動之前，它最多可以保持多長時間而不發起週期性註冊更新。
因此，這一流程可以理解為UE與5GC之間的週期性狀態簽到：
UE已經完成註冊
→ UE長時間保持CM-IDLE
→ T3512持續運作
→ T3512到期
→ UE重新建立NAS信令連線
→ UE發起週期性註冊更新
→ AMF確認並刷新註冊狀態
它的主要目的不是上報新的跨區域移動，而是防止UE與網路長期不同步，無法確認現有註冊上下文是否仍然有效。
T3512究竟在什麼時候開始運作？
T3512並不是由UE自行選擇的本地計時器，它的數值由網路控制。AMF可以在Registration Accept訊息中向UE提供週期性註冊計時器值。除非UE之後收到新的數值，否則會繼續使用已經儲存的T3512設定。
3GPP定義的T3512預設值為54分鐘，但這並不意味著所有商用5G網路中的所有UE都會每54分鐘執行一次更新。AMF可以根據網路設定、UE行為、訂閱資訊和策略指派其他數值。如果網路停用T3512或將其設置為0，則不會執行對應的週期性註冊更新。
在常見的3GPP接取場景中，如果網路沒有啟用嚴格週期註冊計時器能力，UE從5GMM-CONNECTED轉入5GMM-IDLE時會啟動或重新啟動T3512；UE重新進入5GMM-CONNECTED時，該計時器通常停止。這一點很重要，因為週期性註冊更新並不是完全不考慮UE活動、只按照絕對時間機械觸發。
假設UE在09:00完成註冊，隨後釋放NAS信令連線並進入CM-IDLE，同時T3512設定為54分鐘。如果期間沒有其他互動使計時器停止、重新啟動或改變數值，那麼T3512到期後，UE預計會進入週期性註冊更新流程。
較新的規範行為還可以支援嚴格週期註冊計時器。在這種模式下，T3512可以在註冊成功完成後開始運作，並不會僅因為UE進入5GMM-CONNECTED就停止。如果計時器在UE處於連線態時到期，計時器可能被重新啟動，而實際的週期性註冊更新仍根據當前5GMM狀態進行處理。
因此，在Registration Accept中看到“T3512 = 54分鐘”，並不自動意味著54分鐘後一定會準確出現一條Registration Request。封包追蹤分析還需要考慮這段時間內UE是否進入過CONNECTED狀態、是否發生過其他註冊流程、是否啟用了嚴格週期模式，以及計時器是否更新或停用。
週期性Registration Request與初始註冊有何不同？
T3512到期後，UE需要重新建立與網路的控制面通訊。透過gNB恢復NAS信令路徑後，gNB向AMF傳送NGAP Initial UE Message，其中攜帶UE當前位置資訊以及NAS Registration Request。
信令分析中最重要的資訊元素是Registration Request中的 5GS registration type（5GS註冊類型） 。在該流程中，它被設置為 periodic registration updating（週期性註冊更新），明確告訴AMF：UE並不是第一次接取5GS，也不是因為離開註冊區域而更新註冊，而是在週期性刷新既有註冊關係。
UE通常還會攜帶現有5G-GUTI，使AMF能夠快速將該請求與已有UE上下文關聯。訊息還可能包含Last Visited Registered TAI、UE Security Capability和PDU Session Status等資訊，幫助網路核對UE當前持有的移動性和會話狀態。
因此，從封包追蹤開始位置就可以區分三種容易混淆的Registration Request場景：
初始註冊：UE需要建立新的5GS註冊關係
移動性註冊更新：UE的移動位置或註冊區域條件發生變化
週期性註冊更新：既有註冊關係需要按週期刷新
三種流程都會使用Registration Request，但觸發原因完全不同。分析5GC註冊信令時，僅看到“Registration Request”這個訊息名並不足以判斷具體流程，首先應檢查5GS 註冊類型。
服務AMF不變時，為什麼更新流程可以如此簡短？
週期性註冊更新最重要的特徵之一，並不是它增加了多少新的信令訊息，而是在已有上下文仍有效時，它可以比初始註冊短很多。
假設UE仍位於同一AMF的服務區域內，沒有發生AMF切換，先前建立的UE上下文和安全上下文仍可使用，並且沒有訂閱或策略變化需要額外處理。當AMF收到攜帶現有5G-GUTI的Registration Request時，可以利用與該身分關聯的GUAMI資訊判斷UE仍由本地服務，並取得對應的UE上下文。
在這些條件下，完整初始註冊中常見的許多流程並不一定需要重複執行。
如果身分和安全狀態仍有效，可能不需要執行完整5G-AKA，因此封包追蹤中也可能看不到AUSF。由於服務AMF沒有變化，AMF不會僅僅因為發生了一次週期更新就必然重新向UDM註冊自己，或重新取得完整訂閱設定。如果接取區域和策略沒有變化，也可能無需重新執行PCF AM Policy流程。如果不需要重新選擇AUSF、UDM或PCF，對應的NRF發現流程也可能不會出現。
因此，一個典型的簡化信令路徑可能如下：
UE
→ gNB：重新建立接取
→ AMF：Initial UE Message + Periodic Registration Request
→ AMF：利用5G-GUTI取得現有UE上下文
→ gNB / UE：Registration Accept
→ UE：需要時傳送Registration Complete
“可能不需要”這一表述非常重要。3GPP註冊框架允許網路根據當前上下文執行必要的身分、安全、訂閱和策略處理。因此，商用網路中看到的簡化封包追蹤不能被理解成所有週期性註冊更新都必須遵循的固定序列。
Registration Accept可以刷新哪些註冊狀態？
AMF確認UE可以繼續保持註冊後，會透過Registration Accept向UE回傳更新後的註冊結果。根據網路處理結果，該訊息可包含Allowed NSSAI、T3512、TA List，以及在需要時新指派的5G-GUTI等參數。
T3512在週期性註冊更新中尤其重要。如果AMF提供了新值，UE應在下一週期使用該值；如果沒有提供新值，UE可以繼續使用已經儲存的設定。這樣，網路可以隨時間調整週期性註冊行為，而不是把更新間隔永久固定在終端內部。
Registration Accept中的TA List繼續定義UE當前的註冊區域。雖然週期性更新本身並不是因為離開該區域而觸發，但一次成功的註冊互動仍允許網路向UE提供最新的移動性管理參數。
如果Registration Accept中包含新指派的5G-GUTI，UE需要透過Registration Complete確認成功接收該暫時身分。如果AMF沒有指派新的5G-GUTI，沒有出現Registration Complete也不自動代表流程失敗。應根據Registration Accept中實際包含、且需要確認的資訊元素來解釋封包追蹤。
這也說明週期性註冊更新並不只是簡單的連線維持。它仍屬於5GMM Registration框架，使網路能夠重新同步與註冊相關的移動性參數，而不僅僅是檢查UE是否還能回應。
如何在信令封包追蹤中確認週期性註冊更新？
疑難排解週期性註冊更新時，最有效的方法不是一開始就尋找AUSF或UDM信令，而是沿著以下鏈路檢查： T3512 → UE狀態 → Registration Request → AMF上下文 → Registration Accept。
如果UE完成註冊後始終沒有發起週期更新，首先檢查Registration Accept中是否包含有效的T3512值。如果T3512停用或設置為0，就不應期待出現週期更新。如果數值有效，再確認UE是否真正進入適用的5GMM-IDLE狀態，以及期間是否發生過可能讓計時器停止、重新啟動或更新的NAS互動。
如果UE傳送了Registration Request，但AMF把它當作Initial Registration處理，應檢查5GS 註冊類型和5G-GUTI。如果AMF無法將5G-GUTI與已有UE上下文關聯，流程可能進入更複雜的身分恢復或重新註冊路徑。
如果Registration Request被正確識別，但隨後仍出現完整認證流程，這本身並不能證明存在故障。應檢查現有NAS Security Context，並確認網路是否根據安全策略決定重新執行認證。
除UE側的T3512外，AMF還使用一個重要的網路側可達性監督機制： Mobile Reachable Timer（移動可達計時器）。對於正常註冊的UE，該網路側計時器長於T3512，預設關係通常為T3512加4分鐘。AMF在釋放NAS信令連線後啟動Mobile Reachable Timer，並在UE重新建立NAS連線時停止該計時器。
這兩個機制協同工作：
UE側T3512：告訴UE何時應回傳網路刷新註冊狀態
AMF側Mobile Reachable Timer：監督UE是否在預期時間內重新出現
如果UE長時間未與網路聯繫，Mobile Reachable Timer以及後續的隱式解除註冊機制可以讓核心網路逐步處理已無法確認可達性的UE，而不是無限期保留陳舊註冊上下文。
因此，5GC週期性註冊更新的真正目的並不是“每隔幾十分鐘重新註冊一次”。它讓長時間處於空閒狀態的UE與AMF週期性重新建立對註冊狀態的一致認知： UE仍然存在，現有註冊關係仍然有效，相關移動性參數可以繼續用於下一個週期。
常見問題
所有5G網路中的T3512都固定為54分鐘嗎？
不是。54分鐘是3GPP定義的預設值，但AMF可以根據網路設定、UE行為、訂閱資訊和策略指派其他數值。信令分析和故障疑難排解應始終以UE實際收到的T3512值為準，而不能假設它永遠都是54分鐘。
如果UE在54分鐘期間有正常流量，它仍會在第54分鐘準確傳送週期性註冊更新嗎？
不一定。在正常T3512運作機制下，進入5GMM-CONNECTED會影響週期計時器，UE之後回到IDLE時計時器可能重新啟動。因此，不能簡單在初始註冊完成時間上加54分鐘來預測下一條Registration Request。啟用嚴格週期註冊計時器時，計時行為也會有所不同。
每次週期性註冊更新都需要AUSF、UDM和PCF參與嗎？
不需要。如果服務AMF保持不變，現有UE上下文和安全上下文有效，並且訂閱或策略資訊無需刷新，流程可以非常簡短。AUSF、UDM、PCF或NRF是否被調用，取決於當時的UE上下文和網路實現，不應把它們視為每次週期性註冊更新都必須參與的網路功能。
週期性註冊更新適用於Wi-Fi等非3GPP接取嗎？
基於T3512的週期性註冊更新機制適用於透過3GPP接取註冊到5GS的UE。對於非3GPP接取，5GS使用其他相應的註冊與解除註冊管理機制，因此用於NR接取的T3512週期性註冊更新行為不能直接套用到Wi-Fi或其他非3GPP接取場景。
