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.

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.

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

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.

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

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.

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.

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