7.4 IMS
33.1273GPPLawful Interception (LI) architecture and functionsRelease 18TS
7.4.1 General
Figure 7.4-1 depicts the EPS/5GS-Anchored IMS High Level LI Architecture.
Figure 7.4-1: EPS/5GS-Anchored IMS High Level LI Architecture
7.4.2 Architecture
7.4.2.1 Overview
The capabilities defined in this clause apply to the interception of IMS-based services. The target of interception can be a subscriber of the CSP, an inbound roamer or a non-local ID.
The network function involved in providing the interception of IMS-based services are determined based on the deployment option, the network configuration, LI service scope and the IMS session including the roaming scenarios. The IRI-POI functions are provided by the network functions that handle the SIP messages (those network functions are referred to as IMS Signalling Functions) and the triggered CC-POI functions are provided by the network functions that handle the media (these network functions are referred to as IMS Media Functions). The CC-TF functions are also provided by the network functions that handle the SIP messages (referred to as IMS Signalling Functions) and manage the IMS Media Functions. The network functions that provide the CC-TF functions can be different from the network functions that provide the IRI-POI functions.
An architecture depicting the LI for IMS is depicted in figure 7.4-2 below.
Figure 7.4-2: IMS LI architecture
The LICF present in the ADMF receives the warrant from an LEA, derives the intercept information from the warrant and provides it to the LIPF. The LIPF present in the ADMF provisions IRI-POI, CC-TF, MDF2 and MDF3 over the LI_X1 interfaces.
The CC-TF sends the CC intercept trigger to the CC-POI over LI_T3 interface. The IRI-POI generates the xIRI and delivers the same to the MDF2 over LI_X2 interface. The CC-POI generates the xCC and delivers the same to the MDF3 over LI_X3 interface.
The MDF2 generates IRI messages from the received xIRI and delivers those IRI messages to the LEMF over LI_HI2 interface. The MDF3 generates the CC from the received xCC and delivers that CC to the LEMF over LI_HI3 interface.
The network configuration and IMS service scenarios including the roaming scenarios determine the network functions that provide the IRI-POI, CC-TF and CC-POI functions. The network function that provides the IRI-POI or CC-TF is referred to as IMS Signalling Function in figure 7.4-2 and the network function that provides the CC-POI functions is referred to as IMS Media Function in figure 7.4-1.
NOTE: The details of correlation between the xIRI and the xCC when IRI-POI and CC-TF are not co-located is not defined in the present document. The IRI-POI and CC-TF are logical functions and they may be handled by the same process when they are co-located in the same IMS Signalling Function.
7.4.2.2 Target identities
The LIPF provisions the intercept related information associated with the following target identities to the IRI-POI and CC-TF present in the IMS Signalling Functions:
– IMPU.
– IMPI.
– PEI (IMEI only).
– IMEI.
The IRI-POI and CC-TF shall also support interception of non-local identities in any of the IMPU formats (SIP URI, TEL URI as well as the E.164 number in a SIP URI or TEL URI). In case a PBX is connected to a PLMN, the interception of targets that are served by PBX may be treated as non-local identities in the connected PLMN.
NOTE It is assumed that GPSI/MSISDN is mapped to IMPU, and SUPI/IMSI is mapped to IMPI.
7.4.2.3 Target identification
Depending on the session direction, different SIP parameters are used to identify the target subscriber.
Further details on the use of SIP parameters in identifying a target is described in TS 33.128 [15].
7.4.3 IRI-POI
7.4.3.1 General
The IRI-POI detects the SIP messages that are related to a target subscriber and then generates and delivers the related xIRI to the MDF2 over LI_X2.
The following IMS Network Functions (i.e. IMS Signalling Functions) that handle SIP signalling for IMS sessions may provide the IRI-POI functions:
– S-CSCF.
– E-CSCF.
– P-CSCF.
– IBCF.
– MGCF.
– Conference AS/MRFC.
– Telephony AS.
– PTC server.
Clause 7.4.6 gives more information from network topology/session perspective how different IMS Network Functions are to be used in providing the IRI-POI functions. The Telephony AS is one of the IMS Network Functions that provides the IRI-POI for STIR/SHAKEN and RCD/eCNAM (see clause 7.14.2).
7.4.3.2 IRI events
The IRI-POI present in the IMS Signalling Function generates the following xIRI:
– Encapsulated SIP message.
– CC unavailable in serving PLMN.
– Start of interception with an established IMS session.
The encapsulated SIP message xIRI is generated and delivered to the MDF2 when the IRI-POI in the IMS Signalling Function detects that a SIP message is received from, or sent to, a target or processed on behalf of a target at the IMS Signalling Function.
The CC unavailable in PLMN xIRI is generated and delivered to the MDF2 for the session scenarios where access to the target media is not available to the CSP (see clause 7.4.7.1).
The start of interception with an established IMS session xIRI is generated when an interception is activated on an established IMS session. To support the possibility of generating such an xIRI, the IMS Signalling Function shall store and maintain the session related information including the media information for the life of all IMS sessions.
7.4.3.3 Common IRI parameters
The list of parameters in each xIRI are defined in TS 33.128 [15]. Each xIRI shall include at the minimum the following information:
– Target identity.
– Additional identities associated with the target as observed by the IRI-POI.
– Time stamp.
– Correlation information.
7.4.3.4 Specific IRI parameters
The parameters in each xIRI are defined in TS 33.128 [15].
7.4.4 CC-TF and CC-POI
7.4.4.1 General
The CC-TF detects the SIP messages that are related a target and then generates and sends a trigger to the CC-POI over the LI_T3 reference point.
The CC-POI based on the trigger detects the media to be intercepted, generates the xCC and delivers the same to the MDF3.
The following IMS Network Functions (i.e. IMS Media Functions and IMS Signalling Functions) may provide the CC-POI and CC-TF functions:
– IMS-AGW with CC-TF in P-CSCF.
– TrGW with CC-TF in IBCF.
– IM-MGW with CC-TF in MGCF.
– MRFP with CC-TF in AS/MRFC (see NOTE 3).
– MRFP with CC-TF in Conference AS/MRFC (see NOTE 2).
– PTC Server with CC-TF in PTC Server (see NOTE 1).
Clause 7.4.6 gives more information from network topology/session perspective how different IMS Network Functions are to be used in providing the CC-TF/CC-POI functions.
NOTE 1: The PTC Server provides the IRI-POI and CC-POI functions, accordingly, PTC Server itself is the CC-TF.
NOTE 2: Conference AS, MRFC and MRFP together are referred to as Conference Server. Conference AS/MRFC provide the conference focus functions as defined in TS 24.147 [28].
NOTE 3: When music tone or announcement is given to the calling user prior to answer on an incoming call to the target.
7.4.4.2 CC intercept trigger
The CC-TF shall send CC intercept trigger to the CC-POI over LI_T3. The CC intercept trigger, at the minimum, shall consist of the following:
– Correlation Identifier.
– Media Identifier (e.g. SDP information).
The Correlation Identifier is used to correlate the xCC with the corresponding xIRI and is delivered from the CC-POI over the LI_X3 interface to the MDF3.
The Media Identifier is used to identify the media packets that have to be intercepted.
7.4.4.3 Common CC parameters
For the delivery of intercepted media packets, the following information shall be passed from the CC-POI to the MDF3 in addition to the intercepted media packets:
– Target identity.
– Correlation identifier
– Time stamp.
– Direction (indicates media is from or to the target).
7.4.5 Correlation of xCC and xIRI
The IRI messages derived from the xIRI and CC derived from xCC for a session shall be correlated to each other using the correlation information received in the xIRI and xCC. The details of this are specified in TS 33.128 [15].
7.4.6 Network topologies
7.4.6.1 General
The IMS Network Functions that provide the IRI-POI, CC-TF and CC-POI functions can vary based on the network topology and session scenarios such as:
– Network topologies:
– Non-roaming.
– Roaming case with Local Break Out (LBO), VPLMN.
– Roaming case with LBO, HPLMN.
– Roaming case with Home Routed (HR), VPLMN.
– Roaming case with HR, in HPLMN.
– Session types:
– Normal sessions.
– Emergency sessions.
– Redirected sessions.
– IMS specific services such as conferencing, PTC, music, announcements.
– SMS over IMS.
– Target type:
– Non-local ID target.
A deployment option within the CSP may also have a role in selection of the Network Functions. In the case of roaming case, the interception performed in the VPLMN and HPLMN are based on separate independent warrants.
More detailed description of these scenarios is given in TS 33.128 [15].
7.4.6.2 IMS Network Functions providing the IRI-POI
The IMS Network Functions that handle the target side of the session provide the IRI-POI functions except when the alternate option is used for the non-local ID target. When the alternate option is used for the non-local ID target, the IMS network function that handles the session-leg of the local served user connected directly to the non-local ID target.
Table 7.4.6.2-1 below identifies the IMS Network Functions in providing the IRI-POI functions in a non-roaming case for various session scenarios.
Table 7.4.6.2-1: IMS Network Functions providing the IRI-POI functions (non-roaming case)
Session type/target type |
Default |
Alternative option |
Normal sessions |
S-CSCF |
P-CSCF |
SMS over IMS |
S-CSCF |
P-CSCF |
Emergency sessions |
E-CSCF |
P-CSCF (NOTE 1) |
SMS over IMS to emergency services |
E-CSCF |
P-CSCF (NOTE1) |
Redirected sessions: intra-PLMN |
S-CSCF |
P-CSCF |
Redirected sessions: inter-PLMN (CS domain) |
S-CSCF |
MGCF |
Redirected sessions: inter-PLMN (IMS domain) |
S-CSCF |
IBCF |
Conference (NOTE 2) |
Conf-AS/MRFC |
– |
PTC |
PTC-Server |
– |
Non-local ID in CS domain (NOTE 3, NOTE 3A) |
MGCF |
S-CSCF |
Non-local ID in IMS domain (NOTE 3, NOTE 3A) |
IBCF |
S-CSCF |
Non-local ID for SMS over IMS (NOTE 3) |
S-CSCF |
P-CSCF (NOTE 3A) |
NOTE 1: For originated emergency sessions (or SMS over IMS to emergency services centre) handled in the fixed networks, where S-CSCF is also part of an emergency session, the S-CSCF based IRI-POI as a deployment option may also be considered.
NOTE 2: A conference ID can also be a target. Conf-AS stands for conference AS (see NOTE 2 in clause 7.4.4.1). When a normal session is extended to a conference session, the IMS signalling functions that provide the IRI-POI functions prior to the conference may continue to provide the IRI-POI functions in addition to the conference AS/MRFC.
NOTE 3: Non-roaming means that the local served user is non-roaming.
NOTE 3A: The default/alternate option used when the target is non-local ID is mutually independent of default/alternate option used when the target is local served user.
Table 7.4.6.2-2 below identifies the IMS Network Functions in providing the IRI-POI functions in a roaming case for various session scenarios.
Table 7.4.6.2-2: IMS Network Functions providing the IRI-POI functions (roaming case)
Session type/target type |
Local Breakout (LBO) |
Home Routed (HR) |
||||||
HPLMN |
VPLMN |
HPLMN |
VPLMN |
|||||
Default |
Alternate Option |
Default |
Alternate Option |
Default |
Alternate Option |
Default |
Alternate Option |
|
Normal sessions |
S-CSCF |
IBCF |
P-CSCF |
– |
S-CSCF |
P-CSCF |
N9HR/S8HR |
– |
SMS over IMS |
S-CSCF |
IBCF |
P-CSCF |
– |
S-CSCF |
P-CSCF |
N9HR/S8HR |
– |
Emergency sessions/SMS over IMS |
– |
– |
E-CSCF |
P-CSCF |
– |
– |
E-CSCF |
P-CSCF |
SMS over IMS to emergency services |
– |
– |
E-CSCF |
P-CSCF |
– |
– |
E-CSCF |
P-CSCF |
Redirected sessions |
S-CSCF |
See table 7.4.6.2-3 |
– |
– |
S-CSCF |
See table 7.4.6.2-3 |
– |
– |
Conference (NOTE 2) |
Conf-AS/MRFC |
– |
– |
– |
Conf-AS/MRFC |
– |
– |
– |
PTC |
PTC-Server |
– |
– |
– |
PTC-Server |
– |
– |
– |
Non-local ID (E.164) in CS domain (NOTE 3A, NOTE 4, NOTE 4A) |
MGCF |
S-CSCF |
P-CSCF |
IBCF (NOTE 4B) |
MGCF |
S-CSCF (NOTE 3A) |
N9HR/S8HR |
– |
Non-local ID in SIP/IMS domain (NOTE 3A, NOTE 4, NOTE 4A) |
IBCF |
S-CSCF |
P-CSCF |
IBCF (NOTE 4B) |
IBCF |
S-CSCF (NOTE 3A) |
N9HR/S8HR |
– |
Non-local ID for SMS over IMS (NOTE 4) |
S-CSCF |
IBCF |
P-CSCF |
– |
S-CSCF |
P-CSCF |
N9HR/S8HR |
– |
NOTE 4: For roaming, this means the local served user is roaming. Also, see NOTE 3.
NOTE 4A: The default/alternate options used in the HPLMN and default/alternate options used in the VPLMN are mutually independent.
NOTE 4B: This alternate option may be used only in the VPLMN for IMS sessions with home-routed media.
The interception capabilities for normal sessions as defined in tables 7.4.6.2-1 (non-roaming) and 7.4.6.2-2 (roaming) shall be used for the cases where the Conf-AS and the PTSC-Server are not under the control of CSP serving the warrant.
Table 7.4.6.2-3: Extension of table 7.4.6.2-2
Session type/target type |
Local Breakout (LBO) |
Home Routed (HR) |
|
Redirected sessions: Intra-PLMN |
Redirected-to party non-roaming |
P-CSCF |
P-CSCF |
Redirected-to party is roaming |
IBCF |
P-CSCF |
|
Redirected sessions Inter-PLMN |
Redirected-to party in CS domain |
MGCF |
MGCF |
Redirected-to party in IMS domain |
IBCF |
IBCF |
Table 7.4.6.2-3 shows the IMS Network Functions that provide the IRI-POI functions in the HPLMN for redirected sessions in a roaming case when the alternate option is used to provide the IRI-POI functions for the normal case.
NOTE 5: For the redirected do not answer related sessions, the IMS Network Functions that provide the IRI-POI functions prior to the redirection are as illustrated in table 7.4.6.2-2 (normal case) and after the redirection are as illustrated in table 7.4.6.2-3.
The IMS Network Functions that provide the IRI-POI for STIR/SHAKEN and RCD/eCNAM are listed in clause 7.14.2.
7.4.6.3 IMS Network Functions providing the CC-TF and CC-POI functions
The IMS Network Functions that handle the target side (including the non-local ID target) of the session provide the CC-TF and CC-POI functions. For redirected scenarios, the IMS Network Functions that handle the redirected-to-user side of the session provide the CC-TF and CC-POI functions.
Table 7.4.6.3-1 provides the IMS Network Functions that provide the CC-TF functions when the CC-POI functions are provided by the IMS Media Functions as indicated (also see clause 7.4.4.1).
Table 7.4.6.3-1: Mapping between the IMS Network Functions providing the CC-TF and the CC-POI functions
CC-POI |
CC-TF |
PGW (NOTE 1) |
P-CSCF |
PGW-U (NOTE 1) |
P-CSCF |
IMS-AGW |
P-CSCF |
MRFP |
AS/MRFC |
MRFP |
Conference AS/MRFC |
PTC-Server |
PTC-Server |
TrGW |
IBCF |
IM-MGW |
MGCF |
NOTE 1: This is defined in TS 33.107 [11] and outside the scope of the present document.
Table 7.4.6.3-2 below identifies the IMS Media Functions that provide the CC-POI functions in a non-roaming case for session scenarios (PGW and PGW-U based options are not shown in the table).
Table 7.4.6.3-2: IMS Media Functions providing the CC-POI functions (non-roaming case)
Session type/target type |
CC-POI |
Normal sessions |
IMS-AGW |
Emergency sessions |
IMS-AGW |
Redirected sessions: intra-PLMN |
IMS-AGW |
Redirected sessions: inter-PLMN (CS domain) |
IM-MGW |
Redirected sessions: inter-PLMN (IMS-domain) |
TrGW |
Music, announcement |
MRFP |
Conference (NOTE 4) |
MRFP |
PTC |
PTC- Server |
Non-local ID in CS domain (NOTE 2) |
IM-MGW |
Non-local ID in IMS domain (NOTE 2) |
TrGW |
NOTE 2: Non-roaming means that the local served user is non-roaming.
Table 7.4.6.3-3 below identifies the IMS Media Functions that provide the CC-POI functions in a roaming case for various session scenarios (PGW and PGW-U based options are not shown in the table).
Table 7.4.6.3-3: IMS Media Functions providing the CC-POI functions (roaming case)
Session type/target type |
Local Breakout (LBO) |
Home Routed (HR) |
||||
HPLMN |
VPLMN |
HPLMN |
VPLMN |
|||
Default |
Alternate Option |
|||||
Normal sessions |
TrGW |
IMS-AGW |
– |
IMS-AGW |
N9HR/ S8HR |
|
Emergency sessions |
– |
IMS-AGW |
– |
– |
IMS-AGW |
|
Redirected sessions: intra-PLMN |
Redirected-to-party non-roaming |
IMS-AGW |
– |
– |
IMS-AGW |
– |
Redirected-to-party roaming |
TrGW |
– |
– |
IMS-AGW |
– |
|
Redirected sessions: inter-PLMN |
Redirected-to-party in CS domain |
IM-MGW |
– |
– |
IM-MGW |
– |
Redirected-to-party in IMS domain |
TrGW |
– |
– |
TrGW |
– |
|
Conference (NOTE 4) |
MRFP |
– |
– |
MRFP |
– |
|
Music, announcement |
MRFP |
– |
– |
MRFP |
– |
|
PTC |
PTC-Server |
– |
– |
PTC-Server |
– |
|
Non-local ID in CS domain (NOTE 3) |
IM-MGW |
IMS-AGW |
TrGW (NOTE 5) |
IM-MGW |
N9HR/ S8HR |
|
Non-local ID in IMS domain (NOTE 3) |
TrGW |
IMS-AGW |
TrGW (NOTE 5) |
TrGW |
N9HR/S8HR |
NOTE 3: Roaming means that the local served user is roaming.
NOTE 4: When a normal session is extended to a conference session, the IMS-AGW that provides the CC-POI functions prior to the conference may continue to provide the CC-POI functions as an alternate, or in addition, to the MRFP. In that case, the P-CSCF provides the CC-TF functions for the CC-POI in the IMS-AGW.
NOTE 5: This is applicable only for IMS sessions with home-routed media with a TrGW present in the VPLMN.
7.4.7 Roaming cases
7.4.7.1 Media unavailable in a roaming case
For roaming targets, depending on the roaming architecture deployed, media of the target may not enter the HPLMN for certain session scenarios. In such situations, the HPLMN served with the warrant shall be able to do the following:
– Perform the interception without the CC and report to the LEMF that the CC is unavailable due to target’s roaming situation. Note that the Serving System message (reported by the UDM/HSS) also indicates to the LEMF that the target is roaming.
– When a new warrant is activated on a target with an ongoing IMS session with the CC not available, the HPLMN serving the new warrant shall report the CC unavailability indication to the LEMF associated with the new warrant.
See TS 33.128 [15] for the method used to report the CC unavailability indication.
7.4.7.2 S8HR
7.4.7.2.1 Background
The term S8HR is used to denote the home-routed roaming architecture for VoEPS UEs. 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 is used to carry the media packets). The EPS Bearer ID of the IMS signalling bearer is always linked to the dedicated EPS Bearer used as a media bearer.
The SGW/PGW within the EPC may implement control plane and user plane functions in a combined form or in a separated form. In a separated form, the SGW-C/PGW-C provides the control plane functions and SGW-U/PGW-U provides the user plane functions.
NOTE: With S8HR, the PGW (or PGW-C/PGW-U) resides in the HPLMN.
7.4.7.2.2 LI architecture
The present document specifies two options for implementing the LI functions for voice services with S8HR as the roaming architecture:
1. Use the capabilities specified below in the present document for stage 2 and in TS 33.128 [15] for stage 3.
2. Use the capabilities defined in TS 33.107 [11] and TS 33.108 [21] natively as defined in those documents.
According to the present document, to provide the lawful interception of voice services in the VPLMN with S8HR, the architecture presented in figure 7.4.7.4-1 is used with SGW-C providing the BBIFF-C and SGW-U providing the BBIFF-U functions.
NOTE 1: The overall architecture and functions related to the lawful interception of voice services of inbound roaming targets with S8HR as the roaming architecture is also referred in the present document as S8HR LI.
NOTE 2: The LI functions for SGW in a combined form can be visualized presuming that SGW-C and SGW-U are provided by the same network function. In this mode, the BBIFF-C and BBIFF-U functions are provided by BBIFF.
S8HR LI solution requires that Access Point Name (APN) can be identified as being used for S8HR and therefore can be used to identify that the EPS Bearers are used for inbound roamers with S8HR.
7.4.7.2.3 S8HR LI Process
For the describing the S8HR LI process, the following terms apply:
– The packet data connection representing the IMS signalling channel referenced in clause 7.4.7.4.11 is referred to as IMS signalling bearer. This is also referred to as the default bearer and uses the QCI value of 5, GSMA IR.92 [26].
– The packet data connection representing the IMS media channel referenced in clause 7.4.7.4.11 is referred to as IMS media bearer. This is a dedicated bearer and uses the QCI value of 1 for voice media, GSMA IR.92 [26].
– The IMS signalling bearer and IMS media bearers are on separate GTP tunnels but are linked.
The S8HR LI process follows the steps described in clause 7.4.7.4.11 with the following specific aspects that apply to S8HR:
– The LIPF configures the BBIFF-C present in the SGW-C to notify the LMISF-IRI whenever an IMS signalling bearer or an IMS media bearer is created, modified, or deleted for S8HR inbound roaming UEs (i.e. the UEs that use S8HR APN).
– The BBIFF-C present in the SGW-C notifies the LMISF-IRI whenever it detects that such an IMS signalling bearer or an IMS media bearer is created, modified, or deleted.
– When the LMISF-IRI detects that IMS voice media interception is required, the LMISF-IRI instructs the BBIFF-C present in the SGW-C to deliver the user plane packets from the related IMS voice media bearer to the LMISF-CC.
NOTE 1: The LMISF-IRI includes the target UE location (when required) in the xIRI based on the UE location that it receives within the messages that denote the creation, modification, or deletion of IMS signalling or media bearers.
NOTE 2: When a target UE is involved in more than one IMS session, the release of an IMS session will not result in the BBIFF-U stopping the delivery of the user plane packets from the IMS media bearer since the IMS media bearer may still be active for that target UE.
7.4.7.2.4 CC intercept trigger
The CC-POI and IRI-POI functions are provided by the embedded functions LMISF-CC and LMISF-IRI within the LMISF. As such the only interaction required between the two is to establish the correlation between the xCC and xIRI at an IMS session-leg level.
The LMISF-IRI instructs the BBIFF-C present in the SGW-C to deliver the user plane packets (to LMISF-CC) from the IMS media bearer linked to the IMS signalling bearer when it determines that an IMS session is associated with a target and requires CC interception. The BBIFF-C forwards the instruction along with the linked IMS signalling bearer information to BBIFF-U present in the SGW-U.
7.4.7.2.5 S8HR LI and Target UE Mobility
During a session that involves the target UE, the SGW-C/SGW-U associated with the BBIFF-C/BBIFF U can change.
To support the continued interception of IMS sessions, the BBIFF-C in the new SGW-C notifies the LMISF-IRI that a BBIFF relocation has occurred.
The LMISF-IRI provides the functions described in clause 7.4.7.4.12 to support the continued and correlated interception for the CC.
NOTE: The LMISF should not disrupt the ongoing interception, if an IMS signalling bearer deletion notification is received from the BBIFF-C present in the old SGW-C.
7.4.7.3 N9HR
7.4.7.3.1 Background
The term N9HR is used to denote the home-routed roaming architecture for Vo5GS UEs. Within the VPLMN with N9HR, the IMS signalling messages and media packets are carried over the GTP tunnel that corresponds to the PDU session established for the UE for IMS based services.
The IMS signalling packets and the media packets are on separate Quality of Service (QoS) Flows with specific 5QI values (5QI = 5 for IMS signalling and 5QI = 1 for voice, GSMA NG.114 [27]). The H-SMF in the HPLMN assigns a separate QoS Flow Index (QFI) for IMS signalling related packets and IMS voice related packets. The UPF in the VPLMN can isolate the IMS signalling and media related packets from user plane packets based on the QFI value.
7.4.7.3.2 LI architecture
To provide the lawful interception of voice services in the VPLMN with N9HR, the architecture presented in figure 7.4.7.4-1 is used with SMF providing the BBIFF-C and UPF providing the BBIFF-U functions.
NOTE: The overall architecture and functions related to the lawful interception of voice services of inbound roaming targets with N9HR as the roaming architecture is also referred in the present document as N9HR LI.
N9HR LI requires that a Data Network Name (DNN) can be identified as being used for N9HR and therefore can be used to identify that PDU sessions are used for inbound roamers with N9HR.
The BBIFF-C and BBIFF-U functions are provided by adopting a subset of LI functions defined for LI at SMF/UPF as defined in clause 6.2.3 and TS 33.128 [15].
7.4.7.3.3 N9HR LI Process
For the purposes of describing the N9HR LI process, the following terms apply:
– The packet data connection representing the IMS signalling channel referenced in clause 7.4.7.4.11 is referred to as PDU session with IMS signalling related QoS flow.
– The packet data connection representing the IMS media channel referenced in clause 7.4.7.4.11 is referred to as PDU session with IMS media related QoS flow.
The IMS signalling and the IMS voice media are on the same PDU session.
NOTE 1: The QoS flow associated with the IMS signalling related user plane packets have the 5QI value 5, GSMA NG.114 [27] and such user plane packets can be identified at the BBIFF-U in UPF with the assigned QFI value.
NOTE 2: The QoS flow associated with the IMS voice media related user plane packets have the 5QI value 1, GSMA NG.114 [27] and such user plane packets can be identified at the BBIFF-U in UPF with the assigned QFI value.
The N9HR LI process follows the steps described in clause 7.4.7.4.11 with the following specific aspects that apply to N9HR:
– The LIPF configures the BBIFF-C present in the SMF to notify the LMISF-IRI whenever a PDU session is created, modified, or deleted for inbounding roaming UEs with an N9HR DNN.
– The BBIFF-C present in the SMF notifies the LMISF-IRI whenever it detects that a PDU session is created, modified, or deleted for inbound roaming UEs with N9HR DNN. The UE location information and the PDU session ID is included in such notifications.
– When the LMISF-IRI determines that IMS voice media interception is required, the LMISF-IRI instructs the BBIFF-C present in the SMF with the PDU session information that the IMS voice media related user plane packets from that PDU session are to be delivered to LMISF-CC.
NOTE 3: The LMISF-IRI includes the target UE location (when required) in the xIRI based on the UE location that it receives within the messages that denote the creation, modification, or deletion of the PDU session.
NOTE 4: When a target UE is involved in more than one IMS session, the release of an IMS session will not result in the BBIFF-U stopping delivery of IMS media related user plane packets since the IMS media related QoS Flow may still be active within the PDU session.
7.4.7.3.4 CC intercept trigger
The CC-POI and IRI-POI functions are provided by the embedded functions LMISF-CC and LMISF-IRI within the LMISF. As such the only interaction required between the two is to establish the correlation between the xCC and xIRI at an IMS session-leg level.
The LMISF instructs the BBIFF-C present in the SMF to deliver to (to LMISF-CC) the IMS voice media related user plane packets from the PDU session associated with the intercepted IMS session. The BBIFF-C present in the SMF forwards the instruction along with the PDU session information to BBIFF-U present in the UPF.
7.4.7.3.5 N9HR LI and Target UE Mobility
During a session that involves the target UE, the SMF that has the BBIFF-C, or the UPF that has the BBIFF-U can change.
To support the continued interception of IMS sessions, the BBIFF-C in the new SMF notifies the LMISF-IRI that a BBIFF (i.e., SMF or UPF) relocation has occurred.
The LMISF-IRI provides the functions described in clause 7.4.7.4.12 to support the continued and correlated interception of CC.
NOTE: The LMISF should not disrupt the ongoing interception, if a PDU session deletion related notification is received from the BBIFF-C present in the old SMF.
7.4.7.4 LI in VPLMN with home-routed roaming architecture
7.4.7.4.1 Background
With home-routed roaming architecture, all the IMS Signalling Functions and IMS Media Functions reside in the HPLMN. National regulations may still 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 home-routed 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) and the media is exchanged between the UE and the IMS-AGW (in HPLMN).
7.4.7.4.2 LI architecture
To provide the lawful interception of voice services in the VPLMN with home-routed roaming architecture, new LI-specific functions are introduced to examine the packets that flow through the VPLMN packet core network functions in order to generate IRI and CC when the communication involves an inbound roaming target.
Figure 7.4.7.4-1 shown below illustrates a generic LI architecture for home-routed roaming architecture in the VPLMN.
Figure 7.4.7.4-1: VPLMN generic LI architecture for home-routed roaming
NOTE: See clause 7.4.7.4.10 for brief descriptions of the LI functions and interfaces depicted in figure 7.4.7.4-1.
7.4.7.4.3 Target identifiers
The target identifiers used for inbound roaming UEs are same as the identifiers used for IMS sessions in the VPLMN with LBO as the roaming architecture. See clause 7.4.2.2 for further details.
7.4.7.4.4 Target identification
Depending on the session direction, different SIP parameters are used to identify the target. The SIP parameters used to identify the target can be different from the SIP parameters used to identify a target at the P-CSCF (with LBO as the roaming architecture).
Further details on the use of SIP parameters in identifying a target are described in TS 33.128 [15].
7.4.7.4.5 IRI events
The IRI events are same as the xIRI defined for IMS sessions in the VPLMN with LBO as the roaming architecture. See clause 7.4.3.2 for details.
7.4.7.4.6 IRI parameters
The IRI parameters are the same as those defined for IMS sessions in the VPLMN with LBO as the roaming architecture. See clauses 7.4.3.3 and 7.4.3.4 for details.
7.4.7.4.7 CC intercept trigger
The LMISF-IRI instructs the BBIFF-C (over the LI_T1 interface) to deliver the IMS media packets when it determines that an IMS session is associated with a target and requires CC interception. The BBIFF-C forwards the instruction to BBIFF-U over the LI_T3 interface.
7.4.7.4.8 CC parameters
The CC parameters are the same as those defined for IMS sessions in the VPLMN with LBO as the roaming architecture. See clause 7.4.4.3 for details.
7.4.7.4.9 Correlation of xCC and xIRI
The LMISF assigns the correlation number for an IMS session and uses the same correlation number in the associated xIRI and xCC. The interaction between the LMISF-IRI that generates the xIRI and LMISF-CC that generates the xCC is an internal function of LMISF.
7.4.7.4.10 LI specific functions and interfaces
The additional LI specific functions and interfaces introduced to support the LI with home-routed roaming architecture shown in figure 7.4.7.4-1 are listed below:
– LMISF (LI Mirror IMS State Function): A logical LI specific function that provides the IMS state function for LI purposes. The LMISF provides the IRI-POI and CC-POI functions. The LMISF also initiates the required trigger for IMS media interception. The LMISF may be viewed as consisting of two embedded functions: 1) LMISF-IRI (handling the IMS signalling related LI functions, i.e. IRI-POI), 2) LMISF-CC (handling the IMS media related LI functions, i.e. CC-POI). The interface between the two embedded functions is not defined.
NOTE 1: The present document assumes one LMISF per VPLMN for a given roaming agreement.
NOTE 2: The term LMISF is used when a description applies to LMISF-IRI or LMISF-CC.
– BBIFF (Bearer Binding Intercept and Forward Function): Binds the IMS signalling and media to the LMISF for interception purpose. The BBIFF may be split into two BBIFF-C and BBIFF-U, with the former present in the NF that provides the control plane related functions and the latter present in the NF that provides the user plane related functions associated with the inbound roaming UEs.
– LI_X2_LITE: Used to carry the control plane information (e.g. packet data connection related notifications, UE location) from BBIFF-C to LMISF-IRI.
– LI_X3_LITE_S: Used to forward the IMS signalling related user plane packets of inbound roaming UEs from BBIFF-U to the LMISF-IRI.
– LI_X3_LITE_M: Used to forward the IMS media related user plane packets of inbound roaming target UE from BBIFF-U to the LMISF-CC.
– LI_T1: Used to instruct the BBIFF-C that user plane packets of the associated IMS media need to be captured and delivered to the LMISF-CC.
– LI_T3: Used to instruct the BBIFF-U to capture and deliver the selective user plane packets of inbound roaming UEs to the LMISF.
The user plane packets reported by BBIFF-U include the IMS signalling related packets and IMS media related packets. A condition required for this LI architecture is that LMISF shall have access to the IMS signalling messages and the IMS media packets in an unencrypted form.
NOTE 3: The LI functions available within the VPLMN network functions that have access to the packet data connections that carry the IMS signalling and IMS media may be used to provide the BBIFF-C, BBIFF-U functions.
7.4.7.4.11 LI Process
The following steps happen for all home-routed inbound roaming UEs irrespective of whether those UEs are associated with a target:
– The LIPF configures the BBIFF-C (over LI_X1 interface) to notify the LMISF-IRI whenever home-routed inbound roaming UEs establish, modify or delete the IMS signalling and the IMS media channels. The UE exchanges the IMS signalling messages with the P-CSCF residing in the HPLMN over the IMS signalling channel and IMS media with the IMS-AGW residing in the HPLMN over the IMS media channel. The LIPF also provides the same information to LMISF-IRI (over LI_X1 interface) in order to let it know the notifications to be expected from the BBIFF-C.
NOTE 1: The term channel is a generic term used in this description to represent IMS signalling or media related packet data connection within a PDN (Packet Data Network) connection.
– The BBIFF-C notifies the LMISF-IRI (over LI_X2_LITE interface) whenever the IMS signalling channel or the IMS media channel is established, modified or deleted for home-routed inbound roaming UEs. The UE location information is included in such notifications. The BBIFF-C instructs the BBIFF-U (over LI_T3 interface) to deliver the appropriate IMS signalling related user plane packets to the LMISF-IRI.
– The BBIFF-U delivers the IMS signalling related user plane packets to the LMISF-IRI (over the LI_X3_LITE_S interface).
The following steps are performed for the target UEs:
– The LIPF provisions the LMISF-IRI, MDF2 and MDF3 (over LI_X1 interface) with the IMS target information.
– When the received user plane packets from the BBIFF-U represent IMS signalling messages associated with a target, the LMISF-IRI generates the xIRI and delivers them to the MDF2 over the LI_X2 interface.
– Upon identifying that IMS signalling messages are associated with a target that requires CC interception, the LMISF-IRI instructs the BBIFF-C (over LI_T1 interface) that the user plane packets that represent associated IMS media (i.e. from the IMS media channel associated with the IMS signalling channel) are to be delivered to LMISF-CC.
– The BBIFF-C instructs the BBIFF-U (over LI_T3 interface) to deliver user plane packets that represent the associated IMS media to the LMISF-CC.
– The BBIFF-U delivers the indicated user plane packets that represent the IMS media to the LMISF-CC (over LI_X3_LITE_M interface). The LMISF-CC generates xCC from the received IMS media related user plane packets and delivers them to the MDF3 over LI_X3 interface along with the information that correlates the xCC with the xIRI.
NOTE 2: LMISF-CC interacts with the LMISF-IRI to correlate the xCC with the xIRI.
– When all IMS sessions for a target UE have ended, LMISF-IRI instructs the BBIFF-C (over LI_T1 interface) to stop the delivery of IMS media related user plane packets. Upon receiving such a notification, the BBIFF-C instructs the BBIFF-U (over LI_T3 interface) to stop the delivery of the IMS media related user plane packets to the LMISF-CC.
NOTE 3: In the above steps, BBIFF-C and BBIFF-U functions are not aware of any IMS target information (i.e. SIP URI or TEL URI).
NOTE 4: The LMISF-IRI includes the target UE location (when required) in the xIRI based on the UE location that it receives from the BBIFF-C.
The LMISF-IRI stores the IMS signalling messages received from the BBIFF-U for a potential future LI activation (i.e. mid-call interception). Furthermore, the xCC generated from the IMS media related user plane packets may be associated with different session-legs, and hence may have different correlation numbers.
When the inbound roaming UE deregisters for the IMS signalling (i.e. with HPLMN), the LMISIF shall ensure that deregistration is mirrored in its own maintained state for that UE.
7.4.7.4.12 Target UE Mobility
During a session that involves the target UE, the network function associated with the BBIFF-C, or the BBIFF U can change. The lawful interception of IMS sessions involving a target shall continue when such a relocation happens. The xIRI and xCC delivered before and after the relocation shall be correlated.
To support the continued interception of IMS sessions, the BBIFF-C in the new network function notifies the LMISF-IRI (over LI_X2_LITE interface) that a BBIFF relocation has occurred.
The LMISF-IRI provides the following functions to support the continued and correlated interception of CC:
– When a notification is received from the BBIFF-C that a BBIFF relocation has occurred, examine to see whether any IMS session is setup for the UE and is being intercepted.
– If an intercepted IMS session is setup, examine to see whether a CC interception for that IMS session is required.
– If the intercepted IMS session requires CC interception, inform the new BBIFF-C (over the LI_T1 interface) with an instruction that the user plane packets that represent associated IMS media are to be delivered to LMISF-CC.
Further handling of CC interception is as defined in clause 7.4.7.4.11.