7 Multi-media domain

33.1083G Security3GPPHandover interface for Lawful Interception (LI)Release 17TS

7.0 Introduction

Clause 7 deals with IRI reporting in the IMS. IRI reporting in the multi-media domain specified in this clause does not depend on the IP-Connectivity Access Network (IP-CAN), defined in TS 23.228 [40], used to transport the CC. When the IP-CAN is the UMTS PS domain, annexes C and G apply for CC interception at the SGSN/GGSN. However, such CC interception may intercept more than just the CC associated with an IMS based voice service. Hence, for separated VoIP CC intercept and reporting, refer to clause 12.

In addition, this clause also specifies IRI reporting from the HSS handling subscriber data for IMS network. Target identities to be used for interception of IRIs at the HSS are specified in TS 33.107 [19].

According to TS 33.107 [19], interception in the CSCFs shall be supported in the S‑CSCF and optionally in the P‑CSCF where the S-CSCF and the P-CSCF are in the same network. For roaming scenarios where the P-CSCF is in the Visited Network, interception at the P-CSCF is mandatory. The target identities for the intercept of traffic at the CSCFs are only the SIP-URI, TEL‑URI and IMEI (described in TS 23.003 [25], obtained from the Instance IDs, described also in TS 23.003 [25] as requested in clause7A.8 of TS 33.107 [19]. In the intercepting nodes (CSCF’s) the relevant SIP-Messages are duplicated and forwarded to the MF HI2.

The enhanced P-CSCF (eP-CSCF) shall adhere to all the LI requirements pertaining to a P-CSCF. Any additional LI requirements pertaining to the support of Web Real Time Communications (WebRTC) Interworking as specified in TS 23.228 [40] that only apply to the eP-CSCF are described distinctly.

In case of target manipulation of IMS supplementary service setting, the interception shall be made by XCAP servers maintaining XCAP resources related to the supplementary service settings defined in TS 22.173 [78] made on the interface Ut as described in TS 24.623 [77]. Any other points related to attempts to access to Target’s XCAP servers or, XCAP change/transaction in services setting related to the target, are for further studies.

Ut based XCAP manipulation messages for the IMS services for the target is reported. Any copy "en clair" of the XCAP exchanges (aggregated or not), between the UE and the AS, will be transmitted to the LEMF in the HI2 interface through the DF 2, that will encapsulate the XCAP Ut transactions in ASN.1. Such XCAP transactions on the Ut interface have to include any exchange of data, which are contained in the XCAP payload (e.g. the get, put, and delete operations on the XCAP resources).

NOTE: Interception of the target’s supplementary service setting management or modifications that are made outside the Ut interface is for further studies.

For clarification, see Figure 7.1. If the P‑CSCF and S‑CSCF are in the same network and LI is provided at both P-CSCF and S-CSCF, the events are sent twice to the LEMF.

Figure 7.1: IRI Interception at a CSCF

7.1 Identifiers

7.1.0 General

Specific identifiers are necessary to identify a target for interception uniquely and to correlate between the data, which is conveyed over the different handover interfaces (HI2 and HI3). The identifiers are defined in the subsequent subclauses of clause 7.1.

For the delivery of CC and IRI the SGSN, GGSN and CSCF’s provide correlation numbers and target identities to the HI2 and HI3. The correlation number provided in the PS domain (SGSN, GGSN) is unique per PDP context and is used to correlate CC with IRI and the different IRI’s of one PDP context. However, where separated delivery of IMS based VoIP is required, to ensure that the CC related to an IMS based VoIP call is intercepted and reported separately from other PS domain services while being correlated to the IMS based VoIP IRI, refer to clause 12.

Interception is performed on an IMS identifier(s) associated with the target including identifiers such as IMEI, SIP‑URI and Tel‑URI, ETSI EN 300 356 [30].

In addition, in case of interception at the HSS, IMSI shall be supported as target identity if it is available in the subscription data stored in the HSS and the association with IMS identities can be done.

IMEI and MSISDN shall be supported as target identities if the HSS is shared with access services (e.g. PS, EPS) and the association with IMS identities can be done.

Non-Local ID interception is based on SIP-URI or Tel URI. Non-Local Id may be present in any of the SIP headers used to identify either the calling party information and redirecting party information present in the incoming SIP message for incoming calls from target Non-Local ID, or the called party information present in the outgoing SIP message for outgoing calls to target Non-Local ID.

For Non-Local ID target interception, the CSP is not responsible for the deduplication of events.

7.1.1 Lawful Interception Identifier (LIID)

For each target identity related to an interception measure, the authorized operator (NO/AN/SP) shall assign a special Lawful Interception Identifier (LIID), which has been agreed between the LEA and the operator (NO/AN/SP).

Using an indirect identification, pointing to a target identity makes it easier to keep the knowledge about a specific target limited within the authorized operator (NO/AN/SP) and the handling agents at the LEA.

The LIID is a component of the CC delivery procedure and of the IRI records. It shall be used within any information exchanged at the handover interfaces HI2 and HI3 for identification and correlation purposes.

The LIID format shall consist of alphanumeric characters. It might for example, among other information, contain a lawful authorization reference number, and the date, when the lawful authorization was issued.

The authorized operator (NO/AN/SP) shall either enter, based on an agreement with each LEA: a unique LIID for each target identity of the target; or a single LIID for multiple target identities all pertaining to the same target.

Note that, in order to simplify the use of the LIID at the LEMF for the purpose of correlating IMS signalling with GSN CC, the use of a single LIID in association with potentially numerous IMS identities (IMEI, SIP and TEL URIs) is recommended.

If more than one LEA intercepts the same target identity, there shall be unique LIIDs assigned relating to each LEA.

In case the LIID of a given target has different values in the GSN and in the CSCF, it is up to the LEMF to recover the association between the two LIIDs.

7.1.2 Network identifier

The network identifier (NID) is a mandatory parameter; it should be internationally unique. It consists of the following two identifiers.

1) Operator- (NO/AN/SP) identifier (mandatory):
Unique identification of network operator, access network provider or service provider.

