Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · QoS

Service data flow filter

Service data flow filter

QoS →

Service data flow filter is a set of packet header parameter values or ranges used to identify the packet flows of a service data flow for differentiated QoS and charging.

Introduced
Rel-6
Where
Core Network › 5G Core
Specifications
6 specs
Service data flow filter Description Purpose What changed Neighbours Specifications

Description

A Service Data Flow (SDF) filter is a fundamental component in 3GPP's Policy and Charging Control (PCC) architecture, used to identify and classify packet flows that belong to a specific service data flow. An SDF represents a set of IP flows that are treated with the same QoS and charging policies. The SDF filter provides the criteria for matching packets to an SDF by examining packet header fields such as source and destination IP addresses, port numbers, transport protocol (e.g., TCP, UDP), and application protocol. This matching process is essential for enforcing policy decisions, applying QoS treatments, and generating charging records on a per-service basis.

The architecture surrounding SDF filters involves several key entities. In the Policy and Charging Rules Function (PCRF) or Policy Control Function (PCF), SDF filters are part of the PCC rules that are installed into the Policy and Charging Enforcement Function (PCEF) or Session Management Function (SMF) and User Plane Function (UPF). The PCEF/UPF then uses these filters to detect packets belonging to the SDF and apply the associated QoS and charging actions. The filters are typically expressed as a set of parameters, often using a syntax similar to the IPFilterRule format defined in IETF RFC 3588 (Diameter) or the Packet Filter format in 5G. The 3GPP specifications TS 23.203 and TS 23.501 define the possible filter parameters and their usage.

The operation of SDF filters is based on packet inspection. When a packet traverses the UPF (or PCEF), the filter is applied to the packet's header. If the packet matches all the criteria specified in the filter, it is considered part of the SDF. The filter can specify exact values or ranges for parameters like IP addresses and ports. For example, a filter might specify source IP address 192.168.1.1, destination IP address 10.0.0.1, source port 12345, destination port 80, and protocol TCP. Packets matching this filter would be classified into the corresponding SDF. Multiple filters can be associated with a single SDF, and a packet is considered part of the SDF if it matches any of the filters. The filters are typically unidirectional, meaning separate filters are needed for uplink and downlink traffic.

The SDF filter concept has evolved over releases. Initially defined in Rel-6 for the Policy and Charging Control (PCC) framework in 3GPP TS 23.125, it was later refined in TS 23.203. The definition changed in Rel-8 to focus on 'packet flow header parameter values/ranges' and referenced clause 6.2.2.2 for possible filters. In Rel-13, the definition was simplified to refer to 'packet flows' without explicitly mentioning 'service data flow' in the first sentence, reflecting the broader application in 5G. Rel-15 introduced the term 'in the UPF' to align with the 5G architecture. These changes reflect the evolution from 4G EPC to 5G Core and the increasing importance of fine-grained traffic classification for network slicing, edge computing, and differentiated services.

SDF filters are crucial for enabling differentiated services. They allow operators to offer tiered data plans, zero-rating for specific applications, and QoS guarantees for services like VoLTE or mission-critical communications. They also enable charging based on service type, volume, or time. Without SDF filters, all traffic would be treated equally, making it impossible to implement sophisticated business models or ensure quality of experience for specific applications. As networks move towards 5G and beyond, the granularity and flexibility of SDF filters continue to be enhanced to support new use cases like ultra-reliable low-latency communications (URLLC) and massive IoT.

Purpose & Motivation

The Service Data Flow filter exists to enable the identification and classification of packet flows within a service data flow, which is essential for applying differentiated QoS and charging policies. Before its introduction, networks could not easily distinguish between different types of traffic (e.g., voice, video, web browsing) for the purpose of policy enforcement. All packets were treated similarly, which limited the ability to provide guaranteed quality for specific services or to charge differently based on service type. The SDF filter solves this by providing a standardized set of criteria for matching packets to a service, allowing the network to apply appropriate treatment.

