20.1  Architecture

20.1.1  Overview

When S8HR approach is used as the roaming architecture for VoLTE, all of the IMS nodes reside in the HPLMN. National regulations may require the VPLMN to have the capabilities to perform the lawful interception of voice services involving the inbound roaming targets. The LI capabilities provided in the VPLMN with S8HR approach as the roaming architecture shall be to the same extent as the LI capabilities provided in the VPLMN with LBO approach as the roaming architecture.

The IMS signalling messages are exchanged between the UE and the P-CSCF (in HPLMN with S8HR) and the media is exchanged between the UE and the PDN-GW (in HPLMN with S8HR). Within the VPLMN with S8HR, the IMS signalling messages are carried over the GTP tunnel that corresponds to the IMS Signalling Bearer and the media packets are carried over the GTP tunnel that corresponds to the Media Bearer. (i.e. a dedicated EPS Bearer used to carry the media packets). The present document assumes that the EPS Bearer ID of the IMS Signalling Bearer is always linked to the dedicated EPS Bearer used as a Media Bearer.

New LI-specific functions are introduced to examine the packets that flow through the VPLMN packet core network nodes (i.e. S-GW) to generate IRI and CC when the communication involves an inbound roaming target. The LI architecture diagram shown in figure 1j is redrawn below with focus on the new LI specific functions and the reference points.

[not reproduced yet]

Figure 20.1: S8HR LI Architecture

All the functions and reference points shown in figure 20.1 shall adhere to the security requirements specified in clause 8.

A condition required for the operation of S8HR LI is that the IMS signalling messages and the media packets are not encrypted at S-GW/BBIFF. Furthermore, the S8HR LI solution requires that APNs can be identified as being used for S8HR and therefore those APNs can be used to identify the EPS Bearers used for inbound roamers with S8HR.

Refer to Annex J for the detailed illustration of this architecture in reference to S8HR, the process flow steps and the call flows.

20.1.2  LI specific Reference Points  Word‑p. 229

Xia:

Reference point between S-GW/BBIFF and LMISF. This reference point is used to carry the user plane information from the S-GW/BBIFF to the LMISF.

Xib:

Reference point between LMISF and the S-GW/BBIFF. This reference point is used to exchange the control plane information between the LMISF and the S-GW/BBIFF.

20.1.3  LI Specific Functions

20.1.3.1  Void

20.1.3.2  BBIFF: Bearer Binding Intercept and Forward Function

BBIFF is a LI specific function introduced to support the lawful interception of voice services in the VPLMN when S8HR is used as the roaming architecture.

BBIFF shall provide the following functions:

• Receive a list of S8HR APNs and the packet forwarding rules that apply to all users from the LMISF over the Xib reference point.
• As per the LMISF instruction, notify the LMISF over Xib reference point whenever the IMS Signalling Bearer or the Media Bearer with S8HR APN is created, modified or deleted. In that notification, the UE location information received from the MME shall be included.
• As per the packet forwarding rules (i.e. as instructed by the LMISF), deliver the packets of all GTP tunnels used for IMS Signalling Bearer with S8HR APN to the LMISF over the Xia reference point.
• Receive the intercepted IMS Signalling Bearer information from the LMISF over the Xib reference point along with the packet forwarding rules.
• Identify the dedicated EPS Bearer used as the Media Bearer linked to the above-indicated intercepted IMS Signalling Bearer.
• As per the packet forwarding rules (i.e. as instructed by the LMISF), deliver the packets of the GTP tunnel used for Media Bearer associated with the intercepted IMS Signalling Bearer to the LMISF over the Xia reference point.
• When instructed by the LMISF, stop delivering the packets of the GTP tunnels used for Media Bearers associated with the IMS Signalling Bearer with a deactivated interception.

20.1.3.3  LMISF: LI Mirror IMS State Function  Word‑p. 230

LMISF is a LI specific function introduced to support the lawful interception of voice services in the VPLMN when S8HR is used as the roaming architecture.

The LMISF shall provide the following functions:

