すでに確立され、正常に通信を行っているPDUセッションを考えます。UEにはIPアドレスが割り当てられ、gNBは対応するPDUセッションリソースとQoSフローを保持し、UPFではユーザープレーン転送用のPFCPセッションが動作しています。ユーザーがデータ接続を終了する場合、ポリシー機能がセッションの終了を要求する場合、またはネットワークがセッションを維持すべきでないと判断した場合、5GCが行うのは一部のQoSパラメーターの変更ではありません。制御プレーンとユーザープレーンの両方でセッションを解放する必要があります。
これを実現するのが PDUセッション解放です。この手順では、確立済みPDUセッションをどのように削除するかを定めます。UE側の5GSMコンテキストを消去し、RANリソースを解放し、UPF内のN4セッションと転送状態を削除し、該当する場合は関連ポリシーも終了します。目的はAMF、SMF、gNB、UPF、UEの状態を一致させ、対象のPDUセッションが存在しない状態にすることです。
この手順は登録（Registration）とは異なるレベルで動作します。UEは5GSへの登録を維持したまま1つのPDUセッションを解放でき、他のアクティブなPDUセッションは引き続き使用できます。シグナリング解析で重要なのは、 特定のPDUセッションIDに関連するリソースがUE、RAN、SMF、UPF、ポリシー制御層からどのように削除されるかを追跡することであり、Registration Requestから解析をやり直すことではありません。
セッション解放・確立・変更・登録解除の違い
PDUセッションの確立、変更、解放、5GS登録解除は同じトレースに現れることがありますが、それぞれの目的は大きく異なります。
| 手順 | 主な目的 | 結果としての状態 |
|---|---|---|
| PDUセッション確立 | 新しいデータセッションとユーザープレーンリソースを作成する | 新しいPDUセッションがアクティブになる |
| PDUセッション変更 | QoS、ポリシー、既存セッションのリソースを変更する | PDUセッションはアクティブなまま維持される |
| PDUセッション解放 | 指定したPDUセッションを終了し、リソースを解放する | 対象のPDUセッションが存在しなくなる |
| 5GS登録解除 | UEと5GSの登録関係を終了する | UEが該当する5GS登録状態から離脱する |
セッション解放と登録解除は特に混同されやすい手順です。たとえば、UEがインターネット接続用と企業のプライベートネットワーク用の2つのPDUセッションを維持しているとします。一方を解放しても他方が自動的に削除されるわけではなく、AMF内のUE登録コンテキストも必ずしも削除されません。
RRC ReleaseもPDUセッション解放とは区別する必要があります。RRC Releaseは主にUEとgNB間の無線接続状態を変更するもので、コアネットワーク内のPDUセッションはアクティブなままの場合があります。これに対し、PDUセッション解放は特定の PDUセッションIDに関連するセッションリソースを削除します。
セッションが最初にどのように確立されたかについては、5GCコアネットワークのPDUセッション確立手順を参照してください。セッションがアクティブなままでQoSまたはポリシーパラメーターだけが変更される場合は、5GCコアネットワークのPDUセッション変更手順を参照してください。
PDUセッション解放の主なトリガー
PDUセッション解放はネットワーク内のさまざまな地点から開始できます。UEによる操作、ポリシー制御上の判断、ネットワーク状態の不整合、またはリソースに関する条件によって、アクティブなセッションが終了する場合があります。
代表的なトリガーは次のとおりです。
UE起点： 現在のデータセッションが不要になったUEがPDU Session Release Requestを送信する場合。
PCF起点： サービスの認可、利用条件、その他のポリシー要件により、セッションの継続が許可されなくなる場合。
AMF起点： AMFがUEとネットワークのPDUセッション状態の不一致を検出した場合、または関連するネットワークスライスが利用できなくなった場合。
RAN起点： たとえばPDUセッションに関連するすべてのQoSフローが解放済みとなり、RANがその状態をコアネットワークに報告した場合。
SMF起点： ローカルポリシーやUDM、CHFなどから受信した情報に基づき、SMFがセッションの終了を判断する場合。
最初のトリガーが異なるネットワーク機能から発生するため、序盤のシグナリング手順は常に同じとは限りません。ただし、最終的にはSMFが処理を調整します。SMFはPDUセッションの制御コンテキストを管理し、UPFのユーザープレーン、AMF/RANのアクセスリソース、PCFのポリシー関連付けを調整するためです。
パケットトレースの解析では、 最初にどのエンティティが解放を要求したか を特定することが、PDU Session Release Commandから見始めるより有用です。UEのRelease RequestはUE起点を示し、PCFからの終了通知はポリシー起点を示します。AMFによるSM Context解放要求は、別のネットワーク起点の分岐に属します。
UE起点の解放におけるN1・N2・N4シグナリング
UE起点の解放手順を見ると、各レイヤーでセッションリソースがどのように削除されるかを明確に把握できます。
UEがデータアクセスにPDUセッションID 5を使用しているとします。デバイスがこのセッションを必要としなくなると、 PDU Session Release Request を生成してN1 SM Containerに格納して送信します。gNBはUL NAS Transportを使用してNASメッセージをAMFに転送し、AMFは該当するPDUセッションIDを管理するSMFを特定します。
サービスベースインターフェース上で、AMFは既存のSM Contextを通じて解放要求を転送します。たとえばNsmf_PDUSession_UpdateSMContextを呼び出します。これは新しいSM Contextの作成ではありません。既存コンテキストを利用し、アクティブなセッションが解放手順に入ったことをSMFに通知します。
次にSMFがユーザープレーンのクリーンアップを行います。既存のN4セッションに対して、SMFはUPFへ PFCP Session Deletion Request を送信します。UPFは対応するPFCPセッションに関連したユーザープレーン状態を削除し、PFCP Session Deletion Responseを返します。
これはPDUセッション変更時のPFCP Session Modificationとは根本的に異なります。Modificationは既存のN4セッション内のルールを更新しますが、DeletionはUPFからセッション単位の状態を削除します。
ユーザープレーンのクリーンアップを開始すると、SMFはRANとUEに送る情報を準備します。
N2 SM： 該当するPDUセッションリソースの解放をgNBに指示します。
N1 SM： UEにPDU Session Release Commandを伝えます。
AMFはNGAPを使ってPDU Session Resource Release CommandをgNBに送信します。このメッセージにはUEへ届けるNAS PDU Session Release Commandを含めることができます。gNBは対象セッションのアクセス側リソースを解放し、PDU Session Resource Release Responseを返します。
Release Commandを受信したUEはローカルのPDUセッションコンテキストを削除し、 PDU Session Release Complete を5GSMの確認メッセージとして送信します。
代表的なUE起点の流れは次のとおりです。
UE解放要求 → AMF → SMF → PFCPセッション削除 → N2リソース解放 → PDUセッション解放コマンド → UE解放完了
UEが最初にCM-IDLE状態の場合、実ネットワークでは解放手順の続行に必要なシグナリング接続を回復するため、先にService Requestが必要になることがあります。したがって、すべてのパケットトレースが同じ無線状態から始まるとは限りません。
ネットワーク起点の解放とPCFポリシーの終了
ネットワーク起点の場合、UEが最初にPDU Session Release Requestを送るわけではありません。ポリシー制御層や他のコアネットワーク機能で処理が始まる場合があります。
PCF起点の例を考えます。PDUセッションは正常に通信していましたが、その後PCFがポリシーに従って終了を判断します。PCFは既存のポリシー関連付けに対して設定された通知機構を使用し、SMFへ通知します。
ポリシーに基づく解放トリガーを受信した後も、SMFはユーザープレーンを解放する必要があります。そのため、SMFがAMF経由でN1およびN2情報を送るより先に、PFCP Session Deletion RequestとResponseが現れる場合があります。
SMF → AMF → gNB / UE
AMFのN1N2 Message Transferでは、PDUセッションリソース解放に関するN2情報と、UE宛てのPDU Session Release Commandをまとめて運ぶことができます。
UEから見ると、最初のトリガーがPCF、SMF、その他の機能のいずれであっても、明示的なNAS解放手順ではネットワークから PDU Session Release Commandが送信され、その後UEが PDU Session Release Completeを返します。
ただしコアネットワーク側のトレースでは、これら2つのNASメッセージだけでは最初のトリガーを特定できません。重要な証拠はRelease Commandより前にあります。PCFのポリシー終了、AMFのSM Context解放要求、RAN関連イベント、SMFのローカル判断などです。
この違いは技術解析とトラブルシューティングの両方で重要です。 PDU Session Release CommandはネットワークがUEにセッション終了を指示したことを示しますが、最初に解放を引き起こしたエンティティを特定するものではありません。
UPF・RAN・ポリシーコンテキストのリソース削除
UEがデータを送信できなくなっただけで、PDUセッション解放が完了したと判断すべきではありません。該当する解放シナリオに応じ、関連するネットワーク機能でセッションリソースが削除される必要があります。
N4によるUPFセッションの削除
PFCP Session Deletionはユーザープレーンのクリーンアップにおける重要な処理です。UPFが対応するN4セッションを削除すると、そのセッションに関連するPDR、FAR、QER、URR、その他の転送状態は、解放済みPDUセッションの一部として動作しなくなります。
セッションのライフサイクルが終了する際には、PDUセッションに関連するN3リソースや、その他の該当するユーザープレーン終端リソースも解放されます。
N2によるgNBリソースの解放
gNBはPDUセッションとQoSフローに関連するアクセス側リソースを保持しています。PDU Session Resource Release Commandを受けると、RANは該当リソースを削除し、対応する応答メッセージで結果をコアネットワークに報告します。
したがって、PFCP Session Deletionが成功しただけでは、PDUセッション解放全体の完了は証明できません。UPF側は削除済みでもgNBにPDUセッションリソースが残っていれば、ネットワークの状態は一致していません。
UEによる5GSMセッションコンテキストの削除
PDU Session Release Commandを受信したUEはローカルのセッションコンテキストを消去し、PDU Session Release Completeで確認します。IP型PDUセッションでは、関連付けられたIPアドレスやプレフィックスも解放対象になります。
SMFからAMFへの通知とポリシー状態の削除
セッションがReleased状態に達すると、SMFはSM Context Status NotificationをAMFに送信し、AMFが保存しているセッション状態を同期させることができます。
PDUセッションにSM Policy Associationが存在する場合、関連するPCFポリシーの関係も適用される分岐に従って終了または削除する必要があります。特定のDNN、S-NSSAI、加入情報関連状態を必要とする最後のセッションである場合、条件に応じてSMFがUDMやUDRに関係する加入情報や登録情報の追加クリーンアップを行う場合もあります。これらは条件付きの処理であり、すべての解放で発生するわけではありません。
つまり、クリーンアップの対象は単一のトンネルではなく、PDUセッションIDに紐づく一連の状態です。
UEコンテキスト + RANリソース + SMコンテキスト + UPF N4セッション + ポリシー関連付け
シグナリングトレースによる解放完了の確認
PDUセッション解放の失敗は利用者側からは分かりにくいことがあります。UEがすでにデータ転送を停止していても、1つ以上のコアネットワーク機能に古い状態が残る場合があります。また、UEのローカルセッションは削除済みでも、UPFのPFCPセッションがアクティブなままの場合もあります。
考えられるメッセージ順序をすべて暗記するより、対象のPDUセッションIDを基準にチェックポイントを設けるほうが効果的です。
解放対象のセッションを特定： 正しいPDUセッションIDに解析対象を固定し、同時に動いている別セッションのシグナリングが混在しないようにします。
トリガーを特定： 最初のイベントがUEのRelease Request、PCFの終了通知、AMFの要求、その他のネットワーク側イベントのいずれかを判定します。
SMFの処理を確認： 要求が対象PDUセッションを管理するSMFに届き、SMFが解放手順を開始したことを確認します。
N4リソースを確認： PFCP Session Deletion RequestとResponseが完了し、元のUPFセッションルールが削除されたことを確認します。
N2リソースを確認： gNBがPDUセッションリソース解放のシグナリングを受け、対応する解放結果を返したことを確認します。
N1状態を確認： 該当する明示的なNAS解放手順では、UEがRelease Commandを受信し、PDU Session Release Completeを返したことを確認します。
最終状態を確認： AMFのPDUセッション状態、SMFコンテキスト、存在するPCF関連付けがReleased状態と一致することを確認します。
たとえばUEがPDU Session Release Completeを返した後もUPFに対応するPFCPセッションが残っている場合、まずSMFとN4のリソース削除を調べます。PFCP状態は削除済みでもgNBにPDUセッションリソースが残る場合は、次にN2解放経路を確認します。
逆に、PDU Session Release Request、Release Command、対応するコアネットワークのリソース削除が確認できず、RRC Releaseだけが存在しても、PDUセッションが終了したとは結論できません。
仕様のレイヤーによってメッセージ名が異なることも混乱の原因です。説明によってはフローの一段階を「PDU Session Release Ack」と呼ぶ場合がありますが、UEがPDU Session Release Commandを受け入れた後に送る実際の5GSM NASメッセージは PDU Session Release Completeです。無線インターフェースとNASのトレース解析では、実際のMessage Typeに従う必要があります。
したがって、より信頼できる完了条件は次の問いです。 特定の「最終」メッセージが現れたかではなく、元のPDUセッションIDに関連する状態がUE、RAN、SMF、UPFから削除されているか。
よくある質問
PDUセッションを解放するとUEの登録も解除されますか？
必ずしもそうではありません。PDUセッション解放が終了させるのは指定されたデータセッションだけです。UEは5GS登録状態を維持し、他のアクティブなPDUセッションを使用し続けることができます。登録解除はUEと5GSの登録関係を終了する別の手順です。
PDUセッション解放ではUEのIPアドレスも解放されますか？
IP型PDUセッションでは、関連するIPアドレスやプレフィックスも解放対象のリソースです。手順の完了後、それらを解放済みPDUセッションの有効なユーザープレーンアドレスとして使用してはいけません。アドレスプールへの返却や再割り当ての方法はネットワーク実装によって異なります。
PFCPセッション削除とPDUセッション解放は同じですか？
いいえ。PFCP Session Deletionは、SMFがN4を通じてUPFのセッションとユーザープレーンルールを削除する手順です。PDUセッション解放の重要な一部ですが、全体の手順にはUE、RAN、AMF、PCFなどのコンテキストも含まれる場合があります。
PDUセッション解放とPDUセッション変更の主な違いは何ですか？
PDUセッション変更は既存セッションをアクティブに保ちながら、QoS、ポリシー、関連リソースを変更します。PDUセッション解放は指定セッションを終了し、関連リソースを削除します。同じPDUセッションIDが有効で通信を続けている場合、通常は解放完了とはいえません。
UEから解放要求を送った後にネットワークがRelease Commandを送るのはなぜですか？
UE Release RequestはUE側の終了要求を表しますが、SMFはUPF、RAN、UE間の状態を調整しなければなりません。ネットワーク側で解放処理が進むと、PDU Session Release CommandによってUEに該当5GSMコンテキストの削除を指示し、UEはPDU Session Release Completeを返します。
