5Gユーザープレーンのよくあるトラブルシューティング例は、一見すると分かりにくいことがあります。PDU Sessionは正常に確立し、UEはIPアドレスを取得し、PDRは想定トラフィックに一致し、FARにはFORWが含まれ、パケットも流れ始めています。それでもユーザーは動画のバッファリング、想定外に低いダウンロード速度、または片方向だけ動作するトラフィックに悩まされることがあります。
このような場合、PDRとFARだけを確認しても原因が分からないことがあります。問題は トラフィックが識別されたかどうか や パケットがどこへ転送されたかではなく、 転送が許可された後にUPFがどのQoSポリシーを適用したかにある可能性があります。N4インターフェース上のPFCPルール体系では、 QER（QoS Enforcement Rule：QoS適用ルール） がUPF内でこれらのQoSポリシーを適用します。QERはトラフィックの通過可否、uplink/downlink速度制限、QoS Flowとの関連付け、トランスポートレベルのマーキングを制御できます。そのため、ユーザープレーン全体の動作を理解するにはPDR、FAR、QERを合わせて考える必要があります。
PDRとFARが正常でもQERが必要なのはなぜか？
QERを理解する最も簡単な方法は、UPF内の各ルールの役割を分けて考えることです。
PDRはまず「これはどのトラフィックか？」を判断します。PDI、UE IPアドレス、F-TEID、SDF Filterなどの条件を用いてパケットを検出・分類します。トラフィックが識別されると、FARが「このパケットをどう処理し、どこへ転送するか？」を決定します。
しかし、パケットの転送が許可されたからといって、無制限に転送できるわけではありません。ネットワークが引き続き速度、ゲーティング、QoS Flow関連付け、トランスポートレベルマーキングを制御する必要がある場合、UPFは関連するQERを適用しなければなりません。
したがって、代表的な処理順序は次のように簡略化できます。
PDRがトラフィックを識別 → FARが転送動作を決定 → QERがQoSポリシーを適用。
これらのルールは互いに置き換わるものではなく、連携して動作します。パケットがPDRに正しく一致し、FARで転送を許可されても、QERで定義された速度制限やゲーティング条件の対象になる場合があります。QERがなければ、UPFはパケットを転送すべきことは分かっても、QoSの観点でそのトラフィックをどう扱うかを示す同等のポリシー情報を持てません。
QERはいつ設定され、なぜ後から更新されることがあるのか？
QERは通常、PDU Sessionのユーザープレーンルールの一部として、PFCP Session Establishment時にSMFからUPFへ設定されます。UPFがトラフィックを観察した後に独自に作成するQoSルールではありません。制御プレーンが適用すべきQoS動作を決め、UPFがそのルールを実行します。
QERはセッションの全期間で同じとは限りません。サービス稼働中にポリシーが変われば、SMFはPFCP Session Modificationを通じて既存QERを更新できます。加入者ポリシー、アプリケーションポリシー、その他の制御プレーン判断の変更によって、新しい速度制限、異なるGate状態、QoS Flow関連付けの変更、その他のQoSパラメータが反映されることがあります。
そのため、トラブルシューティングは最初のCreate QERだけで終えてはいけません。セッションがしばらく動作した後にQoS問題が発生した場合は、後続のUpdate QERも確認し、初期値と比較する必要があります。
制御プレーン側では、SMFが使用するQoSポリシーはローカル設定またはPCFに関連するポリシー情報から得られる場合があります。N4インターフェースに到達した時点では、UPFが適用可能なPFCPルールとして表現されます。サービス設計に応じて、QoS適用はPDU Sessionレベル、QoS Flowレベル、またはより具体的なSDFやアプリケーショントラフィックに対して行われます。
セッションが正常に見えてもGate Statusがトラフィックを遮断するのはなぜか？
Gate StatusはQERの中でも最も直接的なパラメータの一つで、トラフィックを通過させるかどうかを即座に変えることができます。
uplinkとdownlinkのGate状態は独立して制御できます。GateがOPENならその方向のトラフィックは通過可能です。CLOSEDなら、その方向のトラフィックはQoS適用ルールによってブロックされます。
代表的なトラブルシューティングの流れは次のようになります。
PDU Sessionは正常に確立；
UEはIPアドレスを取得済み；
PDRは正しく一致；
FARにはFORWが含まれる；
それでもアプリケーショントラフィックは動作しない。
この時点で、関連QERのUL GateとDL Gateを確認する必要があります。両方向は別々に制御されるため、一方がOPENでも他方がCLOSEDの場合があります。結果として、UEはdownlinkを受信できるがuplinkを送信できない、またはその逆という片方向のユーザープレーン障害に見えることがあります。
QERが単なる説明用のQoS属性ではなく適用ルールであるのはこのためです。その設定は、特定トラフィックがUPFを通過できるかどうかを直接決定できます。
MBR、GBR、Packet Rateは何を制御するのか？
Gate Statusは「トラフィックは通過できるか？」に答えます。速度関連パラメータは「どれだけのトラフィックを、どの速度で通過させるか？」に答えます。QERはビットレートとパケットレートの両方を基準に制限できます。
最大ビットレート（MBR）
MBRは一致したトラフィックの最大ビットレートを定義し、uplink/downlinkで個別に設定できます。5GC環境では、ルール設計に応じてセッションレベルの制限、特定QoS Flow、またはより具体的なトラフィックフローに対応します。
ユーザーがサービスへ正常にアクセスできても、スループットが毎回ほぼ同じ上限で止まる場合、関連QERのMBRは確認すべきパラメータの一つです。
MBRは無線側容量と混同されやすい点に注意が必要です。無線状態が良く、トランスポート帯域が十分でも、アプリケーションが物理容量をすべて使えるとは限りません。UPFに低いMBRが設定されていれば、ユーザープレーンスループットはその上限に制約されます。低スループットの原因調査では、無線性能だけでなくN4上のQoSルールも確認すべきです。
保証ビットレート（GBR）
GBRは、一定のリソース保証が必要なトラフィックに対応する保証ビットレートを表します。uplink/downlinkで個別に指定することもできます。
GBRは、リアルタイム音声、動画、その他QoSに敏感なアプリケーションなど、より予測可能な性能が必要なサービスで重要になる場合があります。GBR単独の数値だけで判断せず、対応するQoS Flowと全体のQoSポリシーも合わせて考える必要があります。
概念的には、MBRが許容速度の上限を定義し、GBRがサービスのポリシーに対応した保証速度要件を表します。
Packet Rate
一部のトラフィックはビットレートだけでは十分に表せません。QERには指定時間内に許可されるパケット数を制限するPacket Rateパラメータを含めることもできます。
これはDNSトランザクション、IoT キープアライブ、シグナリングに似たトラフィックなど、小さなパケットを大量に生成するワークロードで重要です。総ビットレートが比較的低くても、1秒あたりのパケット数が高くなることがあります。その場合、MBRだけでは観測されたQoS動作を説明できないことがあります。
Packet Rate制限に達すると、全体の帯域使用量がそれほど高く見えなくても、ユーザーは遅延増加、応答低下、リクエスト失敗を経験する場合があります。
QER内でQFI、Flow Level Marking、PPIは何をするのか？
QERは単なる速度制限ルールではありません。Gate Status、MBR、GBRに加えて、QoS Flow識別やパケット処理に関連するパラメータを含めることができます。これらを組み合わせて、ユーザープレーンでのトラフィック処理を決定します。
QoS Flow Identifier（QFI）
QFIはQoS Flowを識別します。一つのPDU Sessionには複数のQoS Flowsを含めることができ、異なるサービストラフィックに異なるQoS処理を提供できます。
ユーザープレーンの観点では、QFIはパケットがどのQoS Flowに関連付けられているかを示します。QERでは、この識別子を用いて対応するQoS適用動作をそのQoS Flowと関連付けられます。
ルールに関連付けられたQFIが想定サービス設計と一致しない場合、速度パラメータが正しく見えてもトラフィックが意図しないQoS Flowに関連付けられる可能性があります。その結果、サービスに想定されたものとは異なるリソース処理を受けることがあります。
DL Flow Level Marking
QERはUPFに対し、downlinkトラフィックへフローレベルのマーキングを適用するよう指示できます。例えばIPトランスポートネットワーク向けにDSCP値を設定できます。
このマーキングは、パケットがどの5G QoS Flowに属するかを決めるものではありません。代わりに、IPトランスポートネットワークへ入った後の識別や処理に影響します。
トランスポートレベルのマーキングが誤っている場合、5G QoS自体は正しく設定されていても、下流トランスポートネットワークが意図しない優先度でパケットを扱う可能性があります。
Paging Policy Indicator（PPI）
PPIはdownlinkトラフィックのページングポリシー処理に関連します。QERは、ページングが関係する適用可能な転送シナリオで、異なるトラフィックを異なる方法で扱うためのページング関連情報を提供できます。
現在アクティブなユーザープレーン状態にないUEでは、downlinkトラフィックの種類によってページングへの影響が異なる場合があります。PPIはその差別化処理の一部として利用できる情報を提供します。
Averaging Window
速度適用は、必ずしも一つのパケットの瞬間的な観測だけに基づけるわけではありません。Averaging Windowは、ビットレート関連の動作を評価する時間窓を定義します。
短い窓はバーストトラフィックへより速く反応し、長い窓はより平滑な平均値を生成し、短いバーストを異なる形で許容できます。そのためQER分析ではQER IDとMBRだけを見てはいけません。最終的なQoS動作は複数パラメータの組み合わせに依存する場合があります。
PFCPメッセージを使ってQERが想定どおり動作しているか確認するには？
QER分析で最も役立つ方法は、すべての情報要素を暗記することではなく、PFCPルールを実際のサービス症状と結び付けることです。
例えばCreate QERには次のような値が含まれる場合があります。
QER ID = 1；
UL Gate = OPEN；
DL Gate = OPEN；
UL MBR = 100000 kbps；
DL MBR = 150000 kbps。
これらは例ですが、重要な点を示しています。 GateがOPENでも、QoS制限が存在しないという意味ではありません。 トラフィックの通過が許可されていても、MBR制限は引き続き適用されます。
実用的なトラブルシューティングは次の手順で進められます。
まずPDRを特定する。 影響を受けるトラフィックに実際に一致するPDRを確認します。誤ったPDRを選ぶと、想定したQERは正しく適用されません。
PDRが参照するQER IDを確認する。 文脈なしにPFCP Session内のすべてのQERを調べる必要はありません。まず分析対象トラフィックに実際に関連するQERを特定します。
Create QERとUpdate QERを確認する。 現在有効なルールが後続のPFCP Session Modificationで変更されていないか確認します。QoS問題は最初のセッション設定ではなく、後の更新で発生する場合があります。
Gate Statusを確認する。 uplinkとdownlinkのGate状態を個別に確認します。一方向だけGateが閉じていても片方向サービス障害が発生します。
MBR、GBR、Packet Rateを確認する。 設定された制限値を観測されたスループットやパケット動作と比較します。特にサービスが毎回ほぼ固定レートで止まる場合は重要です。
QFIとその他QoSパラメータを確認する。 想定QoS Flow、マーキング、ページング関連設定がサービス設計と一致することを確認します。
ルールと実際のユーザープレーントラフィックを比較する。 PFCPはUPFが何を適用すべきかを示し、スループットテストやパケットキャプチャは実際に何が起きたかを示します。この差分が最も有効なトラブルシューティング情報になることがあります。
この方法は、一つのQERフィールドを単独で解釈するより信頼できます。PFCPシグナリングはUPFが 適用すべき内容を示し、ユーザープレーンテストは 実際に観測された結果を示します。両者を比較することが、QERが意図どおり動作しているかを判断する鍵です。
FAQ
QERとFARの主な違いは何か？
FARは主に、一致したパケットをどのように処理し、どこへ転送するかを決定し、FORW、DROP、BUFFなどの動作を含みます。QERはゲーティング、速度制限、QoS Flow関連付け、トランスポートレベルマーキングなどQoS関連動作を適用します。通常はいずれもPDRがトラフィックを識別した後に働きます。簡単に言えば、FARは パケットをどこへ、どのように転送するかを決め、QERは そのトラフィックにどのQoS処理を適用するかを決めます。
Gate StatusがOPENでもユーザースループットが低いのはなぜか？
OPENは、その方向のトラフィックが通過を許可されていることだけを意味します。他のQoS制限は解除されません。MBR、GBR、Packet Rate、関連QoS Flowを引き続き確認する必要があります。MBRが利用可能な無線・トランスポート容量より低く設定されていれば、両方のGateがOPENでもスループットは制限されます。
QERはPFCP Session Establishment時にしか作成できないのか？
いいえ。QERはPFCP Session Establishment時に作成でき、その後PFCP Session Modificationで変更できます。セッション稼働後にQoS動作が変化した場合は、最初のCreate QERだけでなく後続のUpdate QERを確認する必要があります。
QFIとQERは同じものか？
いいえ。QFIはQoS Flowの識別子で、QERはUPFが適用するQoSルールです。QERはQFI情報を含む、または参照することで、特定のQoS処理を対応するQoS Flowに関連付けられます。QFIは どのQoS Flow が関係するかを識別し、QERは トラフィックにどのようにQoS制御を適用するかを定義します。
PDRが一致しFARが転送を許可しているのに、トラフィックが失敗するのはなぜか？
ユーザープレーン処理がFARで必ず終わるとは限らないからです。転送が許可された後も、関連QERがGate Status、MBR、GBR、Packet Rate、その他QoS制約を適用する場合があります。したがって、トラブルシューティングではPDR、FAR、QERを連続した処理チェーンとして考える必要があります。どの段階で不一致があっても最終サービス結果に影響します。
