UPFがユーザープレーンのパケットを受信しても、すぐに転送先を決定するわけではありません。まず、そのパケットがどのPFCPセッションに属するのか、どの処理ルールを適用すべきかを判断する必要があります。N4インターフェースのPFCPルール体系では、 PDR（Packet Detection Rule：パケット検出ルール） がこの最初の処理段階を担当します。PDRは、どのパケットが特定のトラフィック分類に属するかをUPFへ示します。パケットがPDRに一致すると、UPFは関連するFAR、QER、URRなどを適用し、転送、QoS制御、使用量レポートを実行できます。
PDRを理解する最も簡単な方法は、3つの役割を分けて考えることです。 PDRはトラフィックを識別し、PDIは一致条件を定義し、FAR/QER/URRは一致後の処理を決定します。 これらの役割を分けて考えることで、個々のIEを暗記するよりもPFCPのパケット処理をはるかに理解しやすくなります。
N4インターフェースでPDRはどのような問題を解決するのか？
N4は5G CoreにおけるSMFとUPF間の制御インターフェースです。SMFはPFCPセッションを使用してUPFへユーザープレーン処理ルールを設定し、その中でPDRはパケットの検出と分類を担当します。PDRは通常、PFCP Session Establishment時に作成され、その後PFCP Session Modificationによって追加、削除、更新できます。つまり、パケット分類は、現在のPDU Session、トラフィックフロー、転送要件に応じてSMFが設定するルールによって制御されます。
1つのPFCPセッションには複数のPDRを含めることができます。たとえば、同じPDU Sessionでも通常はアップリンクとダウンリンクで別々のルールが必要です。複数のService Data Flow、異なるQoS Flow、より詳細なトラフィック分類が必要な場合には、追加のPDRが必要になることもあります。そのためPDRは、UPFにおけるトラフィック選択ルールと考えることができます。つまり、どの種類のパケットが到着したかを判断し、その後に他のルールが処理方法を決定します。
UPFはどのように一致するPDRを見つけるのか？
UPFのパケット処理は定められた順序で行われます。パケットがUPFへ入ると、まず対応するPFCPセッションを特定し、そのセッションに関連付けられたPDRを評価します。複数のPDRが一致する可能性がある場合、UPFは Precedence の値を使用して相対的な優先順位を決めます。Precedenceの値が小さいほど優先度が高いため、一致するルールを検索する際は、優先度の高いPDRから先に評価されます。
PDRが一致した後も、PDR自体がすべての後続処理を実行するわけではありません。代わりに、他のPFCPルールを参照できます。
FAR（Forwarding Action Rule：転送アクションルール）：パケットを転送、破棄、バッファリング、または特定の宛先インターフェースへ送信するなど、パケットの処理方法と転送方法を決定します。
QER（QoS Enforcement Rule：QoS適用ルール）：ゲーティング、レート制御、その他のトラフィック処理など、QoS関連の制御を適用します。
URR（Usage Reporting Rule：使用量レポートルール）：トラフィック使用量を測定し、課金、監視、ポリシー関連処理などに利用できるレポート情報を提供します。
したがって、UPF全体の処理フローは次のように簡略化できます。
PFCPセッションを特定 → Precedence順にPDRを評価 → パケットを分類 → FAR/QER/URRを適用。 この順序は重要です。FARは「パケットをどう処理するか」を決めますが、その前にUPFはPDRによって「どのパケットまたはトラフィックフローにその処理を適用するか」を確定する必要があります。
PDRの主なパラメータは何か？
Create PDRには複数のInformation Elementが含まれますが、パケット検出の動作を理解するうえでは、まず主要な一部の項目を押さえれば十分です。これらのパラメータは、ルールの識別方法、パケットの一致方法、そして一致後に関連付けられる処理ルールを定義します。
| パラメータ | 主な機能 |
|---|---|
| PDR ID | PFCPセッション内でPDRを一意に識別し、他のパケット検出ルールと区別します |
| Precedence | 複数のルールを評価する際のPDRの相対的な優先度を定義します。値が小さいほど優先度が高くなります |
| PDI | 受信トラフィックがPDRに一致するかをUPFが判断するためのパケット検出条件を含みます |
| Outer Header Removal | アップリンクトラフィックのGTP-U/UDP/IPヘッダーなど、外側のプロトコルヘッダーをUPFが削除するかどうかを指定します |
| FAR ID | 一致したパケットの転送アクションを定義するFARを参照します |
| URR ID | トラフィック測定と使用量レポートに使用するURRを参照します |
| QER ID | 一致したトラフィックにQoS関連処理を適用するQERを参照します |
| Activate Predefined Rules | UPFにあらかじめ用意されている1つ以上の事前定義ルールを有効化します |
| Activate Time / Deactivate Time | PDRが有効になる時刻と無効になる時刻を定義します |
これらのパラメータの中で、実際に どのパケットがPDRに一致できるかを定義するのがPDI（Packet Detection Information）です。FAR IDやQER IDはトラフィック分類後に実行される処理を参照しますが、PDIは分類そのものに使用する情報を含みます。
PDIはどのようにパケット一致条件を定義するのか？
PDIは、PDR内部に含まれるパケット検出条件の集合と考えることができます。単一のフィールドではなく、複数のパラメータを組み合わせて、パケットがUPFへ入った位置、トンネル情報、UEアドレス、Service Flowの特性、QoS情報などからトラフィックを識別します。代表的なPDIパラメータには次のものがあります。
Source Interface：パケットが到着した論理側を示します。たとえば Access はアクセス側からのトラフィック、 Core はコアまたはデータネットワーク側からのトラフィックを示します。
Local F-TEID：GTP-Uトンネルに関連するTEIDとアドレス情報の一致に使用でき、特にアップリンクのトンネルトラフィック検出で重要です。
Network Instance：UPFに設定された論理ネットワークを識別します。たとえばInternetやIMSに関連するネットワークインスタンスです。
UE IP Address：パケットの方向に応じて、UEの送信元または宛先IPアドレスを使ってトラフィックを一致させます。
Traffic Endpoint ID：対応するPDI最適化シナリオで利用可能なトラフィックエンドポイントを識別します。
SDF Filter：送信元・宛先アドレス、プロトコル、ポート、トラフィック方向などの条件に基づいて、より細かいフィルタリングを行います。
Application ID：UPFが必要なアプリケーション検出機能を備えている場合、アプリケーションレベルのトラフィック識別に使用できます。
QFI（QoS Flow Identifier）：パケットに関連付けられたQoS Flowを識別します。
Source Interface Type：送信元に関連する3GPPインターフェースについて、N3、N6、N9などの追加情報を提供します。
PDIに複数の一致パラメータが含まれる場合、それらを組み合わせてパケット検出条件を定義します。受信パケットは適用される条件を満たして初めてPDRに一致したと判断されます。これによりSMFは、広いセッション単位の分類から、より具体的なService Flow検出まで幅広いルールを作成できます。
SDF Filterを使うとトラフィック検出はどこまで細かくできるのか？
Source Interface、F-TEID、UE IP Addressだけでもセッションや大まかなトラフィック分類を識別できますが、個々のService Data Flowまで必ずしも区別できるとは限りません。 SDF Filter は、より細粒度の分類を提供します。その Flow Description には、送信元IPアドレス、宛先IPアドレス、プロトコル番号、送信元ポート、宛先ポート、トラフィック方向を含めることができます。これによりUPFは、同じUEに関連するすべてのパケットを同一に扱うのではなく、特定のIPフローを区別できます。
SDF Filterには、さらに次のような一致情報を含めることもできます。
TOS / Traffic Class：IPv4のType of ServiceまたはIPv6のTraffic Classフィールドに一致させます。
Security Parameter Index（SPI）：IPsec Security Associationに関連するトラフィックの一致に使用できます。
Flow Label：IPv6ヘッダーに含まれるFlow Labelと一致させます。
SDF Filter ID：管理や参照のために、関連するSDF Filterを識別します。
これにより多層的な分類モデルが構成されます。インターフェース、トンネル、UEアドレスなどのPDIパラメータでまずトラフィックを特定のコンテキストに絞り込み、その中でSDF Filterによって個々のIPフローを識別できます。アプリケーション識別もサポートされる場合、UPFはアドレスやポートだけに依存せず、追加のアプリケーションレベル分類を適用できます。
アップリンクPDRとダウンリンクPDRの違いは何か？
アップリンクとダウンリンクを比較することは、PDRの動作を理解する最も分かりやすい方法の1つです。どちらも基本的なルール構造は同じですが、パケットが異なるインターフェースからUPFへ入るため、必要な検出条件が異なります。
一般的なアップリンクでは、パケットは無線アクセス側からUPFへ到着します。そのためPDIは Source Interface = Accessを使用できます。さらにルールでは、 Local F-TEID を使ってGTP-Uトンネルを識別し、 UE IP Address を使ってUEトラフィックを識別できます。典型的なアップリンクPDRでは、次の条件が考えられます。
Source InterfaceがAccessであること。
受信GTP-Uパケットが、関連するTEIDとアドレス情報を含めて指定F-TEIDと一致すること。
UE IPアドレスがセッションに関連付けられたアドレスと一致すること。
条件が満たされるとPDRが一致します。N3で受信するトラフィックは通常GTP-Uでカプセル化されているため、 Outer Header Removal によって、関連FARに基づいてパケットを処理する前にGTP-U/UDP/IPの外部ヘッダーを削除するようUPFへ指示できます。
ダウンリンク検出は逆方向から始まります。通常、パケットはデータネットワーク側からUPFへ到着するため、PDIは Source Interface = Coreを使用できます。この場合、 Network Instance や UE IP Address を使って、そのパケットがどのPDU Sessionに属するかを判断できます。典型的なダウンリンクPDRでは、次の条件が考えられます。
Source InterfaceがCoreであること。
Network Instanceが「internet」や「ims」などの必要な論理ネットワークと一致すること。
パケットの宛先がセッションに関連付けられたUE IPアドレスと一致すること。
ダウンリンクPDRが一致すると、関連FARがアクセス側への転送方法を決定し、必要なトンネル転送動作も指定します。したがってアップリンクPDRとダウンリンクPDRの違いは、パケットがUPFへ入る方向と、そのパケットを識別するために利用できる情報の違いを反映しています。
PDR、FAR、QER、URRはどのように連携するのか？
PDRはパケット識別の問題を解決しますが、ユーザープレーン処理ポリシー全体を表すものではありません。PFCPでは、パケット検出、転送、QoS制御、使用量計測を異なるルールタイプに分離しています。この分離により、それぞれのルールが明確な役割を持ちながら、同じPFCPセッション内で連携できます。
PDR：これはどのトラフィックか？（検出と分類）
FAR：どのように処理し、どこへ送るか？（転送アクション）
QER：どのQoS処理を適用するか？（QoS制御）
URR：使用量をどのように計測・報告するか？（使用量レポート）
PDRに一致したアップリンクパケットを考えます。UPFがそのパケットがどのUEとService Flowに属するかを判断すると、必要なGTP-U外部ヘッダーを削除し、FARが参照する転送動作を適用し、該当するQERを実行し、関連URRに基づいてトラフィック使用量を記録できます。パケット検出結果は、その後のすべての処理に必要なコンテキストを提供します。
エンジニアリングの観点では、PDRを単独の転送ポリシーとして見るべきではありません。PDRはPFCPユーザープレーンルールセットへの入口です。 分類を行うPDR、一致条件を定義するPDI、後続処理を行うFAR/QER/URR という関係を理解すると、Source Interface、F-TEID、UE IP Address、SDF Filterなどのパラメータも、実際のN4シグナリングやパケット解析で理解しやすくなります。
FAQ
UPFがPFCPセッション内のPDRを評価する際にはPrecedenceが使用されます。ただし、2つのルールのPDI条件が完全に排他的であれば、同じパケットが両方のPDRに一致することはないため、相対的なPrecedenceは最終結果を変えません。ルール条件が重なり、同じトラフィックに複数のPDRが一致する可能性がある場合に、Precedenceが特に重要になります。
PDIの一致条件として使用しているUEアドレスが変更された場合、そのアドレスに関連するルールも最新のセッション情報を反映する必要があります。SMFはPFCP Session Modificationを通じて関連PDR情報を更新し、UPFが引き続きUEトラフィックを正しく分類できるようにします。
できます。SDFフィルタリングでは、すべてのフィールドを使ってトラフィックを1つの特定ポートに限定する必要はありません。ルール定義に応じて、ポート範囲や制限の緩い一致条件を使用して、より広いトラフィックを対象にできます。フィルター定義でアドレス範囲の一致が必要な場合は、アドレスマスクも使用できます。
受信パケットを適用可能なPDRに関連付けられない場合、UPFにはそのコンテキスト内で該当トラフィックを処理する一致ルールが存在しません。その後の処理は、適用されるPFCPルール、UPF実装、セッション設定によって異なります。トラブルシューティングでは、トラフィックがUPFへ到達しているのに期待どおり転送されない場合、予期しないPDR不一致は重要な確認ポイントです。
PFCPは、UP機能にあらかじめ設定済みで必要に応じて有効化できる事前定義ルールをサポートします。適用可能なシナリオごとにすべてのルールパラメータを繰り返し設定する代わりに、制御プレーンは対応する事前定義ルールを有効化できます。同じルールセットを複数の適切なセッションで再利用する場合、必要なシグナリング量を減らすことができます。
