Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.128  Word version:  18.7.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  Transport and Communications Protocolp. 31

5.1  Generalp. 31

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 clause 6 and clause 7.

5.2  Protocols for LI_X1 and LI_T interfacesp. 31

5.2.1  General usage of ETSI TS 103 221-1p. 31

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/MDF3 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/MDF3. Clause 6 and clause 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.
Up

5.2.2  Usage for realising LI_X1p. 32

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

5.2.3  Usage for realising LI_X1 (management)p. 32

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 scopingp. 32

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

5.2.5  Usage for realising LI_T2p. 33

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 ProductID 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 ProductID 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.
When the IRI-TF reports the status of a Task via a GetTaskDetailsResponse or GetAllDetailsResponse, the IRI-TF shall also report the details of each 'delegated' Task that the IRI-TF is maintaining at an IRI-POI as a result of that Task. The details are given using the DelegatedTaskStatus structure described in Table 5.2.5-1 below, which is placed in the TaskStatusExtensions element of the TaskStatus structure in the response (see ETSI TS 103 221-1 [7] clause 6.4.2.2).
ETSI TS 103 221-1 [7] field name Description M/C/O
ListOfDelegatedTasks List of DelegatedTask structures (see Table 5.2.5-2).M
ETSI TS 103 221-1 [7] field name Description M/C/O
NEID NE Identifier (see ETSI TS 103 221-1 [7] clause 6.1) of the triggered POI where the TF is maintaining the relevant Task.M
TaskDetailsContains a copy of the relevant Task, as maintained by the TF at the triggered POI.M
TaskStatusCopy of the last TaskStatus information received from the triggered POI regarding the relevant Task, if available.C
LastTaskStatusTimeTime at which the TaskStatus information was received. Shall be present if TaskStatus is supplied.C
Up

5.2.6  Usage for realising LI_T3p. 33

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 ProductID 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 ProductID 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.
When the CC-TF reports the status of a Task via a GetTaskDetailsResponse or GetAllDetailsResponse, the CC-TF shall also report the details of each 'delegated' Task that the CC-TF is maintaining at an CC-POI as a result of that Task, using the mechanism described in clause 5.2.5.
Up

5.2.7  Usage for realising LI_XEM1p. 34

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.
ETSI TS 103 221-1 [7] field name Description M/C/O
XIDShall 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.
Identifier type Owner ETSI TS 103 221-1 [7] TargetIdentifier type Definition
IdentityAssociationTargetIdentifier3GPPTargetIdentifierExtension / IdentityAssociationTargetIdentifierEmpty 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.
ETSI TS 103 221-1 [7] field name Description M/C/O
XIDShall be set to the value assigned by the LIPFM
The LIPF should send one ActivateTask command to each IEF.
Up

5.3  Protocols for LI_X2 and LI_X3p. 35

5.3.1  General usage of ETSI TS 103 221-2p. 35

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/LI_T3 triggering message, as appropriate), noting that the appropriate XID may be given in the ProductID field.
Up

5.3.2  Usage for realising LI_X2p. 35

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 signalling 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 TS33128Payloads.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) shall 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 conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.8) shall be set to indicate the POI (within the NF) that generated the xIRI for the conditional attribute field.
Up

5.3.3  Usage for realising LI_X3p. 35

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) shall 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 conditional attribute (see ETSI TS 103 221-2 [8] clause 5.3.8) shall be set to indicate the POI (within the NF) that generated the xCC for the conditional attribute field.
If defined by LI for a specific 3GPP-defined-network deployment (see clause 6) or a specific 3GPP-defined service (see clause 7), the POI may use the Additional XID Related Information attributes to facilitate efficient delivery of xCC, as specified in ETSI TS 103 221-2 [8] clause 5.3.22.
Up

5.3.4  Service scopingp. 36

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_LAp. 36

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_HI1p. 36

5.4.1  Generalp. 36

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.
ETSI TS 103 120 [6] field name Description M/C/O
ReferenceSet to the LIID associated with the interception.M
DesiredStatus Set to "Active" to indicate that LI should commence. M
TimeSpanAt a minimum, EndTime shall be set.M
TargetIdentifier See Table 5.4.1-2.M
DeliveryTypeSet to the appropriate delivery type (IRI, CC or both).M
DeliveryDetailsShall include at least one appropriate LI delivery destination.M
ETSI TS 103 120 [6] field name Description M/C/O
TargetIdentifierValuesShall contain at least one valid target identifier.M
ServiceTypeIf used, set to the appropriate service scoping dictionary value as defined in clause 5.4.2.O
Up

5.4.2  Service scopingp. 37

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.
Dictionary Owner Dictionary Name
3GPPServiceType
Defined DictionaryEntries
Value Meaning
VoiceService scoping shall include the Voice service type as given in clause 4.4.2.
DataService scoping shall include the Data service type as given in clause 4.4.2.
MessagingService scoping shall include the Messaging service type as given in clause 4.4.2.
PTCService scoping shall include the Push-to-Talk service type as given in clause 4.4.2.
LALSService scoping shall include the LALS service type as given in clause 4.4.2.
RCSService scoping shall include the RCS service type as given in clause 4.4.2.
Up

5.4.3  Location acquisitionp. 37

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.
Dictionary Owner Dictionary Name
3GPPLATaskFlag
Defined DictionaryEntries
Value Meaning
HILADeliveryThe location information shall be delivered via the LI_HILA interface.
HI2DeliveryThe location information shall be delivered via the LI_HI2 interface.
Up

5.5  Protocols for LI_HI2 and LI_HI3p. 37

5.5.1  Generalp. 37

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_HI2p. 38

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 clause 6 and clause 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 ETSI TS 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.
Up

5.5.3  Usage for realising LI_HI3p. 38

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 clause 6 and clause 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.
Up

5.5.4  Service scopingp. 38

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 Identifiersp. 38

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

5.6  Protocols for LI_HI4p. 39

5.6.1  Generalp. 39

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_HI4p. 39

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

Up   Top   ToC