午前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に不要な再登録を要求してしまう可能性があります。
周期登録更新は、この2つの要件を調整します。ネットワークは T3512 を使い、次の関連5GMMインタラクションがないままどれだけの時間経過したら周期登録更新を開始すべきかをUEに通知します。
したがって、この手順は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シグナリング接続を解放して、T3512を54分に設定した状態でCM-IDLEへ移行したとします。その間にタイマーを停止、再開始、または変更する別のインタラクションがなければ、T3512満了時にUEは周期登録更新手順へ入ることが想定されます。
新しい仕様では、厳密な周期登録タイマーをサポートする動作もあります。このモードでは、登録成功後にT3512が開始され、UEが5GMM-CONNECTEDへ入っただけでは停止しません。UEが接続状態にある間にタイマーが満了した場合、タイマーは再開始されることがあり、実際の周期登録更新はその時点の5GMM状態に応じて処理されます。
そのためRegistration Acceptに「T3512 = 54分」と表示されていても、54分後に必ず正確にRegistration Requestが現れるとは限りません。トレース解析では、その間にUEがCONNECTED状態へ入ったか、別の登録が行われたか、厳密な周期動作が有効か、タイマーが更新または無効化されたかも考慮する必要があります。
周期的なRegistration Requestは初期登録とどう違うのか？
T3512が満了すると、UEはネットワークとの制御プレーン通信を再確立する必要があります。gNB経由のNASシグナリング経路が復旧すると、gNBはUEの現在位置情報とNAS Registration Requestを含むNGAP Initial UE MessageをAMFへ送信します。
シグナリング解析で最も重要な情報要素はRegistration Request内の 5GS registration type（5GS登録タイプ） です。この手順では periodic registration updating（周期登録更新）に設定され、UEが初めて5GSへ接続しているわけでも、登録エリアから外れたために登録を更新しているわけでもなく、既存登録を定期的に更新していることをAMFへ明確に伝えます。
UEは通常、既存の5G-GUTIも送信するため、AMFは要求を既存のUEコンテキストへ迅速に関連付けられます。メッセージにはLast Visited Registered TAI、UE Security Capability、PDU Session Statusなどが含まれることもあり、ネットワークがUE側で保持しているモビリティ状態とセッション状態を照合するのに役立ちます。
したがって、混同しやすい3種類のRegistration Requestは、トレースの冒頭から区別できます。
初期登録：UEが新しい5GS登録関係を確立する必要がある
モビリティ登録更新：UEの移動位置または登録エリアの条件が変化した
周期登録更新：既存の登録関係を定期的に更新する必要がある
3つの手順はいずれもRegistration Requestを使用しますが、トリガーは根本的に異なります。5GCの登録シグナリングを解析するとき、メッセージ名が「Registration Request」であることだけでは手順を特定できません。最初に確認すべき要素は5GS登録タイプです。
サービスAMFが変わらない場合、なぜ更新手順はこれほど短くできるのか？
周期登録更新の重要な特徴は、新しいシグナリングメッセージを何個追加するかではなく、既存コンテキストが有効であれば初期登録より大幅に短くできる点です。
UEが同じAMFのサービスエリア内にとどまり、AMF変更がなく、以前確立したUEコンテキストとセキュリティコンテキストが引き続き利用でき、追加処理が必要な加入情報やポリシー変更もないとします。AMFが既存5G-GUTIを含むRegistration Requestを受信すると、そのIDに関連付けられたGUAMI情報を利用してUEが引き続きローカルでサービスされていると判断し、対応するUEコンテキストを取得できます。
この条件では、完全な初期登録で一般的に行われる多くの手順を必ずしも繰り返す必要はありません。
IDとセキュリティ状態がまだ有効なら、完全な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の登録フレームワークでは、その時点のコンテキストに必要なID、セキュリティ、加入情報、ポリシー処理をネットワークが実行できます。したがって商用ネットワークの簡略トレースを、すべての周期登録更新に必須の固定シーケンスと解釈してはいけません。
Registration Acceptはどの登録状態を更新できるのか？
AMFがUEの登録継続を認めると、Registration Acceptを通じて更新された登録結果をUEへ返します。ネットワーク側の結果に応じて、Allowed NSSAI、T3512、TA List、必要に応じて新たに割り当てた5G-GUTIなどのパラメータを含めることができます。
周期登録更新ではT3512が特に重要です。AMFが新しい値を通知した場合、UEは次の周期でその値を使用します。新しい値が通知されなければ、保存済み設定を継続して使用できます。これによりネットワークは、端末内部に間隔を永久固定するのではなく、時間の経過に応じて周期登録動作を調整できます。
Registration Accept内のTA Listは、引き続きUEの現在の登録エリアを定義します。周期更新自体はそのエリアから出たことで起動されるわけではありませんが、正常な登録インタラクションを通じて、ネットワークはUEへ最新のモビリティ管理パラメータを提供できます。
Registration Acceptに新しく割り当てられた5G-GUTIが含まれている場合、UEはRegistration Completeで一時IDを正常に受信したことを確認する必要があります。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が初期登録として処理する場合、5GS登録タイプと5G-GUTIを確認します。AMFが5G-GUTIを既存UEコンテキストに関連付けられない場合、手順はより複雑なID復旧または再登録経路へ入ることがあります。
Registration Requestは正しく認識されているものの、その後に完全な認証手順が現れる場合、それだけで異常とは言えません。既存NAS Security Contextを確認し、ネットワークがセキュリティポリシーに従って再認証を実行する判断をしたかを確認する必要があります。
UE側のT3512に加えて、AMFはネットワーク側の重要な到達可能性監視機構である Mobile Reachable Timer（モバイル到達可能タイマー）を使用します。正常に登録されたUEでは、このネットワーク側タイマーはT3512より長く、標準的な関係は通常T3512プラス4分です。AMFはNASシグナリング接続を解放した後にMobile Reachable Timerを開始し、UEがNAS接続を再確立すると停止します。
2つの機構は連携して動作します。
UE側T3512：UEがいつネットワークへ戻って登録状態を更新すべきかを示す
AMF側Mobile Reachable Timer：UEが想定時間内に再び現れるかを監視する
UEが長時間ネットワークへ接続しない場合、Mobile Reachable Timerとその後の暗黙的デレジストレーション機構により、コアネットワークは到達可能性を確認できないUEを段階的に処理でき、古い登録コンテキストを無期限に保持せずに済みます。
したがって5GCの周期登録更新の本当の目的は「数十分ごとに再登録する」ことではありません。長時間アイドル状態にあるUEとAMFが、登録状態について共通認識を周期的に再確立できるようにすることです。 UEはまだ存在し、既存の登録関係は引き続き有効であり、関連するモビリティパラメータを次の期間も使用できる。
よくある質問
T3512はすべての5Gネットワークで54分に固定されているのか？
いいえ。54分は3GPPで定義されたデフォルト値ですが、AMFはネットワーク設定、UE動作、加入者情報、ポリシーに応じて別の値を割り当てられます。シグナリング解析やトラブルシューティングでは、常にUEが実際に受信したT3512値を使用し、必ず54分だと仮定しないことが重要です。
54分の間にUEが通常のトラフィックを発生させた場合でも、正確に54分後に周期登録更新を送信するのか？
必ずしもそうではありません。通常のT3512動作では5GMM-CONNECTEDへの移行が周期タイマーに影響し、その後UEがIDLEへ戻ったときにタイマーが再開始されることがあります。そのため次のRegistration Requestは、初期登録完了時刻に単純に54分を足すだけでは予測できません。厳密な周期登録タイマーが有効な場合もタイミング動作は異なります。
すべての周期登録更新でAUSF、UDM、PCFが必要なのか？
いいえ。サービスAMFが変わらず、既存UEコンテキストとセキュリティコンテキストが有効で、加入情報やポリシー情報を更新する必要がなければ、手順は非常に短くできます。AUSF、UDM、PCF、NRFが呼び出されるかどうかは、その時点のUEコンテキストとネットワーク実装によります。すべての周期登録更新で必須のネットワーク機能と考えるべきではありません。
周期登録更新はWi-Fiなどの非3GPPアクセスにも適用されるのか？
T3512に基づく周期登録更新機構は、3GPPアクセス経由で5GSへ登録されたUEに適用されます。非3GPPアクセスでは5GSは別の適切な登録・デレジストレーション管理機構を使用するため、NRアクセス向けのT3512周期登録更新動作をWi-Fiやその他の非3GPPアクセスへそのまま適用してはいけません。
