My 33.127 Notes

5.4 LI Interfaces

5.4.13 Lawful Interception Identity Query Function (LI_IQF) Interface

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

LI_IQF is an interface between Lawful Interception Control Function (LICF) and Identity Query Function (IQF) and is used by the LICF to send management information related to Identity Event Functions (IEFs) and Identity Caching Function (ICF), to the IQF.

Further details about this interface is outside the scope of 33.127 V18.0.0 (2022-06) document.

5.4.14 Lawful Interception Internal Query Response (LI_XQR)

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

The LI_XQR interface is used by the IQF to send identifier association queries to the ICF and from the ICF to return identities associations to the IQF in response.

The following are examples of some of the information that may be passed over LI_XQR from the IQF to the ICF:

• Information relating to the type of query.
• Temporary or permanent identifier provided by the LEA.
• Other information associated with identifier required for localisation provided by the LEA.
  • Cell identity.
  • Tracking area identifier.
• Time that identifier provided by the LEA was observed by the LEA.
• Location information request from the LEA for permanent to temporary identifier association.

The following are examples of some of the information that may be passed over LI_XQR from the ICF to the IQF:

• Information relating to the type of query being responded to.
• Temporary and permanent identifiers corresponding to identifier provided by LEA.
• Identifier association validity start and end times.
• Location information.

NOTE: The location information returned in the IQF response is the information associated at the time of the specific identifier association caching at the ICF.

5.4.15 Lawful Interception Handover Interface Query Response (LI_HIQR) Interface

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

The Lawful Interception Handover Interface Query Response (LI_HIQR) interface is used by the Law Enforcement Agency (LEA) to send identifier association queries to the IQF and from the IQF to return identities associations to the LEA in response.

The following are examples of some of the information that may be passed over LI_HIQR from LEA to the IQF:

• Information relating to the type of query.
• Warrant/authorization identifier.
• Temporary or permanent identifier provided by the LEA.
• Other information associated with identifier required for localisation provided by LEA.
  • Cell identity.
  • Tracking area identifier.
• Time that identifier provided by LEA was observed by the LEA.
• Location information request for permanent to temporary identifier association.

The following are examples of some of the information that may be passed over LI_HIQR from IQF to the LEA:

• Information relating to the type of query being responded to.
• Warrant/authorization identifier.
• Temporary and permanent identifiers corresponding to identifier provided by LEA.
• Identifier association validity start and end times.
• Location information.

5.4.16 Lawful Interception Internal Event Record (LI_XER) Interface

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

The Lawful Interception Internal Event Record (LI_XER) interface is used by the IEF to send identifier association events to the ICF.

The following are examples of some of the information that may be passed over LI_XER from the IEF to the ICF:

• Permanent identifier and temporary identifier association.
• Permanent identifier and temporary identifier excommunication / de-association.
• Time stamp of association observation.
• Location information.

5.4.17 Lawful Interception Internal Event Management 1 (LI_XEM1) Interface

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

The LI_XEM1 interface is used by the LICF (proxied by the LIPF) to manage and control the activation state of the IEF(s) and ICF.

LI_XEM1 interfaces shall support the use of ETSI TS 103 221-1 for transport of XEM1 messages / information. However, the requirements specified in the present document shall apply regardless of generic default options specified in ETSI TS 103 221-1.

5.7 Identifier association and reporting

Added in 3GPP TS 33.127 V16.6.0 (2020-12)

5.7.1 General

3GPP networks use temporary identifiers in place of permanent identifiers to ensure that identities which are visible on exposed interfaces (e.g. RAN) cannot be used to track or degrade the privacy of a subscriber. For LI purposes, CSPs are required to be able to provide real-time association between temporary and permanent identifiers where the use of such identifier associations impact the ability of the LEA to uniquely identify the UE, subscriber or true permanent identifiers associated with a service.

33.127 defines two sets of capabilities which allow CSPs to report such association to LEAs:

• Real-time reporting of associations as observed by POIs as part of network access, target communications and service usage.
• Dedicated real-time query, lookup and reporting of identifier associations.

For real-time reporting based on POI observation, associations are reported through a combination of dedicated event records sent from the POI to the MDF over LI_X2 and through inclusion of specific parameters in other communications service records reported over LI_X2.

For dedicated query, lookup and reporting, the following figure shows the high-level architecture used to support identifier association query and response requirements. The Identifier Event Function (IEF) provides the Identifier Caching Function (ICF) with the events necessary to answer the identifier association queries from the IQF. LEAs are able to issue real-time queries to the Identifier Query Function (IQF), which in turn queries the ICF.

