PDR / PDI / F-TEID / SDF Filter / Precedence — UPFはパケットをどう判定するか¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• PDR と PDI の関係（PDIは「どのPacketをこのPDRに当てるか」というMatch条件の束）を説明できる
• PDI の主要IE（Source Interface / Local F-TEID / UE IP Address / Network Instance / SDF Filter / Application ID / QFI）の意味を説明できる
• UL（Access側、F-TEID でMatch）と DL（Core側、UE IP Address + SDF Filter でMatch）の判定キーが違う理由を説明できる
• CHOOSE（CH）フラグ でUPFにTEIDを割り当てさせたとき、実際の値をどのメッセージで確認するかを説明できる
• UL と DL で TEID を割り当てた主体が違う（受信側が割り当てる）ことを説明し、N2・N4・N3 の値を突き合わせられる
• Precedence の値と PDR 選択の関係を説明し、「特定アプリだけ意図したPDRに当たらない」事象を切り分けられる

前提知識¶

• PFCP と PDR / FAR / QER / URR — PDR → FAR / QER / URR の全体像（本章はその中の PDR内部（PDI） に絞ります）
• PDU Session Establishment 深掘り — F-TEID が N4 / N2 をどう渡るか
• 補助: N4 / N3 / N6 / UPF / PFCP辞典 / QoS

Why — 同じUPFに届くPacketを「誰の、どのTraffic」と見分ける必要がある¶

1台のUPFには、何万ものUE・PDU Session・QoS Flow のPacketが混ざって届きます。UPFは1つ1つのPacketについて、

① どの PFCP Session（≒どのUEのどのPDU Session）のPacketか
② その Session の中の、どの PDR に当たるか（どのTrafficとして扱うか）

を決めてから、FAR / QER / URR を適用します（TS 29.244 §5.2.1、要確認）。この「当てる」ための条件を書いたものが PDI です。

PDI の書き方を誤ると、FAR がどれだけ正しくても、Packet は 意図しない PDR に当たる か どの PDR にも当たらない ことになります。「PFCP は Request accepted なのに通信できない」問題の多くは、ここで起きます。

例え話: UPFは大きな物流センターの「仕分け口」です。PDI は仕分け口に貼られた 受付条件の札（どの搬入口から来たか・どの伝票番号か・宛名は誰か・品目は何か）で、Precedence は どの札を先に照合するかの順番 です。札の条件が1文字違うだけで、荷物は別のレーンへ流れるか、どこにも受け付けられずに止まります。

What — PDR と PDI の関係¶

PDR の中で PDI が占める位置¶

Create PDR
├─ PDR ID                       ← Session内でPDRを識別する番号（TEIDではない）
├─ Precedence                   ← 複数PDRがMatchしたときの優先度
├─ PDI（Packet Detection Information）   ← ★この章の主役：Match条件の束
│   ├─ Source Interface         （必須）
│   ├─ Local F-TEID             （任意）
│   ├─ Network Instance         （任意）
│   ├─ UE IP Address            （任意、複数可）
│   ├─ SDF Filter               （任意、複数可）
│   ├─ Application ID           （任意）
│   ├─ QFI                      （任意、複数可）
│   └─ Source Interface Type ほか（任意）
├─ Outer Header Removal         ← Match後に外側ヘッダを外すか
└─ FAR ID / QER ID / URR ID     ← Match後の処理（前章の範囲）

Create PDR と PDI の IE 構成は TS 29.244 §7.5.2.2（Table 7.5.2.2-1 / Table 7.5.2.2-2、表番号は要確認）で定義されています。上は主要IEの抜粋で、Ethernet PDU Session 用の Ethernet Packet Filter、Framed-Route、IP Multicast 関連など、Release で追加された IE は省略しています。5GS 側から見た PDR の属性は TS 23.501 §5.8.2.11.3 にも整理されています（枝番は要確認）。

