5G UEが正常に動作し、無線カバレッジも維持され、さらにアクティブなPDU Sessionが存在している状態でも、AMFが突然ネットワーク起動のDeregistration Requestを送信することがあります。UEは電源を切っておらず、自らDeregistration Requestを送信したわけでもありません。
この動作に矛盾はありません。5GCの登録関係は、必ずしもUEが終了させる必要はありません。運用・保守操作、UEの長時間到達不能、AMF内部の状態処理、またはUDMでの加入者の5Gサブスクリプション撤回などにより、ネットワークが既存の登録を終了することがあります。トレースを解析する際に重要なのは、UPFリソースが最終的に削除されたかどうかだけではなく、 誰が最初に登録解除を決定したのか、UEがまだ通知を受信できるのか、ネットワークが再登録を要求しているのか、そしてどのシグナリングメッセージが正当な理由でまったく現れない可能性があるのかという点です。
登録済みUEを5GSから離脱させる判断は誰が行うのか？
ネットワーク起動登録解除を理解するには、まず「開始」と「契機」を区別する必要があります。手順そのものを最終的に開始して実行するのはAMFですが、その理由が常にAMF内部で発生するとは限りません。
一つ目はAMFから始まるケースです。運用担当者が保守、ユーザー移行、またはその他のネットワーク管理目的でユーザーを明示的に登録解除し、RM-REGISTERED状態のUEを現在の登録から離脱させることがあります。もう一つは暗黙的登録解除です。ネットワークがUEの到達性を確認できなくなり、関連するタイマー条件が満たされた場合、AMFはUEからの開始を待たずにコンテキストのクリーンアップを開始できます。
三つ目の経路はUDMから始まります。たとえば、事業者が加入者の5Gサービスサブスクリプションを撤回した場合、サブスクリプション状態の変化を最初に把握するのはUDMです。UDMがUEへNASシグナリングを直接送るわけではありません。現在そのUEを担当しているAMFに通知し、その後AMFがコアネットワーク側の判断をネットワーク起動登録解除手順へ変換します。
NF間の関係という観点では、主な発生源は次のように整理できます。
AMFによる明示的な開始： 運用・保守操作、ユーザー移行、その他のネットワーク管理目的；
AMFによる暗黙的登録解除： 登録解除タイマーまたは到達性条件が満たされ、UEを通常の登録状態と見なせなくなった場合；
UDMを契機とする登録解除： たとえば、ユーザーのサブスクリプションが撤回され、UDMがAMFにUEの登録解除を指示する場合。
元の原因にかかわらず最終目的は同じです。以前の5GS登録は無効となり、UEはRM-REGISTEREDからRM-DEREGISTEREDへ遷移します。
明示的登録解除と暗黙的登録解除は、なぜトレース上で大きく異なって見えるのか？
どちらの手順も最終的にはUEを登録状態から外しますが、シグナリングの見え方は大きく異なることがあります。
明示的登録解除では、通常ネットワークはまだUEと通信できます。AMFはNAS Deregistration Requestを送信し、現在の登録を終了することをUEへ通知できます。UEが到達可能なままであればDeregistration Acceptを返し、その後ネットワークは残りのコンテキストとアクセス側シグナリング接続の解放を続けます。
暗黙的登録解除は異なる条件から始まります。通常、UEが十分長い時間再出現せず応答もしないため、ネットワークが到達性を確認できなくなった後に発生します。この段階では、UEがすでに電源オフ、圏外、または別の理由で切断されている可能性があり、さらにDeregistration Requestを送っても意味がないことがあります。
そのため、暗黙的登録解除は完全なDeregistration Request → Deregistration Accept交換を伴わず、ネットワーク側のコンテキストクリーンアップだけとしてトレースに現れる場合があります。
ここから、トレース解析に役立つルールを一つ導けます。 ネットワークからUEへのDeregistration Requestが見えないことは、ネットワーク起動登録解除が発生していないことの証明にはなりません。 暗黙的なケースでは、UEがシグナリングに参加できなくなっているからこそ、ネットワークがコンテキストをクリーンアップしている可能性があります。
UDMは加入契約撤回の判断をどのようにAMFへ伝えるのか？
加入者のサービス利用資格の変更は、ネットワーク起動登録解除の最も分かりやすい例の一つです。UEがすでに訪問先ネットワークに登録されサービスを確立している状況で、ホームネットワークがその後ユーザーの5Gサブスクリプションを撤回したとします。このサブスクリプション変更を最初に認識するのはgNBやUEではなくUDMです。
UDMは、AMFが事前に登録したコールバックURIを通じて、担当AMFへDeregistration Notificationを送信できます。典型的なケースでは、通知に SUBSCRIPTION_WITHDRAWN などの理由と、たとえば3GPP_ACCESSのような対象Access Typeを含めることができます。
この通知を受信して初めて、AMFはUE向けのネットワーク登録解除手順へ移ります。AMFはgNBを介してUEへNAS Deregistration Requestを送信できます。UE識別情報とAccess Typeに加えて、特に重要なフィールドが re-registration required（再登録要求）です。
このフィールドは、登録解除後にUEへ新しいRegistrationを実行させるかどうかを示します。ネットワーク起動登録解除のすべてが、必ず成功する再登録を強制するという意味ではありません。ネットワークが単にUEを現在のAMFから離脱させたい場合や、登録コンテキストを再構築させたい場合もあります。加入者が実際に5Gサービス利用資格を失っている場合、その後のRegistrationが成功するかどうかは別の判断です。
UDMからAMFへの通知処理後、AMFは対応する確認応答をUDMへ返します。この時点で制御の流れは「サブスクリプション状態が変化した」から「担当AMFが登録解除を実行している」へ移っています。
ネットワークがUEの登録解除を決めた後、バックエンドのリソースはどのようにクリーンアップされるのか？
この段階以降、一部のリソース解放処理はUE起動登録解除と重なります。N4、PCF、UDMのすべてのメッセージをもう一度列挙することに大きな意味はありません。重要なのは、ネットワーク起動の手順でもなぜこれらのクリーンアップ処理が必要なのかを理解することです。
UEにはすでに1つ以上のアクティブなPDU Sessionsが存在する可能性があります。AMFが登録終了を決定すると、関連するSMFへそれらのセッション解放を指示する必要があります。その後SMFはUPF側のユーザープレーンリソースとN3経路を処理し、有効なサービスコンテキストを失ったSM Policy関係を終了します。残っているセッション状態に応じてUDM内のサブスクリプションや登録関係も削除される場合があります。
AMF自身も、AM Policy Associationや該当するUE Policy Associationを含むアクセス・モビリティポリシー関係を解放する必要がある場合があります。そうしなければ、UEはすでに未登録なのに、PCF、SMF、UDMにはアクティブなサービスが継続していることを示す関係が残るという不整合が生じる可能性があります。
難しいのは「できるだけ多く削除する」ことではありません。ネットワークは現在のAccess Typeと、まだ有効なサービス状態を理解する必要があります。UEが別のアクセスで登録を維持している場合や、一部のコンテキストが別のセッションで引き続き使用されている場合、UE状態をすべて削除するのは誤りです。
したがって、ネットワーク起動のDeregistration Requestを確認した後は、同一の14メッセージが並んでいるかどうかに固執すべきではありません。解放されるべきPDU Sessionsが実際に解放されたか、不要になったポリシー関係が終了したか、維持されるべきコンテキストが保存されたかを確認します。
AMFによる明示的な登録解除とUDMによるサブスクリプション撤回は何が違うのか？
この2つの手順は後半が非常によく似て見えることがあります。どちらも最終的にはAMFがUEを登録解除し、同じPDU Sessionおよびポリシークリーンアップのロジックへ進む可能性があるためです。ただし、開始点は異なります。
運用担当者がAMFからUEを明示的に削除する場合、最初の重要な動作はAMFから直接始まります。UDMからの事前のDeregistration Notificationはありません。AMFは登録解除の運用上の理由をすでに把握しており、UEへ直接Deregistration Requestを送信できます。
加入者の5Gサービスが撤回された場合、開始点はUDMです。AMFが動作する前に、通常はUDMから登録解除通知を受信します。複数NFを含むパケットキャプチャでは、この違いから 既存の登録を終了すべきだと最初に判断したのは誰かを把握できるため、後続のすべてのクリーンアップシグナリングを同じシナリオとして扱わずに済みます。
AMF移行やAMFプール内でのユーザー再配置時には、Deregistration Request内のre-registration要件と、その後UEが新しいRegistration手順へ入るかどうかを合わせて確認する必要があります。この場合、登録解除はUEを別の担当AMFへ移すための一段階であり、加入者の5Gサービスを恒久的に終了するものではない可能性があります。
サブスクリプション撤回は、加入者の利用資格そのものの変更を表すため性質が異なります。NAS手順がUEに再度Registrationを試行させる場合でも、コアネットワークは更新後のサブスクリプション状態に基づいてその試行を評価します。
トレースでは最初のメッセージを誰が送ったかから確認する
ネットワーク起動登録解除は、次の4段階に分けると解析しやすくなります。 起点 → 通知 → リソースクリーンアップ → UE応答。
まず起点を確認します。最初の関連メッセージがUDMからAMFへのDeregistration Notificationであれば、手順はUDM側イベントを契機としています。AMFがUEへ直接Deregistration Requestを送る場合は、AMFによる明示的開始の可能性が高くなります。どちらも現れず、ネットワークがUEコンテキストの削除を始めている場合は、暗黙的登録解除を考えます。
次にNASの方向を確認します。ネットワーク起動登録解除では、Deregistration Requestは AMF → UEの方向に流れます。これはUE起動登録解除とは逆方向です。メッセージ名が同じ場合があるため、方向が重要です。
3番目に、UEがDeregistration Acceptを返すか確認します。明示的登録解除では、UEが到達可能であれば通常は応答が確認できます。暗黙的登録解除ではUEがすでに到達不能である可能性があり、この手順は現れない場合があります。
4番目に、バックエンドリソースを確認します。UEに以前PDU Sessionsが存在していた場合、対応するSMFおよびUPFリソースが解放されたかを確認します。手順がUDMを起点とする場合やポリシー状態が関係する場合は、UDMとPCFの関係も確認します。
実用的な解析手順は次のとおりです。
どのNFが手順を開始または発生させたかを確認する；
Deregistration Requestの方向とAccess Typeを確認する；
re-registration requiredがシナリオに合っているか確認する；
UEがDeregistration Acceptを返すか確認する；
既存PDU Sessionsとユーザープレーンリソースの解放を確認する；
最後に、UEの登録状態がRM-REGISTEREDを離れたことを確認する。
この方法は、番号付きの参照フローと機械的に比較してHTTP/2メッセージが1つ欠けているかを見るよりも、実際のトラブルシューティングに近いものです。ネットワーク起動登録解除には複数の原因があるため、シナリオによって最初のメッセージから異なることがあります。
FAQ
ネットワーク起動登録解除では、必ずDeregistration RequestがUEへ送信されるのか？
いいえ。明示的登録解除では、UEが到達可能であればAMFは通常Deregistration Requestを送信します。暗黙的登録解除はUEが長時間到達不能になった後に発生することが多いため、NAS Deregistration Requestがトレースに現れず、ネットワークが登録コンテキストを直接クリーンアップする場合があります。
UDMはUEを直接登録解除できるのか？
UDMは主に加入者情報とサブスクリプション情報を管理します。サブスクリプション撤回などのイベントは登録解除の契機になりますが、UEに対してネットワーク起動のDeregistration Requestを実行するNFは依然として担当AMFです。トレース解析では UDMを契機とする 場合と AMFが開始する 登録解除を区別する必要があります。
re-registration requiredが1に設定されている場合、UEは必ず再登録に成功するのか？
いいえ。このフィールドはネットワークがUEにRegistrationの再実行を要求していることを示しますが、新しいRegistrationが受け入れられるかどうかは、加入者の利用資格、アクセス制限、ネットワークポリシー、元の登録解除理由に依存します。サブスクリプションが撤回されている場合、再度Registrationを試みても5GCに受け入れられる保証はありません。
リソース解放手順はUE起動登録解除と完全に異なるのか？
いいえ。手順を起動する方向は異なりますが、ネットワークが登録終了を決定した後のPDU Sessions、UPFリソース、ポリシー関係のクリーンアップはUE起動登録解除と大きく重なる場合があります。より有用な違いは、誰が手順を開始したか、NASメッセージの方向、UE確認が期待されるか、再登録が必要かという点です。
