Editing My 33.127 Notes (section)

== 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.

<center>[[File:High-level ID-Retrieval-via-Query-Response.png|High-level ID-Retrieval-via-Query-Response diagram]]</center>

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. <span style="color:red">The IQF shall be able to support both association from permanent identifiers to temporary identifiers and from temporary identifiers to permanent identifiers.</span>

: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.