PFCP and PDR / FAR / QER / URR — How Does the UPF Classify and Forward Packets?¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that PFCP is not a protocol for carrying User Packets, but a Control Protocol for configuring UPF processing rules
• Explain the reference relationships PDR → FAR / QER / URR (the PDR identifies "which Packet," while the others specify "how to handle it")
• Explain why PDR matching criteria differ between UL and DL (F-TEID / UE IP Address / SDF Filter)
• Explain the relationship between FAR Apply Action (FORW / DROP / BUFF / NOCP) and Paging for a CM-IDLE UE
• Follow PDR → FAR ID → FAR in a PFCP capture and identify issues such as a TEID mismatch

Prerequisites¶

• PDU Session Establishment Deep Dive — how the SMF configures the UPF through PFCP Establishment → Modification
• Paging / Service Request — procedures beginning when DL Data arrives for a CM-IDLE UE
• Supplementary: N4 / N3 / N6 / QoS / Charging

Why — The UPF is not just a "box that sends traffic to the Internet"¶

For each Packet it receives, the UPF decides the following:

A Packet arrives
   ↓ Which PDU Session and which Traffic does this Packet belong to?   ← PDR
   ↓ Forward it? Drop it? Buffer it? Where to?                         ← FAR
   ↓ Which bandwidth / QoS should apply?                               ← QER
   ↓ How much has been used?                                           ← URR
Send it (N3 / N6 / N9)

The SMF configures these decision rules on the UPF, using PFCP (Packet Forwarding Control Protocol) (TS 29.244 §4.1 / §5.1, to be confirmed).

Analogy: The UPF is a "sorting center." A PDR is the condition for reading a shipping label, a FAR is the destination and instruction to "store / discard," a QER is the speed limit for the delivery truck, and a URR is the handling-volume ledger. The SMF writes and hands over the rulebook for sorting.

What — Where PFCP fits¶

       Control Plane                       User Plane