• Provide S8HR APN information to the S-GW/BBIFF over the Xib reference point.
• Instruct S-GW/BBIFF over Xib reference point to notify (to LMISF) whenever an IMS Signalling Bearer or a Media Bearer with S8HR APN is created, modified or deleted.
• Instruct S-GW/BBIFF over the Xib reference point to start delivering the packets (to LMISF) of all IMS Signalling Bearers with S8HR APN.
• Receive target identity information from the ADMF over the X1_1 reference point as described in clause 5.1.
• Receive the notification from S-GW/BBIFF over the Xib reference point whenever an IMS Signalling Bearer or a Media Bearer with S8HR APN is created, modified or deleted.
• Store the IMS Signalling Bearer information (e.g. EPS Bearer ID) along with the IMSI associated with the UE to which the IMS Signalling Bearer was created, modified or deleted. Store or update the most recent UE location information received along with the IMS Signalling Bearer or the Media Bearer information.
• Receive and examine the IMS signalling messages delivered by the S-GW/BBIFF over the Xia reference point.
• Receive media packets delivered by the S-GW/BBIFF over the Xia reference point. Identify the intercepted IMS session that relates to the media packets.
• Maintain an IMS signalling state for all inbound roamers with S8HR that are registered to the network or in an IMS session. Part of this function is to track all IMS registrations, re-registrations and de-registrations of inbound roamers with S8HR.
• After examining and determining that the IMS signalling messages involves a target, establish and maintain a map between the target identity and the IMS Signalling Bearer information or the Media Bearer (e.g. EPS Bearer ID along with the IMSI value of the UE). When the IMS signalling messages do not involve a target, establish and maintain a map between the IMS Signalling Bearer or the Media Bearer information and the potential target identities.
• Generate and deliver the IRI to the Delivery Function 2 as described in clause 20.3.
• Inform the S-GW/BBIFF over the Xib reference point with the IMS Signalling Bearer information associated with an intercepted IMS session that requires CC interception and instruct the S-GW/BBIFF to start delivering the packets of the Media Bearer associated with that IMS Signalling Bearer.
• Inform the S-GW/BBIFF over the Xib reference point with the IMS Signalling Bearer information associated with a deactivated interception and instruct the S-GW/BBIFF to stop delivering the packets of the Media Bearer associated with that IMS Signalling Bearer. Generate and deliver the IRI messages to the Delivery Function 2 as described in clause 20.3.
• Generate and deliver the CC to the Delivery Function 3 as described in clause 20.2.
• When target identity is received from the ADMF, determine whether any IMS Signalling Bearer is associated to the target identity. If yes, start the interception process as described in clause 20.3.
• Provide the decompression of IMS signalling messages upon detecting the compression.

20.2  Provision of Content of Communications  Word‑p. 231

20.2.1  Overview

20.2.1.1  General

For interception of content of communications of voice services involving the inbound roamers with S8HR, the following shall occur:

• For each IMS session that is intercepted, LMISF determines whether a CC interception is required.
• When the CC is interception required, LMISF provides the IMS Signalling Bearer information to the S-GW/BBIFFF (as described in clause 20.1.3.3) and instructs the S-GW/BBIFF (as described in clause 20.1.3.3) to start delivering the media packets (i.e. packets from the Media Bearer) associated with that IMS Signalling Bearer.
• S-GW/BBIFF delivers the media packets (i.e. packets from the Media Bearer) associated with the IMS Signalling Bearer (as described in clause 20.1.3.2) to the LMISF.

The S-GW/BBIFF shall provide the LMISF a means to link the intercepted media packets with the associated IMS Signalling Bearer information provided by the LMISF (e.g. the delivered media packets include the EPS Bearer ID of the IMS Signalling Bearer along with the IMSI value of the UE).

The LMISF shall include the Correlation Information (associated with the IMS session) in the CC delivered to the Delivery Function 3 over the X3 reference point. A pictorial view of the CC interception is illustrated in figure 20.2 below:

[not reproduced yet]

Figure 20.2: CC Interception of voice calls involving the inbound roaming target with S8HR

