Content for  TS 33.128  Word version:  18.7.0

Functions having an LI_HIQR interface shall support the use of ETSI TS 103 120 [6] to realise the interface. In the event of a conflict between ETSI TS 103 120 [6] and the present document, the terms of the present document shall apply.

LI_XQR requests are realised using ETSI TS 103 221-1 [7] to transport the IdentityAssociationRequest and IdentityAssociationResponse messages (which are derived from the X1RequestMessage and X1ResponseMessage definitions in ETSI TS 103 221-1 [7]) as described in Annex E.

For requests with RequestType "IdentityAssociation" (see Table 5.7.2-3), the IQF issues an IdentityAssociationRequest message populated with a RequestDetails structure as follows:

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 [7]. 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.

For requests with RequestType "OngoingIdentityAssociation", the IQF shall activate a request for ongoing updates at the ICF by sending it an ActivateAssociationUpdates message populated as follows:

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 [7]. 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 [7] clause 4.2. The IQF shall respond with an Identity­Association­Update­Acknowledgement message.

If the IQF receives a permanent to temporary association request with RequestType "IdentityAssociation" (see Table 5.7.2-3) which does not include an ObservedTime, the IQF issues a LatestAssociationRequest message populated as follows:

The corresponding successful LI_XQR responses are returned using the IdentityAssociationResponse message. The IdentityAssociationResponse message shall be populated with the most recent association present in the ICF, if available. Error conditions are reported using the normal error reporting mechanisms described in TS 103 221-1 [7]. 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.

LI_ST shall be realised using a dedicated separate instance of the Nudsf_DataRepository service as defined in TS 29.598 subject to the following terms. The LISSF shall adopt the role of the NF Service Provider as described in clause 5.2.1 of TS 29.598. The LISSF may be realised as a standalone function or within the ADMF. In either case it shall meet the requirements set out in clause 6.2.3.8 of TS 33.127. An LI function may only store state over LI_ST using an LISSF identified by the LIPF via LI_X0. The LIPF shall provide the necessary details for connection, including the relevant apiRoot, apiVersion, realmId and storageId values (see clause 6.1.3.1 of TS 29.598) and any necessary keys for authentication.

When an LI function wishes to store LI state in the LISSF, it shall perform the Record Create service operation as described in clause 5.2.2.3.1 of TS 29.598. Unless otherwise specified, the recordId shall be a randomly-assigned UUID. The record metadata shall include at least the following information as tag value pairs (see clause 6.1.6.2.3 of TS 29.598).

Further details on the contents of the Record Blocks is given in the relevant clauses. The LIPF shall always be able to store records in the LISSF.

When an LI function wishes to retrieve records from the LISSF and knows the RecordID of the relevant state information, it shall perform a Record Retrieval operation as described in clause 5.2.2.2.2 of TS 29.598. If the LI function does not know the RecordID, it shall perform a search as described in clause 5.2.2.2.6 of TS 29.598 using appropriate search criteria. The details for choosing search criteria are specific to each LI function and are therefore given in later clauses specific to that LI function. The LIPF shall always be able to retrieve records from the LISSF.

When an LI function wishes to remove records from the LISSF, it shall perform a Record Delete service operation as described in clause 5.2.2.5 of TS 29.598. The LIPF shall always be able to remove records from the LISSF.

Functions having a LI_HILA interface shall support the use of ETSI TS 103 120 [6] to realise the interface. In the event of a conflict between ETSI TS 103 120 [6] and the present document, the terms of the present document shall apply. Prior to issuing of location acquisition requests, the LEA shall provide an authorization for these requests This is done by issuing a warrant over the LI_HI1 interface prior to issuing the LI_HILA requests as described in clause 5.4.3.

Functions having a LI_XLA interface shall support the use of ETSI TS 103 221-1 [7] to realise the interface. In the event of a conflict between ETSI TS 103 221-1 [7] and the present document, the terms of the present document shall apply.

LI_XLA requests are realised using ETSI TS 103 221-1 [7] to transport the LocationAcquisitionRequest and LocationAcquisitionResponse messages (which are derived from X1RequestMessage and X1ResponseMessage respectively, as defined in ETSI TS 103 221-1 [7]), see Annex I. The LocationAcquisitionRequest message is populated as follows:

Successful LI_XLA responses are returned using the LocationAcquisitionResponse message. Error conditions are reported using the normal error reporting mechanisms described in ETSI TS 103 221-1 [7]. LI_XLA query responses are represented in XML following the LocationAcquisitionResponse schema (see Annex I). If delivery via the LI_HILA was specified, the fields of the LocationAcquisitionResponse record shall be populated as described in clause 5.11.2.3. If delivery via the LI_HI2 was specified in the original request, the LARF shall leave the LocationAcquisitionResponse record field unpopulated.