2) Network element identifier NEID (optional):
The purpose of the network element identifier is to uniquely identify the relevant network element carrying out the LI operations, such as LI activation, IRI record sending, etc.

A network element identifier may be an IP address or other identifier. National regulations may mandate the sending of the NEID.

7.1.3 Correlation number

Two parameters are defined to enable further correlation than can be accomplished via a LIID alone. The first is called a Correlation number while the second is simply called Correlation. The Correlation Number was initially defined to carry a GPRS/EPS Correlation Number and is limited to those access types that support a PDP Context/EPS Bearer. Subsequently, the Correlation parameter was defined to enable a more general correlation. The value used in the Correlation number parameter or the Correlation parameter may be generated by the CSCF.

When clause 12 is used to provide separated IMS VoIP intercept and delivery, imsVoIP (as defined in clause 12) may be used to provide the correlation between the IRI and CC of an IMS VoIP session and also between IRI messages of the same IMS VoIP session.

See clause 6.1.3 for a definition of the GPRS Correlation Number. See clause 10.5.0 for EPS Correlation Number.

NOTE 1: Void.

It is an implementation matter how the CSCF generates a correlation number parameter value. The CSCF should use the gPRSCorrelationNumber/ePSCorrelationNumber ASN.1 parameter as a container.

For a GPRS/UMTS access or LTE access, if two PDP contexts or two EPS Bearers are used for the communication (one for signalling and one for bearer) two correlation numbers may be delivered via the CSCFs. Different identifiers may be used for correlating a target’s various SIP messages such as:

– LIID;

– implementation dependent number.

NOTE 2: The implementation dependent number may be e.g. a ‘Call-id’. However, when a CSCF acts as a back-to-back user agent a CSCF can have different ‘Call-id’ values for different legs of signalling. Therefore some other number would be needed in such a case.