The IQF and ICF shall support the following query types:

• Single query and response.
• Single query and response followed by triggered real-time reporting of any subsequent changes reported to the ICF (see NOTE 2).

Within 33.127 V18.0.0 document, only a single ICF for all IEFs is supported.

Within 33.127 V18.0.0 document, interfaces and generic functionality for dedicated identifier query and response are defined in this clause, while specific instances of the IEFs are defined within clause 6 and the ICF in clause 7. For each request over LI_HIQR, the LEA shall provide a legal warrant/authorisation unique identifier. In addition, depending on the scenario, the LEA needs to provide, the observed identity (temporary or permanent), along with the serving cell identity, tracking area identifier, and time of observation by LEA.

The IQF shall obtain in real-time the identifier associations which match the LEA query from the ICF and provide a response to the LEA over LI_HIQR. In some cases, it may not be possible to establish a single unique identifier association given the information provided by the LEA. IQF handling in such a scenario is subject to the authorisation in the warrant and is outside the scope of the present document.

NOTE 1: If the LEA is unable to provide the tracking area associated with an observed temporary identifier this may prevent the CSP from uniquely associating the identifier to the correct UE.

NOTE 2: Single query and response followed by triggered real-time reporting of any subsequent changes detected by the IEF is only applicable to queries based on a permanent identifier where the changes reported are new temporary identifiers to which that permanent identifier has been associated.

NOTE 3: The terms identifier and identity are used interchangeably in clause 5.7. This also applies to the naming of functions like IQF.

5.7.2 Functional entities

5.7.2.1 Identity Query Function (IQF)

The IQF is the function responsible for receiving and responding to dedicated LEA real-time queries for identifier associations. The IQF is a sub-function of the ADMF. On receiving a valid query, the IQF shall query the ICF in order to obtain the required mapped identities. The IQF shall be able to support both association from permanent identifiers to temporary identifiers and from temporary identifiers to permanent identifiers.

NOTE 1: Only queries based on applicable subscription permanent identifiers or associated temporary identifiers are supported by the present document. Queries based on ME hardware identifiers or communications services identifiers (e.g. E.164 numbers) are not supported by the IQF.

NOTE 2: A specific query response to the LEA may require both permanent and temporary identifiers to be returned in a single response for a given query. For example, if an LEA queries using a temporary identifier, then it may be necessary to respond with a permanent identifier, plus other associated temporary identifiers in order to fulfil the query.

The IQF shall only support queries that are received from the LEA within the caching duration and shall reject any queries from the LEA which fall outside those time limits.

NOTE 3: It may not always be possible for the CSP to provide an answer due to association information no longer being available in the network. The IQF shall provide support for multiple LEA scenarios. The IQF shall be able to support different query constraints for different LEAs.

NOTE 4: Since IEF event generation and ICF temporary caching applies to all UEs served by the parent NF, any multiple LEA scenarios or differences in requirements are handled by the IQF only and no specific support is provided by IEF or ICF.

The IQF shall support both query and response types as defined in clause 5.7.1.

5.7.2.2 Identity Event Function (IEF)

The IEF is the function responsible for observing and detecting identifier association changes within its parent NF and providing those changes in the form of event records to the ICF over LI_XER. IEFs may be co-located with POIs but may also be placed in other NFs where the NFs handling identifier association do not otherwise support POI functionality.

The IEF shall be able to provide event records to the ICF when associations are updated. Association events include both allocation or deallocation events for temporary identifiers managed by the IEF’s parent NF and for identifier associations which are registered or deregistered in the IEF's parent NF but the identifier allocation is not controlled by that NF.

The IEF shall support activation and deactivation of IEF association reporting capabilities, as controlled by the LICF (proxied by the LIPF) over the LI_XEM1 interface. When IEF reporting capabilities are activated, the IEF shall obtain the current allocation and registration state of all UEs known to the parent NF, (where that information has been retained in the NF as part of normal network operations) and send this as a series of allocation/registration events to the ICF.

NOTE: The IEF can only report on associations that occurred before activation of the IEF if those associations remain valid for UEs which are still served by the parent NF (some allocations may not be retained by the parent NF).

Therefore, not all UE identifier associations may be available at IEF activation (e.g. due to NF or UE mobility) and therefore ICF caching may be incomplete until network reauthentication timers or similar reallocation timers have refreshed all served UEs as part of normal network operation. Such incomplete data will result in no matching identifier responses from the ICF.

