5 Transport and Communications Protocol
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
5.1 General
This clause describes the protocols used for each of the interfaces at a level which is agnostic of the subject service or network. Additional specific fields or behaviours are given in the relevant parts of clauses 6 and 7.
5.2 Protocols for LI_X1 and LI_T interfaces
5.2.1 General usage of ETSI TS 103 221-1
Functions having an LI_X1, LI_T2 or LI_T3 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.
The LIPF and MDF2/3 shall maintain a mapping between internal interception identifiers (XIDs) and external interception identifiers (LIIDs), as defined by ETSI TS 103 221-1 [7] clause 5.1.2. In case of multiple interceptions for a single target identifier, it is an implementation decision for the LIPF/TF whether multiple XIDs are used (i.e. a one-to-one mapping between XID and LIID is maintained) or whether the single XID is used and mapped to multiple LIIDs at the MDF2/3. Clauses 6 and 7 give further details for specific networks or services (e.g. minimum supported target identifier formats).
In the event of a request issued over the interface fails, or an error is reported, the LIPF should raise an alert in the appropriate LI Operations and Management (O&M) system. Further procedures (e.g. retrying a failed request) are left to CSP policy to define.
A failure of LI shall not impact the target’s or other users’ services.
In general, and unless otherwise specified, the function playing the role of the NE (i.e. IRI-POI, IRI-TF, CC-TF, CC-POI, MDF2 or MDF3) shall:
– Accept CreateDestination and ModifyDestination messages regardless of the DeliveryType.
– Reject ActivateTask/ModifyTask messages that contain destination identifiers (DIDs) that reference Destinations that have not been created via a CreateDestination message; Destinations shall be created before they are used.
– Reject ActivateTask/ModifyTask messages that do not result in at least one valid DID for their DeliveryType (e.g. at least one valid DID for an X2 delivery destination for an "X2Only" Task). Additional DIDs for Destinations of other DeliveryTypes (e.g. a DID for an X3 Destination for an "X2Only" Task) shall be accepted, but a ReportTaskIssue message may be sent to indicate the mismatch.
5.2.2 Usage for realising LI_X1
For the purposes of realising LI_X1 between the LIPF and a POI, MDF or TF, the LIPF plays the role of the ADMF as defined in ETSI TS 103 221-1 [7] reference model (clause 4.2), and the POI, MDF or TF plays the role of the NE.
In general, and unless otherwise specified, the ADMF shall:
– When the provisioning of an IRI-POI/IRI-TF/MDF2 is needed to meet the requirements of the warrant, send an ActivateTask (and subsequent ModifyTask if/as needed) with the DeliveryType set to "X2Only" and the ListOfDIDs containing at least one DID for an X2 or LI_HI2 delivery destination over LI_X1 to each of the relevant functions.
– When the provisioning of a CC-POI/CC-TF/MDF3 is needed to meet the requirements of the warrant, send an ActivateTask (and subsequent ModifyTask if/as needed) with the DeliveryType set to "X3Only" and the ListOfDIDs containing at least one DID for X3 or LI_HI3 delivery destination over LI_X1 to each of the relevant functions.
When both the above are required to meet the requirements of the warrant, the ADMF shall send each independently to each relevant function.
When it is required to cease interception, the ADMF shall send a DeactivateTask message to each relevant function, unless the Task has already been removed by other means (e.g. by the use of the ImplicitDeactivationAllowed flag, see ETSI TS 103 221-1 [7] clause 6.2.1.2).
Other deployments compliant with ETSI TS 103 221-1 [7] may be used subject to local agreement.
5.2.3 Usage for realising LI_X1 (management)
For the purposes of realising LI_X1 between the LIPF and a triggered POI, the LIPF plays the role of the “ADMF” as defined in ETSI TS 103 221-1 [7] reference model (clause 4.2), and the triggered POI plays the role of the “NE”.
5.2.4 Service scoping
The LIPF shall be able to provision the POI, TFs and the MDF2/MDF3 according to the service scoping (see clause 4.4) applicable to a warrant as described in clause 6.2.1.2 and Annex C of ETSI TS 103 221-1 [7].
If there is a need to explicitly identify specific CSP service types to be intercepted by the task, the LIPF shall include the ListOfServiceTypes parameter in the TaskDetails of the provisioning message sent to the POIs/TFs. If no service type is provisioned, the POIs shall generate and deliver applicable interception product for all services specified for the NF where the POI is located as described in clause 4.4.2.
If there is a need to explicitly identify specific CSP service types to be delivered by the task, the LIPF shall populate the ServiceType in the ServiceScoping parameter in the MediationDetails of the provisioning message sent to the MDF2/MDF3. If the LIPF includes the ListOfServiceTypes parameter in the TaskDetails of the provisioning message sent to the MDF2/MDF3, the MDF2/MDF3 shall ignore this parameter.
5.2.5 Usage for realising LI_T2
For the purposes of realising LI_T2 between an IRI-TF and a triggered IRI-POI, the IRI-TF plays the role of the "ADMF" as defined in the ETSI TS 103 221-1 [7] reference model (clause 4.2), and the triggered IRI-POI plays the role of the "NE".
In case the IRI-TF receives from the triggered IRI-POI an error in the answer to a triggering message, the IRI-TF shall send a ReportTaskIssue message to the LIPF. In such case, the failure of LI shall not impact the target’s or other users’ services.
Unless otherwise specified, an IRI-TF shall set the Product ID field in any ActivateTask or ModifyTask message issued to a triggered IRI-POI (see ETSI TS 103 221-1 [7] clause 6.2.1.2). The IRI-TF shall set the Product ID to the XID of the Task object associated with the interception at the IRI-TF in order to allow correlation of LI product at the MDF2.
Unless otherwise specified, the TF shall include the MDF2 as the X2 delivery destination in the trigger sent using the ActivateTask/ModifyTask with "X2Only".
When the IRI-TF determines that it is required to remove a Task at a particular IRI-POI (e.g. having detected the end of a session) it shall send a DeactivateTask message for the relevant Task to that IRI-POI, unless the Task has already been removed by other means (e.g. by the use of the ImplicitDeactivationAllowed flag, see ETSI TS 103 221-1 [7] clause 6.2.12).
When the IRI-TF receives a DeactivateTask message or ModifyTask message from the LIPF, the IRI-TF shall send DeactivateTask or ModifyTask messages to all applicable triggered IRI-POIs for all tasks associated to the Task object in the message from the LIPF.
5.2.6 Usage for realising LI_T3
For the purposes of realising LI_T3 between a CC-TF and a triggered CC-POI, the CC-TF plays the role of the "ADMF" as defined in the ETSI TS 103 221-1 [7] reference model (clause 4.2), and the triggered CC-POI plays the role of the "NE".
In case the CC-TF receives from the triggered CC-POI an error in the answer to a triggering message, the CC-TF shall send a ReportTaskIssue message to the LIPF. In such case, the failure of LI shall not impact the target’s or other users’ services.
Unless otherwise specified, a CC-TF shall set the Product ID field in any ActivateTask or ModifyTask message issued to a triggered CC-POI (see ETSI TS 103 221-1 [7] clause 6.2.1.2). The CC-TF shall set the Product ID to the XID of the Task object associated with the interception at the CC-TF in order to allow correlation of LI product at the MDF3.
Unless otherwise specified, the TF shall include MDF3 as the X3 delivery destination in the trigger sent using the ActivateTask/ModifyTask with "X3Only".
When the CC-TF determines that it is required to remove a Task at a particular CC-POI (e.g. having detected the end of a session) it shall send a DeactivateTask message for the relevant Task to that CC-POI, unless the Task has already been removed by other means (e.g. by the use of the ImplicitDeactivationAllowed flag, see ETSI TS 103 221-1 [7] clause 6.2.12).
When the CC-TF receives a DeactivateTask message or ModifyTask message from the LIPF, the CC-TF shall send DeactivateTask or ModifyTask messages to all applicable triggered CC-POIs for all tasks associated to the Task object in the message from the LIPF.
5.2.7 Usage for realising LI_XEM1
For the purposes of realising LI_XEM1 between the LIPF and an IEF, the LIPF plays the role of the ADMF as defined in ETSI TS 103 221-1 [7] reference model (clause 4.2), and the IEF plays the role of the NE.
The IEF shall be enabled by sending the following ActivateTask message from the LIPF.
NOTE: The terms identifier and identity are used interchangeably in clause 5.2.7.
Table 5.2.7-1: ActivateTask message for activating an IEF
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
Shall be set to a value assigned by the LIPF. |
M |
|
TargetIdentifiers |
Shall contain a single Target Identifier of type "IdentityAssociation" (see table 5.2.7-2) |
M |
|
DeliveryType |
Set to "X2Only". |
M |
|
ListOfDIDs |
Shall give the DID of the delivery endpoint of the ICF(s) to which identity association events should be delivered. These delivery endpoints are configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
The following Target 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.
Table 5.2.7-2: Target Identifier Type for LI_XEM1
|
Identifier type |
Owner |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
IdentityAssociationTargetIdentifier |
3GPP |
TargetIdentifierExtension / IdentityAssociationTargetIdentifier |
Empty tag (see XSD schema) |
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.
Table 5.2.7-3: DeactivateTask message for de-activating an IEF
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
Shall be set to the value assigned by the LIPF |
M |
The LIPF should send one ActivateTask command to each IEF.
NOTE: The IEF may receive multiple ActivateTask messages conforming to table 5.2.7-1, each of which can be independently deactivated. The IEF shall remain active as long as at least one valid Task remains active.
5.3 Protocols for LI_X2 and LI_X3
5.3.1 General usage of ETSI TS 103 221-2
Functions having an LI_X2 or LI_X3 interface shall support the use of ETSI TS 103 221-2 [8] to realise the interface.
In the event of a conflict between ETSI TS 103 221-2 [8] and the present document, the terms of the present document shall apply.
The xIRI and the xCC sent using ETSI TS 103 221-2 [8] shall contain the appropriate XID as received in the relevant LI_X1 provisioning message (or LI_T2/3 triggering message, as appropriate).
5.3.2 Usage for realising LI_X2
The POI sending xIRI over the LI_X2 interface shall set the PDU type field within the xIRI to "X2 PDU". (see ETSI TS 103 221-2 [8] clause 5.1).
Where a single xIRI is sent as a result of a network procedure (i.e. as result of several signaling messages exchanged between the target UE and the network), the POI sending the xIRI shall set the Payload Direction field (see ETSI TS 103 221-2 [8] clause 5.2.6) based on the initiator of the network procedure.
Unless otherwise specified by the relevant clause, the payload shall consist of a BER-encoded TS33128Payloads.XIRIPayload structure. The payload format (see ETSI TS 103 221-2 [8] clause 5.4) shall be set according to the relevant clause of the present document (the value 2 is used for TS 33128Payloads.XIRIPayload).The TLS transport profile (see ETSI TS 103 221-2 [8] clause 6) shall be supported and used by default.
Unless otherwise specified, xIRI shall include the timestamp and sequence number conditional attribute fields, with the timestamp value set to the time at which the event occurred.
Unless otherwise specified, the "Matched Target Identifier" conditional attribute shall be set to indicate what target identity was matched to generate the xIRI (see ETSI TS 103 221-2 [8] clause 5.3.18).
Unless otherwise specified, the "Other Target Identifier" conditional attribute shall be set with all other target identities present at the NF that contains the POI (see ETSI TS 103 221-2 [8] clause 5.3.19).
Unless otherwise specified, the NFID conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.7) should be set to indicate the NF that contains the POI. The NFID is defined as a unique identifier assigned to the NF by the network (e.g. FQDN) per carrier implementation and referred to in the following clauses.
Unless otherwise specified, the IPID (see ETSI TS 103 221-2 [8] clause 5.3.8) should be set to indicate the POI (within the NF) that generated the xIRI for the conditional attribute field.
5.3.3 Usage for realising LI_X3
The POI sending xCC over the LI_X3 interface shall set the PDU type field in the xCC to "X3 PDU" (see ETSI TS 103 221-2 [8] clause 5.1).
The payload format shall be specified according to the relevant clause of the present document.
Unless otherwise specified, the NFID conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.7) should be set to indicate the NF that contains the POI. The NFID is defined as a unique identifier assigned to the NF by the network (e.g. FQDN) per carrier implementation and referred to in the following clauses.
Unless otherwise specified, the IPID (see ETSI TS 103 221-2 [8] clause 5.3.8) should be set to indicate the POI (within the NF) that generated the xCC for the conditional attribute field.
NOTE: ETSI TS 103 221-2 [8] specifies in clause 6 a default profile which is mandatory to support, but allows further profiles to be defined. In scenarios where it may not be possible to achieve the necessary LI data rates based on the default profile, alternative profiles may be considered (e.g. based on UDP, multi path TCP or other protocols). Any alternative profile needs to ensure that LI reliability, security and completeness requirements as specified in TS 33.126 [3] are met.
5.3.4 Service scoping
When applicable, the POIs shall deliver the xIRIs/xCC to MDF2/MDF3 over LI_X2/LI_X3 according to the service scoping as provisioned by the LIPF to them (see clause 5.2.4).
5.3.5 Usage for realising LI_X2_LA
Functions having an LI_X2_LA interface shall use the protocols for LI_X2 as defined in clause 5.3.2 to realise the interface with the following additions.
The LI function sending the message over LI_X2_LA shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
5.4 Protocols for LI_HI1
5.4.1 General
Functions having an LI_HI1 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.
The representation of tasking requests shall be as specified in the present clause.
Each request to intercept a particular identifier shall be represented as an LITaskObject (see ETSI TS 103 120 [6] clause 8.2). Table 5.4.1-1 shows the minimum details required for the LITaskObject to be valid.
Table 5.4.1-1: LITaskObject details
|
ETSI TS 103 120 [6] field name |
Description |
M/C/O |
|
Reference |
Set to the LIID associated with the interception. |
M |
|
DesiredStatus |
Set to "Active" to indicate that LI should commence. |
M |
|
TimeSpan |
At a minimum, EndTime shall be set. |
M |
|
TargetIdentifier |
See table 5.4.1-2. |
M |
|
DeliveryType |
Set to the appropriate delivery type (IRI, CC or both). |
M |
|
DeliveryDetails |
Shall include at least one appropriate LI delivery destination. |
M |
Table 5.4.1-2: LITaskObject TargetIdentifier details
|
ETSI TS 103 120 [6] field name |
Description |
M/C/O |
|
TargetIdentifierValues |
Shall contain at least one valid target identifier. |
M |
|
ServiceType |
If used, set to the appropriate service scoping dictionary value as defined in clause 5.4.2. |
O |
5.4.2 Service scoping
Functions having an LI_HI1 interface (i.e. the ADMF) shall be able to receive the service scoping as applicable to the warrant from the LEA over the LI_HI1 interface (see clause 4.4).
Where TS 103 120 [6] is used to realise LI_HI1, and where the details in clause 5.4.1 apply, the ServiceType field of the TargetIdentifier in a given LITaskObject shall be used to identify the appropriate service scoping. For each service scoping type defined in clause 4.4.2 that is required, the appropriate dictionary entry defined in table 5.4.2-1 below shall be included in the ServiceType field. If no service type is required to be provisioned, the ServiceType field shall be omitted.
Table 5.4.2-1: ServiceType Dictionary
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
ServiceType |
|
Defined DictionaryEntries |
|
|
Value |
Meaning |
|
Voice |
Service scoping shall include the Voice service type as given in clause 4.4.2. |
|
Data |
Service scoping shall include the Data service type as given in clause 4.4.2. |
|
Messaging |
Service scoping shall include the Messaging service type as given in clause 4.4.2. |
|
PTC |
Service scoping shall include the Push-to-Talk service type as given in clause 4.4.2. |
|
LALS |
Service scoping shall include the LALS service type as given in clause 4.4.2. |
|
RCS |
Service scoping shall include the RCS service type as given in clause 4.4.2. |
5.4.3 Location acquisition
When required for location acquisition, the warrant sent over the LI_HI1 interface will specify the delivery method using task flags populated as shown in table 5.4.3-1. If the delivery method is HI2Delivery (via MDF2), the LIPF shall ensure that the MDF2 (clause 7.3.5.6.1) is provisioned. Subsequently, the LAF will use this information while processing location acquisition requests received over the LI_HILA interface.
Table 5.4.3-1: LATaskFlag Dictionary for LI_HI1
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
LATaskFlag |
|
Defined DictionaryEntries |
|
|
Value |
Meaning |
|
HILADelivery |
The location information shall be delivered via the LI_HILA interface. |
|
HI2Delivery |
The location information shall be delivered via the LI_HI2 interface. |
5.5 Protocols for LI_HI2 and LI_HI3
5.5.1 General
Functions having an LI_HI2 or LI_HI3 interface shall support the use of ETSI TS 102 232-1 [9] and ETSI TS 102 232-7 [10] to realise the interface.
In the event of a conflict between either specification and the present document, the terms of the present document shall apply.
5.5.2 Usage for realising LI_HI2
The IRI messages sent over LI_HI2 are structured as a header and a payload. The header contains general information like LIID, timestamp, correlation information (as for example defined in ETSI TS 102 232-1 [9]). The payload contains intercept related information based on information that the MDF2 has received from sources in the network, such as the IRI-POI as described in clauses 6 and 7 of the present document. Details of the IRI messages can be found in Annex A of the present document. Messages defined as passing over the LI_HI2 interface shall be passed as the payload of the threeGPP33128DefinedIRI field (see TS ETSI 102 232 -7 [10] clause 15).
If the LI_X2 contains the NFID conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.7), this shall be mapped into the PSHeader networkFunctionIdentifier (see ETSI TS 102 232-1 [9] clause 5.2.14 and ETSI TS 102 232-7 [10] clause 15.3).
If the LI_X2 contains the IPID conditional attribute (see ETSI TS 103 221-2 [8]), the EIPID parameter (see ETSI TS 102 232-1 [9] clause 5.2.13) shall be populated by the MDF2 with the IPID value.
5.5.3 Usage for realising LI_HI3
The CC sent over LI_HI3 is structured as a header and a payload. The header contains general information like LIID, timestamp, correlation information (as for example defined in ETSI TS 102 232-1 [9]). The payload contains content of communication based on information that the MDF3 has received from sources in the network, such as the CC-POI as described in clauses 6 and 7 of the present document. Details of the CC can be found in Annex A of the present document. CC defined as passing over the LI_HI3 interface shall be passed as the payload of the threeGPP33128DefinedCC field (see ETSI TS 102 232-7 [10] clause 15).
If the LI_X3 contains the NFID conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.7), this shall be mapped into the PSHeader networkFunctionIdentifier (see ETSI Ts 102 232-1 [9] clause 5.2.14 and ETSI TS 102 232-7 [10] clause 15.3).
If the LI_X3 contains the IPID conditional attribute (see ETSI TS 103 221-2 [8]), the EIPID parameter (see ETSI TS 102 232-1 [9] clause 5.2.13) shall be populated by the MDF3 with the IPID value.
NOTE: ETSI TS 102 232-1 [9] specifies in clause 6.4 a transport layer based on TCP. However, based on agreement between network operator and LEA, in scenarios where it may not be possible to achieve the necessary LI data rates based on the transport layer based on single TCP connection, alternative profiles may be considered (e.g. based on UDP, multi path TCP or other protocols). Any alternative profile needs to ensure that LI reliability, security and completeness requirements as specified in TS 33.126 [3] are met.
5.5.4 Service scoping
The MDF2 and MDF3 shall be able to deliver the IRI messages and the CC to the LEMF over LI_HI2 and LI_HI3 respectively, according to the provisioned service scoping (see clause 5.2.4).
5.5.5 IRI Target Identifiers
The MDF shall populate the TargetIdentifiers field of the IRIPayload defined in Annex A with all Target Identifiers available at the MDF. For all Identifiers received in the LI_X2 "Matched Target Identifier" conditional attribute (see clause 5.3.2), the MDF shall include the relevant Identifier with the provenance set to "matchedOn". For all Identifiers received in the the LI_X2 "Other Target Identifier" conditional attribute (see clause 5.3.2), the MDF shall include the relevant Identifier with the provenance set to "other". For all Identifiers present in the xIRI payload, the MDF shall include the relevant Identifier with the provenance set to "observed". For all Identifiers present in the provisioning message received over X1, the MDF shall include the relevant Identifier with the provenance set to "lEAProvided". For all Identifiers present in the MDF that are not reported as other TargetIdentifiers, the MDF shall include the relevant Identifier with the provenance set to "other".
5.6 Protocols for LI_HI4
5.6.1 General
Functions having an LI_HI4 shall support the use of ETSI TS 102 232-1 [9] to realise the interface.
In the event of a conflict between ETSI TS 102 232-1 [9] and the present document, the terms of the present document shall apply.
5.6.2 Usage for realising LI_HI4
The LI Notification messages sent over LI_HI4 are structured as a header and a payload. The header contains general information like LIID, timestamp (as for example defined in ETSI TS 102 232-1 [9]). The payload contains the administrative information such as notification. Details of the LI Notification messages can be found in Annex B of the present document.
Where the LI_HI4 interface is present alongside an LI_HI2 interface or LI_HI3 interface, the LI Notification messages shall be transmitted along the same connection as the IRI messages or CC. Where ETSI TS 102 232-1 [9] is used for LI_HI2 or LI_HI3, messages defined as passing over the LI_HI4 interface shall be passed in the hI4Payload sequence.
The MDF2/MDF3 shall support generation LI Notification messages for at least the following events:
– Activation of an interception at the MDF2/MDF3 via LI_X1.
– Modification of an interception at the MDF2/MDF3 via LI_X1.
– Deactivation of an interception at the MDF2/MDF3 via LI_X1.
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 [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.
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 [6] clause 8.3), populated as follows:
Table 5.7.2-1: LDTaskObject representation of LI_HIQR request
|
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 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.
Table 5.7.2-2: RequestDetails structure
|
Field |
Value |
M/C/O |
|
Type |
Shall be set to one of the RequestType values as defined in table 5.7.2-3. |
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). |
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.
Table 5.7.2-3: RequestType Dictionary for LI_HIQR
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
RequestType |
|
Defined DictionaryEntries |
|
|
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". |
Table 5.7.2-3 is formatted in accordance with ETSI TS 103 120 [6] Annex F.
5.7.2.2 Request parameters
The RequestValues field shall contain one of the following:
– SUPI, given in either SUPIIMSI or SUPINAI formats as defined in ETSI TS 103 120 [6] clause C.2.
– SUCI, given as defined in table 5.7.2-4 below.
– 5G-S-TMSI, given as defined in table 5.7.2-4 below.
– 5G-GUTI, given as defined in table 5.7.2-4 below.
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 shall also be present as RequestValues:
– NRCellIdentity, given as defined in table 5.7.2-4 below.
– TrackingAreaCode, given as defined in table 5.7.2-4 below.
The following RequestValue FormatTypes (see ETSI TS 103 120 [6] clause 8.3.5.4) are defined (which are not otherwise defined elsewhere).
Table 5.7.2-4: RequestValue FormatType extensions for LI_HIQR Requests
|
Format Owner |
Format Name |
Description |
Format |
|---|---|---|---|
|
3GPP |
SUCI |
Subscription Concealed Identifier as per TS 23.003 [19] clause 2.2B. |
TS 29.509 [45] clause 6.1.6.3.2 |
|
3GPP |
5GSTMSI |
Shortened form of the 5G-GUTI as defined in TS 23.003 [19] 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 [19] 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 [19] clause 19.6A. |
TS 29.571 [17] clause 5.4.2 |
|
3GPP |
TrackingAreaCode |
Tracking area code as defined in TS 23.003 [19] clause 19.4.2.3. |
TS 29.571 [17] clause 5.4.2 |
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).
Table 5.7.2-4A: LDTaskFlags for LI_HIQR Requests
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
LIHIQRFlags |
|
Defined DictionaryEntries |
|
|
Value |
Meaning |
|
IncludeNCGIInResponse |
A request for returning the NCGI in the response. |
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 [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:
Table 5.7.2-5: 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 |
|
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 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 [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.
Table 5.7.2-6: 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 [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.
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:
Table 5.8-1: RequestDetails structure for LI_XQR
|
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 |
|
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 [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.
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:
Table 5.8-2: 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 [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 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.
5.10 Protocols for LI_ST interface
5.10.1 Overview
LI_ST shall be realised using a dedicated separate instance of the Nudsf_DataRepository service as defined in TS 29.598 [64] subject to the following terms.
The LISSF shall adopt the role of the NF Service Provider as described in TS 29.598 [64] clause 5.2.1. The LISSF may be realised as a standalone function or within the ADMF. In either case it shall meet the requirements set out in TS 33.127 [5] clause 6.2.3.8.
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 TS 29.598 [64] clause 6.1.3.1) and any necessary keys for authentication.
5.10.2 Storage
When an LI function wishes to store LI state in the LISSF, it shall perform the Record Create service operation as described in TS 29.598 [64] clause 5.2.2.3.1. 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 TS 29.598 [64] clause 6.1.6.2.3)
Table 5.10.2-1: Minimum information elements for RecordMeta structure
|
Field Name |
Description |
M/C/O |
|
NFInstanceID |
The NF instance ID associated with the NF in which the LI function is located, if applicable (see TS 29.571 [17] clause 5.3.2). |
C |
|
NEID |
The LI_X1 identifier associated with the LI function. |
M |
|
XID |
XID for the task that the state is associated with, if applicable. |
C |
|
DID |
DID 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.
5.10.3 Retrieval
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 TS 29.598 [64] clause 5.2.2.2.2. If the LI function does not know the RecordID, it shall perform a search as described in TS 29.598 [64] clause 5.2.2.2.6 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.
5.10.4 Removal
When an LI function wishes to remove records from the LISSF, it shall perform a Record Delete service operation as described in TS 29.598 [64] clause 5.2.2.5.
The LIPF shall always be able to remove records from the LISSF.
5.11 Protocols for LI_HILA
5.11.1 General
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.
5.11.2 Usage for realising LI_HILA
5.11.2.1 Request structure
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:
Table 5.11.2.1-1: LDTaskObject representation of LI_HILA request
|
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 |
The use of any other LDTaskObject parameter is outside the scope of the present document.
Table 5.11.2.1-2: RequestDetails structure
|
Field |
Value |
M/C/O |
|
Type |
Shall be set to one of the HILARequestType values as defined in table 5.11.2.1-3. |
M |
|
ReqCurrentLoc |
The LARF shall invoke a ProvideLocationInfo service operation (see TS 29.518 [16] clause 5.5.2.4) as described in clause 7.3.5.4. |
M |
|
RequestValues |
Set to the target identifier (see clause 5.11.2.2). |
M |
Table 5.11.2.1-3: RequestType Dictionary for LI_HILA
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
RequestType |
|
Defined DictionaryEntries |
|
|
Value |
Meaning |
|
LocationAcquisition |
A request for location information of the target, consisting at least of the TAI and the NCGI. |
5.11.2.2 Request parameters
The RequestValues field shall contain at least one of the following:
– SUPI, given in either SUPIIMSI or SUPINAI formats as defined in ETSI TS 103 120 [6] clause C.2.
– GPSI, given in either GPSIMSISDN or GPSINAI formats as defined in ETSI TS 103 120 [6] clause C.2.
5.11.2.3 Response structure
The LI_HILA request is used to generate a request to the LARF over LI_XLA (see clause 5.12.2) to retrieve the target’s network-provided location.
If delivery via the LI_HI2 is required, the LARF will send the acquisition response as a AMFLocationUpdate 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 responsegiven 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:
Table 5.11.2.3-1: LocationResponseDetails
|
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-2. |
C |
Table 5.11.2.3-2: LocationOutcome
|
Field |
Description/Value |
M/C/O |
|
SUPI |
SUPI associated with the UE for which location is returned. |
M |
|
GPSI |
GPSI 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 |
|
Location |
Location of the target if determined by the network. – It shall include the following:a JSON ProvideLocInfo structure as defined in TS 29.518 [22] clause 6.4.6.2.6, in base-64 encoding, in case the location could be determined. |
C |
|
FailureCause |
If 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 TS 29.571 [17] clause 5.2.4.1 in base-64 encoding. |
C |
5.12 Protocols for LI_XLA
5.12.1 General
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_XLA
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:
Table 5.12.2.1-1: LocationAcquisitionRequest representation for an XLA request
|
Field |
Description |
M/C/O |
|
RequestValues |
Set to the target identifier specified in the LI_HILA request (see clause 5.11.2). |
M |
|
ReqCurrentLoc |
The LARF shall invoke a ProvideLocationInfo service operation (see TS 29.518 [16] clause 5.5.2.4) as described in clause 7.3.5.4. 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 |
|
HILADelivery |
Based 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 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 |
||
Table 5.12.2.1-2: HI2Delivery structure
|
Field |
Description |
M/C/O |
|
XID |
The 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 |
|
ListOfDestinations |
Delivery endpoints for LI_X2_LA for the LARF in the 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.