My 33.128 Notes
4.2 Basic principles for internal interfaces
This grid lists internal interfaces associated to identity mapping and indicates the protocol used to realize each interface, and gives a reference to the relevant clauses of the 3GPP TS 33.128 V18.0.0 (2022-06) document that specify how the protocol is to be used for the given interface.
| Interface | Description | Protocol used to realize interface | Usage |
|---|---|---|---|
| LI_ADMF | Used to pass intercept provisioning information form the LICF to the LIPF. | Out of scope of the V18.0.0 document. | |
| LI_IQF | Used to pass information related to IEFs and ICF to IQF. | Out of scope of the V18.0.0 document. | |
| LI_XEM1 | Used by the LICF/LIPF to manage IEFs and ICF. | ETSI TS 103 221-1 | See clause 5.2.7 |
| LI_XER | Used to pass identifier association event records from IEFs to ICF. | See Clause 5.9 | See Clause 5.9 |
| LI_XQR | Used to pass queries from IQF to ICF and responses from ICF to IQF. | ETSI TS 103 221-1 | See Clause 5.8 |
4.3 Basic principles for external handover interfaces
This grid lists the external handover interfaces (HI) associated to identity mapping shown in clause 4.1, indicates the protocol used to realize 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 realize interface | Usage |
|---|---|---|---|
| LI_HI1 | Used to send warrant and other interception request information from LEA to operator. | ETSI TS 103 120 shall be supported. Other methods (e.g. manual exchange) may be used depending on national regulatory requirements. | See clause 5.4 |
| LI_HIQR | Used 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 shall be supported. | See clause 5.7 |
5.2 Protocols for LI_X1 and LI_T interfaces
5.2.7 Usage for realising LI_XEM1
The IEF shall be enabled by sending the following ActivateTask message from the LIPF.
The IdentityAssociationTargetIdentifier Identifier Type is defined for the use of LI_XEM1. Unless otherwise specified, use of any other Target Identifier Type (including adding a target identifier more than once) shall result in the ActivateTask message being rejected with the appropriate error.
The IEF may be reconfigured to send identity associations to a different ICF using a ModifyTask message to modify the delivery destinations.
The IEF shall be disabled by sending the following DeactivateTask message from the LIPF.
The LIPF should send one ActivateTask command to each IEF.
- NOTE: The IEF may receive multiple ActivateTask messages conforming to LI_XEM1 ActivateTask, each of which can be independently deactivated. The IEF shall remain active as long as at least one valid Task remains active.
5.7 Protocols for LI_HIQR
5.7.1 General
Functions having an LI_HIQR interface shall support the use of ETSI TS 103 120 to realise the interface. My ETSI TS 103 120 Notes
In the event of a conflict between ETSI TS 103 120 and 33.128 document, the terms of 33.128 document shall apply.
- NOTE: The terms identifier and identity are used interchangeably in clause 5.7.
5.7.2 Usage for realising LI_HIQR
5.7.2.1 Request structure
LI_HIQR requests are represented by issuing a CREATE request for an LDTaskObject (see ETSI TS 103 120 clause 8.3). LDTaskObject is populated as follows:
| Field | Value | M/C/O |
|---|---|---|
| Reference | Reference to the authorization under which the request is made. The format of this field, and any procedures for allocating or validating it, are for national agreement. | M |
| DesiredStatus | Shall be set to "AwaitingDisclosure". | M |
| RequestDetails | Set according to RequestDetails structure grid below. | M |
| DeliveryDetails | Shall be set to indicate the delivery destination for the LI_HIQR records (see clause 5.7.2.3 and ETSI TS 103 120 clause 8.3.6.2) unless the delivery destination is known via other means. | M |
The use of any other LDTaskObject parameter is outside the scope of 33.128 V18.0.0 (2022-06).
| Type | Value | M/C/O |
|---|---|---|
| Type | Shall be set to one of the RequestType values listed in RequestType Dictionary for LI_HIQR grid below. | M |
| ObservedTime | When the RequestValues provides a temporary identity, this field shall be set to the observation time of that temporary identity.
When the RequestValues provides a permanent identity, this is the time at which the LEA requires that the permanent to temporary association is applicable. Shall not be present for requests of type "OngoingIdentityAssociation". |
C |
| RequestValues | Set to the target identifier plus additional information required (see clause 5.7.2.2 Request Parameters). | M |
- NOTE: If the observed time is in the past, providing a successful query response is subject to associations still being available in the cache when the query is made to the ICF.
| Dictionary Owner | Dictionary Name |
|---|---|
| 3GPP | RequestType |
| Value | Meaning |
|---|---|
| IdentityAssociation | A request for a single IdentityResponseDetails response to the query provided. |
| OngoingIdentityAssociation | A request for an ongoing series of IdentityResponseDetails responses matching the query provided. May only be used when the RequestValues contains a permanent identifier. The request shall be terminated by updating the LDTaskObject DesiredStatus to "Disclosed". |
Grid Defined DictionaryEntries is formatted in accordance with ETSI TS 103 120 Annex F.
5.7.2.2 Request parameters
The RequestValues field, a field within RequestDetails structure of LI_HIQR LDTaskObject, shall contain one of the following:
- SUPI, given in either SUPIIMSI or SUPINAI formats as defined in ETSI TS 103 120 clause C.2.
- SUCI, given as defined in grid below (table 5.7.2-4 in spec)
- 5G-S-TMSI, given as defined in grid below (table 5.7.2-4 in spec)
- 5G-GUTI, given as defined in grid below (table 5.7.2-4 in spec)
If the RequestType is "OngoingIdentityAssociation" (see table 5.7.2-3 in spec), SUPI is the only valid identity type in the RequestValues field. If the RequestType is "OngoingIdentityAssociation" and any other identity type is provided, the IQF shall signal the error by setting the LDTaskObject Status to "Invalid" (see ETSI TS 103 120 clause 8.3.3).
If a temporary identity is provided, the following shall also be present as RequestValues:
- NRCellIdentity, given as defined in grid below (table 5.7.2-4 in spec)
- TrackingAreaCode, given as defined in grid below (table 5.7.2-4 in spec)
The following RequestValue FormatTypes (see ETSI TS 103 120 clause 8.3.5.4) are defined (which are not otherwise defined outside 33.128).
| Format Owner | Format Name | Description | Format |
|---|---|---|---|
| 3GPP | SUCI | Subscription Concealed Identifier as per TS 23.003 clause 2.2B. | From TS 29.509 V18.0.0 clause 6.1.6.3.2: String containing a SUCI.
Pattern: " |
| 3GPP | 5GSTMSI | Shortened form of the 5G-GUTI as defined in TS 23.003 clause 2.11.
Given as a hyphen-separated concatenation of:
|
Matches regular expression:
|
| 3GPP | 5GGUTI | As defined in TS 23.003 clause 2.10. Given as a hyphen separated concatenation of:
|
Matches regular expression:
|
| 3GPP | NRCellIdentity | NR Cell ID (NCI), as defined in TS 23.003 clause 19.6A | TS 29.571 clause 5.4.2 |
| 3GPP | TrackingAreaCode | Tracking area code as defined in TS 23.003 clause 19.4.2.3 | TS 29.571 clause 5.4.2 |
5.7.2.3 Response structure
The LI_HIQR request is used to generate a request to the ICF over LI_XQR (see clause 5.8). The response received over LI_XQR is then transformed into an LI_HIQR response.
LI_HIQR responses and updates are represented as XML following the IdentityResponseDetails type definition (see Annex E).
Responses and updates are delivered within a DELIVER Request (see ETSI TS 103 120 clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 clause 10).
IdentityResponseDetails contain IdentityAssociation records. The fields of each IdentityAssociationRecord shall be set as follows:
| Field | Value | M/C/O |
|---|---|---|
| SUPI | SUPI associated with the provided identity. | M |
| SUCI | SUCI associated with the provided identity, if available. | C |
| 5G-GUTI | 5G GUTI associated with the provided identity, provided in the form given in the request (see table 5.7.2-4). | M |
| PEI | PEI associated with the provided identity during the association period, if known. | C |
| AssociationStartTime | The time that the association between the SUPI and the temporary identity became valid. (see NOTE). | M |
| AssociationEndTime | The time that the association between the SUPI and the temporary identity ceased to be valid. Shall be omitted if the association is still valid (see NOTE). | C |
| FiveGSTAIList | List of tracking areas associated with the registration area within which the UE was or is registered in the lifetime of the reported association, if available. See clause 7.6.2.4 for details. | C |
| GPSI | GPSI associated with the provided identity during the association period, if known. | C |
- NOTE: The AssociationStartTime and AssociationEndTime represent the lifespan of the SUPI to 5G-GUTI association. When a SUCI is present, the AssociationStartTime also represents the time of the SUCI's validity.
If no association is found which matches the criteria provided in the LI_XQR request, then the LI_XQR response contains zero IdentityAssociationRecords. Similarly, the LI_HIQR response contains zero IdentityAssociationRecords.
For responses or updates providing a currently valid SUPI to 5G-GUTI identity association, the AssociationEndTime shall be absent. The AssociationStartTime shall indicate when the 5G-GUTI became associated with the SUPI. The SUCI field shall be populated if it was present in the IEF record for the association (see clause 6.2.2A.2.1). The PEI and TAI List fields may be populated as well, see clause 7.6.2.4 for details.
In the case of ongoing updates, the presence of the AssociationEndTime indicates the SUPI to 5G-GUTI identity disassociation. Such updates shall only happen when no new association is replacing the outgoing one.
The DeliveryObject Reference field (see ETSI TS 103 120 clause 10.2.1) shall be set to the Reference of the LDTaskObject used in the request, to provide correlation between request and response. The DeliveryID, SequenceNumber and LastSequence fields shall be set according to ETSI TS 103 120 clause 10.2.1.
The content manifest (see ETSI TS 103 120 clause 10.2.2) shall be set to indicate the present document, using the following Specification Dictionary extension.
| Dictionary Owner | Dictionary Name |
|---|---|
| 3GPP | ManifestSpecification. |
| Value | Meaning |
|---|---|
| LIHIQRResponse | The delivery contains IdentityResponseDetails (see Annex E) |
5.8 Protocols for LI_XQR
5.8.1 General
LI_XQR requests are realised using ETSI TS 103 221-1 to transport the IdentityAssociationRequest and IdentityAssociationResponse messages (which are derived from the X1RequestMessage and X1ResponseMessage definitions in ETSI TS 103 221-1) as described in Annex E.
- NOTE: The terms identifier and identity are used interchangeably in clause 5.8.
5.8.2 Identity association requests
For requests with RequestType "IdentityAssociation" (see table 5.7.2-3), the IQF issues an IdentityAssociationRequest message populated with a RequestDetails structure as follows:
| ETSI TS 103 221-1 field name | Description | M/C/O |
|---|---|---|
| Type | Shall be set to the RequestType value "IdentityAssociation" as defined in Table 5.7.2-3. | M |
| ObservedTime | Observation time as provided over LI_HIQR (see clause 5.7.2). | M |
| RequestValues | Set to the target identifier plus additional information specified in the LI_HIQR request (see clause 5.7.2). | M |
Successful LI_XQR responses are returned using the IdentityAssociationResponse message. Error conditions are reported using the normal error reporting mechanisms described in TS 103 221-1.
LI_XQR query responses are represented in XML following the IdentityAssociationResponse schema (see Annex E). The fields of the IdentityAssociationResponse record shall be populated as described in Table 5.7.2-5.
5.8.3 Ongoing identity association requests
For requests with RequestType "OngoingIdentityAssociation", the IQF shall activate a request for ongoing updates at the ICF by sending it an ActivateOngoingIdentityAssociationUpdates message populated as follows:
| Field name | Description | M/C/O |
|---|---|---|
| OngoingAssociationTaskID | Unique identifier for this request allocated by the IQF. | M |
| SUPI | Permanent identifier for which ongoing identity association updates shall be issued. | M |
The ICF shall acknowledge the receipt of the ActivateAssociationUpdates message by responding with an ActivateAssociationUpdatesAcknowledgement response (see Annex E) containing an IdentityAssociationRecord representing the association active at the time the ICF receives the ActivateAssociationUpdates message. If no such active association exists, the ActivateAssociationUpdatesAcknowledgement response shall not contain an IdentityAssociationRecord. Error conditions are reported using the normal error reporting mechanisms described in ETSI TS 103 221-1.
When a request with RequestType "OngoingIdentityAssociation" is terminated over LI_HIQR (see table 5.7.2-3), the IQF shall issue a DeactivateAssociationUpdates message (see Annex E) with the appropriate OngoingAssociationTaskID populated. On termination of the request, the ICF shall respond with a DeactivateAssociationUpdatesAcknowledgement message.
While a request with RequestType "OngoingIdentityAssociation" is active, the ICF shall generate an IdentityAssociationUpdate message every time the ICF receives an IEFAssociationRecord or IEFDeassociationRecord over LI_IEF for the relevant identifier. The message shall contain an IdentityAssociationRecord as described in table 5.7.2-5, and the relevant OngoingAssociationTaskID. The IdentityAssociationUpdate message is sent to the IQF over LI_XQR with the ICF becoming the "requester" as defined in ETSI TS 103 221-1 clause 4.2. The IQF shall respond with an IdentityAssociationUpdateAcknowledgement message.
5.9 Protocols for LI_XER
LI_XER records are realised using a TLS connection as defined in clause 6.2.2A.2.3, with records BER-encoded as defined in Annex F.
6.2 5G
6.2.2 LI at AMF
See 33.128 § 6.2.2.2.7 AMF identifier association for details of how AMF reports subscription identifier associations.
Summary is that the IRI-POI present in the AMF shall generate an xIRI containing an AMFIdentifierAssociation record when the IRI-POI present in the AMF detects a new identifier association for a UE matching one of the target identifiers provided via LI_X1. Generation of this record is subject to this record type being enabled for a specific target (see clause 6.2.2.2.1).
6.2.2.4 Identity privacy
The AMF shall ensure for every registration (including re-registration) that SUPI has been provided by the UDM to the AMF and that the SUCI to SUPI mapping has been verified as defined in TS 33.501. This shall be performed regardless of whether the SUPI is a target of interception, and whether the null encryption algorithm is used for the SUCI. The AMF shall maintain the SUPI to SUCI mapping for at least the lifetime of the registration in order to allow interception based on SUPI after the initial registration.
6.2.2.2.7 AMF identifier association added 3GPP TS 33.128 V16.5+, V17+, and V18+. Not in V15.9.0 (2022-06-16).
6.2.2A Identifier Reporting for AMF
6.2.2A.1 Activation of reporting over LI_XEM1
The IEF in the AMF is activated and deactivated over LI_XEM1 by the LIPF using the LI_XEM1 protocol described in clause 5.2.7.
- NOTE: Since the IEF reports association events for all UEs registered in the IEF’s parent AMF, unlike POIs there is no concept of provisioning an IEF with target identifiers.
Upon receiving a valid activate task message over LI_XEM1, the IEF shall start generating records as defined in clause 6.2.2A.2.
Upon receiving a valid deactivate task message over LI_XEM1, the IEF shall stop generating records as defined in clause 6.2.2A.2.
6.2.2A.2 Generation of records over LI_XER
6.2.2A.2.1 Events
The IEF in the AMF shall generate an IEFIdentifierAssociation record whenever the IEF present in the AMF detects a change in association between a SUPI and a 5G-GUTI for any UE registered with the AMF. The IEF shall send the IEFIdentifierAssociation records to the ICF over LI_XER as defined in clause 5.9.
Accordingly, the IEF in the AMF generates IEFIdentifierAssociation records when any of the following events are detected:
- IEFAssociationRecord: Association of a 5G-GUTI to a SUPI, (this may also include SUCI to SUPI association).
- IEFDeassociationRecord: De-association of a 5G-GUTI from a SUPI.
- NOTE1: The de-association of 5G-GUTI from a SUPI event record is only generated if a new 5G-GUTI is not allocated to a SUPI to update a previous association (e.g. at inter-AMF handover).
- NOTE 2: As SUCIs are single use and only valid for a single authentication, they are only valid at the single point in time when the association event is detected and reported to the ICF by the IEF.
In addition, when an IEF is activated as per clause 6.2.2A.1, the IEF shall generate associations event for all SUPIs which are registered in the AMF, where those identifier associations allocated prior to IEF activation remain current and are still available in the AMF (See NOTE 2).
- NOTE 3: Only identifier associations which have been maintained by the AMF as part of normal network operations will be available.
In the case where the IEF in the AMF detects that a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE (5G-GUTI) message as defined in TS 24.501 has been sent by the AMF towards a UE, the IEF shall immediately generate an IEFIdentifierAssociation record. This record shall be generated regardless of whether the CONFIGURATION UPDATE (5G-GUTI) or REGISTRATION ACCEPT procedure is subsequently successfully completed or not.
6.2.2A.2.2 Association Events
For each association event, the IEF shall create an IEFAssociationRecord, as defined below.
| Field name | Description | M/C/O |
|---|---|---|
| sUPI | SUPI associated with detected association event. | M |
| fiveGGUTI | 5G-GUTI shall be provided. Encoded as per TS 24.501 figure 9.11.3.4.1, omitting the first four octets. | M |
| timeStamp | Time at which the identifier association event occurred. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time). | M |
| tAI | Last known TAI associated with the SUPI. Encoded as per TS 24.501 clause 9.11.3.8, omitting the first octet. | M |
| nCGI | Last known nCGI(s) available when identifier association event detected. Given as a sequence of PLMNID (encoded as per TS 38.413 clause 9.3.3.5) and NCI (encoded as per TS 38.413 clause 9.3.1.7). | M |
| nCGITime | ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 clause 5.4.4.9. If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF. | M |
| sUCI | SUCI shall be provided when event is triggered by association of a SUCI to a SUPI. Encoded as per TS 24.501 clause 9.11.3.4, omitting the first 3 octets. | C |
| pEI | PEI, (see NOTE 1). | C |
| fiveGSTAIList | List of tracking areas associated with the registration area within which the UE is current registered, see TS 24.501, clause 9.11.3.9. (see NOTE 2) | C |
| gPSI | GPSI, (see NOTE 1). | C |
| ||
For each de-association event, the IEF shall create an IEFDeassociationRecord, as defined below.
| Field name | Description | M/C/O |
|---|---|---|
| sUPI | SUPI associated with detected de-association event. | M |
| fiveGGUTI | 5G-GUTI shall be provided. Encoded as per TS 24.501 [13] figure 9.11.3.4.1, omitting the first four octets. | M |
| timeStamp | Time at which the identifier de-association event occurred.
Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time). |
M |
| nCGI | Last known nCGI(s) available when identifier de-association event detected. Given as a sequence of PLMNID (encoded as per TS 38.413 clause 9.3.3.5) and NCI (encoded as per TS 38.413 clause 9.3.1.7). | M |
| nCGITime | ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 clause 5.4.4.9.
If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF. |
M |
6.2.2A.2.3 Transmission to the ICF
When activated (see clause 5.2.7), the IEF shall establish a TLS connection to the ICF as given over LI_XEM1. If the IEF fails to establish a TLS connection, it shall report an error over LI_XEM1 using the error reporting mechanisms described in ETSI TS 103 221-1 and attempt to reconnect after a configurable period of time.
When a record has been generated as described in clause 6.2.2A.2.2, the IEF shall encode the IEFAssociationRecord or IEFDeassociationRecord as a BER-encoded IEFMessage structure, following the ASN.1 schema given in Annex F, and transmit it to the ICF over the established TLS connection.
The IEF may transmit a keepalive request using the keepalive record defined in Annex F. Upon receiving a keepalive request, the ICF shall respond with a keepaliveResponse record containing the same sequence number used in the request. The circumstances under which the IEF transmits keepalive requests is out of scope of the 33.128 V18.0.0 (2022-06) document.
7.6 Identifier Association Reporting
Sometimes referred as "identifier mapping reporting."
7.6.1 General
The IEF, ICF and IQF are responsible for detecting, storing and providing to the LEA permanent to temporary identifier associations, requested by the LEA in authorized requests. The IEF as defined in clause 6.2.2A is responsible for detecting and generating identifier associations records. The ICF is responsible for caching identifier associations for short duration and the IQF is responsible for handling requests from the LEA and providing those requests to the ICF in order to identify the matching identifier associations.
7.6.2 ICF
7.6.2.1 General
The ICF is responsible for caching identifier associations provided in event records from the IEF over LI_XER and handling queries and subsequent responses from the IQF for responses over LI_XQR.
7.6.2.2 ICF receipt of records over LI_XER
When the ICF receives an identifier association event record over LI_XER from an IEF (see clause 5.9), the ICF shall use the records to update the identifier associations cached by the ICF. The ICF shall handle the event records as described in clause 7.6.2.4.
7.6.2.3 ICF Query and Response over LI_XQR
When the ICF receives an identifier association query request from the IQF, the ICF shall search the cached identifier associations to establish a match, based on RequestValues received in the request (see clause 5.8), subject to clause 7.6.2.4.
Upon successful matching of one or more identifier associations which were active at or around (within a pre-defined search time window) the observed time specified in the query, the ICF shall provide a response to the IQF using the IdentityAssociationResponse message as defined in clause 5.8. Where the ICF is not able to provide a single identifier association based on the RequestValues, the IQF is responsible for any subsequent handling of multiple identifier associations in terms of whether to provide all associations to the LEA over LI_HIQR.
7.6.2.4 ICF Identifier Association Event Handling
Upon receipt of an Association event as defined in clause 6.2.2A.2, the ICF shall cache the identifier association(s) contained within the record as followings:
- SUPI to 5G-GUTI association received, in an IEFAssociationRecord is stored by ICF as an active association. The previous active association for the same SUPI, if any, is marked as a previously active association and cached until the cache time limit is reached.
- If the IEFAssociationRecord also contains a SUCI, the SUCI is stored as a part of the received SUPI to 5G-GUTI association, for the lifetime of that association.
- Where the IEFDeassociationRecord corresponds to an active SUPI to 5G-GUTI association at ICF, the association is marked as a previously active association and cached until the cache time limit is reached.
The ICF shall have a CSP defined maximum active association lifetime (upon expiry of which the association is deleted from the ICF).
- NOTE 1: The maximum active association lifetime is needed to prevent an association from being deleted from ICF under some error conditions (e.g. a loss of IEF message carrying IEFDeassociationRecord caused by the implicit deregistration of an out-of-service UE). The selection of the maximum active association lifetime value needs to ensure that no valid active associations are deleted upon the lifetime expiry, i.e. the longest possible association refresh time supported by CSP’s network needs to be accommodated.
For previous associations placed in the cache, the ICF shall store the times of association and disassociation, respectively.
Where an IEFAssociationRecord contains a PEI, Generic Public Subscription Identifier (GPSI) or a TAI list, the ICF shall store the received values and associate them both the current received SUPI to 5G-GUTI association and any future association until:
- A subsequent IEFAssociationRecord is received which updates the PEI, GPSI or TAI list values.
- The old PEI / GPSI / TAI list shall be retained in association with previous SUPI to 5G-GUTI associations until those associations are deleted from cache.
- New PEI / GPSI / TAI list shall be used in association with both the association(s) with which it was received and any subsequent associations until another update is received.
- All SUPI associations for which the PEI / GPSI / TAI list is valid are deleted from the cache.
When the ICF receives a query request from the IQF as defined in clause 7.6.2.3, the ICF shall search available identifier associations (both active associations and those marked for deletion in the cache) for a match. The ICF shall be able to use both time and TAI (as a single TAI and in relation to a TAI list) to identify the correct SUPI to 5G-GUTI association(s). For associations which have been disassociated (and will be deleted once the cache time limit is reached), the time of disassociation is used by the ICF to identify the correct association match (based on observed time in LEA request), where multiple associations are held in the cache.
- NOTE 2: Use of nCGI to match associations based on physical location for SUCI / 5G-S-TMSI to SUPI requests, is out of scope of the present document.
As the LEA and CSP are unlikely to have synchronised the time of identifier observation / association provided by the LEA in the query request, with NF time of the IEFs, the ICF shall search the cached identifier associations using a short window time duration both before and after (subject to overall cache duration) the observed time provided by the LEA in the RequestValues over LI_XQR.
- NOTE 3: While the search window duration before and after the LEA provided observed time value is outside the scope of 33.128 V18.0.0, selection of this value by the CSP needs to take into consideration, among other aspects, the duration of a potential period of recovery from a 5G-GUTI update error, in order to prevent missing of otherwise matching associations due to discrepancies between their stored association/disassociation time and the observed time provided by LEA.
- NOTE 4: While the value of the short-term caching time is outside the scope of 33.128 V18.0.0, selection of this value by the CSP needs to take into consideration, among other aspects, the duration of potential period of recovery from a 5G-GUTI update error, in order to prevent previous associations being deleted before they have been fully disassociated by both the UE and AMF.
7.6.3 IQF
7.6.3.1 General
The IQF is responsible for receiving and responding to LEA requests over LI_HIQR. Following receipt of a request over LI_HIQR, the IQF shall validate the request and ensure that the request is within the cache period of associations stored in the ICF. If the request is valid and within the ICF cache period, the IQF shall send an association search request to the ICF over LI_XQR. If the request is not within the ICF cache period or overwise invalid, the IQF shall reject the request and respond to the LEA over LI_HIQR.
Following receipt of an association search request response from the ICF over LI_XQR, the IQF shall forward any matching identifier association(s) to the LEA over LI_HIQR. If the ICF indicates zero matches were found based on the information provided in the initial request over LI_HIQR, the IQF shall respond to the LEA over LI_HIQR indicating that no identifier associations were found based on the request from the LEA.
If the ICF responds with multiple associations of 5G-GUTIs / SUCIs to a single SUPI, the IQF shall provide all matched associations to the LEA over LI_HIQR. Handling in the case of multiple SUPIs to a single 5G-GUTI (where the initial request over LI_HIQR is based on 5G-S-TMSI or SUCI) is outside the scope of 33.128 V18.0.0.
7.6.3.2 IQF Query and Response over LI_HIQR
The IQF is responsible for receiving query requests from and providing query responses to the LEA over LI_HIQR. Further details of LI_HIQR messages are defined in clause 5.7.
7.6.3.3 IQF Query and Response over LI_XQR
The IQF is responsible for generating queries to and receiving query responses requests from the ICF over LI_XQR, based on queries received from the LEA over LI_HIQR. Further details of LI_XQR messages are defined in clause 5.8.