PDR

Packet Detection Rule

Core Network →
Introduced in Rel-14 Also in: Services

PDR is a policy construct in the UPF or TDF that defines matching criteria and actions to identify and process user plane packets for traffic steering and policy enforcement.

Category
Core Network
Introduced
Rel-14
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
4 specs
PDR Description Purpose Related Classification Detected Changes Specifications

Description

The Packet Detection Rule (PDR) is a central element of the packet processing pipeline in the 3GPP 5G Core (5GC) User Plane Function (UPF) and is also used in the 4G/5G Traffic Detection Function (TDF). It is a rule installed by the Session Management Function (SMF) via the PFCP (Packet Forwarding Control Protocol) protocol to instruct the UPF on how to identify and handle specific user plane traffic flows. Each PDR is uniquely identified within a PFCP session and contains two main parts: a Packet Detection Information (PDI) section and a set of associated Actions.

The Packet Detection Information (PDI) defines the matching criteria used to identify packets belonging to a specific flow. This can include a combination of fields such as source/destination IP address, source/destination port numbers, protocol identifier (e.g., TCP/UDP), QoS Flow Identifier (QFI), Network Instance (identifying a virtual network), Source/Destination Interface (e.g., access side, core side), and application identifiers (from Application Detection and Control). The PDI provides the granularity needed to distinguish between different services, users, or network slices. When a user plane packet arrives at the UPF, it is matched against the list of active PDRs in the order of their precedence. The first PDR whose PDI matches the packet is selected for enforcement.

Once a packet matches a PDR, the UPF executes the ordered list of Actions associated with that rule. Key actions include: forwarding the packet to a specific destination (e.g., to a next-hop tunnel or an application function), buffering the packet (e.g., for downlink data notification when the UE is idle), applying a specific QoS enforcement policy (mapping to a QoS Flow, applying rate limiting), triggering usage reporting for charging, and activating/deactivating other PDRs or QoS Enforcement Rules (QERs) dynamically. Multiple PDRs can be chained or nested to create complex service function chains, such as routing traffic through a firewall or a video optimizer before reaching its final destination. The PDR framework provides the SMF with a powerful, programmable interface to control the UPF's behavior on a per-flow basis, which is essential for supporting network slicing, edge computing, and differentiated services in 5G.

Purpose & Motivation

The PDR was created to address the limitations of static, pre-configured packet filtering and forwarding in previous mobile core networks (like the GGSN in 2G/3G). In those systems, traffic handling was relatively coarse, often based on the APN or simple IP filters. The shift to a cloud-native, service-based 5G Core required a much more flexible, dynamic, and granular mechanism to enforce complex policies defined by the control plane (SMF). PDRs, as part of the PFCP protocol, enable this by separating the control logic (in the SMF) from the high-speed packet processing (in the UPF), allowing for real-time, session-specific policy application.

This architecture solves the problem of efficiently supporting diverse 5G use cases with vastly different requirements—from massive IoT requiring simple forwarding to ultra-reliable low-latency communications (URLLC) requiring precise traffic steering and guaranteed QoS. PDRs allow the network to dynamically create and modify traffic handling rules without interrupting user sessions. For example, when a user starts a video call, the SMF can install a new PDR to identify that specific flow and apply a high-priority QoS policy. This level of dynamic control was not feasible with the monolithic GGSN architecture.

Furthermore, PDRs are fundamental to enabling network slicing and edge computing. Different network slices require isolated traffic paths and policies. PDRs can match packets based on a Network Instance (slice identifier) and direct them to the appropriate virtualized or physical resources. For edge computing, PDRs can steer traffic destined for a local application server directly to a local User Plane instance at the network edge, minimizing latency. The PDR model thus provides the essential building block for a programmable, agile, and service-aware 5G user plane.

Classification