NOTE 3: The LIID may be used to associate SIP messages with respective GSN IRI records. In case the target is only permitted to have a single SIP session with a single CC bearer active at any time, the LIID is sufficient to correlate IMS IRI records with GSN IRI records. In all other case s, e.g. the target is permitted to have multiple SIP sessions active concurrently, a combination of the LIID and an implementation dependent number may be used to correlate the IMS IRI records with the GSN IRI records.

In case the LIID of a given target has different values in the GSN and in the CSCF, it is up to the LEMF to recover the association between the two LIIDs.

SIP correlation number is used to correlate events of one specific SIP session.

Correlation number is not applicable to interception at the HSS.

7.2 Timing and quality

7.2.1 Timing

As a general principle, within a telecommunication system, IRI, if buffered, should be buffered for as short a time as possible.

NOTE: If the transmission of IRI fails, it may be buffered or lost.

Subject to national requirements, the following timing requirements shall be supported:

– Each IRI data record shall be sent by the delivery function to the LEMF over the HI2 within seconds of the detection of the triggering event by the IAP at least 95% of the time.

– Each IRI data record shall contain a time-stamp, based on the intercepting nodes clock that is generated following the detection of the IRI triggering event. Subject to national requirements, IMS specific IRI timestamp should have higher precision than 1 second.

7.2.2 Quality

QoS is not applicable to SIP signalling and hence not to IMS specific IRI records.

NOTE: The QoS class in PS domain is defined only for user plane data (CC); refer to subclause 6.2.2.

7.2.3 Void

(Void)

7.3 Security aspects

When KMS based IMS media security TS 33.328 [54] is adopted in the network, the HI2 shall have strong integrity and confidentiality protection. In this case, the HI2 should be protected by TLS. FTP delivery should be done over TLS as specified by IETF RFC 4217 [58]. TLS and certificate profiling shall be according to TS 33.310 [60].

Additional security is defined by national requirements.

7.4 Quantitative aspects

The number of target interceptions supported is a national requirement.

The area of Quantitative Aspects addresses the ability to perform multiple, simultaneous interceptions within a provider’s network and at each of the relevant intercept access points within the network. Specifics related to this topic include:

– The ability to access and monitor all simultaneous communications originated, received, or redirected by the target;

– The ability for multiple LEAs (up to five) to monitor, simultaneously, the same target while maintaining unobtrusiveness, including between agencies;

– The ability of the network to simultaneously support a number of separate (i.e. multiple targets) legally authorized interceptions within its service area(s), including different levels of authorization for each interception, including between agencies (i.e. IRI only, or IRI and communication content when SIP message also contains content).

7.5 IRI for IMS

7.5.0 Introduction

In addition, information on non-transmission related actions of a target constitute IRI and is sent via HI2, e.g. information on SIP message with call forwarding configuration information.

The IRI may be subdivided into the following categories:

1. Control information for HI2 (e.g. correlation information).

2. Basic data context information, for standard data transmission between two parties (e.g. SIP- or XCAP-message).

3. Information needed to decrypt media traffic between the parties.

For each event, a Record is sent to the LEMF, if this is required. The following table gives the mapping between event type received at DF2 level and record type sent to the LEMF.

Table 7.1: Mapping between IMS Events and HI2 Records Type

Event	IRI Record Type
SIP-message	REPORT
XCAP-request	REPORT
XCAP response	REPORT
Media decryption keys available	REPORT
Start of interception for already established IMS session	REPORT
Serving System	REPORT
Subscriber record change	REPORT
Registration Termination	REPORT
Location Information Request	REPORT

A set of information is used to generate the record. The records used transmit the information from mediation function to LEMF. This set of information can be extended in the CSCF or DF2 MF, if new IEs are available and if this is necessary in a specific country. The following table gives the mapping between information received per event and information sent in records.

Once IRI only interception is underway, LEMF receives IMS specific IRI only (SIP IRI) from CSCF or IRI only (XCAP Message IRI) from the XCAP server managing the XCAP resource associated with the IMS supplementary service setting, or IRI only from the HSS. LEMF does not receive CC, and therefore it is not possible to correlate IMS specific IRI with CC.

