Content for TS 33.127 Word version: 18.6.0

0… 5… 5.4… 5.6… 5.7… 6… 6.2.2… 6.2.3… 6.2.5… 6.3… 6.3.3… 6.3.4… 6.4… 7… 7.3… 7.4… 7.4.7… 7.5… 7.6… 7.7… 7.8… 7.9… 7.10… 7.11… 7.12… 7.13… 7.14… 7.15… 7.16… 8… A… A.2… A.3… A.4… B… D… E…

5.7 Identifier association and reporting 5.7.1 General 5.7.2 Functional entities 5.7.2.1 Identity Query Function (IQF) 5.7.2.2 Identity Event Function (IEF) 5.7.2.3 Identity Caching Function (ICF)
...

5.7 Identifier association and reporting p. 38

5.7.1 General p. 38

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.

The present document 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, Figure 5.7-1 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.

Copy of original 3GPP image for 3GPP TS 33.127, Fig. 5.7-1: High-level identifier retrieval via Query and Response.

Figure 5.7-1: High-level identifier retrieval via Query and Response.
(⇒ copy of original 3GPP image)

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 the present document, only a single ICF for all IEFs is supported.

Within the present 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.

5.7.2 Functional entities p. 39

5.7.2.1 Identity Query Function (IQF) p. 39

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.

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.

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

5.7.2.2 Identity Event Function (IEF) p. 40

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.

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) p. 40

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.

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.