Match の基本ルール — 「違う種類は AND、同じ種類は OR」¶

TS 29.244 §5.2.1（要確認）は、Packet が PDR に Match する条件をおおむね次のように定めています。

PDI
├─ Source Interface = Core          ┐
├─ UE IP Address = 10.45.0.3 (dst)  ├─ AND
└─ SDF Filter                       ┘
    ├─ #1 TCP 443  ┐
    └─ #2 UDP 443  ┘─ OR
→ 「Core側から来た、10.45.0.3 宛ての、TCP 443 または UDP 443」に Match

What — PDI を構成する主要IE¶

Source Interface — どちら側から来たか¶

Source Interface は PDI の中で 必須 の IE です（TS 29.244 §7.5.2.2、要確認）。主な値は次のとおりです（TS 29.244 §8.2.2）。

                    UPF
               ┌──────────┐
gNB ── N3 ───► │ Access   │
               │          │
               │     Core │ ◄─── N6 ── DN
               └──────────┘

Local F-TEID — UPF の「受信用」トンネル端点¶

F-TEID（Fully Qualified TEID） は、TEID + IPv4 / IPv6 アドレス の組で GTP-U トンネル端点を表します（TS 29.244 §8.2.3）。PDI の中の Local F-TEID は、UPF 自身が受信する端点 です。

F-TEID IE（概念）
├─ Flags: V4 / V6 / CH (CHOOSE) / CHID (CHOOSE ID)
│          CH=1 のときも V4 / V6 で割り当てさせるアドレス種別を示す
├─ TEID          （CH=0 のとき）
├─ IPv4 / IPv6   （CH=0 のとき）
└─ Choose ID     （CHID=1 のとき。CHID は CH=1 と併用）

UL の G-PDU は次の構造で UPF に届くため、外側の宛先IP と TEID だけで「どの Session のどのトンネルか」を一意に引けます。

Outer IP (dst = UPF N3 IP 198.51.100.20)
└─ UDP (dst 2152)
    └─ GTP-U (TEID = 0x00000101)          ← Local F-TEID と照合
        ├─ PDU Session Container (QFI=1)  ← PDI の QFI と照合（あれば）
        └─ Inner IP (src = UE IP 10.45.0.3)

UE IP Address — S/D フラグで「送信元か宛先か」を区別する¶

UE IP Address IE には S/D フラグ があり、PDI 内では 0 = Source（送信元）/ 1 = Destination（宛先） を表します（TS 29.244 §8.2.62、要確認）。

DL PDR では UE IP Address が主たる判定キーです。UL PDR でも、F-TEID に加えて UE IP Address（Source）を入れておき、なりすまし送信元を弾く構成がとれます（入れるかどうかは SMF実装依存）。IPv6 では /64 などの Prefix で表現されます。UPF が UE IP を割り当てる構成では、CHV4 / CHV6 フラグで UPF に選ばせることもできます（同節、要確認）。

Network Instance — どのネットワークの Packet か¶

Network Instance は、UPF 内で特定のネットワーク（例: DNN ごとの網、N3 用の網）を識別する値で、Domain Name や APN / DNN 形式で符号化され得ます（TS 29.244 §8.2.4）。どの値をどの VRF / ルーティングテーブルに対応付けるかは オペレータ設定・実装依存 です（5GS での使い方は TS 23.501 §5.6.12、要確認）。

QFI — UL の QoS Flow を分ける¶

UL の G-PDU には、gNB が PDU Session Container 拡張ヘッダで QFI を載せます（TS 38.415 §5.5.2.2、TS 29.281 §5.2.2.7、要確認）。同じ N3 トンネル（同じ Local F-TEID）上で複数の QoS Flow を運ぶため、UL PDR を QFI ごと に分けると、QoS Flow 単位で別の QER / URR を当てられます。QoS Flow の意味そのものは 次章 で扱います。

What — SDF Filter と Application ID¶

