UEが3GPPアクセスでCM-IDLEに移行すると、ユーザプレーン接続が非活性化されても、確立済みのPDU Sessionは維持される場合があります。即時配信に必要なアクセス側N3トンネルが利用できなくても、データネットワークからN6経由で下りパケットがUPFに到着することがあります。制御プレーンが配信の復旧を試みる間、バッファリングによってその一部を保持できます。
N4では、SMFがPFCPを介してUPFを制御します。Buffering Action Rule（BAR）は、関連付けられたForwarding Action Rule（FAR）にバッファリング指示を与えます。この区別は重要です。バッファリングを選択するのはFARのApply Actionであり、BARが単独でパケットを照合したりページングを開始したりするわけではありません。また、CM-IDLEであることは、すべてのパケットの保持や、すべての通知に続くページングを保証しません。
PDR、FAR、BARの役割は異なる
Packet Detection Rule（PDR）は対象トラフィックを識別し、FARを参照します。FORWは該当するForwarding Parametersによる転送を要求し、BUFFはバッファリングを要求します。NOCPは、最初に保持した下りパケットについて制御プレーンへの通知を要求します。これは通知アクションであり、メモリ割り当てパラメータではありません。
通常の5GCのBUFF/NOCPでは、特定のFARについて、各QoSフローの最初の下りパケットが報告対象になります。同じQoSフローの後続パケットすべてに追加報告が必要なわけではありません。別のQoSフローに属するパケットや、別のFARに関連付けられたパケットは、追加報告を発生させる場合があります。拡張バッファリングによって、この通知動作が変わることがあります。
FARはBAR IDでBARを参照できます。一つのBARを複数のFARに関連付け、PFCP Sessionでバッファを共有することもできます。TS 29.244 V18.7.0では、PFCP Sessionごとに作成できるBARは最大一つです。BARの作成だけでは下りトラフィックがそれを利用しているとは判断できません。PDRとFARの関係、およびFARのBAR IDを確認してください。
基礎となる分類と転送の段階については、関連ガイドのN4におけるPDRのパケット検出とFARの転送とトンネルパラメータで説明しています。
CM-IDLE中に下りデータが到着すると何が起こるか
登録済みでPDU Sessionが確立されているUEを考えます。ユーザプレーン接続がアクティブな間、UPFは下りパケットをgNBへ転送します。接続が非活性化されると、SMFは関連するN4規則とアクセストンネル情報を更新します。UPFでバッファリングする場合、対象のFARは即時転送に代えてBUFFとNOCPを要求できます。これはセッション制御上の判断であり、無線状態の変化にBARが自律的に反応するものではありません。
下りデータがUPFに到着します。一致するPDRと関連FARが、その処理を決めます。
バッファリングと通知を指示された場合、UPFはデータを保持し、Downlink Data Reportを含むPFCP Session Report Requestを送信します。報告は対象PDRを識別し、SMFはPDRコンテキストまたはDownlink Data Service InformationからQoSフローを特定できます。
SMFはPFCP Session Report Responseで報告を確認し、該当する場合はNamf_Communication_N1N2MessageTransferでAMFに連絡します。AMFはページングとService Request手順を開始し、ユーザプレーン接続を復旧できます。
アクセス側トンネルが確立すると、SMFはUPFの転送アクションとトンネルパラメータを正しい値に更新します。その後、保持されたパケットを新しい指示に従って転送できます。
TS 23.502では、ステージ2のやり取りをData NotificationおよびData Notification Ackと呼びます。N4のパケットキャプチャでは、実際のPFCPメッセージ名とDownlink Data Reportという名称を使用してください。全体を「DDN」と呼ぶのは便利な略称ですが、S11上のEPC Downlink Data Notificationメッセージになるわけではありません。
この流れは一般的なUPFバッファリングの例です。TS 23.502は、指示に応じてSMFへデータを転送し、SMFで保持する方式も認めています。UEがCM-CONNECTEDでも、特定のPDU Sessionにアクティブなユーザプレーン接続がない場合があります。また、RRC_INACTIVEはCM-IDLEとは異なります。アクセスタイプ、MICO、拡張アイドルモードDRX、ページング制限、既知の到達不能状態によって、ページングが変更または阻止されることがあります。アイドル状態の説明を当てはめる前に、実際のセッションとアクセスの状態を確認してください。
BARの各フィールドは手順の文脈で読む
以下の区別は、TS 29.244 V18.7.0の5.2.4、7.5.2.6、7.5.4.11、7.5.9.2節に基づきます。BARは、すべてのN4交換であらゆるバッファ設定を含める必要がある汎用コンテナではありません。
| フィールド | 意味と条件 |
|---|---|
| BAR ID | PFCP Session内のBARを識別します。FARからの参照によって、そのBARに関連付けられたバッファリング指示が選択されます。 |
| Suggested Buffering Packets Count | UDBCに依存するフィールドで、制御プレーンからの新たな指示を待つ間に保持するUL/DLパケット数を提案します。UPFの物理メモリ容量を示すものではありません。指定された場合、参照したCreate/Update BARの表は、上限を超えたパケットの破棄を要求しています。 |
| DL Buffering Suggested Packet Count | 別のフィールドであり、PFCP Sessionの拡張バッファリングで保持する下りパケット数の推奨最大値です。Suggested Buffering Packets Countと混同してはいけません。 |
| DL Buffering Duration | 下りデータの拡張バッファリングを制御します。PFCP Session Report Responseでの設定はDLBDのサポートに依存し、PFCP Session Modificationによる設定はDBDMのサポートと該当条件に依存します。初期確立時に必ず存在するわけではありません。 |
| Downlink Data Notification Delay | 該当する場合、パケット到着後の通知を遅延させます。5.2.4節ではEPC向けの設定として説明されています。一般的なBAR図やデコードされたグループ化IEに表示されているだけで、5GCの汎用ページング遅延制御と判断してはいけません。 |
DL Buffering Durationは保持だけでなく報告にも影響します。指定された拡張バッファリング期間中は、通常、その後の下りデータ到着通知が抑制されます。Extended DL Buffering Notification Control（EDBNC）をサポートし、EDBNが1の場合は、UPFはその期間中、特定のFARについて各QoSフローの最初の保持パケットを報告します。したがって、NOCPだけでは追加報告が必要だとは判断できません。
拡張バッファリングが終了すると、UPFはDL Buffering DurationとDL Buffering Suggested Packet Countの適用を停止し、BARからこれらのパラメータを削除します。すでに保持されたパケットを転送するか破棄するかは、新しい制御プレーン指示で決まります。バッファリングは一時的なトラフィック処理であり、無損失の保存を保証するものではありません。
トレースにすべてのバッファリングパラメータが出ない理由
PFCP Sessionの全履歴から確認してください。BARは確立時や以前の変更時に作成済みで、調査中の交換ではFARだけを更新している可能性があります。オプション項目や能力に依存するフィールドも、毎回のメッセージに必要なわけではありません。任意フィールドの欠落は、参照の解決不能や、条件付き必須フィールドの欠落とは異なります。
TS 29.244は、BUFFとともにバッファリングパラメータを任意で設定することを認めています。ただし、PFCP Session Report ResponseでBARを変更するには、空であってもBARが事前に設定され、FARに関連付けられている必要があります。UPFのローカルなリソース制限でBAR IDの関連付けや該当手順の必須フィールドを代替することはできません。
5.2.4.3節には、より限定された実装上の選択肢があります。UPFがAPN/DNNおよび／またはS-NSSAIについて設定済みの拡張バッファリングをサポートし、その他の指定条件を満たす場合、制御プレーンはタイマをUPFへ設定せず自ら管理し、追加QoSフローの通知のためNOCPを有効に保つことができます。これは、あらゆるBARパラメータをローカル設定で置き換えてよいという包括的な例外ではありません。
調査時は、ネゴシエーション済みのUP Function Features、以前のBAR設定、現在の規則の関連付け、該当するローカルリソース設定を取得してください。これによって、正常な任意パラメータの省略と、未対応機能の使用、不完全なキャプチャ、実際の設定失敗を区別できます。
アクション、バッファリング、通知、復旧を調査する
非活動期間後の最初のメッセージの遅延、ページング成功後の初期パケットの欠落、UPFバッファの増大は、それぞれ原因が異なる可能性があります。パケットと制御プレーン状態を四段階で追跡します。
1. アクションと一致規則を確認する
下りパケットが想定するUPFに実際に到着し、正しいPDRに一致していることを確認します。FAR IDを追い、Apply Actionと、受理されたPFCP Session Modificationの結果を確認します。FARが古いアクセストンネル情報を使って転送している場合は、バッファパラメータを調整する前に、規則とトンネルの更新を調べます。
2. 有効なバッファリング指示を特定する
BAR IDの参照先を特定し、適切なメッセージの文脈で最新のCreate BARまたはUpdate BARを確認します。二つのパケット数フィールドを区別し、機能サポートを確認します。設定上限と実際の保持・破棄パケットを照合してください。推奨数は物理メモリを予約せず、再接続まで全パケットが保持されることも保証しません。
3. 報告とその処理を確認する
PFCP Session Report Request、Downlink Data Report、PDR ID、対応する応答を探します。QoSフローごとの報告範囲、通知抑制、拡張バッファリング、失敗原因を確認します。報告が受理されてもページングが行われない場合は、BARの故障と決めつけず、SMFとAMFの交換およびUE到達性の条件を調べます。
4. 復旧後の配信を確認する
Service Request成功後、SMFがFORWと現在のアクセス側アドレスおよびTEIDを復元したことを確認します。N6到着、N3出力、バッファカウンタを比較します。UEに到達できても、FARがBUFFのまま、トンネル情報が誤っている、保持期間が終了した、またはパケットがすでに破棄された場合は、データを受信できないことがあります。
よくある質問
BUFFはパケット分類にBARを必要とするか
いいえ。PDRがトラフィックを分類し、FARがBUFFを要求します。BARは、設定され関連付けられた場合に具体的なバッファリング指示を提供するもので、追加のパケット分類器ではありません。
Suggested Buffering Packets Countの欠落は設定不良を示すか
いいえ。このフィールドはUDBCサポートに依存し、拡張下りバッファリングのパケット数フィールドとは異なります。省略を評価する前に、メッセージの文脈、合意された機能、既存のBAR状態を確認してください。
すべてのDownlink Data Reportがページングを起こすか
いいえ。SMFとAMFは到達性、アクセス、ポリシーの条件を適用します。報告の結果は、ユーザプレーンの再活性化、拡張バッファリング、失敗処理などになります。ページングは手順の一部として実施される可能性がある処理です。
再接続に成功してもパケットを失うのはなぜか
復旧前にバッファが上限に達したり、保持期間が終了したりした可能性があります。FARやトンネルの更新が不完全な場合もあります。再接続の成功だけでは、保持パケットの状態やN3転送の再開を確認できません。
参考資料
3GPP TS 29.244 V18.7.0：5.2.3–5.2.4、7.5.2.6、7.5.4.11、7.5.8–7.5.9、8.2.28–8.2.30、8.2.100節は、FAR/BARの処理、報告、バッファリング情報要素を扱います。
3GPP TS 23.502 V18.9.0：4.2.3.3節はNetwork Triggered Service Request、データ通知、到達性の例外、拡張バッファリングを説明しています。
