現地でのトラブルシューティングでは、RRC Releaseを見てUEの登録解除がすでに完了したと判断してしまうことがあります。無線接続が実際に切断され、UEがデータ送信を停止していても、AMFの登録コンテキスト、SMFのPDU Session、UPFのN4セッション、PCFのポリシー関連付け、UDMの登録情報が、「電波が消えた」という理由だけで同時に消えるわけではありません。シグナリングトレースで重要なのは、Deregistration Requestに続くNF間のクリーンアップチェーンです。つまり、AMFが登録解除範囲をどのように決定するか、SMFがUPFにユーザプレーン資源の削除をどのように指示するか、PCFとUDMの関連付けをどこまで解放すべきかを確認する必要があります。
UE主導の登録解除 は、すでに登録済みのUEを5GSから制御された形で退出させる手順です。NAS Deregistration Requestから始まり、PDU Sessionの解放、UPF内のN4セッションとユーザプレーントンネルの削除、SM PolicyおよびAM Policyの関連付け終了、UDM内の関連登録状態の削除、最終的なUEとアクセスネットワーク間のシグナリング接続解放までを含む場合があります。通常の登録解除と電源オフは手順前半では似て見えることがありますが、終端方法が異なります。前者はDeregistration Acceptを待ちますが、後者は確認を受け取るためだけにオンライン状態を維持しません。この違いはトレース解析で見落としやすい点です。
なぜ登録解除はUEを単にオフライン表示にするだけではないのか？
UEがInitial Registrationを完了してPDU Sessionを確立すると、5GCが保持するのは単一の「オンライン」フラグだけではありません。AMFは登録およびモビリティコンテキストを保持し、SMFはPDU Sessionコンテキストを管理し、UPFはN4 SessionとFAR、QER、URRなどのユーザプレーン転送資源を保持します。UDMはAMFおよびSMFの登録関係を保存し、PCFはAM、UE、SMのPolicy Associationを保持する場合があります。
UEが単にネットワークから消えた場合でも、これらの資源がまったく同じタイミングで自動的に削除されるわけではありません。特に1つ以上のPDU Sessionが残っている場合、ネットワークはどのセッションを解放するか、どのユーザプレーンルールを削除するか、どのサブスクリプションやポリシー関連付けを維持する必要がなくなったかを判断する必要があります。
そのため、UE主導の登録解除では 登録状態と関連資源を順序立てて解放する処理が実行されます。
UEが現在の5GS登録を終了することを通知
→ AMFが登録解除範囲を決定
→ 関連するPDU Sessionを解放
→ SMFがUPFにユーザプレーン資源の削除を指示
→ セッションおよびポリシー関連付けを削除
→ 登録状態を削除
→ アクセス側のシグナリング接続を解放
このため、登録解除をRRC Releaseや通常のN2接続解放と混同してはいけません。RAN接続の解放は、現在のアクセスシグナリング接続が終了したことだけを意味します。登録解除はさらに上位の処理であり、5GS登録関係と、それに関連するセッションおよびポリシー状態を削除します。トレースにRRC Releaseしかない場合にUEがすでに登録解除済みだと判断すると、「アクセス接続の解放」と「登録関係の削除」を混同する可能性があります。
Deregistration Requestは、UEがどの方法でどのアクセスから離脱するかをどう示すのか？
UEが5GSから能動的に離脱する場合、AMFへNAS Deregistration Request を送信します。シグナリング解析では、後続のPFCPメッセージが存在するかより先に、要求内のDeregistration typeとAccess Typeを確認する必要があります。
Deregistration typeはまず、この手順が 電源オフ のケースかどうかをネットワークに示します。エンジニアリング上、UE主導の登録解除は一般に2つのケースがあります。1つはUEが順序立てて退出する通常の登録解除、もう1つはUEが電源断または同等のシャットダウン状態に入ることを示す電源オフです。
Access Typeは別の問いに答えます。実際に登録解除されるアクセスがどれか、という点です。UEは3GPPアクセスのみ、非3GPPアクセスのみから登録解除することもでき、同じPLMNの両アクセスが同一AMFにより提供されている場合は、条件に応じて両方を対象にできます。したがって、「UEの登録解除」が常にそのUEに関連するすべてのアクセス状態を一度に削除することを意味するわけではありません。
Deregistration RequestにはUEの識別情報も含まれます。有効な5G-GUTIがある場合、UEはそれを利用してAMFがNASメッセージを既存のUEコンテキストに関連付けられるようにします。有効な5G-GUTIがない場合、識別処理はUEが現在利用可能な5GS識別子に依存します。AMFの観点では、このNASメッセージを既存のUEコンテキストに正しく対応付けることが、正しいPDU Sessionとポリシー関連付けを解放する前提条件です。
通常の登録解除では、UEは要求を送信した後、ネットワークから完了確認を待ちます。電源オフでは、「離脱する」という通知をできるだけ早く届け、その後シャットダウンを継続することが目的なので、処理が異なります。通常の登録解除ではT3521を使用してUEがDeregistration Acceptを待つ時間を監視できますが、電源オフでは同じ方法でネットワーク確認を待ちません。
なぜAMFは最初にUEにPDU Sessionが残っているか確認するのか？
AMFがDeregistration Requestを受信した後の重要な判断の1つは、対象アクセスに確立済みのPDU Sessionがまだ存在するかどうかです。
関連するPDU Sessionがない場合、個別に解放すべきユーザプレーンセッションがないため、手順は大幅に短くできます。一方、1つ以上のPDU Sessionがまだアクティブな場合、AMFが自身の登録コンテキストだけを削除すると、SMFとUPFにはそのセッションが存在したままと認識されます。
解放が必要な各PDU Sessionについて、AMFは対応するSMFに Nsmf_PDUSession_ReleaseSMContext を呼び出すことができます。これはAMFからセッション管理層への明示的な指示、つまりUEが対象アクセスを離れるため、そのSM Contextを今後維持しないよう求める処理と理解できます。この指示を受けた後、SMFはN4セッションの削除、ポリシー関連付けの終了、UDM内の関連登録状態のクリーンアップを進められます。
これは登録解除と単独のPDUセッション解放の違いも示しています。1つのPDU Sessionを解放してもUEが5GSから離脱するわけではなく、UEは5GS Registeredのまま残ることができます。一方、UEが登録解除を開始した場合、対象アクセスに関連するPDU Sessionは通常、より広い登録解除処理の一部としてクリーンアップする必要があります。
したがって、トレースにDeregistration Requestがあるのに、その後Nsmf_PDUSession_ReleaseSMContextがない場合でも、直ちに信令欠落と判断してはいけません。まず、そのAccess Type上でUEにPDU Sessionが実際に確立されていたか確認します。PDU Sessionが存在していなければ、N4解放手順がないこと自体が正しいフローである可能性があります。
SMFとUPFはどのようにユーザプレーンを実際に解放するのか？
AMFがSMFへPDU Session解放要求を送信すると、SMFが関連するユーザプレーン資源の削除を担当します。UPFセッションが存在する場合、SMFはN4インターフェースを介して解放します。
一般的には、SMFは PFCP Session Deletion Requestを送信します。UPFは対応するF-SEIDまたはN4 Sessionコンテキストを使用してユーザの転送状態を削除し、PFCP Session Deletion Responseを返します。その後、PDU Sessionに関連するユーザプレーントンネル、転送ルール、関連コンテキストが削除されます。クリーンアップは1本のトンネルだけに限定されず、そのN4 Sessionに関連するFAR、QER、URRなどのルール状態も削除されます。
制御関係は次のように整理できます。
UE → AMF：登録解除したい
→ AMF → SMF：このUEのPDU Sessionコンテキストを解放
→ SMF → UPF：N4 Sessionとユーザプレーン資源を削除
→ UPF → SMF：削除を確認
→ SMF → AMF：SM Contextの解放完了
セッションで動的PCCを使用している場合、SMFはNpcf_SMPolicyControl_Deleteなどにより、対応するSM Policy Associationを終了する必要がある場合があります。また、解放されるセッションが、そのSMFが該当DNNおよびS-NSSAI向けに管理する最後のPDU Sessionである場合、SMFはUDM内のSession Management Subscription Data変更へのサブスクリプションを解除し、Nudm_UECM_Deregistrationを使用してSMFと該当DNN/PDU Session間の関連付けをUDMから削除することもあります。
UPF側のトレースという観点では、登録解除が実際にユーザプレーンへ到達するポイントはNAS Deregistration Request自体ではなく、その後のN4 Session Releaseです。このステップが完了して初めて、元のPDU Sessionに属する転送資源がユーザプレーンから実際に削除されます。
なぜUDMとPCFではさらにコンテキストのクリーンアップが必要なのか？
PDU Session解放が完了するとユーザプレーンはすでに消えている場合がありますが、5GC内には制御プレーンの関連付けが残っている可能性があります。登録解除を完全に終了するには、ネットワークがどのサブスクリプション、登録、ポリシー関係がまだ有効で、どれを削除すべきか判断する必要があります。
セッション管理側では、SMFが該当DNNとS-NSSAIについてユーザの最後のPDU Sessionを管理しなくなった場合、UDMのSM Data更新へのサブスクリプションを解除し、関連するSMF Registrationを削除できます。これにより、UDMがそのセッションをもう提供していないSMFへSession Management更新を送り続けることを防ぎます。
アクセスおよびモビリティポリシー側では、UEが関連するどのAccess Typeでも登録されておらず、AMFとPCFの間にAM Policy Associationが存在する場合、AMFはその関連付けを終了する必要があります。UE Policy Associationが存在する場合も、条件を満たしたときに解放する必要があります。AMFがそのUEについて有効な登録を一切保持しなくなった場合、UDM内のAMF登録関係もNudm_UECM_Deregistrationで削除する必要がある場合があります。
ここには重要な境界があります。 1回の登録解除が発生したからといって、すべてのPCFおよびUDMコンテキストが消えると考えてはいけません。 UEが別のAccess Typeで引き続き登録されている場合や、同じSMFがそのUEの別の関連PDU Sessionを引き続き管理している場合、一部の関連付けはまだ必要です。
したがって、登録解除のクリーンアップは固定されたDELETE要求の列ではありません。原則は1つです。 この登録解除によって利用上の意味を失った状態だけを削除し、別のアクセスやセッションで引き続き使用されるコンテキストは保持することです。 マルチアクセスおよび複数PDU Session環境では、ここは特に誤解されやすい点です。
なぜ通常の登録解除と電源オフでは終了方法が異なるのか？
通常の登録解除と電源オフはいずれも手順前半でPDU Sessionやコアネットワーク資源の解放を引き起こすことがありますが、UE側の終了方法が異なります。
通常の登録解除手順では、UEはDeregistration Requestを送信した後、ネットワークの確認を待ちます。AMFが必要な処理を完了すると、 Deregistration Acceptを返し、ネットワークが登録解除を受け付けたことをUEへ明示的に通知します。T3521などのNAS機構でこの待機時間を監視できます。T3521が満了した場合、UEは単純に登録解除完了とみなすのではなく、プロトコルで定義された再送または例外処理を行います。
登録解除が3GPPアクセスに適用され、AMFとNG-RANの間にN2シグナリング接続が残っている場合、AMFはN2 UE Context Releaseを実行して、対応するアクセス側シグナリング接続を終了できます。
電源オフは異なります。UEはまもなく電源を切るため、確認メッセージを待つだけの目的でオンライン状態を維持する意味はほとんどありません。Deregistration typeが電源オフを示す場合、AMFは通常の登録解除のようにUEが退出前にDeregistration Acceptを受信することを必須としません。UEがDeregistration Requestの送信を可能な範囲で試みた後は、シャットダウン処理を継続できます。
この違いはパケットトレースで特に重要です。
通常の登録解除
Deregistration Request
→ コアネットワークが関連資源を解放
→ Deregistration Accept
→ シグナリング / AN解放
電源オフ
Deregistration Request
→ コアネットワークが関連資源を解放
→ UEはシャットダウン完了前にDeregistration Acceptを待たない
したがって、電源断時のトレースにDeregistration Acceptが存在しないからといって、手順失敗を意味するわけではありません。まずDeregistration typeが通常の登録解除か電源オフかを確認します。UEがすでに電源断している、無線リンクを失っている、または応答を受信する時間がなかった場合、ネットワークは後からMobile Reachable TimerやImplicit Deregistrationなどを使用してUEの異常消失を処理できます。
よくある質問
UEの電源断時、Deregistration Requestは必ずAMFへ届くのか？
いいえ。電源オフ手順では、UEが電源断前に可能な限りDeregistration Requestを送信するよう設計されていますが、すでに圏外になっている、無線リンクが失敗している、または電源が突然失われた場合、ネットワークが受信できないことがあります。そのため5GCには、突然消失したUEを処理するため、Mobile Reachable TimerやImplicit Deregistrationなどのネットワーク側機構が引き続き必要です。
UEの登録解除では必ずPFCP Session Deletionが発生するのか？
いいえ。対象Access Type上に確立済みのPDU Sessionがなければ、解放すべき対応N4ユーザプレーンセッションもないため、PDU Sessionクリーンアップに伴うSMFとUPFの処理が現れない場合があります。PFCP Session Deletionが必要なのは、関連するPDU Sessionとそのユーザプレーン資源が実際に存在するときだけです。
登録解除とPDUセッション解放は同じ手順か？
いいえ。PDUセッション解放は特定のデータセッションを削除する手順であり、UEは5GS Registeredのまま残れます。登録解除はUEと5GSの登録関係を削除します。UEが登録解除するとき、既存PDU Sessionは通常、関連資源として解放する必要がありますが、2つの手順は異なるレイヤで動作し、目的も異なります。
UEの登録解除後もUDMやPCFのコンテキストが一部残るのはなぜか？
まず登録解除の対象となるAccess Typeと、UEが別のアクセスで引き続き登録されているかを確認します。UEに別の有効なアクセス、使用中の他のPDU Session、または引き続き必要なポリシー関係がある場合、一部コンテキストを保持する必要があります。登録解除を、5GC全体でUEに関するすべての状態を無条件に削除する処理と解釈してはいけません。