The figure 20.2 shows that LMISF provides the IMS Signalling Bearer Information to the S-GW/BBIFF. The S-GW/BBIFF uses the IMS Signalling Bearer information to find the associated Media Bearer.

When the LMISF identifies that the CC interception is to be stopped, the following shall occur:

• LMISF stops delivering the CC to Delivery Function 3 over the X3 reference point.
• LMISF provides the IMS Signalling Bearer information to the S-GW/BBIFF with an instruction (as described in clause 20.1.3.3) to stop the delivery of media packets (i.e. packets from the Media Bearer) associated with the IMS Signalling Bearer.
• S-GW/BBIFF stops the delivery of the media packets associated with the IMS Signalling Bearer (as described in clause 20.1.3.2) to the LMISF.

20.2.1.2  S-GW/BBIFF Procedures for CC Interception  Word‑p. 232

When instructed by the LMISF, the S-GW/BBIFF shall use the IMS Signalling Bearer information that it received from the LMISF to determine the media packets of which EPS Bearer (i.e. the Media Bearer) has to be delivered to the LMISF (e.g. EPS Bearer ID of IMS Signalling Bearer is linked to the EPS Bearer used as the Media Bearer). Then, the S-GW/BBIFF shall deliver all the octets above the GTP layer of the GTP tunnel used for the Media Bearer to the LMISF.

S-GW/BBIFF shall indicate to the LMISF whether the media packets were travelling to or from the HPLMN (e.g. based on tunnel end point IDs).

When instructed by the LMISF, the S-GW/BBIFF shall stop the delivery of media packets to the LMISF.

20.2.1.3  Void

20.2.1.4  LMISF Procedures for CC Interception  Word‑p. 233

Upon determining that the CC interception is required or is to be stopped for an IMS session, LMISF shall pass the IMS Signalling Bearer information to the S-GW/BBIFF with an instruction that indicates to the S-GW/BBIFF whether the packets from the Media Bearer associated with the IMS Signalling Bearer shall be delivered, or not delivered, to the LMISF.

When the media packets are received from the S-GW/BBIFF, the LMISF shall determine whether the interception is active on the IMS session. If active, the LMISF shall determine the Correlation Identifier (or Correlation Number) associated with the IMS session to which the media corresponds. If the interception is not active, the LMISF shall discard the media packets.

The LMISF shall construct the CC and deliver the same to the Delivery Function 3 over X3 reference point (see clause 20.2.2).

20.2.2  X3-Interface

For the delivery of intercepted media packets, the following information shall be passed from the LMISF to the Delivery Function 3 in addition to the intercepted media packets:

• target identity;
• Correlation identifier;
• Time stamp (optional);
• Direction (indicates media is from or to the target) - optional.

The Delivery Function 3 delivers the information to the LEMF over the HI3 interface based on the national regulations.

20.3  Provision of Intercept Related Information

20.3.1  Overview

20.3.1.1  General

For interception of intercept related information of voice services involving the inbound roaming targets with S8HR, the following shall occur:

• LMISF provides the S8HR APNs to the S-GW/BBIFF with an indication that all packets from the IMS Signalling Bearer with the S8HR APN are to be delivered to the LMISF.
• S-GW/BBIFF delivers the IMS signalling packets from the S8HR IMS Signalling Bearers to the LMISF.
• LMISF examines whether the IMS signalling messages involve a target and if so, it generates and delivers the IRI to the Delivery Function 2.

The LMISF shall generate the IRI from the IMS signalling messages and deliver the same to the Delivery Function 2 over X2 reference point. All SIP messages executed on behalf of a target shall be delivered as IRI.

The S-GW/BBIFF also notifies the LMISF whenever an S8HR IMS Signalling Bearer or a Media Bearer is created, modified, or deleted along with the IMSI value of the target UE and the location of the UE.

A pictorial view of the general overview of IRI interception is illustrated in figure 20.3 below:

[not reproduced yet]

Figure 20.3: IRI Interception of voice calls involving the inbound roamer with S8HR

The figure 20.3 shows that LMISF provides the S8HR APNs to the S-GW/BBIFF. When the IMS signalling messages correspond to a target, the LMISF generates the IRI and deliver the same to the Delivery Function 2 which in turn delivers the IRI to the LEMF.

