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
• Explain the difference between the N2 SM Information the SMF sends toward the gNB and the N4 (PFCP) rules it sends to the UPF

Prerequisites¶

• PDU Session Establishment Deep Dive — how the SMF configures the UPF through PFCP Establishment → Modification
• Paging / Service Request / CM-IDLE / CM-CONNECTED and 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 Clause 4.1 / Clause 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 Clause 4.1 / Clause 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 Clause 5.3, TS 23.501 Clause 5.8.3, to be confirmed).
• UE Data is carried over N3 using GTP-U (TS 29.281 Clause 5, to be confirmed) and over N6 using the DN's protocol.
• PFCP runs over UDP (the registered PFCP port is UDP 8805; TS 29.244 Clause 4.2.2, to be confirmed) and has node-level procedures (Association Setup / Heartbeat, etc.) and session-level procedures (Session Establishment / Modification / Deletion / Report) (TS 29.244 Clause 6 / Clause 7, to be confirmed).
• Session-level procedures require that a PFCP Association has already been established between the SMF and the UPF (TS 29.244 Clause 6.2.6, to be confirmed).

Do not confuse N2 SM Information with N4 (PFCP)¶

For a single PDU Session, the SMF creates three kinds of information with different destinations.

SMF ──N1 SM info──► AMF ──NAS (N1)──► UE    … for the UE (PDU Session Establishment Accept, etc.)
SMF ──N2 SM info──► AMF ──NGAP (N2)─► gNB   … for the RAN (UPF's N3 F-TEID, QoS Flow setup, etc.)
SMF ──N4 / PFCP─────────────────────► UPF   … for the UPF (PDR / FAR / QER / URR)
gNB ══N3 / GTP-U════════════════════► UPF   … the UE's User Packets themselves

PFCP and N2 SM information work as two wheels that hand F-TEIDs back and forth. The UPF-side N3 F-TEID is either allocated by the SMF (written in Create PDR) or allocated by the UPF (CH flag → returned in Created PDR); either way it is fixed over PFCP and delivered to the gNB in N2 SM information. Conversely, the gNB-side F-TEID returns to the SMF in N2 SM information (Response Transfer) and is installed in the UPF's FAR by PFCP Session Modification.

Analogy: N2 SM information is "a letter addressed to the branch office (gNB)," while PFCP is "a work order addressed to the warehouse (UPF)." Headquarters (the SMF) writes both, but the recipients and delivery routes differ.

What — Packet Forwarding Model¶

TS 29.244 defines the following model for Packet processing within the UPF (TS 29.244 Clause 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"]

Figure: A simplified conceptual view of the Packet Forwarding Model in TS 29.244 (TS 29.244 Clause 5.2.1, to be confirmed). Incoming Packet → PDR lookup shows the processing flow, while the arrows from the PDR to each rule represent references by ID (not chronological processing order). The BAR is referenced by the FAR's BAR ID and is meaningful when the FAR is BUFF. The CP-function destination covers cases such as buffering at the SMF, where packets are sent to the SMF over a GTP-U tunnel on N4.

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 Clause 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 Clause 7.5.2.2, to be confirmed)

Who decides the Local F-TEID? — the CHOOSE (CH) flag¶

The Local F-TEID used for UL matching (UPF-side N3 IP + TEID) can be allocated by the SMF or allocated by the UPF (TS 23.501 Clause 5.8.2.3, to be confirmed).

• To let the UPF allocate it, the SMF sets the CHOOSE (CH) flag in the F-TEID IE in the PDI of Create PDR and sends it without a concrete TEID / IP (TS 29.244 Clause 8.2.3, to be confirmed).
• The UPF returns the allocated value in the Created PDR IE of the Session Establishment Response (TS 29.244 Clause 7.5.3.2, to be confirmed). The SMF puts this value into N2 SM information (UL NG-U UP TNL Information) and passes it to the gNB.
• To have the same F-TEID allocated to multiple PDRs, specify the same value with CHOOSE ID (CHID). The UPF allocates the same F-TEID to PDRs with the same Choose ID (TS 29.244 Clause 8.2.3, to be confirmed).

Which approach is used depends on SMF / UPF capabilities and configuration (UPF-side support is indicated by FTUP in UP Function Features during PFCP Association; TS 29.244 Clause 8.2.25, 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 Clause 5.2.1 / Clause 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. How Precedence values are assigned is not uniformly specified and is SMF-implementation / operations-dependent. For design considerations, see the next chapter.

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 Clause 8.2.26, to be confirmed).

Apply Action is a set of bit flags that are combined (e.g. BUFF + NOCP, FORW + DUPL). However, only one of DROP / FORW / BUFF (including IPMA / IPMD / MBSU etc. depending on the Release) shall be set (TS 29.244 Clause 8.2.26, to be confirmed).

An example of the intended use of DUPL in the specification is Lawful Interception (TS 29.244 Clause 7.5.2.3, to be confirmed). The LI architecture in 5GC is outside the scope of this chapter, and details of duplication destinations and methods include implementation-dependent parts.

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 Clause 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 Clause 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 Clause 8.2.1 / Clause 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 Clause 5.5.2.1, TS 29.281 Clause 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 Clause 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 Clause 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

Figure: A simplified view extracting the PFCP-related parts of the Network Triggered Service Request (TS 23.502 Clause 4.2.3.3), for buffering at the UPF. The N1N2MessageTransfer response, the AMF's Paging decision, Nsmf_PDUSession_UpdateSMContext between the AMF and SMF during the Service Request, PDU Session Resource Setup with the gNB, and so on are omitted. For buffering at the SMF, the DL FAR destination becomes the CP-function, and the DL Packets themselves are sent to the SMF over GTP-U on N4 (TS 23.501 Clause 5.8.3, to be confirmed).

• There are two buffering approaches: at the UPF and at the SMF. The SMF decides which to use (TS 23.501 Clause 5.8.3, to be confirmed).
• The overall procedure from DL Data arrival to Paging is TS 23.502 Clause 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 Clause 4.2.3.2 / Clause 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 Clause 5.2 / Clause 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 Clause 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 Clause 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 Clause 5.2.2 / Clause 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 Clause 7.5.8 / Clause 7.5.5 / Clause 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: (no gNB F-TEID)  │
 │  Create QER / URR                │
 │─────────────────────────────────►│
 │◄─────────────────────────────────│ Response: Created PDR (Local F-TEID)
 │                                  │
 │ Session Modification Request     │
 │  Update FAR #2: FORW +           │
 │    Outer Header Creation (gNB)   │
 │─────────────────────────────────►│

Figure: A conceptual view of the typical order in which PFCP is sent during PDU Session Establishment (TS 23.502 Clause 4.3.2.2.1) in the previous chapter. The Local F-TEID appears in the Created PDR of the Response when the UPF allocates the F-TEID (CH flag). ID values and the number of rules are SMF-implementation-dependent.

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.

Typical situations that require Session Modification¶

If the gNB-side tunnel changes in the middle of a PDU Session, the UPF's DL FAR must follow.

UE under gNB-A : DL FAR  Outer Header Creation = gNB-A IP / TEID=0xAAAA0001
        ↓ Handover, or CM-IDLE → Service Request via gNB-B
UE under gNB-B : DL FAR  Outer Header Creation = gNB-B IP / TEID=0xBBBB0001
        ↑ The SMF rewrites it with PFCP Session Modification (Update FAR)

TEID and IP values are fictitious examples. For the overall Handover flow, see Handover.

Packet Analysis (Wireshark)¶

Display Filter¶

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

Decode example (conceptual) — follow PDR → FAR ID → FAR¶

The following is a conceptual representation of the display structure (display labels differ by Wireshark version).

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 Establishment Response
├─ Cause: Request accepted
└─ Created PDR
    ├─ PDR ID: 1
    └─ Local F-TEID: TEID 0x00000101, 198.51.100.20   ← value allocated by the UPF for the UL PDR (CH case)

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. not an actual capture)

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 Clause 8.2.1, to be confirmed).

