Editing My 33.127 Notes (section)

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