Description
The Traffic Aggregate Description (TAD) is a component within the 3GPP Policy and Charging Control (PCC) framework, specifically defined in the Gx reference point specifications. It functions as a matching rule or filter template that the Policy and Charging Rules Function (PCRF) provides to the Policy and Charging Enforcement Function (PCEF) – typically residing in the Packet Data Network Gateway (PGW) in 4G or the Session Management Function (SMF) in 5G. The primary role of a TAD is to define a set of IP packet filters that collectively identify a group of individual IP flows, aggregating them into a single logical entity for policy enforcement and charging purposes.
Architecturally, the TAD is part of a PCC rule. A PCC rule contains information for detecting a service data flow, defining its associated QoS parameters, and specifying charging rules. When a service (e.g., a video streaming session) consists of multiple concurrent IP flows (e.g., video, audio, and control signaling), defining a separate PCC rule for each flow is inefficient. Instead, a single PCC rule can reference a TAD. The TAD itself contains one or more packet filter information elements. Each packet filter uses parameters such as source/destination IP addresses and port numbers, protocol type (e.g., TCP/UDP), and potentially deeper packet inspection information (like DSCP markings) to match traffic. All IP packets that match any filter within the TAD are considered part of the same Traffic Aggregate.
How it works: The PCRF, based on subscriber profile, service information from the Application Function (AF), and operator policies, determines the necessary QoS and charging for a service. It formulates PCC rules. For a multi-flow service, it creates a PCC rule that includes a TAD with multiple packet filters. This PCC rule is provisioned to the PCEF via the Gx interface. The PCEF then installs these packet filters in its traffic detection engine. As user plane packets pass through, the PCEF matches them against all installed filters. Packets matching filters belonging to the same TAD are aggregated, and the PCEF applies the single set of QoS actions (e.g., assigning to a specific bearer with guaranteed bit rate, marking DSCP) and charging actions (e.g., counting bytes for offline charging) defined in the parent PCC rule to the entire aggregate. This provides a unified policy handle for a complex service.
Purpose & Motivation
The Traffic Aggregate Description was introduced to address the growing complexity of modern IP-based services, which often consist of multiple simultaneous data flows with different characteristics but require a unified policy treatment. Prior to concepts like TAD, policy enforcement was often performed on a per-flow basis, which could lead to inconsistent QoS treatment between the components of a single service and create significant signaling and management overhead for the network. For example, an IMS-based voice call might have separate flows for audio, video, and SIP signaling; treating them with different QoS could degrade the user experience.
The TAD solves this by allowing the network operator to define a service-centric policy rather than a flow-centric policy. It enables the PCRF to describe the complete traffic footprint of a service using a single rule, simplifying policy provisioning, monitoring, and charging. This is particularly important for sponsored data services, zero-rating, and specialized QoS guarantees for enterprise or IoT applications where the service logic is defined by multiple endpoints and protocols. The creation of TAD was motivated by the evolution towards all-IP networks in 3GPP Release 8 (EPS), where dynamic, application-aware PCC became a cornerstone for enabling sophisticated service differentiation and monetization beyond simple best-effort internet access.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the TAD function was enhanced to specifically identify LTE-M (eMTC) traffic and to define a traffic profile for NB-IoT UE Uu operation optimisation. Furthermore, support for the TAD function within the PCEF was expanded as part of the Data Off phase 2 feature, as detailed in the 23.401 specifications.
In Release 16, the TAD function was enhanced to include a description for inter-RAT handover from NR to EN-DC, which was previously missing. Additionally, corrections were made to the description of the Secondary RAT periodic reporting procedure to ensure accuracy. These updates provided clearer specifications for managing traffic aggregates during these specific mobility and reporting scenarios.
In Release 17, the TAD function was enhanced to support Multi-USIM devices, as indicated by the new Function Description for this device type. The specification details that traffic management, including the throttling of Downlink Data Notification Requests based on ARP priority levels, operates within the existing policy enforcement and GTP-based overload control framework. This update integrates the management of traffic aggregates for devices capable of maintaining multiple simultaneous network subscriptions.
- Function Description for Multi-USIM devices TS 23.401CR3622
Explore further
Broader topics and technologies where TAD plays a role.
Defining Specifications
3GPP specifications that define or reference TAD, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.401 vj50 | Evolved Packet System (EPS) Stage 2 Description | Rel-19 |