Once IRI and CC interception is underway, LEMF receives IMS specific IRI both from a GSN and from a CSCF. LEMF receives SIP messages also from a GSN within CC. LEMF receives IRI of XCAP events from functions such as XCAP authentication and resource management function. In certain cases, however, SIP messages may be encrypted between UE and CSCF. XCAP message between the UE and the AS managing the target’s IMS supplementary service settings may be encrypted. In these cases LEMF needs to receive unencrypted SIP or XCAP messages in IMS specific IRI provided from CSCF, or from the XCAP server managing the target’s IMS supplementary service settings. The LI service delivery of XCAP events related to XCAP authentication process is for further study.

In some cases the CC is encrypted according to one of the IMS media security solutions specified in TS 33.328 [54]. In these cases the LEMF receives encrypted CC and decrypts it based on the decryption information received over the HI2 interface.

NOTE 0: CC interception is not applicable at the HSS.

When the InstanceID is present in IMS signalling TS 24.229 [76], and contains an IMEI URN [81], [82], the IMEI shall be extracted and converted to the reporting format defined for partyInformation (imei).

NOTE 1: Delivery of decrypted CC in the above scenario is FFS.

NOTE 1a: GSN has no possibility to decrypt SIP messages based on the IMS security architecture.

NOTE 2: Security mechanisms for protecting delivery of key material over the HI2 in line with TS 33.328 [54] are FFS.

NOTE 2a: When the CSCF is not aware of the activation of multiple lawfully authorized intercepts on a single target, the MF/DF needs to generate the REPORT with Start of Interception on an already established IMS session on its own using information that it has retained.

The DF2 shall not send the REPORT with Start of Interception with an already established IMS session to the LEMFs that were already intercepting the session due to a previous LI activation on the same target.

Table 7.2: Mapping between IMS Events Information and IRI Information