SDF Filter — 5-tuple で Traffic を分ける¶

SDF（Service Data Flow）Filter は、IP ヘッダ・トランスポートヘッダの値で Traffic を細分類する IE です（TS 29.244 §8.2.5）。

SDF Filter IE（概念）
├─ Flags: FD / TTC / SPI / FL / BID
├─ Flow Description       ← FD=1。IPFilterRule 形式の文字列
├─ ToS Traffic Class      ← TTC=1。IPv4 ToS / IPv6 Traffic Class
├─ Security Parameter Index ← SPI=1。IPsec SPI
├─ Flow Label             ← FL=1。IPv6 Flow Label
└─ SDF Filter ID          ← BID=1 のとき（双方向 Filter を ID で参照）

中心となる Flow Description は、Diameter の IPFilterRule 形式（RFC 6733 §4.3.1、要確認）を 3GPP が制約付きで使うもので、TS 29.244 §8.2.5 は TS 29.212 §5.4.2（Flow-Description AVP）の規定を参照しています（要確認）。

permit out 6 from 203.0.113.10 443 to 10.45.0.3
  │      │  │      │            │      └─ UE 側アドレス
  │      │  │      │            └─ 相手側ポート
  │      │  │      └─ 相手側（Remote）アドレス
  │      │  └─ Protocol 番号（6 = TCP、17 = UDP）
  │      └─ 方向
  └─ Action（3GPP では permit のみ）

SDF Filter の元になるのは、多くの場合 PCF から SMF へ渡される PCC Rule の SDF template（Flow Information）です（TS 23.503 §6.3.1、要確認）。PCC Rule と PCF の詳細は PCF / SM Policy Association / PCC Rule で扱います。

Application ID — 5-tuple で書けない分類¶

Application ID は、UPF に 事前定義されたアプリ検出フィルタ を参照する識別子です（TS 29.244 §8.2.6）。その中身（PFD: Packet Flow Description。URL・ドメイン名・5-tuple 等）は、UPF に事前設定するか、SMF が PFCP の PFD Management 手続きで UPF に配る方式があります（TS 29.244 §6.2.5 / §7.4.3、要確認）。SMF に PFD を渡す元は NEF（PFDF）で、Nnef_PFDManagement サービスが使われます（TS 29.551、節番号は要確認）。どこまで深くPacketを検査して判定するか（DPI の範囲）は 実装依存 です。

What — Precedence¶

小さい値が優先¶

同じ Packet に複数の PDR が Match し得るため、PDR には Precedence があります。Precedence は Unsigned32 の値で、値が小さいほど優先度が高い と定義されています（TS 29.244 §8.2.11）。UPF は Session 内の PDR を 優先度の高い順に照合し、最初に Match した1つだけを選ぶ（以降の照合は行わない）と定められています（TS 29.244 §5.2.1、要確認）。

DL Packet: dst=10.45.0.3, src=203.0.113.10, TCP src port 443

PDR #3  Precedence=100  UE IP=10.45.0.3 + SDF(TCP 443 from 203.0.113.10) → match ← 選ばれる
PDR #2  Precedence=255  UE IP=10.45.0.3（SDF無し＝全Traffic）             → （照合されない）

General と Specific の並べ方¶

Precedence 小 ─────────────────────────────── Precedence 大
  Specific（SDF Filter / Application ID 付き）   General（UE IP のみ、Catch-all）

具体的な条件の PDR ほど小さい値 にしないと、General な PDR が先に当たり、Specific な PDR には永遠に到達しません。PCC Rule にも Precedence があり、SMF はそれを基に PDR の Precedence を決めます（TS 23.503 §6.3.1、要確認）。実際の番号の振り方（例: Default QoS Flow 用 Catch-all を大きい値にする）は SMF実装・運用依存 です。

How — UL と DL の判定はこう違う¶

並べて比較する¶

