Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.128  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M…

 

5.7  Protocols for LI_HIQRp. 39

5.7.1  Generalp. 39

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.

5.7.2  Usage for realising LI_HIQRp. 39

5.7.2.1  Request structurep. 39

LI_HIQR requests are represented by issuing a CREATE request for an LDTaskObject (see ETSI TS 103 120 [6] clause 8.3), populated as follows:
Field Value M/C/O
ReferenceReference 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 Table 5.7.2-2 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 [6] clause 8.3.6.2) unless the delivery destination is known via other means.C
The use of any other LDTaskObject parameter is outside the scope of the present document.
Field Value M/C/O
Type Shall be set to one of the RequestType values as defined in Table 5.7.2-3.M
ObservedTimeWhen 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 "Ongoing­Identity­Association".
C
RequestValuesSet to the target identifier plus additional information required (see clause 5.7.2.2).M
Dictionary Owner Dictionary Name
3GPPRequestType
Defined DictionaryEntries
Value Meaning
IdentityAssociationA 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".
Table 5.7.2-3 is formatted in accordance with ETSI TS 103 120 [6] Annex F.
Up

5.7.2.2  Request parametersp. 40

The RequestValues field shall contain one of the following:
If the RequestType is "OngoingIdentityAssociation" (see Table 5.7.2-3), 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 [6] clause 8.3.3).
If a temporary identity is provided, the following may also be present as RequestValues:
If a temporary identity is provided, the following shall also be present as RequestValues:
The following RequestValue FormatTypes (see ETSI TS 103 120 [6] clause 8.3.5.4) are defined (which are not otherwise defined elsewhere).
Format Owner Format Name Description Format
3GPPSUCISubscription Concealed Identifier as per clause 2.2B of TS 23.003. clause 6.1.6.3.2 of TS 29.509
3GPP5GSTMSI Shortened form of the 5G-GUTI as defined in clause 2.11 of TS 23.003. 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}))$
3GPP5GGUTIAs defined in clause 2.10 of TS 23.003. 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}))$
3GPPNRCellIdentityNR Cell ID (NCI), as defined in clause 19.6A of TS 23.003.clause 5.4.2 of TS 29.571
3GPPTrackingAreaCodeTracking area code as defined in clause 19.4.2.3 of TS 23.003clause 5.4.2 of TS 29.571
The LDTaskObject may also contain the "IncludeNCGIInResponse" LDTask flag (see Table 5.7.2-4A). If this flag is present for such a query, then the response shall contain the NR Cell Global Identity associated with the SUPI at the time of association (see Table 5.7.2-5).
Dictionary Owner Dictionary Name
3GPPLIHIQRFlags
Defined DictionaryEntries
Value Meaning
IncludeNCGIInResponseA request for returning the NCGI in the response.
Up

5.7.2.3  Response structurep. 41

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 [6] clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 [6] clause 10).
IdentityResponseDetails contain IdentityAssociation records. The fields of each IdentityAssociationRecord shall be set as follows:
Field Value M/C/O
SUPISUPI associated with the provided identity.M
SUCISUCI 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
PEIPEI associated with the provided identity during the association period, if known.C
AssociationStartTimeThe time that the association between the SUPI and the temporary identity became valid. (see NOTE).M
AssociationEndTimeThe 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
FiveGSTAIListList 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
GPSIGPSI associated with the provided identity during the association period, if known.C
NCGI NR Cell Global Identity associated with the SUPI at the time of association between the SUPI and the temporary identity. Shall be sent if the "IncludeNCGIInResponse" flag is set. 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 Identity­Association­Records. Similarly, the LI_HIQR response contains zero Identity­Association­Records.
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 [6] 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 [6] clause 10.2.1.
The content manifest (see ETSI TS 103 120 [6] clause 10.2.2) shall be set to indicate the present document, using the following Specification Dictionary extension.
Dictionary Owner Dictionary Name
3GPPManifestSpecification
Defined DictionaryEntries
Value Meaning
LIHIQRResponse The delivery contains IdentityResponseDetails (see Annex E)
Up