Parameter	Description	HI2 ASN.1 parameter
Observed SIP URI	Observed SIP URI	partyInformation (partyIdentity(sip-uri))
Observed TEL URI	Observed TEL URI	partyInformation (partyIdentity(tel-uri))
Observed IMEI	Observed IMEI	partyInformation (partyIdentity(imei))
Observed IMPI	Observed IMPI (NOTE 12)	partyInformation (partyIdentity(impi))
Observed IMSI	Observed IMSI (NOTE 12)	partyInformation partyIdentity( (imsi))
Observed MSISDN	Observed MSISDN (NOTE 12)	partyInformation (partyIdentity(msISDN))
Event type	IMS Event It indicates whether the IRI contains a CC unfiltered SIP message, a CC filtered SIP message, an XCAP request, an XCAP response, or the media decryption keys. For interception at the HSS, it indicates whether the IRI contains a Serving system, a Subscriber Record Change, a Registration Termination or a Location Information Request.	iMSevent
Event date	Date of the event generation in the CSCF or in the XCAP server managing the target’s IMS supplementary service setting(s).	timeStamp
Event time	Time of the event generation in the CSCF or in the XCAP server managing the target’s IMS supplementary service setting(s).
Network identifier	Unique number of the intercepting CSCF or the XCAP server managing the target’s IMS supplementary service setting(s).	networkIdentifier
Correlation number	Unique number for each PDP context/Bearer delivered to the LEMF, to help the LEA, to have a correlation between each PDP Context/Bearer and the IRI.	gPRSCorrelationNumber
Correlation	Correlation number; unique number for each PDP context/Bearer delivered to the LEMF, to help the LEA, to have a correlation between each PDP Context/Bearer and the IRI. ASN.1 as: iri-to-CC Signalling PDP context/Bearer correlation number; unique number for signalling PDP context/Bearer delivered to the LEMF, to help the LEA, to have a correlation between each PDP Context/Bearer and the IRI. Used in the case two PDP contexts/Bearers are used. ASN.1 as: iri-to-CC SIP correlation number; either Call-id or some implementation dependent number that uniquely identify SIP messages of the same SIP session. ASN.1 as: iri-to-iri XCAP transaction correlation number: It correlates the XCAP request and reponse.	correlation
Lawful interception identifier	Unique number for each lawful authorization.	lawfulInterceptionIdentifier
SIP message	Either whole SIP message, or SIP message header (plus SDP body, if any). SIP message header (plus SIP message body part conveying IRI such as SDP) is used if warrant requires only IRI. In such cases, specific content in the SIP Message (e.g. ‘Message’, etc.) has to be deleted; unknown headers shall not be deleted. For intercepts requiring IRI only delivery, depending on national regulations, SMS content may be excluded while SMS headers (which convey information including originating and destination addresses, SMS centre address) are included, if available. Location information that the service provider is aware of (e.g. location in PANI header) is removed when delivery of such information is not lawfully authorized.	sIPMessage
Media-decryption-info	Session keys and additional info for the decryption of the CC streams belonging to the intercepted session. This field is present if available at the DF/MF	mediaDecryption-info Contain for each key the follow triplet: cCCSID, cCDecKey, cCSalt (optionally)
SIP message header offer	Header of the SIP message carrying the SDP offer (NOTE 10).	sipMessageHeaderOffer
SIP message header answer	Header of the SIP message carrying the SDP answer (NOTE 10).	sipMessageHeaderAnswer
SDP offer	SDP offer used for the establishment of the IMS session (NOTE 10).	sdpOffer
SDP answer	SDP answer used for the establishment of the IMS session (NOTE 10).	sdpAnswer
MediaSec key retrieval failure indication	Provides the information that the procedure to get encryption keys from the KMS failed.	mediaSecFailureIndication
PANI header information	Elements of P-Access-Network-Info headers in SIP message; defined in TS 24.229 [76] §7.2A.4.	pANI-Header-Info
XCAP message	XCAP message (i.e. to report separately the XCAP request and XCAP response between the UE and the XCAP server managing the XCAP resources of the target’s IMS supplementary service setting(s); based on TS 24.623 [77]).	xCAPMessage
VoIP Roaming Indication	Applicable to IMS events related to VoLTE only. Indicates the roaming architecture in the VPLMN: Local Breakout (LBO) or S8HR (S8-reference point based home routing).	roamingIndication
Changed (old/new) IMSI or MSISDN/TEL URI/SIP URI/IMPI or IMEI	Provides the identity changes in Subscriber Record Change Event.	change-Of-Target-Identity
Other User Identities	Provides other IMPU or IMPI that was allocated to the Target being deregistered in HSS.	otherIdentities
Deregistration Reason	Provides the reason of de-registration in HSS Coded according to 3GPP TS 29.229 [96], values would be coded according to Reason-Code AVP when deregistration is initiated by HSS, and to Server-Assignment-Type AVP when indicated by SCSF.	deregistrationReason
Previous serving system identifier	Provides an identifier as defined in 3GPP TS 29.229 [96] that allows the home network to identify the previous visited network when deregistration is done.	visitedNetworkId
Current Serving System Identifier	Provides an identifier as defined in 3GPP TS 29.229 [96] that allows the home network to identify the current visited network.	visitedNetworkId
Other update	Carrier specific information related to implementation or subscription process on HSS. Raw data will be provided. CSP will provide to LEMF elements to understand such data.	carrierSpecificData
Requesting network identifier	The requesting network identifier PLMN id (Mobile Country Code and Mobile Network Code, defined in E.212 [87]).	requesting-Network-Identifier
Requesting node identifier	The requesting node identifier	requesting-Node-Identifier
Requesting node type	Type of requesting node such as MSC, SMS Centre, GMLC, MME, SGSN.	requesting-Node-Type
Location information	In case of S8HR, this parameter carries the UE location information that the LMISF receives from the MME through the S-GW/BBIFF.	ePSlocationOfTheTarget
Time of Location	Date/Time of location. The time when location was obtained by the location source node.	ePSlocationOfTheTarget

NOTE 3: Void.

NOTE 4: Void.

NOTE 5: Void.

NOTE 6: Void.

