技術Q&A：UEがCM-IDLEにあるとき、N4インターフェースのBARはダウンリンクパケットのバッファリングとデータ通知をどのように制御するのか？
UEがCM-IDLEに入っても、そのPDUセッションは消滅しません。しかし、以前ダウンリンク転送に使用されていたN3ユーザープレーンパスは、もはやアクティブではない可能性があります。この時点で外部ネットワークから新しいデータが到着した場合、パケットは依然としてUPFに到達できますが、CM-CONNECTEDの場合のようにN3経由で即座にgNBへ転送することはできません。したがって、UPFはパケットをバッファリングすべきかどうか、何パケット保持できるか、どれだけの期間バッファリングできるか、そしてダウンリンクデータが到着したことをいつ制御プレーンに通知すべきかを判断する必要があります。
N4インターフェース上のPFCPルールフレームワーク内で、BAR（バッファリングアクションルール）がこのバッファリング動作のルールを提供します。ただし、BARがバッファリングを行うべきかどうかを独立して決定するわけではありません。バッファリングアクションはFAR内のApply Actionによってトリガーされ、BARはそのバッファリングをどのように実行すべきかを定義します。この区別は、FARとBARの関係を理解する上で基本的なものです。
BARはUPFがパケットをバッファリングする方法を定義する
UPFがパケットを受信すると、まずPDRを使用してトラフィックを識別し、次にそのPDRが参照するFARに従って次のアクションを決定します。FARが通常の転送を要求する場合、UPFは転送パラメータに従ってパケットを転送します。FARのApply ActionにBUFFが含まれている場合、パケットは宛先インターフェースに向けて即座に送信されず、バッファリングプロセスに入ります。
ここでBARが重要になります。FARは、影響を受けるパケットをどのようにバッファリングすべきかをUPFに指示するBARを参照できます。この関係は次のようにまとめられます：
PDRがパケットを識別 → FARがBUFF/NOCPを選択 → BARがバッファリング動作を定義。
よくある誤解は、BUFFとBARを同じものとして扱うことです。そうではありません。BUFFは「このパケットを今すぐバッファリングすべきか？」という質問に答えます。BARは「バッファリングが選択された後、どのような条件下でパケットをバッファリングすべきか？」という質問に答えます。関連するBARやUPFのローカルバッファリング設定を確認せずにFARのBUFFだけを見ても、ユーザープレーンの動作の全体像の一部しか把握できません。
NOCPもこのシナリオに一般的に関連付けられています。UPFがダウンリンクパケットをバッファリングしているとき、NOCPはUPFがダウンリンクデータの到着を制御プレーンに通知することを要求できます。これにより、SMFが次の制御プレーン手順を開始できます。したがって、バッファリングと通知は2つの調整されたタスクとして発生します：ユーザープレーンが一時的にパケットを保持し、そのイベントが制御プレーンに報告されます。
最も典型的なBARシナリオはUEがCM-IDLEに入った後に発生する
BARの役割は、UEがCM-CONNECTEDからCM-IDLEに移行するときに最も理解しやすくなります。UEが登録とPDUセッション確立をすでに完了していると仮定します。接続中は、N3ユーザープレーンパスが利用可能で、UPFはダウンリンクパケットをgNBに向けて直接転送できます。
一定期間の非アクティブ状態の後、アクセス側が接続を解放し、UEはCM-IDLEに入ります。PDUセッションは維持されますが、以前アクティブだったN3ユーザープレーン転送パスは即座に利用できなくなります。外部サーバーは必ずしもこの状態変化を認識していないため、新しいダウンリンクIPパケットがN6経由でUPFに引き続き到着する可能性があります。
これが重要な問題を生み出します：UPFはデータを受信しましたが、現在UEに配信するために使用できるN3パスがありません。
この段階で、SMFはN4経由でユーザープレーンルールを更新し、関連するFARが即時転送からバッファリング動作に変更されます。典型的なケースでは、Apply ActionでBUFFとNOCPが有効になり、FORWは現在のダウンリンクアクションとして使用されなくなります。新しいダウンリンクパケットが到着すると、UPFは該当するバッファリングポリシーに従ってパケットを保持し、ダウンリンクデータの到着をSMFに報告します。
通知を受信した後、SMFはAMFと連携して、該当する場合はページングを含め、UEが再び到達可能になるために必要な手順を開始できます。UEがユーザープレーントラフィックを伝送できる状態に戻り、N3パスが復元されると、SMFはUPFルールを再度更新し、ダウンリンク処理がバッファリングから転送に戻ります。バッファリングされたパケットは、その後UEに向けて継続できます。
したがって、BARは単なる静的なメモリ割り当てルールではありません。その真の目的は、ダウンリンクパケットがすでに到着しているが、即時転送がまだ可能でない一時的な期間をユーザープレーンが橋渡しするのを支援することです。
主要なBARパラメータがバッファリングの境界を定義する
バッファリングは無期限に継続することはできません。到達不能なUEのためにUPFが無制限のダウンリンクデータを保持することを許可された場合、ユーザープレーンメモリが不必要に消費される可能性があります。したがって、BARはバッファリング動作に境界を提供します。PFCP手順とUPF機能に応じて、これらにはBAR ID、パケット数制限、バッファリング期間、通知遅延パラメータが含まれます。
BAR ID
BAR IDはPFCPセッション内でバッファリングルールを一意に識別し、関連するFARが正しいBARを参照できるようにします。トラブルシューティング中にCreate BARが見えるだけでは、そのルールが分析対象のトラフィックに影響を与えることを証明するものではありません。対応するFARもチェックして、実際にどのBAR IDを参照しているかを確認する必要があります。
推奨バッファリングパケット数
推奨バッファリングパケット数は、該当するトラフィックに対してUPFがバッファリングするよう推奨されるパケット数を示します。推奨制限を超えると、追加のパケットは破棄される可能性があります。このパラメータは、バッファリング時間ではなく、バッファリング容量の境界を制御します。
その存在はUPFの機能サポートにも依存します。PFCPトレースにフィールドが表示されない場合、それだけではバッファリング制御が欠如していることを証明するものではありません。分析では、UPFが関連機能をサポートしているかどうか、代わりにローカルバッファリングパラメータが使用されているかどうかも考慮する必要があります。
DLバッファリング期間
DLバッファリング期間は、該当する手順の下でダウンリンクパケットがUPFにバッファリングされ続けることができる期間を定義します。これは重要な設計原則を反映しています：バッファリングは、ユーザープレーン配信が復元されている間の一時的なメカニズムとして意図されており、永続的なパケット保存ではありません。
UEが長期間到達不能のままである場合、バッファリングプロセスには定義された終了条件が必要です。そうでなければ、ユーザープレーンリソースが無期限に占有され続ける可能性があります。
ダウンリンクデータ通知遅延
サポートされている手順と機能の組み合わせでは、ダウンリンクデータ通知遅延は、UPFが最初のダウンリンクパケットを受信した後、制御プレーンに通知する前に待機する時間を制御できます。このパラメータは、パケットをバッファリングすべきかどうかではなく、通知がいつ送信されるかに影響します。
したがって、その動作は、パラメータ名だけから推測するのではなく、特定のPFCP手順、ネットワーク実装、UPF機能のコンテキストで解釈されるべきです。
PFCPトレースに完全なBARパラメータが欠けていることがあるのはなぜか？
これはBARを分析する際に最も誤解しやすいポイントの1つです。バッファリングするパケット数、バッファリング期間、その他のバッファリングパラメータは、必ずしもN4経由で動的にプロビジョニングする必要はありません。オペレータや機器ベンダーは、UPFにローカルでバッファリングポリシーを設定することもできます。
この実装では、SMFはFARアクションを動的に変更するだけでよい場合があります。たとえば、UEがCM-IDLEに入った後、SMFはPFCPセッション変更を使用して、関連するFARをBUFF/NOCPに更新できます。UPFがバッファリングアクションを確認すると、ローカルで設定されたパケット数と期間の制限を適用できます。
したがって、トレースでの以下の観察は自動的に異常ではありません：
FARがBUFFを要求しているが、PFCPメッセージにエンジニアが期待する完全なBARパラメータが含まれていない。
少なくとも2つの追加質問を確認する必要があります：UPFがローカルで設定されたバッファリング値を使用しているかどうか、そしてUPFが関連するBARパラメータの動的プロビジョニングをサポートしているかどうか。そうでなければ、実装の違いがSMFからのルール欠落と誤解される可能性があります。
ローカル設定には実用的な利点もあります。一部のN4シグナリングを削減し、UPF実装間の機能差に対応できます。トレードオフは、バッファリング動作の一部が単一のPFCPトレースで完全に見えなくなるため、マルチベンダーのトラブルシューティングではシグナリング分析とUPFのローカル設定の検査の両方が必要になる可能性があることです。
CM-IDLEでダウンリンクデータが到着したとき、PFCPフローはどのように理解すべきか？
BARは、分離された情報要素として分析するのではなく、完全な手順の中に戻すと理解しやすくなります。
UEがCM-CONNECTEDにある間、N3パスが利用可能で、UPFは通常のFARに従ってダウンリンクパケットを転送します。一定期間の非アクティブ状態の後、アクセス側の接続が解放されます。SMFがユーザープレーン接続状態が変化したことを知ると、PFCPセッション変更を使用して関連するUPFルールを更新します。
重要なポイントは、PDUセッションが削除されていないことです。代わりに、現在のダウンリンクユーザープレーンパスが即時配信のために一時的に利用できない状態です。したがって、関連するFARはBUFFと必要な制御プレーン通知アクションを有効にすることでバッファリング動作に移行でき、BARまたはローカルUPF設定が詳細なバッファリング条件を提供します。
その後、インターネットサーバーやアプリケーションが新しいダウンリンクデータを送信すると、パケットはまずUPFに到着します。UPFはPDRを使用してトラフィックを識別し、関連するFARを適用します。現在のアクションがFORWではなくなったため、パケットはバッファリングされます。同時に、UPFはPFCPレポートメカニズムを通じてダウンリンクデータの到着をSMFに報告します。
その後、SMFはAMF側の手順と連携して、UEが再び到達可能になり、ユーザープレーンパスを再確立できるようにします。N3転送が再び利用可能になると、N4上のFARが通常の転送に再度更新され、UPFはダウンリンクトラフィックのUEへの配信を継続できます。
全体的なロジックは次のようにまとめられます：
UEがCM-IDLEに入る → N3が一時的に利用不能 → SMFがFAR/BARを更新 → ダウンリンクデータがUPFに到達 → UPFがバッファリングして報告 → 制御プレーンがUEの到達可能性を復元 → N3が復元 → FARが転送に戻る。
したがって、BARはデータがすでに到着しているが、配信パスがまだ戻っていない期間のユーザープレーン動作を制御します。
BARトラブルシューティングは、アクション、バッファリング、通知、復旧の4ステップに従うべき
BAR関連の問題が明示的な「BARエラー」として現れることはほとんどありません。より多くの場合、症状はUEがアイドル状態に入った後の最初のダウンリンクトラフィックが異常に動作することです。アプリケーションはアクティブな間は正常に動作するかもしれませんが、非アクティブ期間の後、次のメッセージが顕著な遅延を伴って到着します。別のケースでは、UEが正常にページングされて再接続されたにもかかわらず、最初の数個のダウンリンクパケットがすでに失われている場合があります。
これらの問題は4段階で分析できます。
ステップ1：FARが実際にバッファリングモードに入ったことを確認する
関連するダウンリンクPDRが参照するFARから始め、UEがCM-IDLEに入った後に期待されるPFCPセッション変更が発生したことを確認します。Apply Actionが通常のFORW動作から、シナリオで期待されるBUFFおよび通知アクションに変更されたかどうかを確認します。
FARがもはや使用できないユーザープレーンパスに向けてパケットを転送しようとしている場合、問題は主にBARの問題ではありません。
ステップ2：UPFが適用しているバッファリングルールを特定する
FARが参照するBAR IDを確認し、対応するCreate BARまたはUpdate BARパラメータを調べます。PFCPトレースに完全なバッファリングパラメータが含まれていない場合は、UPFのローカルバッファリング設定とサポートされている機能の確認に進みます。
パケット数制限が小さすぎる場合、UEが再び到達可能になる前に最初のダウンリンクパケットの一部が破棄される可能性があります。観察されたバッファリング動作が期待と大幅に異なる場合は、BAR関連付け自体も検証する必要があります。
ステップ3：UPFがダウンリンクデータ到着を報告したことを確認する
パケットをバッファリングするだけではUEとの通信は復旧しません。新しいダウンリンクデータが到着したことを制御プレーンが認識していなければ、後続のページングやユーザープレーン復旧手順は開始されません。したがって、トレースで適切なPFCPセッションレポートとSMFによる正しい処理を確認する必要があります。
パケットがすでにUPFにバッファリングされているが、制御プレーン手順が続かない場合、トラブルシューティングはBARパラメータからUPFからSMFへのレポートパスと後続のSMF手順に移行する必要があります。
ステップ4：ユーザープレーン復旧後に転送が再開されることを確認する
UEが再び到達可能になった後、SMFがN4ルールを正しく更新し、ダウンリンクFARがバッファリングから通常の転送に戻り、必要なN3転送パラメータが復元されることを確認します。
ページングが成功してUEが戻ってきたにもかかわらず、FARがBUFFのままである場合、システムはUEが到達可能である一方でパケットがUPFに留まり続ける状態に入る可能性があります。したがって、BARトラブルシューティングはユーザープレーン転送パスが完全に復元されるまで継続する必要があります。
BARの核心的価値
PFCPルールフレームワーク内で、BARはPDRやFARと同じように通常転送されるすべてのパケットに関与するわけではありません。その重要性は、特定のしかし重要な状況で最も顕著になります：セッションは依然として存在するが、現在のユーザープレーンパスが新しく到着したダウンリンクデータを即座に配信できない場合。
FARがパケット処理アクションをFORWからBUFFに変更し、BARがバッファリング境界を定義し、UPFが一時的にパケットを保持してその到着を報告し、SMFやAMFなどの制御プレーン機能がUEの到達可能性の復元を調整します。これらのメカニズムが一体となって、一時的な配信不能からアクティブなユーザープレーンパスへの移行を橋渡しします。
したがって、BARは「Buffering Action Rule = パケットバッファリングルール」としてのみ理解すべきではありません。より有用な解釈は：BARは、ユーザープレーン配信パスが一時的に利用できない間に、すでに到着したダウンリンクパケットをどのように管理するかをUPFに指示します。BARをCM-IDLE、FAR BUFF/NOCP、PFCPセッションレポート、および後続のページングとユーザープレーン復旧手順と併せて見ることで、N4インターフェース上でのその役割がはるかに明確になります。
よくある質問
FARにおけるBARとBUFFの違いは何ですか？
BUFFはFAR内のApply Actionであり、一致するパケットを即座に転送するのではなくバッファリングすべきことを示します。BARは、パケット数制限、バッファリング期間、その他の該当条件など、そのバッファリングをどのように実行すべきかを定義します。簡単に言えば、FARはバッファリングが必要であることを決定し、BARはバッファリングがどのように実行されるかを定義します。
BARはFARから独立して動作できますか？
BARを独立したパケットマッチングルールとして扱うべきではありません。パケットはまずPDRによってマッチングされ、PDRは関連するFARを参照します。そのFARがバッファリングを要求し、該当するBARを参照する場合、BARパラメータがそれらのパケットのバッファリング方法を制御するために使用されます。
UEがCM-IDLEに入ったとき、なぜダウンリンクパケットは単に破棄されないのですか？
CM-IDLEはPDUセッションが削除されたことを意味しません。外部アプリケーションは、ユーザープレーン配信パスが一時的に利用できないだけの間にデータを送信し続ける可能性があります。短期バッファリングにより、制御プレーンがUEの到達可能性を復元している間にダウンリンクトラフィックの一部を保持でき、アプリケーション継続性の中断を軽減するのに役立ちます。
推奨バッファリングパケット数がないことは、BARが誤設定されていることを意味しますか？
必ずしもそうではありません。このパラメータが現れるかどうかは、PFCP手順、UPF機能、実装によって異なります。パケット数制限やその他のバッファリング動作はUPFにローカルで設定される場合もあるため、機能サポート、BAR関連付け、デバイス側のバッファリング設定を確認する必要があります。
UPFがダウンリンクパケットをバッファリングしたにもかかわらず、UEがまだデータを受信しないのはなぜですか？
バッファリングは手順の一部にすぎません。UPFはダウンリンクデータの到着をSMFに報告する必要があり、制御プレーンはUEの到達可能性を復元するために必要な手順を開始する必要があり、SMFはユーザープレーンパスが再び利用可能になった時点でFARとN3転送パラメータを更新する必要があります。これらのいずれかの段階で障害が発生すると、パケットがバッファリングされたままになるか、最終的に破棄される可能性があります。
