TFT

Traffic Flow Template

Core Network →
Introduced in R99 Also in: Services, Testing

TFT is the set of packet filters in a PDP context that classifies downlink user plane packets and associates them with specific bearers for QoS treatment.

Category
Core Network
Introduced
R99
Where
Core Network › Evolved Packet Core
Also touches
2 segments
Specifications
14 specs
TFT Description Purpose Related Classification Detected Changes Specifications

Description

The Traffic Flow Template (TFT) is a core policy and traffic management construct in 3GPP packet core networks, including GPRS, UMTS, and Evolved Packet System (EPS). It operates at the Gateway GPRS Support Node (GGSN) in UMTS or the Packet Data Network Gateway (P-GW) in EPS. A TFT is essentially a collection of up to eight packet filters (in the downlink direction) that are installed as part of a PDP context (UMTS) or PDN connection/EPS bearer (EPS). Each packet filter contains matching criteria such as source/destination IP addresses and port numbers, protocol type (e.g., TCP/UDP), IPsec Security Parameter Index (SPI), and Type of Service (TOS) field bits.

Architecturally, the TFT is created by the UE or the network (via the Policy and Charging Rules Function - PCRF) and is signaled to the gateway node (GGSN/P-GW) during PDP context activation or modification procedures. In the downlink, when a packet arrives from the external packet data network (e.g., the internet), the GGSN/P-GW performs packet classification by evaluating the packet header against all active TFT filters associated with the user's PDP contexts. The packet is then directed to the specific PDP context (and its associated radio bearer) whose TFT contains the matching filter. This creates a binding between an IP flow (e.g., a VoIP call, a video stream) and a specific bearer that has the requisite Quality of Service (QoS) characteristics (e.g., guaranteed bit rate, priority).

Its role is critical for enabling multiple simultaneous services with different QoS requirements over a single user's IP address. For example, a user can have a default bearer for best-effort internet browsing and a dedicated bearer with a TFT matching their VoIP traffic to ensure low latency and jitter. The TFT mechanism allows the network to apply distinct QoS policies, charging rules, and even routing treatments (like offload to a local breakout) on a per-service-flow basis. In the uplink direction, the UE uses the TFT packet filters to map its own outgoing IP traffic to the correct bearer. The TFT is thus the fundamental tool for implementing flow-based QoS and policy control in 3GPP networks.

Purpose & Motivation

The TFT was introduced to solve the problem of supporting multiple IP-based services, each with distinct Quality of Service (QoS) needs, within a single Packet Data Protocol (PDP) context that traditionally had only one IP address and one set of QoS parameters. Early GPRS/UMTS data services primarily offered a single 'pipe' for all traffic, which was insufficient for real-time services like Voice over IP (VoIP) or video conferencing that require guaranteed bandwidth and low delay amidst other background traffic.

The creation of the TFT, standardized from Release 99 onwards, was motivated by the vision of All-IP networks and multimedia services. It enables the network to identify and differentiate between individual traffic flows (e.g., separate TCP connections for email, web, and a VoIP stream) originating from the same user equipment. By classifying packets into flows, the network can then map each flow to a dedicated bearer with optimized QoS characteristics, a process essential for the 3GPP's standardized QoS architecture. This addressed the limitations of the earlier, service-agnostic 'best-effort' data pipe, allowing operators to offer tiered services, implement sophisticated charging models (e.g., different rates for video vs. chat), and ensure a consistent user experience for latency-sensitive applications.

Classification

Part ofQoS
Related approachesPCRF

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 3 changes

In Release 15, enhancements to the Traffic Flow Template (TFT) function included enabling TFT operations for procedures like header compression re-negotiation and PS data off. The release also introduced support for alternative GGSN addresses to separate control plane and user traffic handling. Furthermore, it provided mechanisms for the specific identification of LTE-M (eMTC) traffic within the TFT framework.

  • TFT operation for header compression re-negotiation and PS data off TS 24.301CR3082
  • Alternative GGSN addresses for control Plane and user traffic TS 29.060CR1061
  • Identification of LTE-M (eMTC) traffic TS 29.274CR1914
Rel-16 2 changes

In Release 16, the specification introduced corrections to the TFT check and removed invalid cases in error handling for TFT operations within EPS. These changes specifically refined the procedures for handling TFT-related errors to ensure more robust operation. The updates focused on the technical implementation of the TFT function without altering its fundamental role in traffic flow management.

  • Correction to TFT check TS 24.301CR3149
  • Remove invalid cases in error handling for TFT operation in EPS TS 24.301CR3350
Rel-17 1 change

In Release 17, the new work for the Traffic Flow Template (TFT) function introduced the capability for "Alternative GGSN Addresses for Control Plane and User Traffic." This enhancement allows the network to provide separate addresses for control signaling and user data traffic within the TFT parameters, specifically supporting the Selected IP Traffic Offload (SIPTO) function for efficiently routing internet traffic closer to the user's network attachment point.

  • Alternative GGSN Addresses for Control Plane and User Traffic IEs TS 29.060CR1071
Rel-18 3 changes

In Release 18, corrections and clarifications were made to the Traffic Flow Template (TFT) function, specifically addressing the handling of an empty packet filter list in 4G and the Traffic Flow Aggregate IE in relation to UE policy container delivery. The release also provided clarification for the 'No TFT operation' procedure applicable when there is no TFT for a default bearer. These updates refined the existing specifications to ensure more precise TFT operations and error handling.

  • Correction to TFT handlling for empty packet filter list in 4G TS 24.301CR3917
  • Correction in the Traffic flow aggregate IE handling in relation to the UE policy container delivery TS 24.301CR4059
  • Clarification to the 'No TFT operation' when no TFT for default bearer TS 24.301CR4087
Rel-19 1 change

In Release 19, the primary update to the Traffic Flow Template (TFT) function was a correction to its operation, as indicated by the Change Request title. The grounding context does not provide specific new technical details, procedures, or capabilities introduced for TFT in this release beyond this corrective scope. Therefore, the change is characterized as a refinement to existing TFT procedures rather than the introduction of new features.

  • Correction on TFT operation TS 24.301CR4630

Explore further

Broader topics and technologies where TFT plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.060 vj00 GPRS Service Description Stage 2 Rel-19
TS 23.207 vj00 End-to-End QoS Framework for GPRS Rel-19
TS 23.802 v1700 Enhanced End-to-End QoS Architecture Rel-7
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.301 vj60 NAS protocol for Evolved Packet System Rel-19
TS 24.302 vj00 Access to EPC via non-3GPP networks; Stage 3 Rel-19
TS 24.801 v810 CT1 SAE NAS Aspects for EPC Rel-8
TS 27.060 vj00 TE-MT Interworking for Packet Domain Rel-19
TS 29.060 vj00 GPRS Tunnelling Protocol (GTP) version 1 Rel-19
TS 29.274 vj50 GTPv2-C Control Plane Protocol Specification Rel-19
TS 34.109 vj00 UE Conformance Test Functions for UMTS Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TR 37.901 vf10 UE Application Layer Data Throughput Performance Rel-15