PDR / PDI / F-TEID / SDF Filter / Precedence — How Does the UPF Classify Packets?¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain the relationship between the PDR and the PDI (the PDI is the bundle of match conditions that decides "which Packets hit this PDR")
• Explain the meaning of the main PDI IEs (Source Interface / Local F-TEID / UE IP Address / Network Instance / SDF Filter / Application ID / QFI)
• Explain why the matching keys differ between UL (Access side, matched by F-TEID) and DL (Core side, matched by UE IP Address + SDF Filter)
• Explain, when the UPF is asked to allocate the TEID with the CHOOSE (CH) flag, which message carries the actual value
• Explain that different nodes allocate the UL and DL TEIDs (the receiver allocates), and cross-check the values on N2, N4 and N3
• Explain the relationship between Precedence values and PDR selection, and isolate cases where "only a specific application does not hit the intended PDR"

Prerequisites¶

• PFCP and PDR / FAR / QER / URR — the overall picture of PDR → FAR / QER / URR (this chapter narrows down to the inside of the PDR (the PDI))
• PDU Session Establishment Deep Dive — how F-TEIDs travel over N4 / N2
• Supplementary: N4 / N3 / N6 / UPF / PFCP Dictionary / QoS

Why — the UPF must tell "whose Packet, and which Traffic" among everything that arrives¶

A single UPF receives a mix of Packets belonging to tens of thousands of UEs, PDU Sessions and QoS Flows. For each Packet, the UPF decides

① which PFCP Session (≈ which PDU Session of which UE) the Packet belongs to
② which PDR within that Session it hits (which Traffic it is treated as)

and only then applies the FAR / QER / URR (TS 29.244 §5.2.1, to be confirmed). The conditions for this "hit" are written in the PDI.

If the PDI is written incorrectly, no matter how correct the FAR is, the Packet will hit an unintended PDR or hit no PDR at all. Many "PFCP says Request accepted, but nothing gets through" problems happen here.

Analogy: The UPF is the "sorting intake" of a big logistics center. The PDI is the acceptance-condition tag posted at each intake (which dock it came from, which waybill number, who the addressee is, what kind of goods). Precedence is the order in which the tags are checked. If a tag's condition is off by a single character, the parcel flows to a different lane, or stops without being accepted anywhere.

What — the relationship between the PDR and the PDI¶

Where the PDI sits inside a PDR¶

Create PDR
├─ PDR ID                       ← number identifying the PDR within the Session (not a TEID)
├─ Precedence                   ← priority when multiple PDRs match
├─ PDI (Packet Detection Information)   ← ★ the star of this chapter: the bundle of match conditions
│   ├─ Source Interface         (mandatory)
│   ├─ Local F-TEID             (optional)
│   ├─ Network Instance         (optional)
│   ├─ UE IP Address            (optional, may be multiple)
│   ├─ SDF Filter               (optional, may be multiple)
│   ├─ Application ID           (optional)
│   ├─ QFI                      (optional, may be multiple)
│   └─ Source Interface Type, etc. (optional)
├─ Outer Header Removal         ← whether to strip the outer header after a match
└─ FAR ID / QER ID / URR ID     ← processing after the match (scope of the previous chapter)

The IE structure of Create PDR and PDI is defined in TS 29.244 §7.5.2.2 (Table 7.5.2.2-1 / Table 7.5.2.2-2; table numbers to be confirmed). The above is an excerpt of the main IEs; IEs added in later Releases, such as the Ethernet Packet Filter for Ethernet PDU Sessions, Framed-Route and IP-Multicast-related IEs, are omitted. PDR attributes as seen from the 5GS side are also summarized in TS 23.501 §5.8.2.11.3 (sub-clause numbering to be confirmed).

The basic matching rule — "different kinds are AND, the same kind is OR"¶

TS 29.244 §5.2.1 (to be confirmed) defines the conditions for a Packet to match a PDR roughly as follows.

PDI
├─ Source Interface = Core          ┐
├─ UE IP Address = 10.45.0.3 (dst)  ├─ AND
└─ SDF Filter                       ┘
    ├─ #1 TCP 443  ┐
    └─ #2 UDP 443  ┘─ OR
→ matches "from the Core side, destined to 10.45.0.3, TCP 443 or UDP 443"

What — the main IEs that make up the PDI¶

Source Interface — which side did it come from?¶

Source Interface is a mandatory IE in the PDI (TS 29.244 §7.5.2.2, to be confirmed). The main values are as follows (TS 29.244 §8.2.2).

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

Local F-TEID — the UPF's "receive" tunnel endpoint¶

An F-TEID (Fully Qualified TEID) represents a GTP-U tunnel endpoint as the pair TEID + IPv4 / IPv6 address (TS 29.244 §8.2.3). The Local F-TEID in the PDI is the endpoint on which the UPF itself receives.

