Description
The Mediation and Delivery Function 2 (MDF2) is a critical component within the 3GPP security architecture, specifically defined for Lawful Interception (LI) and Data Retention (DR). It operates as a mediation entity that receives intercepted communication content (CC) and intercept-related information (IRI) from various network functions, such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF) in a 5G Core network. The MDF2 is responsible for standardizing, formatting, and securely delivering this intercepted data to one or more Law Enforcement Monitoring Facilities (LEMFs) as mandated by legal authorities. Its architecture is designed to be access-agnostic, supporting interception across multiple network generations and technologies, including 5G, 4G, and non-3GPP access.
Functionally, the MDF2 receives HI2 and HI3 interface messages (for IRI and CC delivery, respectively) from the network's internal interception functions. It acts upon activation requests received via the HI1 interface from an Administration Function (ADMF). The MDF2 performs mediation tasks such as data buffering, correlation of IRI and CC for the same target, conversion into standardized formats (e.g., ETSI-standardized formats like ETSI TS 102 232), and adaptation to the specific requirements of different LEMFs. It then delivers the processed data to the LEMF over the Handover Interface HI2 (for IRI) and HI3 (for CC). The function ensures secure, reliable, and auditable delivery, maintaining the integrity and confidentiality of the intercepted data throughout the process.
Key components of the MDF2's role include its interfaces: HI1 for interception activation/deactivation, HI2 for IRI delivery, and HI3 for CC delivery. It must handle high volumes of data with low latency, especially for real-time content interception like voice calls. The MDF2 also plays a vital role in ensuring that the interception process is target-specific, minimizing data collection to only the legally authorized subjects, thereby upholding privacy principles. Its implementation is crucial for network operators to meet regulatory obligations without compromising the overall security and performance of the commercial network. In a 5G standalone architecture, the MDF2 is a logical function that can be implemented as a dedicated network element or integrated into other network functions, providing flexibility for operators.
Purpose & Motivation
MDF2 was created to address the evolving requirements for lawful interception in modern telecommunications networks, particularly with the introduction of 5G. As networks became more virtualized, cloud-native, and service-based, traditional interception methods designed for monolithic network nodes became inadequate. The purpose of MDF2 is to provide a standardized, scalable, and secure mediation function that can interface with the new 5G Core network functions (NFs) which are often deployed as software instances in a cloud environment. It solves the problem of efficiently collecting and delivering intercepted data from a disaggregated network architecture to law enforcement agencies.
Historically, lawful interception functions were often tightly integrated into specific network elements like MSCs or SGSNs. The shift to a Service-Based Architecture (SBA) in 5G, where control plane functions communicate via HTTP/2-based service interfaces (e.g., Nausf, Namf), necessitated a re-architected interception system. MDF2 provides this new mediation layer, ensuring that interception mandates can be fulfilled regardless of the underlying network software implementation or cloud infrastructure. It addresses limitations of previous approaches by being designed for agility, supporting network slicing (where interception must be per-slice aware), and handling the increased data rates and low-latency services of 5G.
Furthermore, MDF2, alongside MDF3, is specified to ensure a clear separation of concerns. While MDF2 handles the delivery of intercepted communication content and associated data, other functions handle activation and provisioning. This modular design simplifies implementation, testing, and compliance certification for network equipment vendors and operators. Its creation was motivated by the need for a future-proof interception framework that maintains regulatory compliance while supporting the technical innovations and architectural complexities of 5G and beyond.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (10 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the MDF2 function was enhanced with new procedures for initiating interception, specifically for the "Start of Interception with registered UE" and the "Start of Interception with established PDU session." Furthermore, the release introduced clarifications on the mechanisms for location information derivation and its delivery via the relevant lawful interception interfaces.
In Release 16, the MDF2 function was updated with a clarification to the trigger for the PDSR (Provisional Delivery Status Report) delivery procedure. This refinement specifically governs how and when the MDF2 sends IRI (Intercept Related Information) to the LEMF over the LI_HI2 interface. The change ensures more precise control over the delivery of intercept-related information based on specific provisioning triggers.
- Clarification to trigger for PDSR Delivery TS 33.128CR0145
In Release 17, the MDF2 function was enhanced with clarifications on ID Mapping for Location Delivery and saw the addition of new HeaderReporting options within its MediationDetails. These updates provided more specific guidance on how location information is correlated and delivered, and expanded the configurable reporting parameters available for the intercept related information (IRI) sent to the Law Enforcement Monitoring Facility.
In Release 18, the MDF2 function was updated to clarify the delivery of different services and the applicability of messaging service scoping, and to provide missing details for STIR/SHAKEN procedures. The release also introduced a solution for the delivery of RCS communication content from the CC-POI in the RCS Server to the MDF3, which interacts with the MDF2 via the LI_MDF interface. Furthermore, a correction was made to specify that the delivery of an NCGI (New Radio Cell Global Identifier) can be requested as part of the location information or intercept related information handled by the MDF2.
- Solution for the delivery of RCS CC from the CC-POI in the RCS Server TS 33.128CR0608
- Clarification on the delivery of different services and the applicability of messaging service scoping TS 33.128CR0606
- LI_XQR Ongoing Association: Correction that delivery of NCGI can be requested TS 33.128CR0615
- STIR/SHAKEN: Missing details in the MDF2 clause TS 33.128CR0392
Explore further
Broader topics and technologies where MDF2 plays a role.
Defining Specifications
3GPP specifications that define or reference MDF2, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 33.127 vj50 | Lawful Interception Architecture and Functions | Rel-19 |
| TS 33.128 vj50 | 3GPP TS 33.128: Lawful Interception Protocols | Rel-19 |