The motivation for SDF filters came from the need to support advanced services in 3GPP networks, particularly with the rise of IMS and the desire to offer VoIP and multimedia services over packet-switched networks. Operators needed a way to ensure that voice packets received higher priority than best-effort data, and to charge for services based on their value rather than just volume. The PCC architecture, introduced in Release 6, provided the framework, and SDF filters were the key mechanism for traffic detection. Over time, the filters became more sophisticated, supporting a wider range of parameters and being applied in both 4G and 5G networks.

In 5G, the concept of SDF filters has been extended to support the Service-Based Architecture and the separation of control and user planes. The UPF uses SDF filters to enforce policies received from the SMF, which in turn receives them from the PCF. This allows for dynamic policy updates and fine-grained control. The filters also play a role in network slicing, where each slice can have its own set of SDF filters to ensure isolation and specific QoS. The ongoing evolution of SDF filters reflects the increasing complexity and diversity of mobile services, and the need for flexible, scalable, and efficient traffic management.

What changed in its specifications

The latest release-to-release comparison of specifications that define Service data flow filter. Each summary describes the whole specification, not only this term.

TS 23.203Rel-16 → Rel-17

NB-IoT/eMTC support for Non-Terrestrial Networks: adds QCI characteristic for satellite access, note on GEO/LEO delays, and PCRF policy control for satellite PDN connections.

Full comparison in TS 23.203 →
TS 23.501Rel-18 → Rel-19

Rel-19 added MPQUIC steering to multi-access PDU sessions, XR and media handling, and an Energy Information Function. It also added Local Offloading Management for edge computing, Vertical Federated Learning for AI/ML, and Ambient IoT text.

Full comparison in TS 23.501 →

Release Timeline

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-6 Initial

Initial definition: 'a set of filter parameters used to identify one or more of the packet flows constituting a service data flow. At least the following means for the packet flow identification shall be supported: source and destination IP address+port, transport protocol, or application protocol.' This introduced the concept in the PCC framework.

Definition carried over unchanged from Rel-6.

Definition revised to: 'A set of packet flow header parameter values/ranges used to identify one or more of the packet flows constituting a service data flow. The possible service data flow filters are defined in clause 6.2.2.2.' This change shifted focus to 'packet flow header parameter values/ranges' and referenced a specific clause for detailed filter definitions.

Definition carried over unchanged from Rel-8.

Definition carried over unchanged from Rel-9.

Definition carried over unchanged from Rel-10.

Definition carried over unchanged from Rel-11.

Definition revised to: 'A set of packet flow header parameter values/ranges used to identify one or more of the packet flows. The possible service data flow filters are defined in clause 6.2.2.2.' The phrase 'constituting a service data flow' was removed, simplifying the definition and broadening its applicability.

Definition carried over unchanged from Rel-13.

Definition revised to: 'A set of packet flow header parameter values/ranges used to identify one or more of the packet flows in the UPF. The possible service data flow filters are defined in clause 6.3.1.' This added 'in the UPF' to align with 5G architecture and updated the clause reference to 6.3.1.

Definition revised to: 'A set of packet flow header parameter values/ranges used to identify one or more of the packet flows in the UPF. The possible service data flow filters are defined in clause 6.2.2.2.' The clause reference was changed back to 6.2.2.2, likely due to renumbering in the specification.

Definition carried over unchanged from Rel-16.

Definition carried over unchanged from Rel-17.

Definition carried over unchanged from Rel-18.

Definition carried over unchanged from Rel-19.

Defining Specifications

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

SpecificationTitleRelease
TS 23.125 v700 Flow Based Charging Architecture Rel-7 read
TS 23.203 vk10 Policy and Charging Control Architecture Rel-20 read
TS 23.501 vk30 5G System Architecture Rel-20 read
TS 23.503 vk30 5G Policy and Charging Control Framework Rel-20 read
TS 29.212 vk00 Diameter-Based PCC Reference Points Rel-20 read
TS 29.512 vk10 Session Management Policy Control Service Stage 3 Rel-20 read