NOTE 7: LIID parameter has to be present in each record sent to the LEMF.

NOTE 8: Details for the parameter SIP message. If the warrant requires only signaling information, specific content in the parameter ‘SIP message’ like IMS (Immediate Messaging) has to be deleted/filtered. It should be noted that SDP content within SIP messages is reported even for warrants requiring only IRI.

NOTE 9: In case of IMS event reporting involving the correlation number parameter, the gPRSCorrelationNumber HI2 ASN.1 parameter, which is also used in the IRIs coming from UMTS PS nodes, is used as container.

NOTE 10: This parameter is applicable only in case of start of interception for an already established IMS session.

NOTE 11: For separated IMS VoIP, the imsVoIP (as defined in clause 12) may be used instead of Correlation Number or Correlation shown in table 7.2.

NOTE 12: Applicable to HSS only.

pANI-header-info parameter includes elements present in the P-Access-Network-Info (PANI) header in intercepted SIP messages originated by the target’s UE and handled by the CSCFs. The mediation function shall parse these intercepted SIP messages and copy from the PANI header the type/class of access and, if required by the warrant, location information in the related parameters specified in Annexes B.3 and B.9. In such case, the SIP messages carrying the PANI header shall also be sent to the LEMF unmodified.

In case the warrant does not require providing target’s location information, any location information shall be filtered from the intercepted raw SIP messages, prior that these are delivered to the LEMF. In such case, as an implementation option, location information may be masked (e.g. filled with blanks or other characters) instead of filtered.

7.5.1 Events and information

This clause describes the information sent from the Delivery Function (DF) to the Law Enforcement Monitoring Facility (LEMF) to support Lawfully Authorized Electronic Surveillance (LAES). The information is described as records and information carried by a record. This focus is on describing the information being transferred to the LEMF.

The IRI events and data are encoded into records as defined in the Table 7.1: Mapping between IMS Events and HI2 Records Type and Annexes B.3 and B.9 Intercept related information (HI2). IRI is described in terms of a ‘causing event’ and information associated with that event. Within each IRI Record there is a set of events and associated information elements to support the particular service.

The communication events described in Table 7-1: Mapping between the IMS Event and HI2 Record Type and Table 7.2: Mapping between IMS Events Information and IRI Information convey the basic information for reporting the disposition of a communication. This clause describes those events and supporting information.

Each record described in this clause consists of a set of parameters. Each parameter is either:

– mandatory (M): required for the record,

– conditional (C): required in situations where a condition is met (the condition is given in the Description), or

– optional (O): provided at the discretion of the implementation.

The information to be carried by each parameter is identified. Both optional and conditional parameters are considered to be OPTIONAL syntactically in ASN.1 Stage 3 descriptions. The Stage 2 inclusion takes precedence over Stage 3 syntax.

Table 7.3: SIP-Message REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target (if available).
observed TEL-URI	C	TEL URI of the target (if available).
observed IMEI	C	IMEI of the target (if available).
event type	M	Provide IMS event type.
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Shall be provided.
lawful intercept identifier	M	Shall be provided.
correlation number	C	If available and not included in the SIP-message. NOTE 1
correlation	C	If applicable for this communication. NOTE 1
SIP message	M	The relevant SIP message or SIP message header.
PANI header information	O	P-Access-Network-Access-Info header information in SIP messages; described in TS 24.229 [76] §7.2A.4. Provided if available and applicable.
VoIP Roaming Indication	C	Shall be provided when SIP messages are sent by the VPLMN.
Location information	C	In case of S8HR, when authorized, provides the UE location information that the LMISF receives from the MME through the S-GW/BBIFF.
Time of Location	C	Date/Time of Location. (if target location provided).

If transfer of ticket related information, as specified in TS 33.328 [54], is detected by the MF/DF via an intercepted SIP messages analysis during an IMS session, the DF/MF, after extracting and collecting the exchanged tickets and getting the corresponding decryption keys info from the KMS, as specified in TS 33.107 [19], shall send a Media Decryption key available IRI REPORT to the LEMF containing the information needed to decrypt the media:

