Traffic Detection Function Control plane function

Description

The Traffic Detection Function Control plane function (TDF-C) is a logical entity introduced as part of the disaggregation of the monolithic TDF. It represents the control plane component, responsible for all signaling and policy management aspects related to traffic detection. The TDF-C communicates with the Policy and Charging Rules Function (PCRF) in 4G or the Policy Control Function (PCF) in 5G over the Sd reference point (or its 5G equivalent). Its primary role is to receive, manage, and store Application Detection and Control (ADC) rules from the policy controller. These rules define what applications to detect, the detection method (e.g., signature-based, behavioral), and the required actions upon detection, such as reporting to the PCRF/PCF or instructing the user plane to gate or redirect the traffic.

Architecturally, the TDF-C is separate from the Traffic Detection Function User plane (TDF-U), which handles the actual deep packet inspection and packet forwarding. This separation follows the Control and User Plane Separation (CUPS) principle, which is a key trend in modern network design for increased scalability, independent scaling of resources, and flexibility in deployment (e.g., placing user plane functions closer to the edge). The TDF-C contains the logic for session management, rule provisioning, and event reporting. It interprets the ADC rules from the PCRF/PCF and translates them into specific configuration instructions for one or more TDF-U instances. The communication between TDF-C and TDF-U is standardized, typically using a protocol like PFCP (Packet Forwarding Control Protocol) as defined for other CUPS scenarios.

In operation, when a user session is established, the PCRF/PCF determines the need for application detection and provisions ADC rules to the TDF-C. The TDF-C then sets up the corresponding detection session on the appropriate TDF-U by installing packet detection rules (PDRs) and forwarding action rules (FARs). When the TDF-U detects the specified application traffic, it can send event reports back to the TDF-C, which then aggregates and forwards these reports to the PCRF/PCF. This allows the policy framework to make dynamic decisions based on real-time application usage. The TDF-C also handles charging-related functions, such as triggering the generation of TDF-CDRs by the charging system based on application detection events.

Purpose & Motivation

The TDF-C was introduced in 3GPP Release 14 primarily to support the industry-wide shift towards network function virtualization (NFV), software-defined networking (SDN), and Control and User Plane Separation (CUPS). The traditional, monolithic TDF combined control and user plane functions in a single physical appliance, which limited deployment flexibility, made scaling inefficient (as both planes had to scale together), and hindered innovation in the data plane. Operators needed the ability to deploy high-performance, scalable user plane functions (for DPI) independently from the control plane logic.

By separating the TDF into TDF-C and TDF-U, 3GPP addressed these limitations. It allows operators to deploy TDF-U instances in a distributed manner, for example, at the network edge for low-latency inspection, while centralizing the TDF-C for easier management and policy coordination. This separation enables more efficient resource utilization, as the control plane (TDF-C) can be scaled based on the number of sessions and policy complexity, while the user plane (TDF-U) can be scaled based on throughput and packet processing needs. It also facilitates the use of commercial off-the-shelf hardware for the user plane and cloud-native deployment for the control plane.

The creation of TDF-C was motivated by the need for greater agility in deploying new application detection services and integrating with modern orchestration and management systems. It provides a standardized way to control multiple, potentially vendor-diverse, TDF-U nodes, ensuring interoperability and simplifying network operations. This architectural evolution was a necessary step to make application-aware policy enforcement compatible with 5G core network principles and the broader trend towards disaggregated, service-based architectures.