Content for  TS 33.127  Word version:  16.4.0

Top   Top   Up   Prev   Next
0…   5…   5.4…   5.6…   6…   6.3…   7…   7.3…   7.4…   7.4.7…   7.5…   8…   A…   A.2…   A.3…   A.4…   B…


5  Functional architectureWord‑p. 13

5.1  General

The following clauses describe the high-level functional architecture for LI for 3GPP-defined services and network technologies. It describes the architectural elements necessary for LI, their roles and responsibilities, and the interfaces and interactions between them.
Clause 6 and Clause 7 of the present document describe how the LI for various 3GPP-defined network technologies and services are realised within the generic LI architecture, including associations of LI architectural elements with the network functions involved.
Not all LI architectural elements and interfaces are used in all network technologies and services.

5.2  High-level generic LI architecture

The overall conceptual view of LI architecture is shown in Figure 5.2-1 below.
Reproduction of 3GPP TS 33.127, Figure 5.2-1: A high-level generic view of LI architecture
The functional entities of the architecture are described in more detail in Clause 5.3 below. Details of the specific interfaces between these entities are described in Clause 5.4.

5.3  Functional entitiesWord‑p. 14

5.3.1  Law Enforcement Agency (LEA)

In general the LEA is responsible for submitting the warrant to the CSPs, although in some countries the warrant may be provided by a different legal entity (e.g. judiciary).

5.3.2  Point of Interception (POI)Word‑p. 15  General

The Point of Interception (POI) detects the target communication, derives the intercept related information or communications content from the target communications and delivers the POI output as xIRI to the MDF2 or as xCC to the MDF3. The output of a POI is determined by the type of the NF associated with the POI. A POI may be embedded within a Network Function (NF) or separate from a NF with which it is associated.
Multiple POIs may have to be involved in executing a warrant.
Up  Directly provisioned and triggered POIs

POIs are divided into two categories:
  • Directly provisioned POIs are provisioned by the LIPF.
  • Triggered POIs are triggered by a Triggering Function (TF) (see clause 5.3.3).
The directly provisioned POIs detect the target's communications that need to be intercepted, and then derive the intercept related information or communication contents from that target communications depending on the POI type (see clause The triggered POIs detects the target communications based on the trigger received from an associated Triggering Function and then derives the intercept related information or communication contents of target communications depending on the POI type (see clause
Up  IRI-POIs and CC-POIs

POIs are divided into two types for each category based on the type of data they send to the MDF (see clause 5.3.4):
  • IRI-POI delivers xIRI to the MDF2.
  • CC-POI delivers xCC to the MDF3.