SMF ════════ UPF                    gNB ════════ UPF ════════ DN
      N4 / PFCP                           N3 / GTP-U       N6
  (configures rules)                   (the UE's Packets themselves)

• PFCP is the Control Protocol on N4 (SMF ⇔ UPF) (TS 29.244 §4.1 / §5.1, to be confirmed). It does not carry the UE's User Packets themselves. Even when User Packets are forwarded between the UPF and SMF for SMF buffering, an N4 GTP-U Tunnel, not PFCP, is used (TS 29.244 §5.3, TS 23.501 §5.8.3, to be confirmed).
• UE Data is carried over N3 using GTP-U (TS 29.281 §5, to be confirmed) and over N6 using the DN's protocol.
• PFCP runs over UDP and has node-level procedures (Association Setup / Heartbeat, etc.) and session-level procedures (Session Establishment / Modification / Deletion / Report) (TS 29.244 §6 / §7, to be confirmed).

What — Packet Forwarding Model¶

TS 29.244 defines the following model for Packet processing within the UPF (TS 29.244 §5.2.1, to be confirmed).

flowchart LR
    P[Incoming Packet] --> PDR{"PDR lookup
(PDI and Precedence)"}
    PDR -- "FAR ID" --> FAR["FAR
Apply Action / Forwarding Parameters"]
    PDR -- "QER ID(s)" --> QER["QER
Gate / MBR / GBR / QFI"]
    PDR -- "URR ID(s)" --> URR["URR
Volume / Time / Event measurement"]
    FAR -- "BAR ID (optional)" --> BAR["BAR
Buffering"]
    FAR --> OUT["N3 / N6 / N9 / CP-function"]

Other rules have been added in later Releases, such as MAR (Multi-Access Rule) for ATSSS (not covered in this chapter). Parameters for each rule in 5GS are also organized in TS 23.501 §5.8.2.11 (sub-clause to be confirmed).

What — PDR (Packet Detection Rule)¶

A PDR is a rule that determines which PDU Session and which Traffic a received Packet belongs to.

Main contents of a PDR¶

Create PDR
├─ PDR ID
├─ Precedence                     ← Priority when multiple rules match
├─ PDI (Packet Detection Information)
│   ├─ Source Interface            ← Access (N3 side) / Core (N6 side), etc.
│   ├─ Local F-TEID                ← Primarily used for UL matching
│   ├─ Network Instance
│   ├─ UE IP Address               ← Primarily used for DL matching
│   ├─ SDF Filter                  ← e.g. 5-tuple
│   └─ QFI
├─ Outer Header Removal (optional) ← Remove GTP-U/UDP/IP on UL
├─ FAR ID
├─ URR ID (zero or more)
└─ QER ID (zero or more)

(IE composition: TS 29.244 §7.5.2.2, to be confirmed)

UL and DL use different matching clues¶

UL:  gNB ──GTP-U (TEID=0x00000101)──► UPF
         PDR #1: Source=Access, F-TEID=198.51.100.20/0x00000101 → MATCH
         Outer Header Removal: GTP-U/UDP/IPv4 → inner IP goes to N6

DL:  DN ──IP (dst=10.45.0.3)──► UPF
         PDR #2: Source=Core, UE IP=10.45.0.3 (destination) → MATCH
         FAR → encapsulate in GTP-U with Outer Header Creation and send to gNB

Precedence — when multiple PDRs match¶

Since multiple PDRs may match the same Packet, PDRs have Precedence. The UPF selects the matching PDR with the smallest Precedence value (i.e. the highest priority) (TS 29.244 §5.2.1 / §8.2.11, to be confirmed).

DL Packet (dst=10.45.0.3, dst port=5060)
 ├─ PDR #2  Precedence=255  UE IP=10.45.0.3                  → match
 └─ PDR #3  Precedence=100  UE IP=10.45.0.3 + SDF(port 5060) → match
        ↓ Smaller value has priority
     Apply PDR #3 (e.g. to a separate QoS Flow for IMS)

In multiple QoS Flow and Traffic Steering scenarios, it is important to check whether the selected PDR is the intended one.

What — FAR (Forwarding Action Rule)¶

The FAR determines what to do with a Packet matched by a PDR. Its central IE is Apply Action (TS 29.244 §8.2.26, to be confirmed).

Other flags, such as those related to IP multicast and control of DL Data notifications, have been added in some Releases (to be confirmed).

Forwarding Parameters¶

Create FAR
├─ FAR ID
├─ Apply Action = FORW
└─ Forwarding Parameters
    ├─ Destination Interface      ← Access (to N3) / Core (to N6), etc.
    ├─ Network Instance
    └─ Outer Header Creation (used for DL)
        ├─ Description = GTP-U/UDP/IPv4
        ├─ TEID          = 0x12345678   ← gNB-side TEID
        └─ IPv4 Address  = 192.0.2.10   ← gNB-side N3 IP

Outer Header Creation — encapsulation in GTP-U for DL¶

DL Packets arriving from the DN are plain IP. To send them to the gNB, the UPF must encapsulate them in GTP-U, which requires the destination IP and TEID in the FAR's Outer Header Creation (TS 29.244 §8.2.56, to be confirmed).

Inner:  IP(dst=UE IP) | payload
  ↓ Outer Header Creation
Outer:  IP(dst=gNB N3 IP) | UDP(2152) | GTP-U(TEID=gNB-side) | IP(dst=UE IP) | payload

The GTP-U UDP port 2152 is specified in TS 29.281 §4.4.2 (to be confirmed).

This value is returned by the gNB in NGAP PDU Session Resource Setup Response (DL QoS Flow per TNL Information in the Response Transfer; TS 38.413 §8.2.1 / §9.3.4.2, to be confirmed). In the previous chapter, the SMF applied the gNB F-TEID to the UPF in PFCP Session Modification to populate this Outer Header Creation.

Note that DL GTP-U received by the gNB has a PDU Session Container extension header carrying the QFI (TS 38.415 §5.5.2.1, TS 29.281 §5.2.2.7, to be confirmed).

How — The connection between BUFF / NOCP and Paging¶

When the N3 tunnel is released by AN Release (TS 23.502 §4.2.6, to be confirmed) or by deactivation of the UP connection, the UPF has no DL destination (gNB F-TEID). In this case, the SMF can set the DL FAR to BUFF + NOCP (when buffering at the UPF; TS 23.501 §5.8.3, to be confirmed).

sequenceDiagram
    participant DN
    participant UPF
    participant SMF
    participant AMF
    participant gNB
    participant UE
    DN->>UPF: DL Packet
    Note over UPF: DL PDR match → FAR: BUFF + NOCP
    UPF->>SMF: PFCP Session Report Request (Downlink Data Report)
    SMF-->>UPF: PFCP Session Report Response
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
    AMF->>gNB: NGAP Paging
    gNB->>UE: Paging
    UE->>AMF: Service Request
    Note over AMF,SMF: New gNB F-TEID arrives at SMF in N2 SM information
    SMF->>UPF: PFCP Session Modification (FAR: FORW + new Outer Header Creation)
    UPF->>gNB: Send buffered DL Packet

• There are two buffering approaches: at the UPF and at the SMF. The SMF decides which to use (TS 23.501 §5.8.3, to be confirmed).
• The overall procedure from DL Data arrival to Paging is TS 23.502 §4.2.3.3 (Network Triggered Service Request).
• In a Service Request (reactivation of the UP connection) or Handover, a new DL F-TEID is notified by the gNB (TS 23.502 §4.2.3.2 / §4.9.1, to be confirmed), so the SMF updates the FAR's Outer Header Creation using PFCP Session Modification.

In other words, at the start of Paging there is a DL PDR → FAR (BUFF + NOCP) inside the UPF.

What — QER (QoS Enforcement Rule)¶

A QER applies QoS to matched traffic (QER handling under TS 29.244 §5.2 / §7.5.2.5; sub-clause to be confirmed).

Create QER
├─ QER ID
├─ Gate Status        ← OPEN / CLOSED independently for UL / DL
├─ MBR                ← Maximum Bit Rate (UL / DL)
├─ GBR (optional)     ← Guaranteed Bit Rate
├─ QFI (optional)     ← QFI to add to the GTP-U header for DL
└─ RQI (optional)     ← Reflective QoS

• One PDR can refer to multiple QERs; for example, QoS Flow-level MBR and PDU Session-level Session-AMBR can be represented by separate QERs (mapping in 5GS: TS 23.501 §5.8.2.11, to be confirmed).
• If Gate Status = CLOSED, the traffic does not pass even if the FAR is FORW (TS 29.244 §8.2.7 Gate Status, to be confirmed). Suspect the QER when "it does not flow despite FORW."
• The specific rate-control method (e.g. Token Bucket) and hardware implementation are vendor-dependent.

For QoS Flow / 5QI / AMBR concepts, see QoS.

What — URR (Usage Reporting Rule)¶

A URR measures usage and reports it to the SMF when conditions are met (TS 29.244 §5.2.2 / §7.5.2.4, to be confirmed).

Create URR
├─ URR ID
├─ Measurement Method   ← VOLUM (bytes) / DURAT (time) / EVENT
├─ Reporting Triggers   ← threshold reached, quota consumed, periodic, etc.
├─ Volume Threshold / Volume Quota (optional)
└─ Time Threshold / Time Quota (optional)

Usage Reports are returned to the SMF in PFCP Session Report Request (UPF-initiated), Session Modification Response, Session Deletion Response, etc. (TS 29.244 §7.5.8 / §7.5.5 / §7.5.7, to be confirmed).

UE Traffic → UPF (URR: measurement) ──Usage Report──► SMF ──Nchf──► CHF

How — PFCP Session procedures¶

SMF                                UPF
 │ Session Establishment Request    │
 │  Create PDR #1 (UL)  → FAR #1    │
 │  Create PDR #2 (DL)  → FAR #2    │
 │  Create FAR #1: FORW → Core      │
 │  Create FAR #2: (gNB F-TEID not yet known) │
 │  Create QER / URR                │
 │─────────────────────────────────►│
 │◄─────────────────────────────────│ Response: Created PDR (Local F-TEID)
 │                                  │
 │ Session Modification Request     │
 │  Update FAR #2: FORW +           │
 │    Outer Header Creation (gNB)   │
 │─────────────────────────────────►│

How the DL FAR's Apply Action is configured at Establishment time (e.g. BUFF / DROP until the gNB F-TEID arrives) is SMF-implementation-dependent.

It is helpful to think of PDU Session establishment as the SMF programming the UPF's Packet Processing Pipeline.

Packet Analysis (Wireshark)¶

Display Filter¶

Field names vary by Wireshark version and are not asserted here (to be confirmed).

Follow PDR → FAR ID → FAR¶

PFCP Session Establishment Request
├─ Create PDR
│   ├─ PDR ID: 2
│   ├─ Precedence: 255
│   ├─ PDI
│   │   ├─ Source Interface: Core
│   │   └─ UE IP Address: 10.45.0.3 (destination)
│   ├─ FAR ID: 2          ─────┐
│   └─ QER ID: 1               │
└─ Create FAR                  │
    ├─ FAR ID: 2         ◄─────┘
    └─ Apply Action: ...

PFCP Session Modification Request
└─ Update FAR
    ├─ FAR ID: 2
    ├─ Apply Action: FORW
    └─ Update Forwarding Parameters
        ├─ Destination Interface: Access
        └─ Outer Header Creation: GTP-U/UDP/IPv4, TEID 0x12345678, 192.0.2.10

(Values are fictitious examples. capture needed)

In Wireshark, the basic approach is to link the FAR ID in the PDR to the FAR ID in the FAR. Always check the Cause in the PFCP Response as well (e.g. Request accepted) (TS 29.244 §8.2.1, to be confirmed).

Trouble Shooting — PFCP succeeds, but Ping does not work¶

"Request accepted" for PFCP Session Establishment / Modification alone is not enough. Check the following in order.

① Is there a UL PDR? (Source Interface = Access)
② Does the UL PDR's Local F-TEID match the TEID actually used by the gNB?
③ Is the reference from the UL PDR to the FAR (FAR ID) correct?
④ Is the UL FAR FORW? Destination Interface = Core?
⑤ Does the DL PDR match the UE IP Address? (Does it match the assigned UE IP?)
⑥ Is the DL FAR FORW? Has it been left as BUFF / DROP?
⑦ Is the gNB IP in the DL FAR's Outer Header Creation correct?
⑧ Does the DL FAR's TEID match the value reported by the gNB?
⑨ Is the QER Gate Status CLOSED, or is the MBR extremely low?
⑩ Is IP Routing on N3 / N6 working?

Find a TEID mismatch¶

NGAP PDU Session Resource Setup Response   → gNB: DL TEID = 0x12345678
PFCP Session Modification (Update FAR)      → UPF: DL TEID = 0x87654321
                                               → mismatch

The most efficient approach is to compare the Tunnel information reported by the gNB in NGAP with the PFCP FAR / Outer Header Creation.

Boundary between 3GPP specifications and vendor implementations¶

For example, 3GPP does not specify whether a FAR is programmed into the Linux kernel, DPDK, SmartNIC, or ASIC.

Comparison with EPC (4G)¶

PFCP was introduced with Rel-14 CUPS (TS 23.214 §4 / TS 29.244 §4.1, to be confirmed) and is used as-is on N4 in 5GC.

3GPP Specification¶

Summary¶

• PFCP is the Control Protocol used by the SMF to configure Packet processing rules on the UPF over N4. User Packets flow over N3 using GTP-U
• PDR = which Packet; FAR = what to do / where to send it; QER = QoS; URR = usage measurement. The PDR references FAR / QER / URR by ID
• UL PDRs primarily match on Local F-TEID, and DL PDRs primarily on UE IP Address. If multiple rules match, the one with the smallest Precedence wins
• Outer Header Creation in the FAR specifies the DL destination (gNB IP / TEID). That is why the SMF applies the gNB F-TEID to the UPF using PFCP Modification
• For a CM-IDLE UE, the DL FAR can be set to BUFF + NOCP, leading to Session Report → Paging
• Even if PFCP returns Request accepted, the User Plane may not work. Compare the NGAP F-TEID with the PFCP value

Comprehension check¶

Next Step¶

• When PFCP is sent → PDU Session Establishment Deep Dive
• Paging / Service Request triggered by DL Data → Paging / Service Request
• QoS Flow / 5QI / AMBR → QoS
• Where usage data goes → Charging
• Messages and IEs → PFCP Dictionary / N4