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.

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.

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

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.

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

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.

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.

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.

The IEF may be reconfigured to send identity associations to a different ICF using a ModifyTask message to modify the delivery destinations. The IEF shall be disabled by sending the following DeactivateTask message from the LIPF.

The LIPF should send one ActivateTask command to each IEF.

The LIPF shall be able to provision the POI, TFs and the MDF2/MDF3 with Traffic Policies as described in ETSI TS 103 221-1 [7] Annex F. Whether the Traffic Policies are applied on a per-task basis (at the POIs or the MDF2/MDF3) or they are applied at the LIID level is up to implementation. Additional information on the use of Traffic Policies in this document is described in clause 4.5.

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. Table 5.3.1-1 shows the minimum details of xIRI records sent over LI_X2 and xCC messages sent over LI_X3 in addition to those described in 103 221-2 [8].

Table 5.3.1-2 shows the minimum details for the Conditional Attribute Fields included in xIRI records sent over LI_X2 and xCC messages sent over LI_X3 in addition to those described in 103 221-2 [8].

Additional details specific to xIRI records can be found in clause 5.3.2. Additional details specific to xCC messages can be found in clause 5.3.3.

Table 5.3.2-1 shows the minimum details of xIRI records sent over LI_X2 in addition to those described in 103 221-2 [8] and clause 5.3.1.

Table 5.3.2-2 shows the minimum details for the Conditional Attribute Fields included in xIRI records sent over LI_X2 and xCC messages sent over LI_X3 in addition to those described in 103 221-2 [8] and Table 5.3.1-2.

Table 5.3.2-3 shows details for the @TS33128Payloads.XIRIPayload.

The TLS transport profile (see ETSI TS 103 221-2 [8] clause 6) shall be supported and used by default.

Table 5.3.3-1 shows the minimum details of xCC messages sent over LI_X3 in addition to those described in 103 221-2 [8] and clause 5.2.1.

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.

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

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

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.

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.

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.

Functions having an LI_HI1 interface (i.e. the ADMF) shall be able to receive Traffic Policies as applicable to an intercept task over the LI_HI1 interface (see clause 4.5.2). Where ETSI TS 103 120 [6] is used to realise LI_HI1, and where the details in clause 5.4.1 apply, when the use of Traffic Policies is required, the ListOfTrafficPolicyReferences field in a given LITaskObject shall be used to identify the appropriate Traffic Policies for that task. The referenced TrafficPolicyObjects shall be defined as described in ETSI TS 103 120 [6] prior to being referenced in an LITaskObject. Unless otherwise specified, Traffic Policies shall not be used in place of service scoping. Additional information on the use of Traffic Policies in this document is described in clause 4.5.

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. Messages sent over LI_HI2 or LI_HI3 are structured as a header and a payload. The header contains general information like LIID, timestamp, correlation information. Table 5.5.1-1 shows the minimum header details for IRI messages sent over LI_HI2 and CC messages sent over LI_HI3 in addition to those described in 102 232-1 [9] and ETSI TS 102 232-7 [10].

The payload contains information that the MDF has received from sources in the network, such as the POI as described in clauses 6 and 7 of the present document.

The payload of IRI messages contains intercept related information. Details of the IRI messages can be found in Annex A of the present document. Table 5.5.2-1 shows the minimum payload details for IRI messages sent over LI_HI2 in addition to those described in 102 232-1 [9] and ETSI TS 102 232-7 [10].

Table 5.5.2-2 shows details for the @TS33128Payloads.IRIPayload.

The payload of CC messages contains content of communication. Details of the CC can be found in Annex A of the present document. Table 5.5.3-1 shows the minimum payload details for CC messages sent over LI_HI3 in addition to those described in 102 232-1 [9] and ETSI TS 102 232-7 [10].

Table 5.5.3-2 shows details for the @TS33128Payloads.CCPayload.

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

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

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.

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.