5.8  Protocols for LI_XQRp. 42

5.8.1  Generalp. 42

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

5.8.2  Identity association requestsp. 43

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 [7] field name Description M/C/O
Type Shall be set to the RequestType value "IdentityAssociation" as defined in Table 5.7.2-3. M
ObservedTimeObservation time as provided over LI_HIQR (see clause 5.7.2).M
RequestValuesSet 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 [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.
Up

5.8.3  Ongoing identity association requestsp. 43

For requests with RequestType "OngoingIdentityAssociation", the IQF shall activate a request for ongoing updates at the ICF by sending it an Activate­Ongoing­Identity­Association­Updates message populated as follows:
Field Value M/C/O
OngoingAssociationTaskIDUnique identifier for this request allocated by the IQF.M
SUPIPermanent 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 [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.
Up

5.9  Protocols for LI_XERp. 43

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.

5.10  Protocols for LI_ST interfacep. 44

5.10.1  Overviewp. 44

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

5.10.2  Storagep. 44

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).
Field Name Description M/C/O
NFInstanceIDThe NF instance ID associated with the NF in which the LI function is located, if applicable (see clause 5.3.2 of TS 29.571)C
NEIDThe LI_X1 identifier associated with the LI function.M
XIDXID for the task that the state is associated with, if applicable.C
DIDDID for the destination that the state is associated with, if applicable.C
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.
Up

5.10.3  Retrievalp. 44

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

5.10.4  Removalp. 44

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.

5.11  Protocols for LI_HILAp. 44

5.11.1  Generalp. 44

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

5.11.2  Usage for realising LI_HILAp. 45

5.11.2.1  Request structurep. 45

LI_HILA requests are represented by issuing a CREATE request for an LDTaskObject (see ETSI TS 103 120 [6] clause 8.3), populated as follows:
Field Value M/C/O
Reference The LDID (as in ETSI TS 103 280 [97] with country code, unique LEA identifier, and the LIID used in the warrant as unique request identifier.M
DesiredStatus Shall be set to "AwaitingDisclosure". M
RequestDetails Set according to Table 5.11.2.1-2 below.M
DeliveryDetails Shall be set to indicate the delivery destination for the LI_HILA records (see clause 5.11.2.3 and ETSI TS 103 120 [6] clause 8.3.6.2) unless the delivery destination is known via other means.C
The use of any other LDTaskObject parameter is outside the scope of the present document.
Field Value M/C/O
Type Shall be set to one of the HIARequestType values as defined in Table 5.11.2.1-3.M
RequestValuesSet to the target identifier (see clause 5.11.2.2).M
Dictionary Owner Dictionary Name
3GPPRequestType
Defined DictionaryEntries
Value Meaning
LocationAcquisitionA request for location information of the target, consisting at least of the TAI and the ECGI/NCGI.
Up

5.11.2.2  Request parametersp. 45

The RequestValues field shall contain at least one of the following:
The LDTaskObject for a location acquisition request may also contain the "ReqCurrentLoc" LDTask flag (see Table 5.11.2.2-1). If this flag is present, the LAF shall set the ReqCurrentLoc parameter in the LI_XLA request sent to the LARF to true. If this flag is absent, the LAF shall either set the ReqCurrentLoc parameter in the LI_XLA request sent to the LARF to false or not include this parameter.
Dictionary Owner Dictionary Name
3GPPLIHILAFlags
Defined DictionaryEntries
Value Meaning
ReqCurrentLocIndicates whether the current location of the UE is requested.
Up

5.11.2.3  Response structurep. 46

If delivery via the LI_HI2 is required, the LARF will send the acquisition response as either an AMFLocationUpdate (in case of the 5GC) or an MMELocationUpdate (in case of the EPC) xIRI record to the MDF2 via LI_X2_LA. Full details are given in clause 7.3.5.6.
If delivery via the LI_HILA is required, the LARF returns the acquisition response as part of the LI_XLA response, which the LAF then transforms into a LI_HILA response given as a LocationResponseDetails structure (see Table 5.11.2.3-1). Full details are given in clause 7.3.5. LocationResponseDetails contains LocationOutcome records.
The fields of the LocationResponseDetails structure shall be set as follows:
Field Description/Value M/C/O
LocationOutcomes Locations of the target if determined by the network, or failure causes. The format of each LocationOutcome shall be set as defined in Table 5.11.2.3-3 in case of EPC or as defined in Table 5.11.2.3-2 in case of 5GC.C
Field Description/Value M/C/O
SUPISUPI associated with the UE for which location is returned.M
GPSIGPSI associated with the UE for which location is returned. Shall be included if the GPSI of the UE for which location is returned is known.C
LocationLocation of the target if determined by the network.
  • It shall include a JSON ProvideLocInfo structure as defined in clause 6.4.6.2.6 of TS 29.518, in base-64 encoding, in case the location could be determined.
C
FailureCauseIf the location acquisition procedure fails, this parameter shall be included. The values for this parameter shall be derived from values of the failure response received from the AMF.
  • If a ProblemDetails structure is returned, the errorDetails field shall be populated with a JSON ProblemDetails structure as defined in clause 5.2.4.1 of TS 29.571 in base-64 encoding.
C
Field Description/Value M/C/O
IMSIIMSI associated with the UE for which location is returned.M
MSISDNsList of MSISDNs associated with the UE for which location is returned, if available.C
LocationLocation of the target if determined by the network.
It shall include the MME-Location-Information AVP as defined in clause 7.3.115 of TS 29.272, in base-64 encoding, in case the location could be determined.
C
FailureCauseIf the location acquisition procedure fails, this parameter shall be included. The value of this parameter shall be set to the Result-Code as returned from the MME.C
Responses are delivered within a DELIVER Request (see ETSI TS 103 120 [6] clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 [6] clause 10).
The DeliveryObject Reference field (see ETSI TS 103 120 [6] clause 10.2.1) shall be set to the Reference of the LDTaskObject used in the request to provide a correlation between request and response. The DeliveryID, SequenceNumber, and LastSequence fields shall be set according to ETSI TS 103 120 [6] clause 10.2.1.
The content manifest (see ETSI TS 103 120 [6] clause 10.2.2) shall be set to indicate the present document and the type of response using the following Specification Dictionary extension.#
Dictionary Owner Dictionary Name
3GPPManifestSpecification
Defined DictionaryEntries
Value Meaning
HILAResponse The delivery contains a LocationResponseDetails (see Annex I)
Up

5.12  Protocols for LI_XLAp. 47

5.12.1  Generalp. 47

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.

5.12.2  Usage for realising LI_XLAp. 47

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:
Field Description M/C/O
RequestValuesSet to the target identifier specified in the LI_HILA request (see clause 5.11.2).M
ReqCurrentLoc Indicates whether the current location of the UE is requested.
If set to true, the LARF shall:
If set to false, the LARF shall use the location information in the UE context at the MME/AMF.
This parameter shall be set to true if the request received over LI_HILA had the ReqCurrentLoc flag set and shall be set to false if the request received over LI_HILA did not have the ReqCurrentLoc flag.
M
HILADeliveryBased on the information received over the LI_HI1 interface (see 5.4.3). If set, the LARF shall return the location information to the LAF (see NOTE).C
HI2Delivery Based on the information received from the LI_HI1 interface (see clause 5.4.3). If present, the format shall be as defined in Table 5.12.2.1-2 (See NOTE).C
NOTE:
At least one delivery method is required
Field Value M/C/O
XIDThe value shall be used by the LARF to fill the XID field of the X2 PDUs. The value shall be the same as the one provisioned on the MDF2 (see clause 7.3.5.6.2).C
ListOfDestinationsDelivery endpoints for LI_X2_LA for the LARF in the MME/AMF. This field shall be present unless the delivery details are known via other means.C
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.
Up

Up   Top   ToC