Both IRI-POIs and CC-POIs are either directly provisioned or triggered (see clause
In the present document, an xIRI is identified with the event that has caused its generation within the IRI-POI.
Up  Failure handling

In case a network procedure involving the target UE and requiring the generation of an xIRI fails, the IRI-POI shall be able to report the failure reason available from the involved network protocol.

5.3.3  Triggering Function

The Triggering Function (TF) is provisioned by the LIPF and is responsible for triggering triggered POIs in response to network and service events matching the criteria provisioned by the LIPF. The Triggering Function detects the target communications and sends a trigger to the associated triggered POI.
As a part of this triggering, the Triggering Function shall send all necessary interception rules (i.e. rules that allow the POIs to detect the target communications), forwarding rules (i.e. MDF2, MDF3 address), target identity, and the correlation information.
A Triggering Function may interact with other POIs to obtain correlation information. Details of this interface are not specified by the present document.
The Triggering Function that triggers CC-POI is referred to as a CC-TF and the Triggering Function that triggers an IRI-POI is referred to as IRI-TF.

5.3.4  Mediation and Delivery Function (MDF)

The Mediation and Delivery Function (MDF) delivers the Interception Product to the Law Enforcement Monitoring Facility (LEMF).
Two variations of MDF are defined: MDF2 and MDF3.
MDF2 generates the IRI messages from the xIRI and sends them to one or more LEMFs. The MDF3 generates the CC from the xCC and delivers it to one or more intercepting LEMFs. An overview of this is shown in Figure 5.3-2 below.
Reproduction of 3GPP TS 33.127, Figure 5.3-2: MDF2 and MDF3
The MDF2 and MDF3 are provisioned by the LIPF with the intercept information necessary to deliver the IRI and/or CC to one or more LEMFs.
The LI_MDF interface between MDF2 and MDF3 (shown in Figure 5.3-2) allows the MDF3 and MDF2 to exchange information between the two.

5.3.5  Administration Function (ADMF)Word‑p. 16  General

The Administration Function (ADMF) provides the CSP's administrative and management functions for the LI capability. This includes overall responsibility for the provisioning/activating, modifying, and de-activating/de-provisioning the Point(s) Of Interception (POI), Triggering Functions (TF), and the Mediation and Delivery Functions (MDF).
The ADMF includes two logical sub-functions:
  • Lawful Interception Control Function (LICF).
  • Lawful Interception Provisioning Function (LIPF).
Within one ADMF there is one LICF, and at least one, but possibly multiple LIPFs.
The LICF and LIPF communicate via the internal LI_ADMF interface, the details of which are outside the scope of the present document.
The ADMF contains the issuing Certificate Authority (CA) for all LI components (POIs, MDFs etc.). Further details are defined in clause 8.3.
For further details on the roles and responsibilities of the ADMF refer to Annex B.
Up  LICFWord‑p. 17
The LICF controls the management of the end-to-end life cycle of a warrant. The LICF contains the master record of all sensitive information and LI configuration data. The LICF is ultimately responsible for all decisions within the overall LI system. The LICF, via the LIPF acting as its proxy is responsible for auditing other LI components (POIs, MDFs etc.). The LICF is responsible for communication with administrative LEA systems (LI_HI1).
The LICF provides the intercept information derived from the warrant for provisioning at the POI, TF, MDF2 and MDF3.With the exception of the communication with the LEA, all other communication between the LICF and any other entities shall be proxied by the LIPF.
The LICF also maintains and authorises the master list of POIs, TFs and MDFs. In dynamic networks the LIPF is responsible for providing the LICF with any necessary updates to the POI/TF and MDF list.

The LIPF provisions all the applicable POIs, TFs and MDFs.
The role of the LIPF varies depending on implementation of network functions and of the ADMF itself (e.g. virtual or non-virtual).
In its simplest form, the LIPF is the secure proxy used by the LICF to communicate with POIs, TFs, MDFs or other infrastructure required to operate LI within the CSP network. In this scenario the LIPF does not store target information and simply routes LI_X1 messages from and to the LICF.
In scenarios where the ADMF is required to take an active role in POI triggering, the LIPF is responsible for receiving triggering information (e.g. from an IRI-TF) and forwarding the trigger to the appropriate POI.
For directly provisioned POIs, TFs and MDFs, the LIPF will forward all LI administration instructions from the LICF to the intended destination POI, TF or MDF.
In SBA as defined in TS 23.501 or virtualised deployments, the LIPF is responsible for identifying changes to NFs, POIs, and TFs and MDFs through interaction with the SIRF or underlying virtualisation infrastructure. The LIPF shall notify the LICF of changes affecting the number of active NFs/POIs and TFs or other information which the LICF requires to maintain the master POI/TF and MDF list.
While the LIPF is assumed to be stateful with respect to dynamic interceptions it is managing, it shall not hold the full static target or other historic LI data. If the LIPF is deployed in a virtualised environment, the LIPF shall not store LI information in persistent storage and shall rely on the LICF to manage re-synchronisation in the case of LIPF restart.

5.3.6  System Information Retrieval Function (SIRF)

The System Information Retrieval Function (SIRF) is responsible for providing the LIPF with the system related information for NFs that are known by the SIRF (e.g. service topology). The information provided shall allow the LIPF/LICF to perform the necessary operations to establish and maintain interception of the target service (e.g. provisioning POIs, TFs and MDFs over LI_X1). LIPF/LICF knowledge of POI, TF and MDF existence is provided directly by interactions between the LIPF/LICF and the underlying CSP management systems that instantiate NFs (as defined in clause 5.5). The NRF/SIRF are not involved in this step of NF/POI or MDF instantiation.
While the LIPF is responsible for interactions with the SIRF, the LIPF will forward applicable information to the LICF. Details of LIPF vs LICF responsibilities in managing and maintaining interception are defined in clause 5.3.2.
As described in clause 5.6 of the present document, the OSS/BSS is responsible for managing the number of NFs within the network including the NF within which the SIRF is implemented. Therefore, the SIRF is not responsible for notifying the LIPF that a new NF, POI, TF or MDF has been instantiated (in virtualised networks) or connected to the network using manual processes (legacy networks). The LIPF is notified of these events directly by the relevant CSP management system as described in clause 5.6, prior to any interaction with the SIRF. When the SIRF subsequently notifies the LIPF that, for example an NF associated with a POI has now been registered with the SIRF, the LIPF knows that an NF and POI which it has already configured for LI usage is ready for live user traffic service.
In virtualised networks where selective per POI provisioning of target identifiers is not required, or only limited network static network slicing is in use, implementation of the SIRF is not required to allow the LIPF and LICF to meet LI requirements.

5.3.7  LEMF - Law Enforcement Monitoring FacilityWord‑p. 18
The Law Enforcement Monitoring Facility (LEMF) receives the Interception Product. The LEMF is out of scope of the present document.

Up   Top   ToC