F-TEID IE (conceptual)
├─ Flags: V4 / V6 / CH (CHOOSE) / CHID (CHOOSE ID)
│          even when CH=1, V4 / V6 indicate which address type to allocate
├─ TEID          (when CH=0)
├─ IPv4 / IPv6   (when CH=0)
└─ Choose ID     (when CHID=1; CHID is used together with CH=1)

A UL G-PDU arrives at the UPF with the following structure, so the outer destination IP and the TEID alone uniquely identify "which tunnel of which Session."

Outer IP (dst = UPF N3 IP 198.51.100.20)
└─ UDP (dst 2152)
    └─ GTP-U (TEID = 0x00000101)          ← compared with the Local F-TEID
        ├─ PDU Session Container (QFI=1)  ← compared with the PDI's QFI (if present)
        └─ Inner IP (src = UE IP 10.45.0.3)

UE IP Address — the S/D flag distinguishes "source or destination"¶

The UE IP Address IE has an S/D flag, which in the PDI means 0 = Source / 1 = Destination (TS 29.244 §8.2.62, to be confirmed).

In a DL PDR, the UE IP Address is the main matching key. In a UL PDR, you can also include the UE IP Address (Source) in addition to the F-TEID to reject spoofed source addresses (whether to include it is SMF implementation dependent). In IPv6, it is expressed as a prefix such as /64. In configurations where the UPF allocates the UE IP, the CHV4 / CHV6 flags can let the UPF choose it (same clause, to be confirmed).

Network Instance — which network does the Packet belong to?¶

The Network Instance is a value that identifies a particular network within the UPF (e.g., a per-DNN network, the network used for N3), and may be encoded as a Domain Name or in APN / DNN format (TS 29.244 §8.2.4). Which value maps to which VRF / routing table is operator configuration and implementation dependent (its use in 5GS is in TS 23.501 §5.6.12, to be confirmed).

QFI — splitting UL QoS Flows¶

In a UL G-PDU, the gNB carries the QFI in the PDU Session Container extension header (TS 38.415 §5.5.2.2, TS 29.281 §5.2.2.7, to be confirmed). Because multiple QoS Flows are carried over the same N3 tunnel (the same Local F-TEID), splitting UL PDRs per QFI lets you apply different QERs / URRs per QoS Flow. The meaning of a QoS Flow itself is covered in the next chapter.

What — SDF Filter and Application ID¶

SDF Filter — splitting Traffic by 5-tuple¶

An SDF (Service Data Flow) Filter is an IE that classifies Traffic in detail by the values of the IP header and transport header (TS 29.244 §8.2.5).

SDF Filter IE (conceptual)
├─ Flags: FD / TTC / SPI / FL / BID
├─ Flow Description       ← FD=1. A string in IPFilterRule format
├─ 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          ← when BID=1 (refers to a bidirectional filter by ID)

The central Flow Description uses the Diameter IPFilterRule format (RFC 6733 §4.3.1, to be confirmed) with 3GPP restrictions, and TS 29.244 §8.2.5 refers to the provisions of TS 29.212 §5.4.2 (Flow-Description AVP) (to be confirmed).

permit out 6 from 203.0.113.10 443 to 10.45.0.3
  │      │  │      │            │      └─ UE-side address
  │      │  │      │            └─ remote-side port
  │      │  │      └─ remote-side address
  │      │  └─ protocol number (6 = TCP, 17 = UDP)
  │      └─ direction
  └─ Action (only permit in 3GPP)

The SDF Filter usually originates from the SDF template (Flow Information) of a PCC Rule passed from the PCF to the SMF (TS 23.503 §6.3.1, to be confirmed). PCC Rules and the PCF are covered in PCF / SM Policy Association / PCC Rule.

Application ID — classification that cannot be written as a 5-tuple¶

The Application ID is an identifier that refers to an application detection filter predefined in the UPF (TS 29.244 §8.2.6). Its contents (PFDs: Packet Flow Descriptions, such as URLs, domain names and 5-tuples) can either be preconfigured in the UPF or distributed to the UPF by the SMF through the PFCP PFD Management procedure (TS 29.244 §6.2.5 / §7.4.3, to be confirmed). The source that provides PFDs to the SMF is the NEF (PFDF), using the Nnef_PFDManagement service (TS 29.551, clause numbers to be confirmed). How deeply Packets are inspected to make the decision (the scope of DPI) is implementation dependent.

What — Precedence¶

The smaller value wins¶

