Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.128  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M…

 

4  Generalp. 26

4.1  Introductionp. 26

The present document provides details of the internal and external interfaces required for a network operator, access provider and/or service provider to provide the necessary information to a Law Enforcement Agency (LEA) required to meet LI requirements. LI requirements for 3GPP networks and services are given in TS 33.126.
The high-level architecture that defines the necessary interfaces is specified in TS 33.127. The generic high-level interception architecture is as follows:
Reproduction of 3GPP TS 33.128, Fig. 4.1-1: High-level interception architecture diagram with key point-to-point LI interfaces
Up
The generic high-level acquisition architecture is as follows:
Reproduction of 3GPP TS 33.128, Fig. 4.1-2: High-level acquisition architecture diagram with key point-to-point LI interfaces
Up
The specification of the interfaces is split into two parts:
  • Internal interfaces used between an operator's network functions are described in clause 4.2.
  • External interfaces used in communicating with a LEA are described in clause 4.3.

4.2  Basic principles for internal interfacesp. 28

This clause lists the internal interfaces shown in clause 4.1, indicates the protocol used to realise each interface, and gives a reference to the relevant clauses of the present document that specify how the protocol is to be used for the given interface.
Interface Description Protocol used to realise interface Usage
LI_ADMFUsed to pass intercept provisioning information form the LICF to the LIPF.Out of scope of the present document.
LI_IQFUsed to pass information related to IEFs and ICF to IQF.Out of scope of the present document.
LI_LAFCUsed to pass information from LICF to LAF.Out of scope of the present document.
LI_LAFPUsed to pass information from LIPF to LAF.Out of scope of the present document.
LI_MDFUsed by MDF2 and MDF3 in interactions necessary to correctly generate CC and IRI from xCC and xIRI.Out of scope of the present document.
LI_SIUsed to provide system information to the LIPF from the SIRF.Out of scope of the present document.
LI_STUsed to transfer LI state information to and from the LISSF.TS 29.598. See clauses 5.10 and 6.2.3.10
LI_T2Used to pass triggering information from the IRI-TF to a Triggered IRI-POI. ETSI TS 103 221-1 [7].See clause 5.2.4
LI_T3Used to pass triggering information from a CC-TF to a Triggered CC-POI. ETSI TS 103 221-1 [7].See clause 5.2.4
LI_X1Used to configure and audit Directly-provisioned POIs, TFs and MDFs. ETSI TS 103 221-1 [7].See clause 5.2.2
LI_X1 (Mana­gement)Used to audit Triggered POIs. ETSI TS 103 221-1 [7].See clause 5.2.3
LI_X2Used to pass xIRI from IRI-POIs to the MDF2. ETSI TS 103 221-2 [8].See clause 5.3.2
LI_X2_LAUsed to pass xIRI from LARF to the MDF2 ETSI TS 103 221-2 [8].See clause 5.3.5
LI_X3Used to pass xCC from CC-POIs to the MDF3. ETSI TS 103 221-2 [8].See clause 5.3.3
LI_XEM1Used by the LICF/LIPF to manage IEFs and ICF. ETSI TS 103 221-1 [7].See clause 5.2.7
LI_XERUsed to pass identifier association event records from IEFs to ICF.See Clause 5.9. See clause 5.9
LI_XLAUsed to send the location acquisition requests from LAF to LARF and used by the LARF to send the location acquisition responses to the LAF. ETSI TS 103 221-1 [7].See clause 5.12
LI_XQRUsed to pass queries from IQF to ICF and responses from ICF to IQF. ETSI TS 103 221-1 [7].See clause 5.8
Up

4.3  Basic principles for external handover interfacesp. 29

This clause lists the external handover interfaces shown in clause 4.1, indicates the protocol used to realise each interface, and gives a reference to the relevant clauses of the present document that specify how the protocol is to be used for the given interface.
Interface Description Protocol used to realise interface Usage
LI_HI1Used to send warrant and other interception request information from LEA to operator. ETSI TS 103 120 [6] shall be supported.
Other methods (e.g. manual exchange) may be used depending on national regulatory requirements.
See clause 5.4
LI_HI2Used to send IRI from the MDF2 to the LEMF. ETSI TS 102 232-1 [9] and ETSI TS 102 232-7 [10] shall be supported.See clause 5.5
LI_HI3Used to send CC from the MDF3 to the LEMF. ETSI TS 102 232-1 [9] and ETSI TS 102 232-7 [10] shall be supported.See clause 5.5
LI_HI4Used to send LI notification information from MDF2/MDF3 to LEMF. ETSI TS 102 232-1 [9] and ETSI TS 102 232-7 [10] shall be supported.See clause 5.6
LI_HILAUsed to send the location acquisition requests from LEA to CSP and used by the CSP to send the location acquisition responses to the LEA. ETSI TS 103 120 [6] shall be supported.See clause 5.11
LI_HIQRUsed to send warrant and other identifier association query information from LEA to CSP and used by the CSP to send query responses to the LEA. ETSI TS 103 120 [6] shall be supported.See clause 5.7
Up

4.4  Service scopingp. 30

4.4.1  Generalp. 30

The interception product shall be delivered to the LEMF over LI_HI2 and LI_HI3, observing the service scoping described in the following clauses.

4.4.2  CSP service typep. 30

The LIPF shall be able to provision the POIs, TFs and MDF2/MDF3 according to the requirements of the warrant with the following CSP service type(s):
  • Voice.
  • Data.
  • Messaging (e.g. SMS/MMS).
  • Push-to-Talk (including MCPTT).
  • LALS (the Target Positioning service, per clause 7.3.3.2 of TS 33.127).
  • RCS.
When multiple service types are applicable to a target due to multiple warrants, the MDF2/MDF3 shall be able to deliver interception product to each LEMF based on the CSP service type(s) of the respective warrant.
When no service type is provisioned, the POIs shall generate and deliver applicable interception product for all services specified for the NF where the POI is located.
When no service type is provisioned, the MDF2/MDF3 shall deliver all interception product it receives from the POIs.
Up

4.4.3  Delivery typep. 30

  • IRI.
  • CC.
  • IRI and CC.
The LIPF shall be able to provision the POI, TF and the MDF2/MDF3 according the delivery type(s) applicable to a warrant.
When different delivery types are applicable to a target due to multiple warrants, the MDF2/MDF3 shall be able to deliver IRI/CC to each LEMF based on the delivery type(s) of the respective warrant.

4.4.4  Location Reportingp. 31

The LIPF shall be able to provision the POIs and MDF2 according to the requirements of the warrant with the following location reporting types:
  • Report location only at the beginning and end of a session.
  • Do not report location.
When no location reporting type is provisioned, the POIs and MDF2/MDF3 shall report location every time the target location information is received at the POI (including location update with no physical change of location).
When different location reporting types are applicable to a target due to multiple warrants, then POI may be provisioned as if the reporting of all location information occurrences at the POI is required, with MDF2 restricting the delivery of location to the LEMF as per the provisioned information for a warrant.
Up

4.4.5  LALS Triggeringp. 31

The LIPF shall be able to provision the LTF associated with a POI or MDF2 with the LALS triggered location service parameters provided in the warrant or use a default set of parameters.

4.4.6  Roaming Interceptionp. 31

  • Stop interception when the target is roaming outbound internationally.

Up   Top   ToC