Order of inspection¶

flowchart LR
    A["① PFCP Association
Setup / Heartbeat"] --> B["② Establishment Request
Create PDR / FAR / QER / URR"]
    B --> C["③ Establishment Response
Cause / Created PDR"]
    C --> D["④ NGAP Setup Response
gNB DL F-TEID"]
    D --> E["⑤ Modification Request
Update FAR Outer Header Creation"]
    E --> F["⑥ GTP-U
actual TEID / IP"]

Without ①, session procedures cannot succeed. Compare the Local F-TEID in ③ with the TEID in UL GTP-U in ⑥, and the gNB F-TEID in ④ with the TEID in ⑤ and in DL GTP-U in ⑥, and check that each pair matches.

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 Clause 4 / TS 29.244 Clause 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
• N2 SM information (for the gNB) and PFCP (for the UPF) are different things. F-TEIDs travel between them to complete the UL / DL tunnels
• Apply Action is a combination of flags (BUFF + NOCP, FORW + DUPL, etc.). To let the UPF allocate the F-TEID, use the CH flag; the result is returned in Created PDR

How this connects to the surrounding chapters¶

CM-IDLE / Paging       DL Packet arrives → DL FAR (BUFF + NOCP) → Session Report → Paging
Service Request        New gNB F-TEID → PFCP Modification sets DL FAR to FORW
PDU Session setup      PFCP Establishment creates PDR / FAR / QER / URR
This chapter           The UPF processes Packets according to PDR → FAR / QER / URR
Next chapter           What a PDR "looks at" to match (PDI / F-TEID / SDF Filter / Precedence)

Comprehension check¶

Next Step¶

• Next chapter: What a PDR looks at to match (details of PDI / F-TEID / SDF Filter / Precedence) → PDR / PDI / F-TEID / SDF Filter / Precedence
• When PFCP is sent → PDU Session Establishment Deep Dive
• Paging / Service Request triggered by DL Data → CM-IDLE / CM-CONNECTED and Service Request / Paging / Service Request
• QER QFI and QoS Flows → QoS Flow / QFI / 5QI / QoS
• The big picture of the UPF / SMF → UPF / SMF
• Where usage data goes → Charging
• Messages and IEs → PFCP Dictionary / N4