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.

Internal interfaces and related protocols

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.

External handover interfaces and related protocols

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.

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). See spec for how LDTaskObject is populated.

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

RequestValue FormatType extensions for LI_HIQR Requests

Format Owner	Format Name	Description	Format
3GPP	SUCI	Subscription Concealed Identifier as per TS 23.003 clause 2.2B.	TS 29.509 clause 6.1.6.3.2
3GPP	5GSTMSI	Shortened form of the 5G-GUTI as defined in TS 23.003 clause 2.11. Given as a hyphen-separated concatenation of: The string "5gstmsi". The AMF Set ID given as three hexadecimal digits (10 bits). The AMF Pointer given as two hexadecimal digits (6 bits). The 5G-TMSI given as eight hexadecimal digits (32 bits)	Matches regular expression: ^(5gstmsi-([0-3][0-9A-Fa-f]{2})-([0-3][0-9A-Fa-f])-([0-9A-Fa-f]{8}))$
3GPP	5GGUTI	As defined in TS 23.003 clause 2.10. Given as a hyphen separated concatenation of: The string "5gguti". MCC given as a three decimal digits. MNC given as a two or three digit decimal digits AMF Region ID given as two hexadecimal digits (8 bits). The AMF Set ID, AMF Pointer and 5G-TMSI as defined above in 5GSTMSI	Matches regular expression: ^(5gguti-([0-9]{3})-([0-9]{2,3})-([0-9A-Fa-f]{2})-([0-3][0-9A-Fa-f]{2})-([0-3][0-9A-Fa-f])-([0-9A-Fa-f]{8}))$
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:

IdentityAssociationRecord

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.

Specification Dictionary

Dictionary Owner	Dictionary Name
3GPP	ManifestSpecification.

Defined DictionaryEntries

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:

RequestDetails structure for LI_XQR

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:

ActivateAssociationUpdates message for LI_XQR

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.

To Telecommunications info