flowchart LR
    subgraph UL["UL：Access → Core"]
        A1["G-PDU
dst=UPF N3 IP
TEID=0x00000101"] --> A2{"PDI
Source=Access
Local F-TEID 一致?"}
        A2 -- "Match" --> A3["Outer Header Removal
GTP-U/UDP/IPv4"]
        A3 --> A4["FAR: FORW
Destination=Core → N6"]
    end
    subgraph DL["DL：Core → Access"]
        B1["IP Packet
dst=UE IP 10.45.0.3"] --> B2{"PDI
Source=Core
UE IP + SDF 一致?"}
        B2 -- "Match" --> B3["FAR: FORW
Destination=Access"]
        B3 --> B4["Outer Header Creation
gNB IP + gNB TEID → N3"]
    end

DL では、N6 から届いた時点で まだ N3 の TEID は存在しません。だから IP 型 PDU Session の PSA では、DL PDR は TEID ではなく UE IP Address で Match するしかありません（Ethernet 型は MAC アドレス等の Ethernet Packet Filter、Unstructured 型は N6 の PtP tunnelling 等で判定します）。なお、UPF が複数段のとき、I-UPF が PSA から N9 の GTP-U で受ける DL は、Source Interface = Core と Local F-TEID（N9 用） で Match します。

Outer Header Removal — UL の Match 後に外す¶

Outer Header Removal は PDR に付く IE で、Match した Packet から外側ヘッダを外す指示です（TS 29.244 §8.2.64、要確認）。

（値の一覧と、PDU Session Container 等の拡張ヘッダ削除を指示する GTP-U Extension Header Deletion フィールドの有無は版により異なるため要確認）

PDI での照合は 外す前の Packet（外側 IP・TEID・拡張ヘッダの QFI）と Inner IP の両方を使い、Removal は Match 後 の処理です。

Outer Header Creation — DL は FAR 側で付ける¶

DL で GTP-U を付ける Outer Header Creation は PDR ではなく FAR の Forwarding Parameters に入ります（TS 29.244 §8.2.56、要確認）。中身と更新タイミングは 前章 を参照してください。本章で押さえるべきは、DL の判定（PDR）と DL の宛先（FAR）は別のIE であり、DL だけ通らないときは両方を見る必要がある点です。

How — TEID は誰が割り当てるのか¶

受信側が割り当てる¶

GTP-U の TEID は 受信する側がローカルに割り当て、送信側はその値を使う ものです（TS 29.281 §5.1、要確認）。

UL：gNB ──GTP-U(TEID=0x00000101)──► UPF     0x00000101 は UPF側（UPF または SMF）が割り当てた値
DL：UPF ──GTP-U(TEID=0x12345678)──► gNB     0x12345678 は gNB が割り当てた値

したがって UL の TEID と DL の TEID は別物 で、同じ値である必要も理由もありません。「同じPDU Sessionなのに TEID が2つある」のは正常です。

CHOOSE（CH）フラグ — UPF に割り当てさせる¶

CN 側（UPF 側）のトンネル情報は、SMF が割り当てる方式と UPF に割り当てさせる方式の両方が規定されています（TS 23.501 §5.8.2.3、要確認）。UPF に割り当てさせる場合、SMF は Create PDR の Local F-TEID に CH=1 を立て、TEID と IP アドレスを入れずに送ります（TS 29.244 §8.2.3）。UPF がこの方式に対応しているかは、UP Function Features の FTUP で示されます（TS 29.244 §8.2.25、要確認）。

sequenceDiagram
    participant SMF
    participant UPF
    participant AMF
    participant gNB
    SMF->>UPF: PFCP Session Establishment Request
Create PDR (PDR ID 1, UL, QFI=1): Local F-TEID CH=1, CHID=1
Create PDR (PDR ID 3, UL, QFI=2): Local F-TEID CH=1, CHID=1
    Note over UPF: TEIDとIPを割り当て
同じ CHOOSE ID には同じ F-TEID
    UPF-->>SMF: PFCP Session Establishment Response
Created PDR (PDR ID 1): F-TEID 198.51.100.20 / 0x00000101
Created PDR (PDR ID 3): F-TEID 198.51.100.20 / 0x00000101
    SMF->>AMF: N2 SM 情報（UL NG-U UP TNL Information = 198.51.100.20 / 0x00000101）
    AMF->>gNB: NGAP PDU Session Resource Setup Request
    gNB-->>AMF: PDU Session Resource Setup Response
（DL QoS Flow per TNL Information = 192.0.2.10 / 0x12345678）
    Note over SMF,UPF: AMF経由でSMFへ。SMFは PFCP Session Modification で DL FAR の Outer Header Creation に反映（前章）

• CH=1 のとき、Request 側には TEID が載っていません。実際の値は Session Establishment Response の Created PDR に入ります（TS 29.244 §7.5.3.2、要確認）。
• CHOOSE ID（CHID） を使うと、複数の PDR（例: QFI ごとの UL PDR）に 同じ F-TEID を割り当てさせられます。5GC では 1 つの N3 トンネル上に複数の QoS Flow を載せるため、これが重要です（TS 29.244 §8.2.3、要確認）。
• UPF 側 F-TEID は N2 SM 情報（PDU Session Resource Setup Request Transfer、TS 38.413 §9.3.4.1、要確認）内の UL NG-U UP TNL Information として gNB へ届き、gNB 側 F-TEID は PDU Session Resource Setup Response Transfer（TS 38.413 §9.3.4.2、要確認）内の DL QoS Flow per TNL Information として戻ってきます。流れの全体は PDU Session Establishment 深掘り を参照してください。
• UPF が TEID をどの範囲から、どのアルゴリズムで払い出すかは 実装依存 です。

PDR ID ≠ TEID ≠ QFI¶

PDR ID = 1 だからといって N3 で gtp.teid == 1 を探しても見つかりません。PDR ID は N4 の中だけで使う番号で、N3 の Packet には現れません。

Packet Analysis (Wireshark)¶

Display Filter¶

PFCP の F-TEID・PDR ID・Precedence 等のフィールド名は Wireshark の版で異なるため断定しません（要確認）。GUI で該当フィールドを右クリックし「Apply as Filter」で確認するのが確実です。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はドキュメント用アドレスと架空の TEID です（要キャプチャ）。

PFCP Session Establishment Request
├─ Create PDR
│   ├─ PDR ID: 1
│   ├─ Precedence: 255
│   ├─ PDI
│   │   ├─ Source Interface: Access (0)
│   │   ├─ F-TEID: CH=1, CHID=1, Choose ID=1     ← TEIDはまだ無い
│   │   ├─ Network Instance: n3
│   │   ├─ UE IP Address: 10.45.0.3 (S/D=Source)
│   │   └─ QFI: 1
│   ├─ Outer Header Removal: GTP-U/UDP/IPv4
│   └─ FAR ID: 1
├─ Create PDR
│   ├─ PDR ID: 2
│   ├─ Precedence: 255
│   ├─ PDI
│   │   ├─ Source Interface: Core (1)
│   │   ├─ Network Instance: internet
│   │   └─ UE IP Address: 10.45.0.3 (S/D=Destination)
│   └─ FAR ID: 2
└─ Create PDR
    ├─ PDR ID: 4
    ├─ Precedence: 100                            ← 小さい＝優先
    ├─ PDI
    │   ├─ Source Interface: Core (1)
    │   ├─ UE IP Address: 10.45.0.3 (S/D=Destination)
    │   └─ SDF Filter: FD=1
    │       └─ Flow Description: permit out 6 from 203.0.113.10 443 to 10.45.0.3
    └─ FAR ID: 2

PFCP Session Establishment Response
├─ Cause: Request accepted
└─ Created PDR
    ├─ PDR ID: 1
    └─ F-TEID: 198.51.100.20 / TEID 0x00000101    ← ここで初めて値が分かる

Network Instance の値（n3 / internet）は運用上の命名例で、実際の値は オペレータ設定依存 です。

見る順番¶

① PDR ID ............ どのPDRの話か（N4内だけの番号）
② Precedence ........ 他のPDRと比べて先に照合されるか
③ PDI
   ├─ Source Interface → UL（Access）か DL（Core）か
   ├─ Local F-TEID ... CH=1 なら Response の Created PDR を見に行く
   ├─ UE IP Address .. S/D はどちらか
   ├─ SDF Filter / Application ID → General か Specific か
   └─ QFI
④ Outer Header Removal → UL で GTP-U を外す設定があるか
⑤ FAR ID / QER ID / URR ID → Match後どこへつながるか（前章）

最初から全 IE を読むのではなく、「この PDR は何に Match し、Match 後どこへつながるか」 を先に掴みます。

Interface 横断で突き合わせる¶

N2・N4・N3 の3か所で 同じ値が同じ意味で現れているか を表にすると、どこで食い違ったかが一目で分かります。

Trouble Shooting¶

DL だけ NG のときの順序¶

DL PDR
 ├─ Source Interface = Core？
 ├─ UE IP Address = 割り当てた UE IP？ S/D = Destination？
 └─ Precedence と SDF Filter で、意図した PDR に当たっている？
      ↓
DL FAR（前章）
 ├─ Apply Action = FORW？
 └─ Destination Interface = Access？
      ↓
Outer Header Creation
 ├─ gNB IP = N2 の DL QoS Flow per TNL Information？
 └─ TEID  = 同上？

3GPP仕様とVendor実装の境界¶

3GPP は「どのようなルールを UPF に与えるか」を定めますが、「UPF の内部でそのルールをどう高速に検索するか」は定めません。

EPC（4G）との比較¶

4G では「トンネル = Bearer = QoS」だったため TEID だけで QoS まで決まりましたが、5G では TEID で Session を、QFI で QoS Flow を 見分ける二段構えになりました。UL PDR の PDI に QFI が入るのはそのためです。

3GPP Specification¶

Summary¶

• PDR = Match 条件（PDI）+ Match 後の参照先。PDI は Source Interface（必須）と、F-TEID・UE IP・Network Instance・SDF Filter・Application ID・QFI 等の Match field の束
• 種類の違う Match field は AND、同じ種類の複数 IE は OR、PDI に無い field は 全一致
• UL は Access + Local F-TEID（+ QFI）、DL は Core + UE IP Address（Destination）+ SDF Filter。IP 型 PDU Session の PSA では、DL は N6 に届いた時点で TEID が無いから
• TEID は 受信側が割り当てる。UL の TEID は UPF 側、DL の TEID は gNB が割り当てた値で、両者は別物
• CH=1 なら Request に TEID は無く、Created PDR で初めて値が分かる。CHOOSE ID で QoS Flow ごとの UL PDR が同じ F-TEID を共有する
• Precedence は小さい値が優先。Specific な PDR ほど小さい値にしないと、Catch-all に吸われる
• PDR ID ≠ TEID ≠ QFI。N2・N4・N3 で値を横断的に突き合わせる

理解度チェック¶

Next Step¶

• 次章: UL PDR の QFI が指す QoS Flow / QFI / 5QI → QoS Flow / QFI / 5QI
• SDF Filter と Precedence の出どころ（PCC Rule） → PCF / SM Policy Association / PCC Rule
• FAR / QER / URR と Outer Header Creation の詳細 → PFCP と PDR / FAR / QER / URR
• F-TEID が N2 / N4 をどう渡るか → PDU Session Establishment 深掘り
• インタフェース・辞典 → N4 / N3 / N6 / UPF / PFCP辞典