When IEF reporting capabilities are deactivated, the IEF shall immediately stop sending event records to the ICF.

5.7.2.3 Identity Caching Function (ICF)

The ICF is the LI function responsible for caching of identifier associations provided by the IEF in event records received over the LI_XER and answering queries from the IQF received over LI_XQR. The ICF shall support association queries from both temporary identities to permanent identities and from permanent identities to temporary identities.

The ICF shall store identifier associations received from the IEF and hold them indefinitely as active associations until:

• A new association event is received which updates a previous association.
• A disassociation event is received for a stored association.
• A CSP defined maximum age is reached.

Upon receiving a disassociation event or a new association event from the IEF, the ICF shall match any corresponding identifier associations, mark them for deletion and begin the cache time for that association. After being marked for deletion, associations shall be deleted and purged irrecoverably from the ICF once their cache time limit is reached.

NOTE: The cache time limit after which automatic deletion should occur is outside the scope of the present document. However, this CSP determined value needs to be no shorter than the maximum allowed query delay (i.e., the time from the identity observation by the LEA to the query reception by the CSP). Otherwise, this value needs to be as short as possible.

The ICF shall support both query and response types as defined in clause 5.7.1. For the on-going triggered response query type, after sending the initial response, the ICF shall send a further response each time the permanent identifier provided in the initial query is associated or de-associated with a temporary identifier until the IQF deprovisions the query in the ICF.

The ICF shall support immediate deletion of identifier associations received in events for one or more IEF(s) when requested to do so by the LICF (proxied by the LIPF) over LI_XEM1.

7.3 Location of 7 Service layer based interception

From 3GPP TS 33.127 V16.0.0 (2019-06)

7.3.4 Cell database information reporting

When a cell identity is provided for the target's location in IRI, the Communication Service Provider (CSP) may also provide Cell Site Information (CSI) for the reported cell identity. The MDF2 may retrieve CSI by access to a CSP maintained database (referred to as CSP Cell Database) as shown in figure 7.3.4-1. When using CSI supplemental reporting and the CSP cannot deliver via IRI messages generated from the xIRI, the MDF2 shall generate a Cell Site Report (CSR) for location information specific to the cell identity reported.

The following information shall be delivered when CSI is provided in IRI or a MDF2 generated CSR:

• LIID.
• Cell identity.
• Date/time(s) established by MDF2.
• Cell supplemental information.

If CSI for a cell identity has been previously reported to the LEMF for the current interception, and if allowed by CSP-LEA mutual agreement, the CSP may not need to resend this specific CSI, unless it has changed.

If the CSP does not support CSR or CSI, the database can be provided by non-real-time means.

7.7 Identity Caching Function

7.7.1 General

The ICF is responsible for receiving identity caching events from all IEFs in the network over the LI_XER interface and handling queries from the IQF over the LI_XQR interface to the IQF as defined in clause 5.7.

The temporary cache duration shall be configurable by the LICF on a per CSP network basis.

NOTE: The terms identifier and identity are used interchangeably in clause 7.7. This also applies to the naming of functions like IQF.

7.7.2 ICF Query Identities

The IQF present in the ADMF shall be able to query the records held by the ICF using one of the following target identifiers:

• SUPI.
• SUCI.
• 5G-S-TMSI.
• 5G-GUTI.

NOTE: Targeting based on GPSI, PEI, IMS identifiers or other legacy identifiers (e.g. MSISDN) is not supported by the present document.

The list of event parameters is specified in TS 33.128. Each event shall include at the minimum the following information:

• Query target identifier.
• Time of target identifier observation.

For queries based on temporary identifiers the following additional information shall be included:

• Tracking area identifier.
• Cell identity.

7.7.3 ICF Response parameters

The list of event parameters is specified in TS 33.128. Each event shall include at the minimum the following information:

• Subscription permanent identifier.
• Related temporary identifier(s).
• Start of validity timestamp(s).
• End of validity timestamp(s).

The following additional information shall be included if it was available in the IEF records provided to the ICF:

• Permanent equipment identifier (PEI).
• Generic Public Subscription Identifier (GPSI).

The following additional information shall be included when available and if requested in the IQF to ICF query:

• Location information (i.e. Cell identity and tracking area identifier).

7.7.4 Network topologies

Since the ICF caches events independently of network topology for individual service usage UEs, no specific network topology handling is provided by the ICF. The IQF shall be responsible for handling any network topology requirements that may be applied by the LEA in an individual warrant.

To Telecommunications info