PDUセッションがしばらく正常に動作している場合を考えます。UEにはすでにIPアドレスが割り当てられ、N3のユーザプレーン経路は有効で、アプリケーショントラフィックも想定どおり流れています。その後、サービス条件が変化し、以前に許可されていたデータレートを下げる必要が生じたり、あるQoSフローに別の5QIが必要になったり、ネットワークがセッションの最大レートを10 Mbpsに制限したりすることがあります。
この場合、5GCはPDUセッション全体を切断して再構築する必要はありません。既存セッションをアクティブなまま維持し、影響を受けるQoSルール、QoSフローのパラメータ、またはユーザプレーンの適用ポリシーだけを更新できます。これがPDU Session Modificationの役割です。
PDU Session Establishmentとの違いは明確です。セッション確立ではそれまで存在しなかったセッションを作成し、セッション変更ではすでにアクティブなセッションを変更します。したがって重要なのは、SMFがどのように選択されたか、UPFがどのように初期作成されたかではなく、何が変更を引き起こしたのか、SMFが新しいポリシーをどのように取得するのか、UEとgNBが何を更新する必要があるのか、そして新しいQoSポリシーが実際にUPFで適用されているのかです。
PDUセッション変更の適用範囲
PDU Session Modificationには重要な前提があります。対象となるPDUセッションがすでに存在している必要があります。UE、SMF、PCF、および関連するRANコンテキストはすでにそのセッションに関連付けられており、通常はユーザプレーンも稼働しています。
変更手順の目的は、セッションをアクティブなまま維持しながらパラメータを変更することです。QoSは代表的な例です。既存のQoSフローに別の5QI、MBR、MFBR、またはその他の許可済みパラメータが必要になる場合があります。また、ポリシー変更によって、UPFですでに適用されているレート制御の更新が必要になることもあります。
QoS変更を単にNASフィールドを1つ変更する処理と考えるべきではありません。1回のQoS更新が、システムの次の3つの部分に影響することがあります。
UE側：UEは新しいQoSルールまたはQoSフローのパラメータを受信する必要があります。
RAN側：gNBは対応するPDU Session ResourceまたはQoSフローのリソースを変更する必要がある場合があります。
UPF側：ユーザプレーンでの適用内容が変わる場合、関連するPFCPルールをN4経由で更新する必要があります。
したがって、PDU Session Modificationは、アクティブなセッションのオンライン再設定と捉えるのが適切です。セッション識別子は変わらず、変更は既存のPDU Session IDと、それに関連付けられたQoSフローに適用されます。
もう1つ重要な境界があります。PDU Session Modificationは既存のQoSフローを更新できるだけでなく、適用可能なサービスシナリオでは、同じPDUセッション内に新しいQoSフローを確立するためにも使用できます。たとえば、アプリケーション主導のVoNR通話ポリシーによって、特定のQoS特性を持つ追加フローが必要になる場合があります。ただし、ここでの主題は新しいフローの作成ではなく、既存QoSフローのパラメータ変更です。
セッション変更の主なトリガー
PDU Session Establishmentとの大きな違いの1つは、トリガーがUEだけではないことです。アクティブなPDUセッションは、UEからの要求、ネットワークポリシーの変更、サブスクリプションデータの更新、または無線条件の変化によって再設定されることがあります。
一般的なトリガーは、次の5種類に分類できます。
UE起点：UEがPDU Session Modification Requestを送信し、QoSまたは関連するセッション変更を要求します。
PCF起点：ポリシー制御が変更されます。たとえば使用量のしきい値に達してネットワークが許可レートを下げる場合や、アプリケーションポリシーによって異なるQoSが必要になる場合です。
UDM起点：加入者ランクや契約QoSプロファイルの更新などにより、セッション管理サブスクリプションデータが変更されます。
SMF起点：SMFがローカルポリシー、ネットワーク設定、または現在のセッション状態に基づいてセッションの再設定を決定します。
RAN関連トリガー：gNBが無線状態またはリソース状態を報告し、その後SMFがセッションパラメータを変更する必要があると判断します。
これらのトリガーは最終的にSMFに集約されます。SMFがPDUセッションの制御コンテキストを保持し、新しいサービス要件やポリシー要件をUE、RAN、UPFで適用できるパラメータへ変換するためです。
PDU Session Modificationをトラブルシューティングする際は、最初からPDU Session Modification Commandを起点に後続処理だけを追うべきではありません。より有効なのは、変更を引き起こした最初の制御イベントを特定することです。最初のイベントがUE Modification RequestならUE起点です。PCFがNotification URIを通じて新しいポリシーをSMFへ通知した場合はポリシー起点です。UDMのサブスクリプションデータ更新が先に現れた場合は、加入情報変更の経路を追って調査します。
UE起点のPDUセッション変更
UE起点の手順は、アプリケーションが異なるQoSを必要とするケースとして考えると理解しやすくなります。
UEが現在PDU Session ID 5を使用しており、そのQoSフローの1つが元の設定のままだとします。アプリケーションに新しいサービス要件が生じると、UEはPDU Session Modification Requestを送信して異なるQoSパラメータを要求します。
NASメッセージはまずgNBを経由してAMFへ到達します。続いてAMFはSMF側の既存SM Contextを更新します。サービスベースインターフェースでは、AMFは次の処理を使用します。
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
これはCreate SM Contextとは異なります。SM Contextはすでに存在しており、ネットワークは既存セッションのコンテキストを更新しています。
UEからの要求には、Requested QoS Rules、Requested QoS Flow Descriptions、および関連するPacket Filtersが含まれる場合があります。要求を受信したSMFは、ネットワークがその変更を許可できるか判断します。セッションで動的ポリシー制御を使用している場合、SMFはサービス要求をPCFにも送り、認可を求めます。
たとえば、UEが特定のフローに5QI 8を要求した場合、SMFはPCF SM Policy Controlサービスを呼び出して現在のPolicy Associationを変更できます。PCFは加入者ポリシー、サービスルール、現在のネットワーク状態を評価し、実際に許可されるQoSパラメータを返します。
重要な点は、UEが要求したQoSが、最終的に実際に適用されるQoSと同じとは限らないことです。UEはサービス要件を提示しますが、最終パラメータはSMFとPCFによる認可の対象となります。
許可されるパラメータが確定すると、SMFは2種類の情報を生成します。
N1 SM：新しいQoS関連パラメータをUEへ通知するPDU Session Modification Command。
N2 SM：PDU Session Resource Modify手順用の情報で、対応するQoSフローのリソースを変更するようgNBへ指示します。
AMFはNGAPを介してN2情報をgNBへ渡し、N1に含まれるPDU Session Modification CommandをUEへ転送します。
gNBが関連リソースを調整すると、PDU Session Resource Modify Responseを返します。UEが新しいパラメータを受け入れると、NASでPDU Session Modification Completeを送信します。
SMFが関連する実行結果を受信して初めて、新しいセッションパラメータがポリシー認可の段階からアクセス側およびUE側での実際の適用へ移行したことを確認できます。
PCF起点のネットワーク側QoS変更
ネットワーク側の変更は別のロジックで進みます。UEは新しいQoSを要求しておらず、変更はポリシー制御層から始まります。
使用量しきい値を例に考えます。ユーザーはすでにアクティブなPDUセッションを持ち、継続的にデータを転送しています。PCFはセッションに使用量情報の報告または監視を要求します。累積使用量が設定されたしきい値に達すると、ポリシーによってセッションまたは関連フローの最大レートを10 Mbpsへ低下させることができます。
その後PCFは、SM Policy Associationの確立時に登録されたNotification URIを通じてSMFへ通知します。通知には、更新後のMBRや対応するPolicy Control Triggerなど、新しいSM Policy Decisionが含まれます。
SMFの観点では、これは新しいセッションの作成ではありません。有効でアクティブなPDUセッションを変更する処理です。
新しいレートをUPFで適用する必要がある場合、SMFはN4経由でPFCP Session Modification Requestを送信します。たとえば、対象QERのMBRを10 Mbpsに変更できます。UPFが変更を受け入れて初めて、新しいレート制限がユーザプレーンで有効になります。
「Modification」という語の次の2つの使い方を混同しないことが重要です。
PDU Session Modification：アクティブなPDUセッションを変更する5GS全体の手順。
PFCP Session Modification：SMFがN4を介してUPFのユーザプレーンルールを更新するための個別の制御手順。
両者は異なるレイヤーで動作します。PDU Session ModificationにPFCP Session Modificationが含まれる場合はありますが、PFCPの変更メッセージが1つ存在するだけで、PDUセッション変更全体が完了したとは限りません。
UPFが新しいQERを適用し始めた後も、SMFはRANとUEを更新する必要がある場合があります。N1/N2情報はAMFを介して送信され、gNBはPDU Session Resource Modify Requestを、UEはPDU Session Modification Commandを受信します。
gNBが無線リソースの更新を完了し、UEが新しいQoSパラメータを受け入れると、双方が実行結果を返します。その後SMFは成功結果をPCFへ通知でき、ポリシーシステムはQoSのポリシー判断が単にポリシーとして保存されたのではなく、実際に適用されたことを把握できます。
N1、N2、N4をまたぐ協調変更
PDU Session Modificationで特に混乱しやすいのは、同じQoS変更によってNAS、NGAP、PFCPで同時に変更手順が発生する場合があることです。
3つの経路を分けて考えると、ロジックは明確になります。
N1でUEのセッションパラメータを更新
N1 SMはUEとSMFの間でセッション管理情報を伝送します。ネットワークがセッション変更を決定すると、SMFはAMF経由でPDU Session Modification CommandをUEへ送信します。
UEはローカルのPDUセッションパラメータを更新し、PDU Session Modification Completeで受け入れを確認します。
N2でRANリソースを更新
QoSフローに関連する無線リソースを変更する必要がある場合、SMFは対応するN2 SM情報を生成し、AMF経由でgNBへ渡します。gNBはPDU Session Resource Modify手順によって関連するQoSフローリソースを変更し、該当する場合は変更に成功したQFIを含む結果を返します。
N4でUPFの適用ルールを更新
変更がユーザプレーン転送またはQoS適用に影響する場合、SMFはPFCP Session Modificationを使用して関連するUPFルールを更新します。
レート制限の変更ではQERの更新が必要になる場合があります。その他のポリシー変更がPDR、FAR、または別のユーザプレーンルールに影響することもあります。どのルールを変更するかはサービスと制御ポリシーによって決まり、PDU Session ModificationのたびにすべてのPFCPルールを書き換えるわけではありません。
完全なQoS変更は次のように整理できます。
ポリシー / UE要求
→ SMFがセッションパラメータを再計算
→ N4がUPFの適用内容を更新
→ N2がgNBリソースを更新
→ N1がUEパラメータを更新
→ 各側が結果を確認
実際のメッセージ順序は、トリガーや変更対象のパラメータによって異なる場合があります。トラブルシューティング時に、すべてのシナリオでまったく同じメッセージシーケンスが必要だと考えるのは適切ではありません。より重要なのは、変更が必要なすべての実行ポイントが、新しいパラメータを実際に受信して適用していることを確認することです。
変更完了とシグナリングのトラブルシューティング
PDU Session Modificationの問題には、セッション確立失敗とは異なる特徴があります。PDUセッションがアクティブなままで、ユーザーが引き続きデータを転送できても、結果として得られるQoSが意図したポリシーと一致しない場合があります。
たとえば、ポリシーがレートを10 Mbpsへ下げるよう要求し、PCFがすでに新しいポリシー判断を通知していても、実際のスループットテストではそれより大幅に高い値が出ることがあります。PDUセッションが存続しているだけでは変更成功の証明になりません。新しいパラメータがどの段階で適用されなくなったのかを調べる必要があります。
実際のトラブルシューティングでは、次のチェックポイントを使用できます。
トリガーを特定：最初のイベントがUE Modification Request、PCF Notification、UDMデータ変更、またはSMF/RAN側イベントのどれだったかを確認します。
SMFの判断を確認：SMFが要求を受け入れたか、PCFが期待どおりのポリシー判断を返したかを確認します。
N4での適用を確認：UPFが新しいQoSを適用する必要がある場合、PFCP Session Modificationが成功し、関連QERパラメータが実際に変更されたかを確認します。
N2の実行を確認：gNBがPDU Session Resource Modify Requestを受信し、正常に変更されたQoSフローを返したかを確認します。
N1の確認を確認：UEがPDU Session Modification Commandを受信し、PDU Session Modification Completeを返したかを確認します。
サービス結果を検証：実トラフィックが更新後のレート、QoS、またはサービスポリシーに従っているかを確認します。
PCFがすでに10 Mbpsを許可しているのにUPF内のQERが古いMBRのままであれば、SMFからN4までの経路を重点的に調査します。UPFが新しいレートを適用済みでもgNBのQoSフローが古いパラメータを使っている場合は、N2 Resource Modify手順をさらに確認する必要があります。ネットワーク側で必要な変更がすべて完了しているのにUEがModification Completeを返さない場合は、新しいQoSルールが受け入れられたかNAS側を確認します。
メッセージ名の1つにも注意が必要です。一部の手順図では、UEの確認ステップを「PDU Session Modification Command Ack」と表記することがあります。しかし5GSM NASシグナリングで、UEがPDU Session Modification Commandを受け入れた後に実際に送信するメッセージはPDU Session Modification Completeです。したがってパケット解析では、実際のNAS Message Typeを使用する必要があります。
このようなレイヤー別のトラブルシューティングは、Registration Requestから調査をやり直すよりはるかに効率的です。PDUセッションはすでに存在しています。問題は、アクティブなセッションが新しいポリシーに従って一貫して更新されていないことです。したがって、障害範囲は現在のSM Context、ポリシー、QoSフロー、ユーザプレーンでの適用に絞るべきです。
よくある質問
PDU Session ModificationでUEのIPアドレスは再割り当てされますか？
通常のQoS変更は、セッション全体を再構築するのではなく、既存のPDUセッションとそのQoSフローを更新します。その他のセッション属性が変わるかどうかは具体的なシナリオによりますが、5QIやMBRなどのパラメータだけを変更する処理を、別のPDU Session Establishment手順として扱うべきではありません。
PDU Session Modificationは常にUEから開始されますか？
いいえ。UEはPDU Session Modification Requestで変更を要求できますが、PCFのポリシー変更、UDMのサブスクリプションデータ更新、SMFのローカル判断、RAN関連イベントでもネットワーク側の変更が開始されます。通常、SMFがUE、RAN、UPF間で必要な更新を調整します。
PDU Session ModificationとPFCP Session Modificationの違いは何ですか？
PDU Session Modificationはアクティブなセッションを変更する5GS全体の手順で、UE、RAN、SMF、PCF、ユーザプレーンが関与する場合があります。PFCP Session ModificationはSMFとUPFの間のN4インターフェースで行われ、UPF内の具体的なユーザプレーンルールを変更します。後者は前者の一部になり得ますが、同じ手順ではありません。
QERがすでに更新されているのに、なぜgNBとUEも変更する必要があるのですか？
QERはUPFでのQoS適用を制御しますが、QoSフローはUPFだけで定義されるものではありません。UEには新しいQoSルールやフロー記述が必要になる場合があり、RANも対応する無線リソースを調整する必要があります。そのため、一部のQoS変更ではN1、N2、N4の整合性が必要です。UPFだけを更新しても、PDU Session Modification全体が完了したことにはなりません。
PDU Session Modificationで新しいQoSフローを追加できますか？
はい。PDU Session Modificationは既存QoSフローのパラメータを更新でき、適用可能なシナリオでは同じPDUセッション内に新しいQoSフローを確立するためにも使用できます。たとえば、アプリケーション主導のVoNRサービスで、特定の5QIを持つ追加QoSフローが必要になる場合があります。このシナリオは既存フローの単純な更新とはサービスコンテキストが異なるため、別に分析する方が適切です。