To support the mid-call interception, the LMISF maintains the IMS call state (including any necessary information from the SIP messages). When the target identity provisioned into the LMISF is involved in an ongoing IMS call, the LMISF shall start the interception as described in clause 20.3.2.

20.3.1.2  Void

20.3.1.3  S-GW/BBIFF Procedures for IRI interception  Word‑p. 234

When instructed by the LMISF, the S-GW/BBIFF shall notify the LMISF whenever the IMS Signalling Bearer or the Media Bearer with S8HR APN is created, modified or deleted.

When instructed by the LMISF, the S-GW/BBIFF shall deliver all the octets above the GTP layer of GTP tunnel used for IMS Signalling Bearer to the LMISF along with the associated with IMS Signalling Bearer information.

20.3.1.4  LMISF Procedures for IRI interception

The LMISF shall receive the notification from S-GW/BBIFF whenever a GTP tunnel for IMS Signalling Bearer or a Media Bearer with S8HR APN is created, modified or deleted. The LMISF shall store the Tunnel information (Tunnel ID) of the GTP tunnel along with the IMSI associated with the UE to which the GTP tunnel was created. If delivered, the LMISF shall also store the UE location information along with the time that it has received the same from S-GW/BBIFF.

The LMISF shall receive and examine the IMS signalling messages delivered by the S-GW/BBIFF. After examining and determining that an IMS signalling message involves a target, LMISF shall deliver the SIP message to the Delivery Function 2 over the X2 reference point (see clause 20.3.2). The up-to-date UE location information stored in the LMISF, as available, shall also be delivered to the Delivery Function 2. LMISF shall maintain an IMS call state for all inbound roaming users (for the target identity or potential target identity). The maintained current IMS call state (along with the stored necessary information from the SIP messages) shall be sufficient to support the mid-call interception.

When the received IMS signalling message involves compression, the LMISF shall perform the decompression of SIP messages (as defined in clause 8 of TS 24.229) and follow the steps used to process the uncompressed SIP messages.

Refer to clause 20.1.3.3 for a complete list of LMISF functions that also include a few functions that aid the overall interception capabilities of voice services involving the inbound roamers with S8HR as the roaming architecture.

20.3.2  IRI Events  Word‑p. 235

20.3.2.1  General

In general, the IRI events applicable to S8HR LI are similar to the IRI events defined in clause 7A except that the LMISF (instead of CSCF) examines and generates the IRI events. However, since the interception in LMISF is used only for S8HR LI (i.e. roaming case), certain events defined in clause 7A are not applicable:

Any SIP messages sent to, and received from, the target UE as observed at the S-GW/BBIFF shall be delivered as IRI with the additional information as listed in clause 20.3.3. The LMISF shall include the UE location (along with timestamp) received from the Serving Gateway/BBIFF in the appropriate events.

The provisioned target identity can be a SIP URL, a TEL URL or an IMEI. The method used to verify a target identity is dependent on the call direction. S-GW/BBIFF shall indicate to the LMISF whether the IMS signalling packets were travelling to or from the HPLMN (e.g. based tunnel end point IDs).

For calls originating from the inbound roaming target, calling party identity (e.g. SIP headers: P-Preferred-Id, From) is used verify the target identity. For calls terminating to the inbound roaming target, called party identity (e.g. SIP headers: Request URI, P-Called-Party-Id, To) is used to verify the target.

For incoming calls to an inbound roaming user from a Non-Local-Id as the target, calling party identity (P-Asserted-Id, From) or redirecting party identity (History-Info, Diversion) are used to verify the target. For outgoing calls from an inbound roaming user to a Non-Local-Id as the target, the called party identity (Request-URI, To) is used to verify the target. See Annex I for an informative illustration of Non-Local-Id target interception cases. The LMISF will have to provide the functions provided by the P-CSCF (Annex I) in the VPLMN.

20.3.2.2  IMEI-based interception

To support the IMEI-based interception, the LMISF shall provide (if possible) the functions equivalent to functions defined for CSCF in clause 7A.8.

