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.
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.
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 184.108.40.206). The triggered POIs detect 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 220.127.116.11).
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 18.104.22.168).
In the present document, an xIRI is identified with the event that has caused its generation within the IRI-POI.
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.
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.
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.
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 is also responsible for managing the Identifier Event Functions (IEF) and Identifier Caching Function (ICF). The ADMF is also responsible for controlling and managing the Location Acquisition Requesting Function (LARF).
The ADMF includes the following logical sub-functions:
Lawful Interception Control Function (LICF).
Lawful Interception Provisioning Function (LIPF).
Identifier Query Function (IQF).
Certificate Authority (CA).
Location Acquisition Function (LAF).
Within one ADMF there is one LICF, one IQF, one LAF, 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 LICF and LAF communicate via the internal LI_LAFC interface, the details of which are outside the scope of the present document.
The LIPF and LAF communicate via the internal LI_LAFP 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.
The IQF is used for handling identifier association requests. Further details are defined in clause 5.7.
The LAF is used for handling location acquisition requests. Further details are defined in clause 7.3.5.
For further details on the roles and responsibilities of the ADMF refer to Annex B.
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, IEFs, ICF, TFs, MDFs, and LARFs. In dynamic networks the LIPF is responsible for providing the LICF with any necessary updates to the POI, TF, IEF, ICF, MDF, and LARF list.
The LICF is responsible for management and audit of the IEF(s) and ICF proxied by the LIPF.
The LICF shall support activating and deactivating of IEF identifier association reporting capabilities on a per IEF basis proxied by the LIPF.
The LICF shall provide the IQF with information relating to IEFs and ICF necessary for the IQF to handle queries from the LEA and obtain answers to such queries.
If the LICF deactivates event record reporting to an IEF, the LICF shall also instruct the ICF to immediately delete all cached identifier associations which the ICF had received from that IEF.
The LICF shall ensure that the ICF is always activated before IEFs and de-activated after IEFs to ensure that data loss does not occur due to an IEF sending events before an ICF is configured to receive them.
The LICF shall provide the LAF with information necessary for the LAF to handle location acquisition queries from the LEA and obtain answers to such queries.
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.
The LICF and LIPF shall support selective management and provisioning of groups of POIs, TFs and IEFs, based on the warrant parameters (e.g., service scope, target identities), the target UE type and profile (e.g. a smartphone, a CIoT device) and the CSP's network deployment architecture and services implementation (e.g. Slicing, MEC and URLLC enablers, etc.), with the purpose of optimizing the LI system operation and avoiding its over-provisioning. This selective management and provisioning shall apply independently of architectural alternatives in clause 8.2.
The selective management and provisioning of LI functions may be supported by ADMF's GUI configuration capabilities, as well as by ADMF's ability to obtain and use the CSP network data to drive its provisioning decisions.
The following are examples of the ADMF's configuration capabilities:
Single or multiple POIs or TFs or IEFs.
Groups of one or more POIs, TFs, and IEFs of a specific parent NF type.
POIs, TFs, and IEFs associated with NFs in a specific slice.
POIs, TFs, and IEFs independently where they are contained in the same parent NF.
Enabling only specific services or features of POIs (individually and in groups).
Selective provisioning shall be supported on a per warrant basis.
The Location Acquisition Function (LAF) is responsible for processing the location requests received from the LEA during the location acquisition procedure. Further details of the LAF are defined in clause 7.3.5.
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.
The Location Acquisition Requesting Function (LARF) is a function associated with the AMF responsible for handling the location requests from the LAF during the location acquisition procedure. Further details of the LARF are defined in clause 7.3.5.