Table 7.4: Media Decryption key available REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target (if available).
observed TEL-URI	C	TEL URI of the target (if available).
observed IMEI	C	IMEI of the target (if available).
event type	M	Decryption Keys Available
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Shall be provided.
lawful intercept identifier	M	Shall be provided.
correlation number	C	Provided if available. NOTE 1
correlation	C	Provided if available. NOTE 1
mediaDecryption-info.CCKeyInfo. cCCSID	C	Uniquely map the session key to the SRTP streams to decrypt. There could be several SRTP streams (audio, video, etc.) with different decryption keys and salt for a media session. The field reports the value from the CS_ID field in the ticket exchange headers as defined in the IETF RFC 6043 [61] provided if available.
mediaDecryption-info. CCKeyInfo.cCDecKey	C	Decryption key in both media directions. Provided if available.
mediaDecryption-info. CCKeyInfo.cCSalt	C	Provided if available.
mediaSecFailureIndication	O	May be provided in case of failure

NOTE 1: For separated IMS VoIP, the imsVoIP (as defined in clause 12) may be used instead of Correlation Number or Correlation shown in table 7.3, table 7.4 and table 7.5.

If Start of interception for an already established IMS session event is detected by the MF/DF, the DF/MF shall send a Start of Interception for already established IMS Session IRI REPORT to the affected LEMF containing the parameters listed in table 7.5:

NOTE 2: In some situation (e.g. during activation of second, third, etc, intercepts on the target), the MF/DF may have to detect on its own that an interception is activated on an already established IMS Session.

Table 7.5: Start of interception for already established IMS session REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target (if available).
observed TEL-URI	C	TEL URI of the target (if available).
observed IMEI	C	IMEI of the target (if available).
event type	M	Start of interception for already established IMS session
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Shall be provided.
lawful intercept identifier	M	Shall be provided.
correlation number	C	Provided if available. NOTE 1
correlation	C	Provided if available. NOTE 1
Sip message header offer	C	Provided if available
Sip message header answer	C	Provided if available
SDP offer	C	Provided if available
SDP answer	C	Provided if available
PANI header information	O	Provided if available and applicable.
VoIP Roaming Indication	C	Shall be provided when SIP messages are sent by the VPLMN.
Location information	C	In case of S8HR, when authorized, provides the UE location information that the LMISF receives from the MME through the S-GW/BBIFF.
Time of Location	C	Date/Time of Location. (if target location provided).

Table 7.6: XCAP REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target (if available). It may come from the X 3GPP Asserted Identity Header or the X-3GPP-Intended-Identity of the target described in TS 24.623 [77] and TS 24.109 [79] or from the XUI which is described in IETF RFC 4825 [80] (if available). It is part of the URI determined by the path selector results
observed Tel URI	C	Tel URI of the target (if available). It may come from the X 3GPP Asserted Identity Header or the X-3GPP-Intended-Identity of the target described in TS 24.623 [77] and TS 24.109 [79] or from the XUI which is described in IETF RFC 4825 [80] (if available). It is part of the URI determined by the path selector results
event type	M	Shall be provided. Provide XCAP event type (to be defined by further studies).
event date	M	Shall be provided. Provide the date the event is detected.
event time	M	Shall be provided. Provide the time the event is detected.
IMS event	M	Shall be provided. Provide the event information than an event related to XCAP transaction or server.
Network identifier	M	Shall be provided.
Lawful intercept identifier	M	Shall be provided.
X 3GPP asserted identity	C	Information to complement the observed SIP URI or Tel URI (if available) as slight formal differences do happen due to XCAP usage.
XUI	C	Information to complement the observed SIP URI or Tel URI (if available) as slight formal differences do happen due to XCAP usage.
Correlation	C	Provided if available. It correlates the XCAP request to the XCAP response.
XCAP message	M	Shall be provided with either the related XCAP request with the XCAP content, either XCAP response, with the XCAP content.

The following IRI records are applicable to HSS interception: Serving System, Subscriber Record Change, Registration Termination, Location Information Request.