Part ofPFCP
Specific typesPDI
Related approachesQERFAR

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (128 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-14, normative work from Rel-15.

Rel-15 22 changes

In Release 15, the Packet Detection Rule (PDR) function was formally specified and introduced, enabling traffic detection and routing based on rules provided by the SMF to the UPF. This included enhancements such as defining PDR for Ethernet PDU session types and allowing traffic mapping information to disallow uplink packets. Additionally, the release added capabilities for associating multiple SDFs with a PDR and incorporating QFIs into the Packet Detection Information for QoS handling.

  • PS Data Off supporting non-IP data packet TS 23.501CR0680
  • Corrections to RQoS logic when receiving DL packet with RQI TS 23.501CR0011
  • Update on Traffic Detection Information TS 23.501CR0026
  • Proposal of Specifying Packet Detection Rule TS 23.501CR0027
  • Corrections and clarifications for the usage of Packet Filter Set TS 23.501CR0035
  • Traffic mapping information that disallows UL packets TS 23.501CR0053

+ 16 more changes

Rel-16 41 changes

In Release 16, the PDR function was enhanced to support deferred activation and deactivation, allowing for more dynamic traffic steering. It also saw updates to the packet forwarding model and clarifications for creating PDR information elements within modification messages. Furthermore, the enhancements enabled PFCP sessions to be successively controlled by different SMFs within the same set, improving control plane flexibility.

  • Support of forwarding of broadcast and multicast packets TS 23.501CR1659
  • NIDD Description Update for Maximum Packet Size TS 23.501CR1364
  • Adding N4 Notification about buffered packets being dropped TS 23.501CR1465
  • Correction of RAN part of packet delay for QoS monitoring TS 23.501CR2293
  • Drop downlink packets with notification of the discarded downlink packet TS 23.501CR2427
  • Correction of packet delay calculation for QoS monitoring TS 23.501CR2532

+ 35 more changes

Rel-17 28 changes

In Release 17, the PDR function was enhanced to support new detection and reporting capabilities over the N4mb interface, including User Plane (In)Activity Detection and Reporting. It also gained the ability to incorporate Transport Level Marking information for PFCP sessions and to facilitate Packet Loss Rate measurements. Furthermore, specific enhancements were made for Multicast and Broadcast Service (MBS) packet detection and forwarding.

  • Packet Loss Rate measurements TS 23.501CR2587
  • PFCP Node related messages supported over N4mb TS 29.244CR0606
  • User Plane (In)Activity Detection and Reporting over N4mb TS 29.244CR0608
  • Transport Level Marking information for PFCP sessions over N4mb TS 29.244CR0622
  • Detection of satellite backhaul based on configuration information TS 23.501CR2674
  • Packet size for PDB TS 23.501CR2806

+ 22 more changes

Rel-18 23 changes

In Release 18, enhancements to the Packet Detection Rule (PDR) function included extensions to the PFCP protocol to support High Reliability - Single Bidirectional Offload (HR-SBO) PDU sessions and the introduction of TL-Containers in PFCP Session Modification and Deletion procedures. Furthermore, PDR capabilities were updated to incorporate Fully Qualified Domain Names (FQDN) within Traffic Detection Information and to define packet filters using DSCP and ECN fields for more granular traffic detection. These changes, along with updates for user plane inactivity detection and clarifications on protocol description applicability for End of Data Burst (EoDB) identification, expanded the traffic detection and control mechanisms available to the SMF and UPF.

  • PCF support of 5GS Packet Delay Variation monitoring based on QoS monitoring mechanism and exposed to AF TS 23.501CR3792
  • Update NEF to support NWDAF-assisted application detection TS 23.501CR4105
  • Update about the Packet Delay Variation description and add PDV in QoS monitoring parameters TS 23.501CR4506
  • User plane inactivity detection update TS 29.244CR0731
  • PFCP extensions for HR-SBO PDU sessions TS 29.244CR0750
  • TL-Containers in PFCP Session Modification/Deletion Request/Response TS 29.244CR0767

+ 17 more changes

Rel-19 14 changes

In Release 19, the PDR function was enhanced with new packet inspection functionalities in the UPF, including the exposure of NAT information. Furthermore, the release introduced mechanisms for providing alternative SMFs per PFCP session and for excluding specific PFCP sessions from restoration upon an SMF failure, improving session resilience and management.

  • Adding the NAT information exposure and Packet Inspection functionality in the UPF NF profile TS 23.501CR5420
  • UPF Packet Inspection functionalities TS 29.244CR0881
  • PFCP sessions excluded from the restoration upon a SMF failure with SMF set being deployed TS 29.244CR0895
  • Identification and marking of Data Burst Size in DL GTP-U packets TS 29.244CR0892
  • Removing Editor's Note for Packet Inspection Functionalities TS 29.244CR0934
  • Providing alternative SMF(s) per PFCP Session TS 29.244CR0911

+ 8 more changes

Explore further

Broader topics and technologies where PDR plays a role.

Defining Specifications

3GPP specifications that define or reference PDR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 26.510 vj10 Media Delivery APIs for 5GMS and RTC Systems Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TS 29.244 vj40 PFCP Specification for Control/User Plane Separation Rel-19