Because multiple PDRs may match the same Packet, a PDR has a Precedence. Precedence is an Unsigned32 value and is defined such that the smaller the value, the higher the priority (TS 29.244 §8.2.11). The UPF is required to check the PDRs in the Session in order of decreasing priority and select only the first one that matches (no further checks are made) (TS 29.244 §5.2.1, to be confirmed).

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 ← selected
PDR #2  Precedence=255  UE IP=10.45.0.3 (no SDF = all Traffic)            → (not checked)

Ordering General and Specific¶

Smaller Precedence ──────────────────────────────── Larger Precedence
  Specific (with SDF Filter / Application ID)        General (UE IP only, catch-all)

Unless the more specific a PDR's conditions are, the smaller its value, the General PDR hits first and the Specific PDR is never reached. PCC Rules also have a Precedence, and the SMF decides the PDR Precedence based on it (TS 23.503 §6.3.1, to be confirmed). The actual numbering scheme (e.g., giving the catch-all for the Default QoS Flow a large value) is SMF implementation and operations dependent.

How — UL and DL matching differ like this¶

Side by side¶

flowchart LR
    subgraph UL["UL: Access → Core"]
        A1["G-PDU
dst=UPF N3 IP
TEID=0x00000101"] --> A2{"PDI
Source=Access
Local F-TEID matches?"}
        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 match?"}
        B2 -- "Match" --> B3["FAR: FORW
Destination=Access"]
        B3 --> B4["Outer Header Creation
gNB IP + gNB TEID → N3"]
    end

In DL, there is no N3 TEID yet when the Packet arrives from N6. That is why, at the PSA of an IP-type PDU Session, the DL PDR has no choice but to match on the UE IP Address instead of a TEID (an Ethernet-type session uses Ethernet Packet Filters such as MAC addresses, and an Unstructured-type session uses, e.g., N6 PtP tunnelling). Note that when there are multiple UPF tiers, DL that an I-UPF receives from the PSA over GTP-U on N9 is matched by Source Interface = Core and the Local F-TEID (for N9).

Outer Header Removal — stripped after the UL match¶

Outer Header Removal is an IE attached to the PDR that instructs the UPF to strip the outer header from a matched Packet (TS 29.244 §8.2.64, to be confirmed).

(The list of values, and the presence of the GTP-U Extension Header Deletion field that instructs deletion of extension headers such as the PDU Session Container, differ between versions and are to be confirmed.)

PDI matching uses both the Packet before stripping (outer IP, TEID, QFI in the extension header) and the inner IP; removal is processing done after the match.

Outer Header Creation — DL adds it on the FAR side¶

The Outer Header Creation that adds GTP-U in DL goes not into the PDR but into the Forwarding Parameters of the FAR (TS 29.244 §8.2.56, to be confirmed). See the previous chapter for its contents and update timing. The point to grasp in this chapter is that DL matching (PDR) and the DL destination (FAR) are separate IEs, and when only DL fails you need to look at both.

How — who allocates the TEID?¶

The receiver allocates it¶

A GTP-U TEID is allocated locally by the receiving side, and the sending side uses that value (TS 29.281 §5.1, to be confirmed).

UL: gNB ──GTP-U(TEID=0x00000101)──► UPF     0x00000101 is a value allocated on the UPF side (UPF or SMF)
DL: UPF ──GTP-U(TEID=0x12345678)──► gNB     0x12345678 is a value allocated by the gNB

Therefore the UL TEID and the DL TEID are different things, and there is neither a need nor a reason for them to be the same value. "Two TEIDs for the same PDU Session" is normal.

The CHOOSE (CH) flag — letting the UPF allocate it¶

Both methods are specified for the CN-side (UPF-side) tunnel information: allocation by the SMF and allocation by the UPF (TS 23.501 §5.8.2.3, to be confirmed). When the UPF allocates it, the SMF sets CH=1 in the Local F-TEID of the Create PDR and sends it without the TEID or IP address (TS 29.244 §8.2.3). Whether the UPF supports this method is indicated by FTUP in the UP Function Features (TS 29.244 §8.2.25, to be confirmed).

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: Allocates TEID and IP
same F-TEID for the same CHOOSE ID
    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 information (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: To the SMF via the AMF. The SMF reflects it in the DL FAR Outer Header Creation with PFCP Session Modification (previous chapter)

• When CH=1, the Request does not carry the TEID. The actual value is in the Created PDR of the Session Establishment Response (TS 29.244 §7.5.3.2, to be confirmed).
• Using a CHOOSE ID (CHID) lets you have the same F-TEID allocated to multiple PDRs (e.g., per-QFI UL PDRs). This matters in 5GC because multiple QoS Flows are carried over one N3 tunnel (TS 29.244 §8.2.3, to be confirmed).
• The UPF-side F-TEID reaches the gNB as the UL NG-U UP TNL Information inside the N2 SM information (PDU Session Resource Setup Request Transfer, TS 38.413 §9.3.4.1, to be confirmed), and the gNB-side F-TEID comes back as the DL QoS Flow per TNL Information inside the PDU Session Resource Setup Response Transfer (TS 38.413 §9.3.4.2, to be confirmed). See PDU Session Establishment Deep Dive for the whole flow.
• From which range and with which algorithm the UPF hands out TEIDs is implementation dependent.

PDR ID ≠ TEID ≠ QFI¶

Even if PDR ID = 1, searching N3 with gtp.teid == 1 will not find anything. The PDR ID is a number used only inside N4 and never appears in N3 Packets.

Packet Analysis (Wireshark)¶

Display filters¶

Field names for PFCP F-TEID, PDR ID, Precedence, etc. differ between Wireshark versions and are not asserted here (to be confirmed). The reliable approach is to right-click the field in the GUI and check it with "Apply as Filter."

Decode example (conceptual)¶

The following is a conceptual representation of the display structure; the values are documentation addresses and fictitious TEIDs (capture needed).

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     ← no TEID yet
│   │   ├─ 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                            ← smaller = higher priority
    ├─ 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    ← the value is known only here

The Network Instance values (n3 / internet) are operational naming examples; actual values are operator configuration dependent.

Order of checks¶

① PDR ID ............ which PDR we are talking about (a number used only within N4)
② Precedence ........ whether it is checked before other PDRs
③ PDI
   ├─ Source Interface → UL (Access) or DL (Core)?
   ├─ Local F-TEID ... if CH=1, go look at the Created PDR in the Response
   ├─ UE IP Address .. which way is S/D?
   ├─ SDF Filter / Application ID → General or Specific?
   └─ QFI
④ Outer Header Removal → is there a setting to strip GTP-U for UL?
⑤ FAR ID / QER ID / URR ID → where does it lead after the match? (previous chapter)

Rather than reading every IE from the start, first grasp "what this PDR matches, and where it leads after the match."

Cross-check across interfaces¶

Tabulating whether the same value appears with the same meaning in the three places N2, N4 and N3 shows at a glance where they diverged.

Trouble Shooting¶

Order of checks when only DL fails¶

DL PDR
 ├─ Source Interface = Core?
 ├─ UE IP Address = the allocated UE IP? S/D = Destination?
 └─ With Precedence and SDF Filters, does it hit the intended PDR?
      ↓
DL FAR (previous chapter)
 ├─ Apply Action = FORW?
 └─ Destination Interface = Access?
      ↓
Outer Header Creation
 ├─ gNB IP = DL QoS Flow per TNL Information on N2?
 └─ TEID  = same as above?

Boundary between 3GPP specifications and vendor implementations¶

3GPP defines "what rules are given to the UPF," but not "how the UPF internally looks up those rules at high speed."

Comparison with EPC (4G)¶

In 4G, "tunnel = Bearer = QoS," so the TEID alone determined the QoS; in 5G, it became a two-stage scheme that distinguishes the Session by TEID and the QoS Flow by QFI. That is why the QFI is included in the PDI of a UL PDR.

3GPP Specification¶

Summary¶

• PDR = match conditions (PDI) + what to reference after a match. The PDI is a bundle of Source Interface (mandatory) and match fields such as F-TEID, UE IP, Network Instance, SDF Filter, Application ID and QFI
• Match fields of different kinds are AND, multiple IEs of the same kind are OR, and fields absent from the PDI match everything
• UL is Access + Local F-TEID (+ QFI), DL is Core + UE IP Address (Destination) + SDF Filter, because, at the PSA of an IP-type PDU Session, DL has no TEID when it arrives at N6
• TEIDs are allocated by the receiver. The UL TEID is allocated on the UPF side, the DL TEID by the gNB, and the two are different things
• With CH=1, the Request carries no TEID, and the value first appears in the Created PDR. With a CHOOSE ID, per-QoS-Flow UL PDRs share the same F-TEID
• Precedence: the smaller value wins. Unless more specific PDRs get smaller values, they are swallowed by the catch-all
• PDR ID ≠ TEID ≠ QFI. Cross-check the values across N2, N4 and N3

Comprehension check¶

Next Step¶

• Next chapter: the QoS Flow / QFI / 5QI that the UL PDR's QFI points to → QoS Flow / QFI / 5QI
• Where SDF Filters and Precedence come from (PCC Rules) → PCF / SM Policy Association / PCC Rule
• Details of FAR / QER / URR and Outer Header Creation → PFCP and PDR / FAR / QER / URR
• How F-TEIDs travel over N2 / N4 → PDU Session Establishment Deep Dive
• Interfaces and dictionaries → N4 / N3 / N6 / UPF / PFCP Dictionary