Table 7.7: Serving System REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target; provided if available
observed Tel URI	C	Tel URI of the target; provided if available
observed MSISDN	C	MSISDN of the target; provided if available
observed IMSI	C	IMSI of the target; provided if available
observed IMEI	C	IMEI of the target; provided if available
observed IMPI	C	IMPI of the target; provided if available
observed IMPU(s)	C	Additional IMPU(s) of the target; provided if available
event type	M	Shall be provided. Provides Serving System
event date	M	Shall be provided. Provides the date the event is detected
event time	M	Shall be provided. Provides the time the event is detected
Network identifier	M	Shall be provided
Lawful intercept identifier	M	Shall be provided
Current Serving System Identifier	C	Provides information about the Visited PLMN Id in case of roaming.

Table 7.8: Subscriber Record Change REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target; provided if available
observed Tel URI	C	Tel URI of the target; provided if available
observed MSISDN	C	MSISDN of the target; provided if available
observed IMSI	C	IMSI of the target; provided if available
observed IMEI	C	IMEI of the target; provided if available
observed IMPI	C	IMPI of the target; provided if available
old observed SIP-URI	C	Previous SIP URI of the target; provided if available
old observed Tel URI	C	Previous Tel URI of the target; provided if available
old observed MSISDN	C	Previous MSISDN of the target; provided if available
old observed IMSI	C	IMSI of the target; provided if available
old observed IMEI	C	IMEI of the target; provided if available
old observed IMPI	C	IMPI of the target; provided if available
IMSI or MSISDN/TEL URI/SIP URI/IMPI or IMEI change type	M	Provides information about which identity was changed
event type	M	Shall be provided. Provides Subscriber Record Change.
event date	M	Shall be provided. Provide the date the event is detected.
event time	M	Shall be provided. Provide the time the event is detected.
Network identifier	M	Shall be provided.
Lawful intercept identifier	M	Shall be provided.
Other update	O	Provides carrier specific information

Table 7.9: Registration Termination REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target; provided if available
observed Tel URI	C	Tel URI of the target; provided if available
observed MSISDN	C	MSISDN of the target; provided if available
observed IMSI	C	IMSI of the target; provided if available
observed IMEI	C	IMEI of the target; provided if available
observed IMPI	C	IMPI of the target; provided if available
event type	M	Shall be provided. Provides Registration Termination
event date	M	Shall be provided. Provide the date the event is detected.
event time	M	Shall be provided. Provide the time the event is detected.
deregistration reason	C	Provided if available. Provides the reason for deregistration
Network identifier	M	Shall be provided.
Lawful intercept identifier	M	Shall be provided.
Previous serving system identifier	C	Provided if available. Provides the identity of the previous VPLMN.
Other User Identities	C	Provided if available. Includes other IMPUs or IMPIs that were allocated to the target and will be deregistered.

Table 7.10: Location Information Request REPORT Record

Parameter	MOC	Description/Conditions
observed SIP-URI	C	SIP URI of the target; provided if available
observed Tel URI	C	Tel URI of the target; provided if available
observed MSISDN	C	MSISDN of the target; provided if available
observed IMSI	C	IMSI of the target; provided if available
observed IMEI	C	IMEI of the target; provided if available
observed IMPI	C	IMPI of the target; provided if available
event type	M	Shall be provided. Provides Location Information Request
event date	M	Shall be provided. Provide the date the event is detected.
event time	M	Shall be provided. Provide the time the event is detected.
Lawful intercept identifier	M	Shall be provided.
Network identifier	M	Shall be provided.
Requesting network identifier	C	Provided if available. Provides the requesting network identifier PLMN id (Mobile Country Code and Mobile Network Code, defined in E212 [87]).
Requesting node identifier	M	Shall be provided. Provides the requesting node identifier.
Requesting node type	C	Provides the requesting node type (GMLC); provided if available.

7.6 Correlation indications of IMS IRI with GSN CC at the LEMF

See Annex F.

7.7 Void