7.10 LI in VPLMN for IMS-based services with home-routed roaming
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.10.1 Background
This clause defines protocol and procedures to support the LI in the VPLMN for IMS-based services with home-routed roaming architecture where IMS signaling (e.g. CSCFs) and media functions (e.g. IMS-AGW) are in the HPLMN. The scope of LI functions defined here are the following in the VPLMN:
– IMS-based voice services.
– SMS over IP.
For IMS-based voice services and the SMS over IP, the target can be an inbound roaming UE or a non-local ID.
As defined in TS 33.127 [5] clause 7.4.7.4.2, LMISF-IRI, LMISF-CC, BBIFF-C and BBIFF-U handle the LI in the VPLMN for IMS-based services with home routed roaming architecture.
NOTE 1: When N9 is the interface between the two PLMNs for the user plane data, the LI architecture is referred to as N9HR LI. With N9HR LI, the BBIFF-C is present in the SMF and the BBIFF-U is present in the UPF.
NOTE 2: When S8 is the interface between the two PLMNs for the user plane data, the LI architecture is referred to as S8HR LI. With S8HR LI, the BBIFF-C and BBIFF-U are combined into BBIFF and is present in the SGW. When SGW is deployed with CUPS, the S8U is the interface between the two PLMNs for the user plane data and in this case, the BBIFF-C is present in the SGW-C and BBIFF-U is present in the SGW-U.
This clause uses the term "HR LI" in referring to the common functions associated with the N9HR LI and S8HR LI collectively.
The HR LI includes two phases of LI processing with the following scope:
– Phase 1 – Initial configuration and target checking, applies to all in-bound roaming UEs with home-routed roaming and using IMS-based services. No interception is done in this phase.
– Phase 2 – Applies to specific target UEs or UEs in communication with a target non-local ID. Interception is done in this phase.
The details of the above two phases of LI processes are described in TS 33.127 [5] clause 7.4.7.4.11.
7.10.2 Backward compatibility
The present document provides two options for stage 3 definitions for implementing S8HR LI:
– Use LI_X1, LI_X2 and LI_X3 interfaces specified below in the present document.
– Use TS 33.107 [36] natively as defined in that document.
In both cases, the present document specifies the stage 3 for the LI_HI1 and LI_HI2 interfaces. Only the first option indicated above is used for N9HR LI.
7.10.3 HR LI Phase 1
7.10.3.1 Overview
The Phase-1 of HR LI that applies to all inbound roaming UEs with home-routed roaming using the IMS-based services include the functions that revolve around the following interfaces (see TS 33.127 [5]):
– LI_X1: Used by the LIPF to provision the BBIFF-C/BBIFF and optionally, the LMISF-IRI to enable the same for HR LI (aka initial configuration of HR LI).
– LI_T3: Used by the BBIFF-C to instruct the BBIFF-U to capture and deliver the IMS signaling related user plane packets of inbound roaming UEs to the LMISF-IRI.
– LI_X2_LITE: Used by the BBIFF-C/BBIFF to carry the control plane information (e.g. packet data connection related notifications, UE location) to LMISF-IRI for inbound roaming UEs.
– LI_X3_LITE_S: Used by the BBIFF-U/BBIFF to forward the IMS signalling related user plane packets of inbound roaming UEs to the LMISF-IRI.
The triggering interface LI_T3 is not used in the case of BBIFF in SGW. The LI_X3_LITE_S is also used in HR LI Phase-2.
The LI_X2_LITE shall be realized using the X2 protocol as defined in ETSI TS 103 221-2 [8]. Likewise, the LI_X3_LITE_S and LI_X3_LITE_M shall be realized using the X3 protocol as defined in ETSI TS 103 221-2 [8].
7.10.3.2 Provisioning over LI_X1
7.10.3.2.1 General
For Phase-1 of HR LI, the following LI functions are provisioned over LI_X1 by the LIPF using the X1 protocol defined in ETSI TS 103 221-1 [7] with the LIPF playing the role of ADMF and the following LI functions playing the role of NE as per the reference model depicted in ETSI TS 103 221-1 [7]:
– BBIFF-C present in the SMF.
– BBIFF-C present in the SGW-C.
– BBIFF present in the SGW.
– LMISF-IRI.
As described in clause 7.10.1, the Phase-1 of HR LI applies to all inbound roaming UEs that use the IMS-based services with home-routed roaming. The target identities "HR" and "IMSSignaling" are used for Phase-1 of HR LI.
7.10.3.2.2 Provisioning of BBIFF-C and BBIFF
The minimum details of LI_X1 ActivationTask message is shown in table 7.10.3.2-2.
Table 7.10.3.2-1: Void
Table 7.10.3.2-2: ActivateTask message for activating BBIFF-C and BBIFF
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
Shall be set to a value assigned by the LIPF. This shall be same as the XID used for ActivateTask as shown in table 7.10.3.2-4 when LMISF-IRI is configured using the ActivateTask. |
M |
|
TargetIdentifiers |
Shall contain Target Identifiers of type "HR" and "IMSSignaling" (see table 7.10.3.2-3). |
M |
|
DeliveryType |
Set to "X2andX3". |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-IRI to which the xIRI and xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
Table 7.10.3.2-3: Target Identifier Type for enabling HR LI
|
Identifier type |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
HR |
TargetIdentifierExtension /HR |
Empty tag (see XSD schema) |
|
IMSSignaling |
TargetIdentifierExtension/IMSSignaling |
Empty tag (see XSD schema) |
7.10.3.2.3 Provisioning of LMISF-IRI
The LMISF-IRI is listed as the delivery endpoint over LI_X2_LITE for xIRI generated by the BBIFF-C/BBIFF and for the xCC generated by the BBIFF-U/BBIFF.
The provisioning of LMISF-IRI is to enable it to receive the xIRIs and xCC sent from the BBIFF-C (SMF, SGW-C), BBIFF-U (UPF, SGW-U) and BBIFF (SGW). As an alternate deployment option, LMISF-IRI may be presumed to be enabled to receive such xIRI/xCC by default. This clause does not apply to such alternate deployment option.
Table 7.10.3.2-4 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the LMISF-IRI for Phase-1.
Table 7.10.3.2-4: ActivateTask message for activating the LMISF-IRI for Phase-1
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
Shall be set to a value assigned by the LIPF. This shall be same as the XID used for ActivateTask as shown in table 7.10.3-2. |
M |
|
TargetIdentifiers |
Shall contain two Target Identifiers of type "HR" and "IMSSignaling" (see table 7.10.3.2-3). |
M |
|
DeliveryType |
Set to "X2andX3". LMISF-IRI shall use this only to enable the receiving of xIRI and xCC from the BBIFF-C/BBIFF. |
M |
|
ListOfDIDs |
Shall be given as an empty list, since DIDs are not required in LMISF-IRI for Phase-1. |
M |
7.10.3.3 Generation of xIRI over LI_X2_LITE
7.10.3.3.1 General
LI_X2_LITE is an interface between the BBIFF-C/BBIFF to the LMISF-IRI. The xIRIs are generated at the BBIFF-C/BBIFF and are sent over LI_X2_LITE interface to the LMISF-IRI. These xIRIs are applicable to HR LI Phase-1 only.
For N9HR LI, the BBIFF-C present in the SMF shall generate the xIRIs as described in clause 7.10.3.3.2. For S8HR LI, the BBIFF-C present in the SGW-C and BBIFF present in the SGW shall generate the xIRIs as defined in clause 7.10.3.3.3.
The xIRIs are generated only when the following prior conditions are met:
– ActivateTask with target identity "HR" and "IMSSignaling" is received with X2 being included in the delivery type.
– The MCC + MNC of the Operator Identifier field of the DNN (for N9HR) or APN (for S8HR) is different from the MCC+MNC configured in the SMF (N9HR) or SGW-C/SGW (S8HR) – see TS 29.502 [16], clause 6.1.6.2.2 and 23.003 [19] clause 9.1.2.
– The Network Identifier field of DNN (for N9HR) or APN (for S8HR) contains "IMS" (IMS services) – see GSMA IR.88 [67].
The first point is indicating that HR LI is enabled (see clause 7.10.3.2.2). The second point is telling that the UE is an inbound roamer with home-routed based roaming. The third point is telling that the PDU session/PDN connection is for IMS services.
7.10.3.3.2 N9HR LI
The BBIFF-C present in the SMF shall generate the following xIRI when the prior conditions defined in clause 7.10.3.3.1 are met:
– N9HRPDUSessionInfo.
The main purpose of the xIRI is to report the UE location, PDU session ID and the SMF identity. The scenarios that result in the above xIRI are listed below and apply to all inbound roaming UEs with home-routed roaming and using IMS services:
– PDU session is established with the creation of a default QoS flow for IMS signaling.
– PDU session is modified with the creation of a dedicated QoS flow used for IMS media.
– PDU session is modified with the updates to the QoS flow.
– PDU session is modified with the deleting of dedicated QoS flow used for IMS media.
– PDU session is deleted.
– MA PDU session is created, modified or deleted.
– SMF relocation.
– New UE location due to UE requested or network initiated service request.
– New UE location due to hand-over situations including EPS to 5GS handover.
– New UE location due to tracking area updates or routing area updates.
– New SMF from the SMF set is taking over the PDU session.
– HR LI is enabled with an established PDU session.
The exact trigger for the xIRI is subject to implementation, however, the following can be used as a general guidance along with observing the prior conditions listed in clause 7.10.3.3.1:
– SMF receives the Nsmf_PDU_Session_Create response message with n1SmInfoToUe IE containing the PDU SESSION ESTABLISHMENT ACCEPT (see TS 29.502 [16]) from the H-SMF and sends the NAS message (via AMF) PDU SESSION ESTABLISHMENT ACCEPT to the UE as a part of PDU session establishment procedures. This may also happen with MA PDU session establishment procedures, or during handover procedures with access type change, or as a part of SMF relocation procedures.
– SMF receives an Nsmf_PDUSession_UpdateSMContext request from the AMF with a new UE location. This may happen whenever a PDU session or a MA PDU session is modified with the addition, modification or deletion of a dedicated QoS flow. This may also happen for UE-initiated or network-initiated service request procedures, or as a part of the handover procedures, or as a part of the tracking area update procedures.
– When a new SMF (e.g. in the SMF set) takes over the control for the PDU session.
– When an ActivateTask is received from the LIPF over LI_X1 (see clause 7.10.3.2.2) to enable the HR LI, the BBIFF-C present in the SMF detects that a PDU session for IMS services is already established for an inbound roaming UE with home-routed roaming.
NOTE: The sending of xIRI for each already established PDU session may result in a significant number of xIRI messages from the BBIFF-C to the LMISF-IRI.
The contents of xIRI N9HRPDUSessionInfo record is shown in table 7.10.3.3-1 below.
Table 7.10.3.3-1: Payload of N9HRPDUSessionInfo record
|
Field name |
Description |
M/C/O |
|
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU Session_CreateSMContext service operation). |
M |
|
pEI |
PEI associated with the PDU session, if available. |
C |
|
pDUSessionID |
PDU Session ID. See TS 24.501 [13] clause 9.4. |
M |
|
location |
UE location information provided by the AMF. |
C |
|
sNSSAI |
Slice identifiers associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.12.2.2. |
C |
|
dNN |
Data Network Name associated with the UE traffic, as defined in TS 23.003[19] clause 9A and described in TS 23.501 [2] clause 4.3.2.2. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
|
messageCause |
Included to indicate why the xIRI is generated (see table 7.10.3.3-2). |
M |
Table 7.10.3.3-2: messageCause details
|
Field name |
Description |
|
pDUSessionEstablished |
Indicates that the PDU session is established. |
|
pDUSessionModified |
Indicates that the PDU session is being modified. |
|
pDUReleased |
Indicates that the PDU session is being released. |
|
updatedLocationAvailable |
Indicates that an updated UE location is available |
|
sMFChanged |
Indicates that the SMF that is handling the PDU session is changed. |
|
other |
Indicates that cause is other than those listed elsewhere in this table. |
|
hRLIEnabled |
Indicates that the HR LI is enabled after the PDU session for IMS services is established. |
The xIRIs shall include the Network Function ID (NFID), a conditional attribute field as defined in ETSI TS 103 221-2 [8], with the V-SMF identity.
Handling of this xIRI within the LMISF-IRI is described in clause 7.10.3.4.
7.10.3.3.3 S8HR LI
The BBIFF-C present in the SGW-C and BBIFF present in the SGW shall generate the following xIRI for the purpose of S8HR LI when the prior conditions defined in clause 7.10.3.3.1 are met:
– S8HRBearerInfo.
The main purpose of the xIRI is to report the UE location and the SGW/SGW-C identity to the LMISF-IRI. This xIRI is generated for the following scenarios that apply to all inbound roaming UEs with home-routed roaming and using IMS services:
– PDN connection is established with the creation of a default bearer for IMS signaling.
– Dedicated bearer is activated for the for IMS media.
– Dedicated bearer is updated for IMS media.
– Dedicated bearer is deactivated for IMS media.
– PDN is disconnected.
– SGW-C/SGW relocation.
– New UE location due to UE requested or network initiated service request.
– New UE location due to hand-over situations including 5GS to EPS handover.
– New UE location due to tracking area updates or routing area updates.
– HR LI is enabled with an established PDN connection with the creation of a default bearer.
The exact trigger for the xIRI is subject to implementation, however, the following can be used as a general guidance observing the prior conditions listed in clause 7.10.3.3.1:
– SGW-C/SGW receives a Create Session Response from the PGW-C/PGW and forwards the same to the MME as a part of PDN connection establishment procedures that creates the default bearer used for IMS signaling or as a part of the handover procedures that results in the SGW-C/SGW relocation or 5GS to EPS relocation.
– SGW-C/SGW receives a Create Session Response from the MME and forwards the same to the PGW-C/PGW as a part of dedicated bearer activation procedure on a PDN connection used for IMS media.
– SGW-C/SGW receives an Update Bearer Response from MME and forwards the same to the PGW-C/PGW as a part of bearer update procedures with or without the bearer update QoS.
– SGW-C/SGW receives a Delete Bearer Response from MME and forwards the same to the PGW-C/PGW as a part of bearer deactivation procedure.
– SGW-C/SGW receives a Delete Session Request from the MME and forwards the same to the PGW-C/PGW as a part of PDN disconnection procedures. The procedures potentially have the last known UE location.
– SGW-C/SGW receives a Create Session Request from the MME and sends a Modify Bearer Request to the PGW-C/PGW as a part of tracking area/routing area update procedures with a change of SGW-C/SGW. The procedures potentially have a new UE location.
– SGW-C/SGW receives a Modify Bearer Request from the MME and sends the same to the PGW-C/PGW as a part of Service Request handling procedures, or hand-over procedures, or tracking area/routing area update procedures without a change in the SGW-C/SGW. The procedures potentially have a new UE location.
– When an ActivateTask is received from the LIPF over LI_X1 (see clause 7.10.3.2.2) to enable the HR LI, the BBIFF-C/BBIFF present in the SGW-C/SGW detects that a PDN connection with a default bearer used for IMS services is already established for an inbound roaming UE with home-routed roaming.
NOTE: The sending of xIRI for each already established PDN connection may result in a significant number of xIRI messages from the BBIFF-C/BBIFF to the LMISF-IRI.
The details of the xIRI S8HRBearerInfo record is defined in table 7.10.3.3-3 below.
Table 7.10.3.3-3: Payload for S8HRBearerInfo record
|
Field name |
Description |
M/C/O |
|
iMSI |
IMSI associated with the PDN connection on which a bearer is created. |
M |
|
iMEI |
IMEI associated with the PDN connection on which a bearer is created, if available. |
C |
|
bearerID |
The identity of the EPS bearer. |
M |
|
linkedBearerID |
The identity of the default bearer when the bearerID is for dedicated bearer. |
C |
|
location |
Location information provided by the MME. |
C |
|
aPN |
Packet Data Network to which the connection is being made, as defined in TS 23.003[19] clause 9A and described in TS 23.401 [50] clause 4.3.2.2. Applicable for PDN connection establishment. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
|
sGWIPAddress |
IP Address of the SGW-C or SGW as applicable and when available. |
C |
|
messageCause |
Included to indicate why the xIRI is generated (see table 7.10.3.3-4). |
M |
Table 7.10.3.3-4: messageCause details
|
Field name |
Description |
|
bearerActivated |
Indicates that the bearer is activated (default or dedicated). |
|
bearerModified |
Indicates that the bearer is being modified. |
|
bearerDeleted |
Indicates that the bearer is being deactivated. |
|
pDNDisconnected |
Indicates that the PDN is disconnected. |
|
updatedLocationAvailable |
Indicates that an updated UE location is available. |
|
sGWChanged |
Indicates that the SGW that is handling the PDN connection is changed. |
|
other |
Indicates that cause is other than those listed elsewhere in this table. |
|
hRLIEnabled |
Indicates that the HR LI is enabled after the PDN connection with default bearer for IMS services is established. |
All of the xIRIs listed above shall also include the Network Function ID (NFID), a conditional attribute field as defined in ETSI TS 103 221-2 [8], with the SGW-C/SGW identity.
Handling of this xIRI within the LMISF-IRI is described in clause 7.10.3.4.
7.10.3.4 LMISF-IRI handling of xIRIs received over LI_X2_LITE
7.10.3.4.1 Handling of xIRIs
The LMISF-IRI that receives the xIRI, N9HRPDUSessionInfo record shall store or update the record with the information received in the xIRI (e.g. UE location) as applicable, for the future handling.
The LMISF-IRI that receives the xIRI, S8HRBearerInfo record shall store or update the record with the information received in the xIRI (e.g. UE location) as applicable, for the future handling.
The stored record is referred to LI_X2_LITE record in the present document.
7.10.3.4.2 Handling of the stored record
For the N9HR LI related LI_X2_LITE records, the LMISF-IRI shall use the SUPI and PDU Session ID to uniquely associate a record with the inbound roaming UE.
For S8HR LI related LI_X2_LITE records, the LMISF-IRI shall use the IMSI, Linked Bearer ID or the Bearer ID (when the Linked Bearer ID is not present) to uniquely associate a record with the inbound roaming UE.
7.10.3.5 Triggering of BBIFF-U from BBIFF-C over LI_T3
7.10.3.5.1 General
With HR LI Phase-1, the user plane packets from the IMS signaling channel are delivered to the LMISF-IRI for all inbound roaming UEs with home-routed roaming.
When BBIFF is separated into BBIFF-C and BBIFF-U, these user plane packets are captured at the BBIFF-U. In order to enable the BBIFF-U to do that function, the BBIFF-C triggers the BBIFF-U over the LI_T3 interface.
The BBIFF-U delivers the user plane from the IMS signaling channel over the LI_X3_LITE-S interface to the LMISF-IRI.
7.10.3.5.2 N9HR LI
When the BBIFF-C present in the SMF detects that a PDU session is established with IMS signaling related QoS Flow for an inbound roaming UE with home-routed roaming, it shall send an activation message to the BBIFF-U present in the UPF over the LI_T3 interface with the associated QFI value.
The exact point at which the trigger is sent is left to the implementation (preferably, when the SMF receives the N4: Session Establishment/Modification Response from the UPF), however, the BBIFF-C can send the trigger only when the following conditions are met:
– ActivateTask with target identity "HR" and "IMSSignaling" is received with X3 being included in the delivery type.
– The MCC + MNC of the Operator Identifier field of the DNN is different from the MCC+MNC configured in the SMF – see TS 29.502[16] clause 6.1.6.2.2 and 23.203 [19] clause 9.1.2.
– The Network Identifier field of DNN contains "IMS" (IMS services) – see GSMA IR.88 [67].
– The 5QI value associated with the QoS Flow is 5 – see GSMA NG.114 [68].
The first point is indicating that N9HR LI is enabled (see clause 7.10.3.3.1) with a need to capture and deliver the IMS signaling related user plane packets. The second point is telling that the UE is an inbound roamer with Home Routed based roaming. The third point is telling that the PDU session is established for IMS services. The fourth point is telling that the IMS signaling related QoS Flow is established.
If the PDU session for IMS services is already established for an inbound roaming UE with Home-Routed based roaming when the above indicated ActivateTask is received, then the BBIFF-C shall send the trigger at the time Activation Task is received from the LIPF.
The details of ActivateTask sent to the BBIFF-U are shown in table 7.10.3.5-1.
Table 7.10.3.5-1: ActivateTask message for triggering the BBIFF-U in the UPF
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Shall be set to the XID of the Task Object associated with the interception at the BBIFF-C. |
M |
|
TargetIdentifiers |
Packet detection criteria as determined by the BBIFF-C in the SMF, which enables the BBIFF-U to isolate user-plane packets. The BBIFF-U in the UPF shall support the identifier types given in table 6.2.3-7. The target identity type of PDR ID shall be mandatory. The BBIFF-C in SMF shall use the QFI associated with the IMS signaling (5QI = 5) related QoS flow to populate the QFI field within the PDI of PDR ID. |
M |
|
DeliveryType |
Set to "X3Only". |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-IRI to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
Correlation ID to assign to X3 PDUs generated by the BBIFF-U in the UPF. This field is populated with the same CorrelationID the BBIFF-C in the SMF uses for the associated xIRI. |
M |
When the BBIFF-C present in the SMF detects that the PDU session is released (e.g. when SMF receives the N4: Session Release Response from the UPF), it shall send a deactivation message to the BBIFF-U present in the UPF over the LI_T3 interface, if the task is still active in the BBIFF-U.
The BBIFF-C shall also send the deactivation message to the BBIFF-U when a DeactivateTask is received from the LIPF for the XID if the task is still active in the BBIFF-U.
7.10.3.5.3 S8HR LI
When the BBIFF-C present in the SGW-C detects that the default bearer used for IMS signaling is activated on the PDN connection for an inbound roaming UE with home-routed roaming, it shall send an activation message to the BBIFF-U present in the SGW-U over the LI_T3 interface.
The exact point at which the trigger is sent is left to the implementation (preferably, when the SGW-C receives the Sx: Session Establishment/Modification Response from the SGW-U). However, the BBIFF-C can send the trigger only when the following conditions are met:
– ActivateTask with target identity "HR" and "IMSSignaling" is received with X3 being included in the delivery type.
– The MCC + MNC of the Operator Identifier field of the APN is different from the MCC+MNC configured in the SGW/SGW-C – see TS 29.502 [16] clause 6.1.6.2.2 and 23.203 [19] clause 9.1.2.
– The Network Identifier field of APN contains "IMS" (IMS services) – see GSMA IR.88 [67].
– The QCI value associated with the default bearer is 5 – see GSMA NG.114 [68].
The first point is indicating that S8HR LI is enabled (see clause 7.10.3.3.1) with a need to capture and deliver the IMS signaling related user plane packets. The second point is telling that the UE is an inbound roamer with Home Routed based roaming. The third point is telling that the PDN connection is established for IMS services. The fourth point is telling that the IMS signaling bearer is activated.
If the default bearer (for IMS signaling bearer) on the PDN connection is already established for an inbound roaming UE with Home-Routed based roaming when the above indicated ActivateTask is received, then the BBIFF-C shall send the trigger at the time Activation Task is received from the LIPF.
The details of ActivateTask sent to the BBIFF-U present in the SGW-U are shown in table 7.10.3.5-2.
Table 7.10.3.5-2: ActivateTask message for triggering the BBIFF-U in the SGW-U
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Shall be set to the XID of the Task Object associated with the interception at the BBIFF-C. |
M |
|
TargetIdentifiers |
Packet detection criteria as determined by the BBIFF-C in the SGW-C, which enables the BBIFF-U in SGW-U to isolate user-plane packets. The BBIFF-U in the SGW-U shall support the identifier types given in table 6.2.3-7. The target identity type of PDR ID shall be mandatory. The BBIFF-C in SGW-C shall use the F-TIEDs associated with the IMS signaling (QCI = 5) related default bearer to populate the F-TEID field within the PDI of PDR ID. |
M |
|
DeliveryType |
Set to "X3Only". |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-IRI to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
Correlation ID to assign to X3 PDUs generated by the BBIFF-U in the SGW-U. This field is populated with the same CorrelationID the BBIFF-C in the SGW-C uses for the associated xIRI. |
M |
When the BBIFF-C present in the SGW-C detects that the PDN connection is released (e.g. when SGW-C receives the Sx: Session Release Response from the SGW-U), it shall send a deactivation message to the BBIFF-U present in the SGW-U over the LI_T3 interface, if the task is still active in the BBIFF-U.
The BBIFF-C present in the SGW-C shall also send the deactivation message to the BBIFF-U present in the SGW-U when a DeactivateTask is received from the LIPF for the XID if the task is still active in the BBIFF-U.
7.10.3.6 Generation of xCC over LI_X3_LITE_S
7.10.3.6.1 BBIFF-U
The BBIFF-U in UPF and the BBIFF-U in SGW-U shall send the xCC over LI_X3_LITE_S for each of the packet matching the criteria specified in the Triggering message (i.e. Activate Task message) received over the LI_T3 from the BBIFF-C.
7.10.3.6.2 BBIFF
The BBIFF present in the SGW shall send the xCC over LI_X3_LITE_S for each of the packet from the default bearer with the QCI value of 5 (GSMA NG.114 [68]) with following other conditions:
– ActivateTask with target identity "HR" and "IMSSignaling" is received with delivery type "X3Only".
– The MCC + MNC of the Operator Identifier field of the APN is different from the MCC+MNC configured in the SGW – see TS 29.502 [16], clause 6.1.6.2.2 and 23.203 [19] clause 9.1.2.
– The Network Identifier field of APN contains "IMS" (IMS services) – see GSMA IR.88 [67].
The first point is indicating that S8HR LI is enabled (see clause 7.10.3.2.2) with a need to capture and deliver the IMS signaling related user plane packets. The second point is telling that the UE is an inbound roamer with Home Routed based roaming. The third point is telling that the PDN connection is established for IMS services.
The BBIFF in SGW uses the QCI value of 5 (GSMA NG.114 [68]) to identify that the packets are from the IMS signaling bearer.
7.10.3.6.3 X3 PDU format
Each X3 PDU shall contain the contents of the user plane packet given using the GTP-U, IP or Ethernet payload format.
The BBIFF-U/BBIFF shall set the payload format to indicate the appropriate payload type (5 for IPv4 Packet, 6 for IPv6 Packet, 12 for GTP-U Packet as described in ETSI TS 103 221-2 [8] clauses 5.4 and 5.4.13.
7.10.3.7 LMISF-IRI handling of xCC received over LI_X3_LITE_S
The LMISF-IRI shall extract the IMS signaling messages (i.e. SIP messages) from the xCC received over the LI_X3_LITE_S from the BBIFF-U/BBIFF.
The LMISF-IRI shall examine the extracted SIP message for a target match as described in clause 7.10.4.2. If no match is found, then the LMISF-IRI shall store the extracted SIP message for a later use. If a match is found, then the LMISF-IRI shall proceed according to clause 7.10.4.3.
The record that stores the SIP message is referred to as LI_X2_LITE_S record.
7.10.4 HR LI Phase 2
7.10.4.1 Overview
The Phase-2 of HR LI that applies to inbound roaming target UEs that use IMS-based services with home-routed roaming or the inbound roaming UEs that use IMS-based services with home-routed roaming to communicate with the target non-local ID include the functions that revolve around the following interfaces.
– LI_X1: Used by the LIPF to provision the LMISF-IRI, MDF2 and MDF3 with the LI information for a target.
– LI_T1: Used by the LMISF-IRI to instruct the BBIFF-C/BBIFF that IMS media related user plane packets of target’s communication need to be captured and delivered to the LMISF-CC.
– LI_T3: Used by the BBIFF-C to instruct the BBIFF-U to capture and deliver the IMS media related user plane packets of target’s communication to the LMISF-CC.
– LI_X3_LITE_S: Used by the BBIFF-U/BBIFF to forward the IMS signalling related user plane packets of inbound roaming UEs to the LMISF-IRI.
– LI_X3_LITE_M: Used by the BBIFF-U/BBIFF to forward the IMS media related user plane packets of target’s communication to the LMISF-CC.
The triggering interface LI_T3 is not used in the case of BBIFF in SGW. The LI_X3_LITE_S is also used for HR LI Phase-1.
7.10.4.2 Provisioning over LI_X1
7.10.4.2.1 General
For Phase-2 of HR LI, the following LI functions are provisioned over LI_X1 by the LIPF using the X1 protocol defined in ETSI TS 103 221-1 [7] with the LIPF playing the role of ADMF and the following LI functions playing the role of NE as per the reference model depicted in ETSI TS 103 221-1 [7].
– LMISF-IRI.
– MDF2.
– MDF3.
As described in clause 7.10.1, the Phase-2 of HR LI applies to inbound roaming target UEs that use IMS-based services with home-routed roaming or the inbound roaming UEs that use IMS-based services with home-routed roaming to communicate with the target non-local ID. The following target identities are used for Phase-2 of HR LI:
– IMPU.
– IMPI.
– PEIIMEI.
– IMEI.
The target identity in the IMPI format may contain a value derived from a SUPI or an IMSI. The target identity in the IMPU format containing a SIP URI or TEL URI may contain a value derived from a GPSI, MSISDN, an E.164 number, or IMSI. Only IMPU is used for target non-local ID. For triggered LALS, the LTF function associated with LMISF-IRI (see clause 7.3.1 and Annex G) is provisioned with the target identity of IMPU.
7.10.4.2.2 Provisioning of LMISF-IRI
The LMISF-IRI shall be provisioned over LI_X1 by the LIPF for target based interception of IMS services in the VPLMN with home-routed roaming.
The target identities listed in clause 7.10.4.2.1 shall apply for the provisioning of LMISF-IRI with LMISF-IRI playing the combined role of IRI-POI and CC-TF for the interception of IMS-based services in the VPLMN with home-routed roaming.
The LMISF-IRI shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:
– The enumerated value of "voice" or "messaging" in the service type field.
– When location reporting is required, one or both of "reportBeginingAndEnd", "reportUponChange".
– "SuspendOnOutboundInternationalRoaming".
Table 7.10.4.2-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the LMISF-IRI for Phase-2.
Table 7.10.4.2-1: ActivateTask message for activating LMISF-IRI for Phase-2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. The value used here is different from the value used in ActivateTask shown in table 7.10.3.2-4. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in clause 7.10.4.2.1. |
M |
|
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. |
M |
|
ListOfDIDs |
Delivery endpoints of LI_X2 or LI_X3. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ServiceScoping |
Using the format defined in ETS TS 103 221 [7] based on the service scoping listed above the table. When multiple intercepts are activated on a target identifier, the service scoping shall be the union of all of them. |
C |
7.10.4.2.3 Provisioning of the MDF2
The MDF2 listed as the delivery endpoint over LI_X2 for xIRI generated by the LMISF-IRI shall be provisioned over LI_X1 by the LIPF.
The target identities listed in clause 7.10.4.2.1 shall apply for the provisioning of MDF2.
The MDF2 shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:
– The enumerated value of "voice" or "messaging" in the service type field.
– When location reporting is required, one or both of "reportBeginingAndEnd", "reportUponChange".
Table 7.10.4.2-2 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
Table 7.10.4.2-2 ActivateTask message for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in clause 7.10.4.2.1. |
M |
|
DeliveryType |
This value shall be Ignored by the MDF2. |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, See table 7.10.4.2-3. |
M |
Table 7.10.4.2-3: Mediation Details for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to "HI2Only". |
M |
|
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
|
ServiceScoping |
Using the format defined in ETS TS 103 221 [7] include the service scoping as applicable to this LIID based on the service scoping listed above the table. |
C |
7.10.4.2.4 Provisioning of the MDF3
The MDF3 listed as the delivery endpoint over LI_X3 for xCC generated by the LMISF-CC shall be provisioned over LI_X1 by the LIPF.
The target identities listed in clause 7.10.4.2.1 shall apply for the provisioning of MDF3.
The MDF3 shall support the following service scoping from the structure defined in ETSI TS 103 221-1 [7]:
– The enumerated value of "voice" or "messaging" in the service type field.
– When location reporting is required, one or both of "reportBeginingAndEnd", "reportUponChange".
Table 7.10.4.2-4 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF3.
Table 7.10.4.2-4 ActivateTask message for MDF3
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in clause 7.10.4.2.1. |
M |
|
DeliveryType |
This value shall be Ignored by the MDF3. |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI3. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, See table 7.10.4.2-5. |
M |
Table 7.10.4.2-5: Mediation Details for MDF3
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to "HI3Only". |
M |
|
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
|
ServiceScoping |
Using the format defined in ETS TS 103 221 [7] include the service scoping as applicable to this LIID based on the service scoping listed above the table. |
C |
7.10.4.3 Generation of xIRI over LI_X2
7.10.4.3.1 General concepts
The LMISF-IRI extracts the SIP messages that it receives within the xCC from the BBIFF-U/BBIFF over the LI_X3_LITE_S.
On the originating end of a voice session, the LMISF-IRI examines the SIP message, the stored LI_X2_LITE record and the stored LI_X3_LITE_S record to check for the following:
– Whether the calling party identity is a target.
– Whether the called party identity is a target non-local ID.
On the terminating end of a voice session, the LMISF-IRI examines the SIP message, the stored LI_X2_LITE record and the stored LI_X3_LITE_S record to check for the following:
– Whether the called party identity is a target.
– Whether the calling party identity is a target non-local ID.
– Whether the redirecting party identity is a target non-local ID.
The SIP headers used for identifying a calling party identity, called party identity, redirecting party identity can be same identities used by the IMS signaling functions with the following additions:
– P-Preferred Identity as calling party identity.
When any of the conditions listed above are true, the LMISF-IRI concludes that target is involved in an IMS session that shall be intercepted. Accordingly, the LMISF-IRI generates the xIRIs and delivers the same to the MDF2 over the LI_X2.
For IMS-based voice services, if media interception is required, the LMISIF-IRI sends a trigger for the same to the BBIFF-C/BBIFF over the LI_T1 interface.
7.10.4.3.2 Target match
7.10.4.3.2.1 General
When an IMS UE performs an IMS registration (using SIP REGISTER) request, the LMISF-IRI examines the following for a target match:
– From header and To header of the SIP REGISTER when the target identity is IMPU.
– SUPI or IMSI stored in the LI_X2_LITE record when the target identity is IMPI.
– +sip.instance-id of Contact header of the SIP REGISTER when the target identity is PEIIMEI or IMEI.
The LMISF-IRI shall store the +sip.instance-id in the LI_X2_LITE_S record for later use.
7.10.4.3.2.2 Service type of voice
When an IMS UE originates an IMS session (using SIP INVITE), the LMISF-IRI examines the following to verify for a target match:
– P-Preferred Identity header and From header present in the SIP INVITE when the target identity is IMPU.
– Request URI header and To header present in the SIP INVITE when the target identity is IMPU and target is non-local ID.
– SUPI or IMSI stored in the LI_X2_LITE record when the target identity is IMPI.
– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.
When an IMS UE receives an incoming IMS session (using SIP INVITE), the LMISF-IRI examines the following to verify for a target match:
– Request URI and To header present in the SIP INVITE when the target identity is IMPU.
– P-Asserted-Id, From header, History Info header and Diversion header present in the SIP header when the target identity is IMPU and target is non-local ID.
– SUPI or IMSI stored in the LI_X2_LITE record when the target identity is IMPI.
– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.
LMISF-IRI may use the Via header or the Route header to determine whether the SIP INVITE is for an originating IMS session or a terminating IMS session. LMISF-IRI stores the SIP Call Id to associate the subsequent SIP messages received on the same session for a target match.
For subsequent SIP messages, the LMISF-IRI may use the stored LI_X3_LITE_S record to determine for a target match.
7.10.4.3.2.3 Service type of messaging
When the Service Type received in the LI_X1 provisioning is "messaging", the LMISF-IRI examines the SIP MESSAGE for a target match as shown below:
– For MO-SMS over IP, P-Preferred Identity header and From header present in the SIP MESSAGE when the target identity is IMPU.
– For MO-SMS over IP, TP-DA field of SMS-SUBMIT within the Message-body of SIP MESSAGE when the target identity IMPU for target non-local ID.
– For MT-SMS over IP, the Request URI and To header present in the SIP MESSAGE when the target identity is IMPU.
– For MT-SMS over IP, the TP-OA field or TP-RA field of SMS-SUBMIT within the Message-body SIP MESSAGE when the target identity IMPU for target non-local ID.
– SUPI or IMSI stored in the LI_X2_LITE record when the target identity is IMPI.
– +sip.instance-id of Contact header received in the SIP REGISTER request when the target identity is PEIIMEI or IMEI.
LMISF-IRI may use the Via header or the Route header to determine whether the SIP MESSAGE is for MO-SMS over IP or MT-SMS over IP.
7.10.4.3.3 xIRIs
The xIRIs generated at the LMISF-IRI shall be same as the xIRIs generated in the IRI-POIs present in the IMS signaling functions (see clause 7.12.4.12).
As defined in TS 33.127 [5] the LMISF-IRI generates the following xIRIs:
– Encapsulated SIP message.
– Start of interception with an established IMS session.
The xIRI CC Unavailable defined in TS 33.127 [5] for IMS-based services is not applicable to N9HR LI and S8HR LI. The encapsulated SIP message is sent using the xIRI IMSMessage record.
Further details of the xIRIs are defined in clause 7.12.4.12.
7.10.4.4 Triggering of BBIFF-C from LMISF over LI_T1
7.10.4.4.1 General
When the intercepted IMS-session requires the media interception, the LMISF-IRI sends a trigger to the BBIFF-C/BBIFF over to the LI_T1 interface (see TS 33.127 [5]) with LMISF-CC as the delivery end point.
The LMISF-IRI upon discovering through the xIRIs received over the LI_X2_LITE interface that a change in SMF or SGW-C/SGW has occurred for an interception involving an IMS-session shall send the trigger to BBFF-C/BBIFF present in the new SMF or SGW-C/SGW over LI_T1 interface with LMISF-CC as the delivery end point to continue the IMS media interception when required.
When the IMS session is completely released (e.g. all session-legs are released), the LMISF-IRI sends a trigger to the BBIFF-C/BBIFF to stop the media intereption. The LMISF-IRI may also send the trigger to stop the media interception when the target information is deprovisioned in the LMISF-IRI by the LIPF.
NOTE: When multiple warrants are active on a target, the activation or deactivation of a warrant may not result in a trigger to BBIFF-C./BBIFF (e.g. if a trigger has already been sent due to other warrants).
The present document supports the media interception of IMS voice media.
7.10.4.4.2 N9HR LI
The LI_T1 trigger that the LMISF-IRI sends to the BBIFF-C present in the SMF shall include at least the following information:
– The XID that LMISF-IRI receives from the LIPF over LI_X1 for the target related activation.
– Target identity: SUPI, PDU session ID, IMS voice media.
– Delivery end point: LMISF-CC.
The details of ActivateTask sent to the BBIFF-C in SMF over LI_T1 are shown in table 7.10.4.4-1.
Table 7.10.4.4-1: ActivateTask message for triggering the BBIFF-C in the SMF over LI_T1
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Allocated by the LMISF-IRI as per ETSI TS 103 221-1 [7]. |
M |
|
TargetIdentifiers |
Information that identifies the need to intercept the IMS voice media. The target identifiers as shown in table 7.10.4.4-2. |
M |
|
DeliveryType |
Set to "X3Only". |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-CC to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
This value is set by the LMISF-IRI and shall be same as the value to be used in the xCC generated at the LMISF-CC. The BBIIF-C passes this field to the BBIFF-U over LI_T3. |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the LMISF-IRI. This value shall be passed to the BBIFF-U over LI_T3. |
M |
Table 7.10.4.4-2: Target Identifier Types for LI_T1 (BBIFF-C in SMF)
|
Identifier type |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
SUPI |
SUPI |
ETSI TS 103 221-1 [7] |
|
PDUSessionID |
TargetIdentifierExtension/PDUSessionID |
Integer (see XSD schema) |
|
IMSVoiceMedia |
TargetIdentifierExtension/IMSVoiceMedia |
Empty tag (see XSD schema) |
|
NOTE: The LMISF-IRI shall use the SUPI and PDU Session ID received over the LI_X2_LITE interface to populate the target identifiers SUPI and PDUSessionID respectively. The SUPI is in either SUPIIMSI or IMSI format (ETSI TS 103-221-1 [7]). |
||
The DeactivateTask message that the LMISF-IRI sends to the BBIFF-C present in the SMF shall include the XID of the Task created by the ActivateTask message (see table 7.10.4.4-1).
7.10.4.4.3 S8HR LI
The LI_T1 trigger that the LMISF-IRI sends to the BBIFF-C present in the SGW-C/SGW shall include at least the following information:
– The XID that LMISF-IRI receives from the LIPF over LI_X1 for the target related activation.
– Target identity: IMSI, Bearer ID, IMS voice media.
– Delivery end point: LMISF-CC.
The details of ActivateTask sent to the BBIFF-C in SGW-C over LI_T1 are shown in table 7.10.4.4-3.
Table 7.10.4.4-3: ActivateTask message for triggering BBIFF-C/BBIFF in the SGW-C/SGW over LI_T1
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Allocated by the LMISF-IRI as per ETSI TS 103 221-1 [7]. |
M |
|
TargetIdentifiers |
Information that identifies the need to intercept the IMS voice media. See table 7.10.4.4-4. |
M |
|
DeliveryType |
Set to "X3Only". |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-CC to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
This value is set by the LMISF-IRI and shall be same as the value to be used in the xCC generated at the LMISF-CC. The BBIIF-C in passes this field to the BBIFF-U over LI_T3. |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the LMISF-IRI. This value shall be passed to the BBIFF-U over LI_T3. |
M |
Table 7.10.4.4-4: Target Identifier Types for LI_T1 (BBIFF-C/BBIFF in SGW-C/SGW)
|
Identifier type |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
IMSI |
IMSI |
ETSI TS 103 221-1 [7] |
|
BearerID |
TargetIdentifierExtension/BearerID |
Integer (see XSD schema) |
|
IMSVoiceMedia |
TargetIdentifierExtension/IMSVoiceMedia |
Empty tag (see XSD schema) |
|
NOTE: The LMISF-IRI shall use the IMSI and Bearer ID received over the LI_X2_LITE interface to populate the target identifiers IMSI and BearerID respectively. |
||
The DeactivateTask message that the LMISF-IRI sends to the BBIFF-C/BBIFF present in the SGW-C/SGW shall include the XID of the Task created by the ActivateTask message (see table 7.10.4.4-3).
7.10.4.5 Triggering of BBIFF-U from BBIFF-C over LI_T3
7.10.4.5.1 General
When the trigger is received over the LI_T1 for activating the media interception, the BBIFF-C present in the SGW-C shall send a trigger over LI_T3 to the BBIFF-U present in the SGW-U when a dedicated bearer for the IMS media is established on the PDN connection.
When the trigger is received over the LI_T1 for activating the media interception, the BBIFF-C present in the SMF shall send a trigger over LI_T3 to the BBIFF-U present in the UPF when the PDU session is modified for adding IMS media related QoS flow.
If the trigger over LI_T1 is received for activating the media interception after the IMS media related changes has happened (i.e. dedicated bearer is established for IMS media, PDU session is modified for adding the IMS media related QoS flow), then the BBIFF-C shall send the trigger to the BBIFF-U over LI_T3 immediately.
The BBIFF-C shall trigger the BBIFF-U to stop the delivery of xCC to the LMISF-CC when it receives the trigger from the LMISF-IRI over LI_T1 for stopping the media interception, independent of whether the IMS media related changes have happened or not.
7.10.4.5.2 N9HR LI
The LI_T3 trigger that the BBIFF-C in SMF sends to the BBIFF-U present in the UPF shall include at least the following information:
– XID assigned locally by the BBIFF-C in the SMF.
– The Product ID that includes the XID it receives from the LMISF-IRI over LI_T1.
– Target identity: PFCP Session ID, PDR ID with the QFI associated with the IMS voice media (5Q = 1) related QoS flow.
– Delivery end point: LMISF-CC
The details of ActivateTask sent to the BBIFF-U in UPF over LI_T3 are shown in table 7.10.4.5-1.
Table 7.10.4.5-1: ActivateTask message for triggering the BBIFF-U in the UPF over LI_T3
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Allocated by the BBIFF-C as per ETSI TS 103 221-1 [7]. |
M |
|
TargetIdentifiers |
Packet detection criteria as determined by the BBIFF-C in the SMF, which enables the BBIFF-U to isolate user-plane packets of IMS voice media. The BBIFF-U in the UPF shall support the identifier types given in Table 6.2.3-7. The target identity type of PDR ID shall be mandatory. The BBIFF-C in SMF shall use the QFI associated with the IMS voice media (5QI = 1) related QoS flow to populate the QFI field within the PDI of PDR ID. |
M |
|
DeliveryType |
Set to “X3Only”. |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-CC to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
Correlation ID to assign to X3 PDUs generated by the BBIFF-U in the UPF. This field is populated with the same CorrelationID received over the LI_T1 interface (see table 7.10.4.4.1). |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception as received in the ProductID field over LI_T1 interface (see table 7.10.4.4.1). This value shall be used by the BBIFF-U in the UPF to fill the XID of X3 PDUs. |
M |
The DeactivateTask sent to the BBIFF-U present in the UPF over LI_T3 shall include the XID of the Task created by the ActivateTask message (see table 7.10.4.5-1).
7.10.4.5.3 S8HR LI
The LI_T3 trigger that the BBIFF-C in SGW-C sends to the BBIFF-U present in the SGW-U shall include at least the following information:
– XID assigned locally by the BBIFF-C in the SGW-C.
– The Product ID that includes the XID it receives from the LMISF-IRI over LI_T1.
– Target identity: PFCP Session ID, PDR ID with the F-TEID associated with the IMS voice media (QCI = 1) related dedicated bearer.
– Delivery end point: LMISF-CC.
The details of ActivateTask sent to the BBIFF-U in SGW-U over LI_T3 are shown in table 7.10.4.5-2.
Table 7.10.4.5-2: ActivateTask message for triggering the BBIFF-U in the SGW-U
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Allocated by the BBIFF-C as per ETSI TS 103 221-1 [7]. |
M |
|
TargetIdentifiers |
Packet detection criteria as determined by the BBIFF-C in the SGW-C, which enables the BBIFF-U in SGW-U to isolate user-plane packets. The BBIFF-U in the SGW-U shall support the identifier types given in Table 6.2.3-7. The target identity type of PDR ID shall be mandatory. The BBIFF-C in SGW-C shall use the F-TEIDs associated with the IMS voice media (QCI = 1) related dedicated bearer to populate the F-TEID field within the PDI of PDR ID. |
M |
|
DeliveryType |
Set to “X3Only”. |
M |
|
ListOfDIDs |
Shall give the DID of the LMISF-CC to which the xCC should be delivered. The delivery endpoint is configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
Correlation ID to assign to X3 PDUs generated by the BBIFF-U in the SGW-U. This field is populated with the same CorrelationID received over the LI_T1 interface (see table 7.10.4.4.3). |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception as received in the ProductID field over LI_T1 interface (see table 7.10.4.4.3). This value shall be used by the BBIFF-U in the SGW-U to fill the XID of X3 PDUs. |
M |
The DeactivateTask sent to the BBIFF-U present in the SGW-U over LI_T3 shall include the XID of the Task created by the ActivateTask message (see table 7.10.4.5-2).
7.10.4.6 Generation of xCC over LI_X3_LITE_M
The BBIFF-U in UPF and the BBIFF-U in SGW-U shall send the xCC over LI_X3_LITE_M for each of the packet matching the criteria specified in the Triggering message (i.e. Activate Task message) received over the LI_T3 from the BBIFF-C.
The BBIFF in SGW shall identify the IMS voice media (QCI = 1) related dedicated bearer associated with the IMS signaling related bearer as indicated in the trigger received over the LI_T1 from the LMISF-IRI and then send xCC over LI_X3_LITE_M for each of the packet captured from that dedicated bearer.
The BBIFF-U/BBIFF shall set the payload format to indicate the appropriate payload type (5 for IPv4 Packet, 6 for IPv6 Packet, or 12 for GTP-U Packet as described in ETSI TS 103 221-2 [8] clauses 5.4 and 5.4.13).
7.10.4.7 Generation of xCC over LI_X3
The xCC generated at the LMISF-CC shall be same as the xCC generated in the CC-POIs present in the IMS media functions. Further details of this are not specified in the present document.
The correlation identifier value included in the xCC of an IMS session can be dependent on the UDP port numbers associated with the voice-media related RTP streams. This is the case when a user is involved in multiple IMS sessions. An illustrated of this is shown in clause 7.10.4.8
7.10.4.8 Correlation identifier
The xIRIs generated at the LMISF-IRI shall be correlated using the correlation identifier field defined ETSI TS 103 221-2 [8]. This correlation identifier value can be independent of the correlation identifier value received in the xCC from the BBIFF-U/BBIFF over the LI_X3_LITE_S interface.
Furthermore, the xIRIs generated at the LMISF_IRI shall include the correlation identifier value used in the xCC generated at the LMISF-CC. Any intra-LMISF interactions required to associate the correlation identifier values used by the LMISF-IRI and LMISF-CC are outside the scope of the present document.
Each session-leg of an IMS session may have to be correlated separately. This is accomplished using the RTP/RTCP port numbers present in the SDP of IMS signaling message and the UDP port numbers present in the IMS voice media related RTP as illustrated in figure 7.10.4.8-1 below.
Figure 7.10.4.8-1: Correlation at the session-leg level (an illustration)
Figure 7.10.4.8-1 illustrates an example where an IMS session includes two session-legs.
Session-leg 1:
– Source IP address: 192.0.2.10 and source port number: 24000 (RTP), 24001 (RTCP).
– Destination IP address: 198.51.100.1 and destination port number: 32000 (RTP), 32001 (RTCP).
Session-leg 2:
– Source IP address: 192.0.2.10 and source port number: 26000 (RTP), 26001 (RTCP).
– Destination IP address: 198.51.100.1 and destination port number: 36000 (RTP), 36001 (RTCP).
The IP address of the two end-points happen to be the same for the two session legs. The RTP port numbers present in the SDP of IMS signaling message and the UDP port numbers of the associated with the IMS voice-media related RTP happen to be the same for a session-leg.
Therefore, in general, multiple session-legs can be identified using the RTP port numbers present in the SDP of IMS signaling message and the UDP port numbers associated with the IMS voice-media related RTP.
7.10.4.9 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the LMISF-IRI, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The IRI messages delivered over the LI_HI2 for HR LI are same as the IRI messages delivered over the LI_HI2 for LI IMS-based voice services. Further details of this are outside the scope of the present document.
7.10.4.10 Generation of CC over LI_HI3
When the xCC is received over LI_X3 from the LMISF-CC, the MDF3 shall deliver the CC over LI_HI3 without undue delay.
The CC delivered over the LI_HI3 for HR LI is the same as the CC delivered over the LI_HI3 for LI IMS-based voice services. Further details of this are outside the scope of the present document.