20.3.2.3  Mid-call Interception

The mid-call interception is performed using the procedures described in clause 7A.3.1 except that LMISF (instead of CSCF as described in clause 7A.3.1) maintains the IMS call state, stores the SIP messages and generates the IRI.

When a lawfully authorized interception is deactivated while the target is on an IMS session, the LMISF shall stop delivering the IRI events to the Delivery Function 2.

20.3.2.4  Signalling Compression

If compression of the IMS signalling traffic is detected (as defined in RFC 3320 [69] and RFC 4896 [70]), then the SIP messages are first decompressed (as defined in clause 8 of TS 24.229) and processed with the steps used to process the uncompressed SIP messages.

20.3.2.5  Limitations

The limitations described in the NOTE of clause 15.4.1 apply to lawful interception capabilities provided in the VPLMN for voice services involving the inbound roamers with S8HR as the roaming architecture.

20.3.3  X2-Interface  Word‑p. 236

For the delivery of intercepted SIP messages, the following information shall be passed from the LMISF to the Delivery Function 2 on the X2 reference point:

• Target Identity (SIP URL, TEL URL, IMEI);
• Correlation Identifier;
• Event Time and Date;
• Network Element Identifier;
• UE Location (conditional, as applicable, e.g. IMS session establishment events);
• date/time of Location (if target location provided);
• SIP Header;
• SIP payload.

The Delivery Function 2 delivers the IRI to the LEMF over the HI2 interface based on the national regulations.

20.4  Lawful Interception with CUPS architecture

20.5  S8HR LI and Target UE Mobility  Word‑p. 238

20.5.1  Overview

During a session (packet data or voice) that involves the target UE, the S-GW/BBIFF that provides the IMS Signalling packets and Media packets to the LMISF can change (i.e. S-GW/BBIFF relocation).

The lawful interception of voice calls involving the target shall continue when the S-GW/BBIFF relocation happens. The IRI events and the CC delivered before and after the relocation shall be correlated.

20.5.2  S-GW Relocation

As described in sub-clause 20.1.3.3, the LMISF provides the S8HR APNs to the S-GW/BBIFF and the S-GW/BBIFF notifies the LMISF whenever an IMS Signalling Bearer for the S8HR APN is created, modified or deleted along with the IMSI value of the UE and the UE location. This happens independently of S-GW relocation. When the IMS signalling packets are received from the S-GW/BBIFF, the LMISF delivers the IRI events to the DF2 if the IMS signalling packets are associated with an intercepted IMS session, This, also happens independent of S-GW relocation.

When a target UE is on an IMS session and if the S-GW that has the associated IMS Signalling Bearer changes, the IMS Signalling Bearer is created at the new S-GW/BBIFF as well. The new S-GW/BBIFF that notifies the LMISF about the IMS Signalling Bearer shall include an indication in the notification to inform the LMISF that a S-GW relocation has occurred.

The LMISF shall provide the following functions to support the continued and correlated interception for the CC:

• When a notification is received from the S-GW/BBIFF (over the Xib reference point) indicating that an IMS Signalling Bearer is created due to S-GW relocation, examine to see whether the IMS Signalling Bearer is associated with an IMS session that is being intercepted.
• If the IMS Signalling Bearer is associated with an intercepted IMS session, examine to see whether the intercepted IMS session requires the CC interception.
• If the intercepted IMS session requires CC interception, inform the S-GW/BBIFF (over the Xib reference point) with the IMS Signalling Bearer information (e.g. IMS Signalling Bearer ID, IMSI value) with an instruction to deliver (to LMISF) the packets from the Media Bearer associated with the IMS Signalling Bearer.

The new S-GW/BBIFF delivers the packets from the Media Bearer associated with the IMS Signalling Bearer to the LMISF as described in sub-clause to 20.2.1.2. The LMISF delivers the received media packets to the DF3 as CC along with the correlation information as described in clause 20.2.1.4.

The LMISF shall not disrupt the ongoing interception of IRI and CC, if a IMS Signalling Bearer deletion notification is received from the old S-GW/BBIFF.