5 Circuit-switch domain

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

5.0 General

For North America, the use of J‑STD‑025‑A [23] is recommended.

5.1 Specific identifiers for LI

5.1.0 Introduction

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 (HI1, HI2 and HI3). The identifiers, which apply to all communication technologies, are defined in the clauses below.

5.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). It is used within parameters of all HI interface ports.

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

The Lawful Interception IDentifier 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 (or digit string for sub-address option, see annex J). 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 enter for each target identity of the target a unique LIID.

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

5.1.2 Communication IDentifier (CID)

5.1.2.0 General

For each activity relating to a target identity, a CID is generated by the relevant network element. The CID consists of the following two identifiers:

– Network IDentifier (NID);

– Communication Identity Number (CIN) – optional.

NOTE 1: For all non CC related records like SMS, SCI etc. no correlation to a CC could be made.

The CID distinguishes between the different activities of the target identity. It is also used for correlation between IRI records and CC connections, as well as for correlation between LALS reports and IRI records of the triggering events. It is used at the interface ports HI2 and HI3.

The Communication IDentifier is specified in the subsequent subclauses of 5.1.2. For ASN.1 coding details, see annex B.

5.1.2.1 Network Identifier (NID)

The Network IDentifier is a mandatory parameter; it should be internationally unique. It consists of one or both of the following two identifiers.

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

– 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 E.164 international node number

– an X.25 address;

– an IP address.

National regulations may mandate the sending of the NEID.

5.1.2.2 Communication Identity Number (CIN) – optional

This parameter is mandatory for IRI in case of reporting events for connection-oriented types of communication (e.g. circuit switched calls).

The communication identity number is a temporary identifier of an intercepted communication, relating to a specific target identity.

The Communication Identity Number (CIN) identifies uniquely an intercepted communications session within the relevant network element. All the results of interception within a single communications session has to have the same CIN. If a single target has two or more communications sessions through the same operator, and through the same network element then the CIN for each session shall be different.

NOTE: If two or more target identities, related either to an unique target or to different targets, are involved in the same communication the same CIN value may be assigned by the relevant network element to the communication sessions of the different target identities.

5.1.3 CC link identifier (CCLID)

This identifier is only used at the interface ports HI2 and HI3 in case of the reuse of CC links (option B, see clause 5.4.4.2).

For each CC link, which is set up by the mediation function towards the LEMF, a CC link identifier (CCLID) is transmitted in the HI2 records and HI3 setup message in addition to CIN and NID. For the correct correlation of multiparty calls this identity number indicates in the IRI records of each multiparty call, which CC link is used for the transmission of the CC.

The CCLID may use the same format as the CIN; in this case, it need not be transmitted explicitly during set up of the CC links, as part of HI3. The CIN may also implicitly represent the CCLID.

5.1.4 Correlation of CC and IRI

To assure correlation between the independently transmitted Content of Communication (CC) and Intercept Related Information (IRI) of an intercepted call the following parameters are used:

– Lawful Interception IDentifier (LIID), see clause 5.1.1;

– Communication IDentifier (CID), see clause 5.1.2;

– CC Link IDentifier (CCLID), see clause 5.1.3.

These parameters are transferred from the MF to the LEMF in:

– HI2: see clause 5.2.2.1;

– HI3: see clause 5.3.2.

Correlation of the present document ID’s to TS 33.107 [19] ID’s.

The ID Lawful Interception Identifier (LIID) out of the present document is supported at the IIF with warrant reference number.

Parameters out of the present document, see clause 5.1.2:

Communication Identifier (CID)

For each call or other activity relating to a target identity a CID is generated by the relevant network element. The CID consists of the following two identifiers:

– Network IDentifier (NID);

– Communication Identity Number (CIN).

Intercepting Node ID is used for the NID in the UMTS system.

The correlation number is used for the CIN.

For the Communication IDentifier (CID) in the UMTS system we use the combination of Interception Node ID and the correlation number.

5.1.5 Usage of Identifiers

The identifiers are exchanged between the mediation function and the LEMF via the interfaces HI1, HI2 and HI3. There exist several interface options for the exchange of information. Tables 5.1 and 5.2 define the usage of numbers and identifiers depending on these options.

NOTE: X in tables 5.1 and 5.2: Identifier used within parameters of the interface.

Table 5.1: Usage of identifiers, IRI and CC transmitted; options A, B (see clause 5.4.4)

Identifier	IRI and CC transmitted (option A)			IRI and CC transmitted (option B)
	HI1	HI2	HI3	HI1	HI2	HI3
LIID	X	X	X	X	X	X
NID		X	X		X	X
CIN		X	X		X	X (see note 1)
CCLID					X	X (see note 2)
NOTE 1: The CIN of the 1st call for which this CC link has been set-up. NOTE 2: The CCLID may be omitted, see clause 5.1.3.

Table 5.2: Usage of identifiers, only IRI transmitted

Identifier	Only IRI transmitted
	HI1	HI2
LIID	X	X
NID		X
CIN		X
CCLID

5.2 HI2: interface port for IRI

5.2.1 Definition of Intercept Related Information

Intercept Related Information will in principle be available in the following phases of a call (successful or not):

1) At call initiation when the target identity becomes active, at which time call destination information may or may not be available (set up phase of a call, target may be the originating or terminating party, or be involved indirectly by a supplementary service).

2) At the end of a call, when the target identity becomes inactive (release phase of call).

3) At certain times between the above phases, when relevant information becomes available (active phase of call).

In addition, information on non-call related actions of a target constitutes IRI and is sent via HI2, e.g. information on subscriber controlled input.

The Intercept Related Information (IRI) may be subdivided into the following categories:

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

2) Basic call information, for standard calls between two parties.

3) Information related to supplementary services, which have been invoked during a call.

4) Information on non-call related target actions.

5.2.2 Structure of IRI records

5.2.2.0 General

Each IRI-record contains several parameters. In the subsequent subclauses of 5.2.2, the usage of these parameters is explained in more detail.

Mandatory parameters are indicated as HI2 control information. Optional parameters are provided depending on the availability at the MF. For the internal structure of the IRI records, the ASN.1 description, with the application of the basic encoding rules (BER) is used. This ASN.1 specification is enclosed in annex B.

5.2.2.1 Control Information for HI2

The main purpose of this information is the unique identification of records related to a target identity, including their unique mapping to the links carrying the Content of Communication. In general, parameters of this category are mandatory, i.e. they have to be provided in any record.

The following items are identified (in brackets: ASN.1 name and reference to the ASN.1 definition or clause B.3a):

1) Record type (IRIContent, see clause B.3a)
IRI-BEGIN, IRI-CONTINUE, IRI-END, IRI-REPORT-record types.

2) Version indication (iRIversion, see clause B.3a)
Identification of the particular version of the HI2 interface specification.

3) Communication Identifier (CommunicationIdentifier, see clauses 5.1.2 and B.3a).

4) Lawful Interception Identifier (LawfulInterceptionIdentifier, see clauses 5.1.1 and B.3a).

5) Date & time (TimeStamp, see clause B.3a)
Date & time of record trigger condition.
The parameter shall have the capability to indicate whether the time information is given as Local time without time zone, or as UTC. Normally, the operator (NO/AN/SP) shall define these options.

6) CC Link Identifier (CC-Link-Identifier, see clause 5.1.3 for definition and clause B.3a for ASN.1 definition).

Table 5.3 summarizes the items of HI2 control information. It is mandatory information, except the CID – it may be omitted for non-call related IRI records – and the CCLID. Their format and coding definition is LI specific, i.e. not based on other signalling standards.

Table 5.3: Parameters for LI control information in IRI records (HI2 interface port)

IRI parameters: LI control information
IRI parameter name	ASN.1 name (used in annex B)
Type of record	IRIContent
Version indication	iRIversion
Lawful Interception IDentifier (LIID)	LawfulInterceptionIdentifier
Communication IDentifier (CID) – Communication Identity Number (CIN) – Network IDentifier (NID)	CommunicationIdentifier
Date & time	TimeStamp
CC Link IDentifier (CCLID) (only used in case of option B)	CC-Link-Identifier

5.2.2.2 Basic call information

This clause defines parameters within IRI records for basic calls, i.e. calls, for which during their progress no supplementary services have been invoked. In general, the parameters are related to either the originating or terminating party of a call; consequently, ASN.1 containers are defined for the originating/terminating types of parties, which allow to include the relevant, party-related information. The structure of these containers and the representation of individual items are defined in clause B.3a.

NOTE: A third type of party information is defined for the forwarded-to-party (see clause 5.2.2.3 on calls with supplementary services being invoked).

The items below are to be included, when they become available for the first time during a call in progress. If the same item appears identically several times during a call, it needs only to be transmitted once, e.g. in an IRI-BEGIN record. The ASN.1 name of the respective parameters, as defined in clause B.3a, is indicated in brackets.

1) Direction of call (intercepted-Call-Direct)
Indication, whether the target identity is originating or terminating Party.

2) Address of originating and terminating parties (CallingPartyNumber or CalledPartyNumber)
If e.g. in case of call originated by the target at transmission of the IRI-BEGIN record only a partial terminating address is available, it shall be transmitted, the complete address shall follow, when available.

3) Basic Service, LLC (Services-Information)
Parameters as received from signalling protocol (e.g. BC, HLC, TMR, LLC).

4) Cause (ISUP-parameters or DSS1-parameters-codeset-0)
Reason for release of intercepted call. Cause value as received from signalling protocol. It is transmitted with the ASN.1 container of the party, which initiated the release; in case of a network-initiated release, it may be either one.

5) Additional network parameters
e.g. location information (Location).

Parameters defined within table 5.5 shall be used for existing services, in the given 3GPP format. National extensions may be possible using the ASN.1 parameter National-Parameters.

5.2.2.3 Information on supplementary services, related to a call in progress

The general principle is to transmit service related information within IRI records, when the corresponding event/information, which needs to be conveyed to the LEMF, is received from the signalling protocol. Where possible, the coding of the related information shall use the same formats as defined by standard signalling protocols.

The selection, which types of events or information elements are relevant for transmission to the LEAs is conforming to the requirements defined in ETSI TS 101 331 [1] and ETSI ES 201 158 [2].

A dedicated ASN.1 parameter is defined for supplementary services related to forwarding or re-routing calls (forwarded-to-Party information), due to the major relevance of these kinds of services with respect to LI. For the various cases of forwarded calls, the information related to forwarding is included in the originatingParty/terminatingParty/forwarded-to-Party information:

1) If a call to the target has been previously forwarded, available parameters relating to the redirecting party(ies) are encapsulated within the originatingPartyInformation parameter.

2) If the call is forwarded at the target’s access (conditional or unconditional forwarding towards the
forwarded-to-party), the parameters which are related to the redirecting party (target) are encapsulated within the terminatingPartyInformation parameter.

3) All parameters related to the forwarded-to-party or beyond the forwarded-to-party are encapsulated within the forwarded-to-Party ASN1 coded parameter. In addition, this parameter includes the
supplementary-Services-Information, containing the forwarded-to address, and the redirection information parameter, with the reason of the call forwarding, the number of redirection, etc.).

For the detailed specification of supplementary services related procedures see clause 5.4.

Parameters defined within table 5.4 shall be used for existing services, in the given format. National extensions may be possible using the ASN.1 parameter National-Parameters.

5.2.2.4 Information on non-call related supplementary services

The general principle is to transmit non-call related service information as received from the signalling protocol.

A typical user action to be reported is Subscriber Controlled Input (SCI).

For the detailed specification of the related procedures see clause 5.4.

5.2.3 Delivery of IRI

The events defined in TS 33.107 [19] are used to generate Records for the delivery via HI2. The LALS reports defined in TS 33.107 [19] are delivered via HI2, as well.

There are thirteen different events type received at DF2 level. According to each event, a Record is sent to the LEMF if this is required. In the case of LALS reports, which are not associated with an event, a Record is sent to the LEMF without the event parameter.

The following table gives the mapping between event type received at DF2 level and record type sent to the LEMF.

It is an implementation option if the redundant information will be sent for each further event.

Table 5.4: Structure of the records for UMTS (CS)

Event	IRI Record Type
Call establishment	BEGIN
Answer	CONTINUE
Supplementary service	CONTINUE
Handover	CONTINUE
Release	END
Location update	REPORT
Subscriber controlled input	REPORT
SMS	REPORT
Serving system	REPORT
HLR subscriber record change	REPORT
Cancel location	REPORT
Register location	REPORT
Location information request	REPORT

The LALS report records are sent to the LEMF with the REPORT IRI Record Type.

NOTE 1: Void.

A set of information is used to generate the records. The records used transmit the information from mediation function to LEMF. This set of information can be extended in 3G MSC server or 3G GMSC server or DF2/MF, if this is necessary in a specific country. The following table gives the mapping between information received per event or report and information sent in records.

Table 5.5: Description of parameters

Parameter	Definition	ASN.1 parameter
Observed MSISDN	Target Identifier with the MSISDN of the target	PartyInformation/msISDN
Observed IMSI	Target Identifier with the IMSI of the target	PartyInformation/imsi
Observed IMEI	Target Identifier with the IMEI of the target, it has to be checked for each call over the radio interface	PartyInformation/imei
Observed Non-Local ID	Target Identifier with the E.164 number of Non-Local ID target	Partyinformation/e164-Format
New observed MSISDN	New target identifier with MSISDN of the target, when available	PartyInformation/msISDN
New observed IMSI	New target identifier with IMSI of the target, when available	PartyInformation/imsi
New observed IMEI	New target identifier with IMEI of the target, when available	PartyInformation/imei
Event type	Description of which type of event is delivered: Establishment, Answer, Supplementary service, Handover, Release, SMS, Location update, Subscriber controlled input, HLR subscriber record change, Serving system, Cancel location, Register location, Location information request	umts-CS-Event. In case this parameter is not sent over the HI2 interface, the presence of other parameters on HI2 indicates the event type (e.g. sMS or sciData parameter presence)
Event date	Date of the event generation in the 3G MSC server or 3G GMSC server or in the HLR	timeStamp
Event time	Time of the event generation in the 3G MSC server or 3G GMSC server or in the HLR
Dialled number	Dialled number before digit modification, IN‑modification, etc.	PartyInformation (= originating)/DSS1-parameters/calledpartynumber
Connected number	Number of the answering party	PartyInformation/supplementary-Services-Info
Other party address	Directory number of the other party for originating calls Calling party for terminating calls	PartyInformation (= terminating)/calledpartynumber PartyInformation/callingpartynumber
Call direction	Information if the target is calling or called e.g. MOC/MTC or originating/terminating in or/out	intercepted-Call-Direct
CID	Unique number for each call sent to the DF, to help the LEA, to have a correlation between each call and the IRI (combination of Interception Node ID and the correlation number)	communicationIdentifier
Lawful interception identifier	Unique number for each surveillance lawful authorization	lawfulInterceptionIdentifier
CGI/SAI	CGI or SAI of the target; for the location information	locationOfTheTarget
Location area code	Location-area-code of the target defines the Location Area in a PLMN
Location Information	LALS location information
Time of Location	Date/Time of location. The time when location was obtained by the location source node.
Serving system identifier	VPLMN ID of the serving system or of the third party network interworking with the HLR	serving-System-Identifier
Basic service	Information about Tele service or bearer service	PartyInformation/DSS1-parameters-codeset-0
Supplementary service	Supplementary services used by the target e.g. Call forwarding, CW, ECT	PartyInformation/Supplementary-Services
Forwarded to number	Forwarded to number at call forwarding	PartyInformation/calledPartyNumber (party-Qualifier indicating forwarded-to-party)
Call release reason	Call release reason of the target call	release-Reason-Of-intercepted-Call
SMS	The SMS content with header which is sent with the SMS-service	sMS
SCI	Non-call related Subscriber Controlled Input (SCI) which the 3G MSC server receives from the ME	PartyInformation/sciData
Other update	Carrier specific information related to its implementation or subscription process on its HLR	carrierSpecificData
Changed (old/new) IMSI or MSISDN or IMEI	Provides the identity changes in Subscriber Record Change Event.	change-Of-Target-Identity
Previous serving system identifier	Previous VPLMN Id of the target	current-Previous-Systems/previous-Serving-System-Identifier
Previous serving MSC-number	An E.164 number of the previous serving MSC included in the intercepted MAP message	current-Previous-Systems/previous-Serving-MSC-Number
Previous serving MSC-address	An IP address of the previous serving MSC, included in the intercepted MAP message	current-Previous-Systems/previous-Serving-MSC- Address
NOTE: LIID parameter has to be present in each record sent to the LEMF.

Table 5.5A: Serving System REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN
observed IMSI	C	Provide at least one and others when available.
observed IMEI
event type	C	Provide Serving System event type.
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Network identifier of the HLR reporting the event (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
serving system identifier	C	Provide the VPLMN id (Mobile Country Code and Mobile Network Country, E. 212 number [87]).

Table 5.5B: HLR subscriber record change REPORT Record

Parameter	MOC	Description/Conditions
new observed MSISDN	C	Provide at least one and others when available.
new observed IMSI
New observed IMEI
observed MSISDN	C	Provide at least one and others when available.
observed IMSI
observed IMEI
event type	C	Provide HLR subscriber record change event type.
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Network identifier of the HLR reporting the event (Network element identifier included).
changed (old/new) IMSI or MSISDN or IMEI	M	Shall provide what was changed (old/new MSISDN, old/new IMSI or old/new IMEI)
lawful intercept identifier	M	Shall be provided.
carrier specific data	C	Provide to raw data of this specific update related to HLR.

Table 5.5C: Cancel location REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN	C	Provide at least one and others when available.
observed IMSI
event type	C	Provide cancel Location change event type. (purge from HLR sent to SGSN included).
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Network identifier of the HLR reporting the event (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
previous serving system identifier	C	Provide the previous VPLMN id (Mobile Country Code and Mobile Network Country, defined in E212 [87])).
previous serving MSC-number	C	Provide to identify the E.164 number of the previous serving MSC.
previous serving MSC-address	C	Provide to identify the IP address of the previous serving MSC.

Table 5.5D: Register location REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN	C	Provide at least one and others when available.
observed IMSI
event type	C	Provide register location event type.
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Network identifier of the HLR reporting the event (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
previous serving system identifier	C	Provide the previous VPLMN id (Mobile Country Code and Mobile Network Country; defined in E212 [87]) ).
previous serving MSC number	C	Provide to identify the E.164 number of the previous serving MSC.
previous serving MSC address	C	Provide to identify the IP address of the previous serving MSC.
current serving system identifier	C	Provide the previous VPLMN id (Mobile Country Code and Mobile Network Country, defined in E212 [87])).
current serving MSC number	C	Provide to identify the E.164 number of the current serving MSC.
current serving MSC address	C	Provide to identify the IP address of the current serving MSC.

Table 5.5E: Location information request REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN	C	Provide at least one and others when available.
observed IMSI
event type	C	Provide location information request event type.
event date	M	Provide the date and time the event is detected.
event time
network identifier	M	Network identifier of the HLR reporting the event (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
requesting network identifier	C	Provide the requesting network identifier PLMN id (Mobile Country Code and Mobile Network Country, defined in E212 [87]).
requesting node type	C	Provide the requesting node type (GMSC; SMS Centre; GMLC, MME, SGSN).

Table 5.5F: LALS Target Positioning REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN
observed IMSI	C	Provide at least one and others when available.
observed IMEI
event date	M	Provide the date and time the LCS Report is available at LI LCS Client.
event time
network identifier	M	Network identifier of the LI LCS Client (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
location information	C	Provide the LALS location information, if the positioning is successful
extended location parameters	O	If available, additional location information and associated QoS information.
Time of Location	C	Date/Time of Location. (if target location provided).
LALS error code	C	Provide the error identification code if the positioning is not successful.

Table 5.5G: LALS Enhanced Location for IRI REPORT Record

Parameter	MOC	Description/Conditions
observed MSISDN
observed IMSI	C	Provide at least one and others when available.
observed IMEI
event date	M	Provide the date and time the LCS Report is available at LI LCS Client.
event time
network identifier	M	Network identifier of the LI LCS Client (Network element identifier included).
lawful intercept identifier	M	Shall be provided.
communication identity number	C	Provided for correlation with the IRI records of the call, if available in the corresponding LALS triggering event.
location information	C	Provide the LALS location information, if the positioning is successful.
extended location parameters	O	If available, additional location information and associated QoS information.
Time of Location	C	Date/Time of Location. (if target location provided).
LALS error code	C	Provide the error identification code if the positioning is not successful.

NOTE 2: See the TS 33.107 [19] for a detailed description of LALS. See Annex O for information on using of the CS ASN.1 information object for the LALS reporting.

NOTE 3: In some specific scenarios the amount of Enhanced Location for IRI reports data may overload the X2 and/or HI2 interfaces. To prevent the overload, a flow control for Enhanced Location for IRI Reports may be implemented, e.g. by limiting the frequency of the reports for individual target.

5.3 HI3: interface port for Content of Communication

5.3.0 General

The port HI3 shall transport the Content of the Communication (CC) of the intercepted telecommunication service to the LEMF. The Content of Communication shall be presented as a transparent en-clair copy of the information flow during an established, frequently bi-directional, communication of the target. It may contain voice or data.

A target call has two directions of transmission associated with it, to the target, and from the target. Two communication channels to the LEMF are needed for transmission of the Content of Communication (stereo transmission).

The network does not record or store the Content of Communication.

5.3.1 CS-based Delivery of Content of Communication

CC will be delivered as described in annex J.

Exceptionally, SMS will be delivered via HI2.

The transmission media used to support the HI3 port shall be standard ISDN calls, based on 64 kbit/s circuit switched bearer connections. The CC links are set up on demand to the LEMF. The LEMF constitutes an ISDN DSS1 user function, with an ISDN DSS1 basic or primary rate access. It may be locally connected to the target switching node, or it may be located somewhere in the target network or in another network, with or without a transit network in between.

For network signalling, the standard ISDN user part shall be used. No modifications of the existing ISDN protocols shall be required. Any information needed for LI, like to enable correlation with the IRI records of a call, can be inserted in the existing messages and parameters, without the need to extend the ETSI standard protocols for the LI application.

For each LI activation, a fixed LEMF address is assigned; this address is, within the present document, not used for any identification purposes; identification and correlation of the CC links is performed by separate, LI specific information, see clause 5.1.

The functions defined in the ISDN user part standard, Version 1 (ETSI ISUP V1) are required as a minimum within the target network and, if applicable, the destination and transit networks, especially for the support of:

– Correlation of HI3 information to the other HI port’s information, using the supplementary service user-to-user signalling 1 implicit (UUS1).

– Access verification of the delivery call (see clause 5.3.3).

The bearer capability used for the CC links is 64 kbit/s unrestricted digital information; this type guarantees that the information is passed transparently to the LEMF. No specific HLC parameter value is required.

The CC communication channel is a one-way connection, from the operator’s (NO/AN/SP) IIF to the LEMF, the opposite direction is not switched through in the switching node of the target.

The scenario for delivery of the Content of Communication is as follows:

1) At call attempt initiation, for one 64 kbit/s bi-directional target call, two ISDN delivery calls are established from the MF to the LEMF. One call offers the Content of Communication towards the target identity (CC Rx call/channel), the other call offers the Content of Communication from the target identity (CC Tx call/channel). See figure 5.1.

2) During the establishment of each of these calls, appropriate checks are made (see clause 5.3.3).

3) The MF passes during call set up, within the signalling protocol elements of the CC link the LIID and the CID to the LEMF. The LEMF uses this information to identify the target identity and to correlate between the IRI and CC.

4) At the end of a call attempt, each delivery call associated with that call attempt shall be released by the MF.

Figure 5.1: Content of Communication transmission from MF to LEMF

5.3.2 Control information for Content of Communication

The delivery calls shall use unmodified standard ISDN protocols (DSS1, ISDN user part). Table 5.6 summarizes specific settings of parameters for the CC links. The User-to-User service 1 parameter is used during call set up (within the ISUP Initial Address Message [29] or DSS1 Set Up Message [30], respectively) to transmit LI-specific control information. This information is carried transparently and delivered to the specific LEMF remote user.

To identify the delivered information, including correlating the delivery calls with the IRI records, parameters 1 to 3 and 5 shall be included in the call set up. Parameters 6 to 9 specify settings of further relevant information. Other parameters of the ISDN protocols shall correspond to normal basic calls.

Table 5.6: Definition of HI3 specific signalling information; UUS1 coding details (see clause J.1)

No.	Used information element of CC link signalling protocol	Information	Purpose
1	CLI-Parameter with attribute "network provided"	See clause 5.3.3	LEMF can check identity of origin of call.
2	UUS1-parameter	Lawful Interception IDentifier (LIID); see clause 5.1	Identifier, identifying target identity
3	UUS1-parameter	Communication IDentifier (CID), see clause 5.1	Identifier, identifying specific call of target identity
4	UUS1-parameter	CC Link IDentifier (CCLID), if required; see clause 5.1	Identifier, used for correlation CC link-IRI records
5	UUS1-parameter	Direction indication (communication from/towards target/combined (mono))	Signal from (Tx)/towards (Rx) target identity or combined
6	UUS1-parameter	Bearer capability of target call	Indication to the LEMF of the basic service in use by the target
7	Closed user group interlock code	Closed user group interlock code	Supplementary Service CUG Security measure at set up of the CC link
8	Basic Service (BS)	Basic Service (BS) of CC link: 64 kbit/s unrestricted	Guarantee transparent transmission of CC copy from MF to LEMF
9	ISDN user part forward call indicators parameter	ISDN user part preference indicator: "ISDN user part required all the way"	Guarantee transparent transmission of UUS1 and other supplementary services information
10	ISDN user part optional forward call indicators parameter	Connected line identity request parameter: requested	Sending of the connected number by the destination network

Parameters 2, 3 and 4 are also present in the IRI records, for correlation with the CC links. Parameter 5 indicates in case of separate transmission of each communication direction, which part is carried by a CC link. Parameter 6, the basic service of the target call, can be used by the LEMF for processing of the CC signal, e.g. to apply compression methods for speech signals, in order to save storage space. Parameter 7 contains the CUG of the LEA. It is optionally used at set up the CC link to the LEA. Parameter 8, the basic service of the CC link, is set to "64 kbit/s unrestricted": All information of the Rx, Tx channels can be transmitted fully transparently to the LEA. The setting of the ISDN user part indicator guarantees, that the services supporting the LI CC link delivery are available for the complete CC link connection.

The MF uses en-bloc dialling, i.e. there exists only one message in forward direction to the LEA.

NOTE: The LEMF should at reception of the set up message not use the alerting state, it should connect immediately, to minimize time delay until switching through the CC links. Not all networks will support such a transition. Exceptionally, it may be necessary to send an alerting message before the connected message.

The maximum length of the user information parameter can be more than the minimum length of 35 octets (national option, see ITU-T Recommendation Q.763 [29]), i.e. the network transmitting the CC links shall support the standard maximum size of 131 octets for the UUS1 parameter.

The User-to-User service 1 parameter cannot be discarded by the ETSI ISUP procedures: the only reason, which would allow the ISUP procedures to discard it would be, if the maximum length of the message carrying UUS1 would be exceeded. With the specified amount of services used for the CC links, this cannot happen.

The signalling messages of the two CC channels (stereo mode) carry the same parameter values, except for the direction indication.

See clause J.1 for the ASN.1 definition of the UUS1 LI specific content of the UUS1 parameter.

5.3.3 Security requirements at the interface port of HI3

5.3.3.0 General

The process of access verification and additional (optional) authentication between the MF and the LEMF shall not delay the set up of the CC.

For the protection and access verification of the Content of Communication delivery call the ISDN supplementary services CLIP, COLP and CUG shall be used when available in the network involved.

Generally any authentication shall be processed before the set-up of the CC links between the MF and the LEMF is completed. If this is technically not feasible the authentication may be processed after completion of the CC connection in parallel to the existing connection.

5.3.3.1 LI access verification

The supplementary service CLIP shall be used to check for the correct origin of the delivery call.

NOTE: When using CLIP, the supplementary service CLIR has to not be used.

The supplementary service COLP shall be used to ensure that only the intended terminal on the LEA’s side accepts incoming calls from the Handover Interface (HI).

To ensure access verification the following two checks shall be performed:

– check of Calling-Line Identification Presentation (CLIP) at the LEMF; and

– check of COnnected-Line identification Presentation (COLP) at the Handover Interface (HI) (due to the fact that the connected number will not always be transported by the networks involved, there shall be the possibility for deactivating the COLP check for a given interception measure. In addition, the COLP check shall accept two different numbers as correct numbers, i.e. the user provided number and the network provided number. Usually, the user provided number contains a DDI extension).

5.3.3.2 Access protection

In order to prevent faulty connections to the LEA, the CC links may be set up as CUG calls.

In this case, the following settings of the CUG parameters should be used:

– Incoming Access: not allowed;

– Outgoing Access: not allowed;

– Incoming calls barred within a CUG: no;

– Outgoing calls barred within a CUG: yes.

5.3.3.3 Authentication

In addition to the minimum access verification mechanisms described above, optional authentication mechanisms according to the standard series ISO 9798 "Information technology – Entity authentication – parts 1 to 5" may be used.

These mechanisms shall only be used in addition to the access verification and protection mechanisms.

5.4 LI procedures for supplementary services

5.4.1 General

In general, LI shall be possible for all connections and activities in which the target is involved. The target shall not be able to distinguish alterations in the offered service. It shall also not be possible to prevent interception by invoking supplementary services. Consequently, from a supplementary services viewpoint, the status of interactions with LI is "no impact", i.e. the behaviour of supplementary services shall not be influenced by interception.

Depending on the type of supplementary service, additional CC links to the LEA may be required, in addition to already existing CC links.

Within the IRI records, the transmission of additional, supplementary service specific data may be required.

Supplementary services, which have an impact on LI, with respect to CC links or IRI record content, are shown in table 5.7. The table is based on UMTS services, it considers the services which have been standardized at the time of finalizing the present document. Future services should be treated following the same principles.

NOTE 1: Co-ordination of handling of new services should be performed via 3GPP SA WG3-LI. If required, additions will be included in a subsequent version of the present document.

The question of Lawful Interception with Intelligent Networks is not covered in this version (see note 2).

NOTE 2: The general principle is, that LI takes place on the basis of a technical identity, i.e. a directory number. Only numbers which are known to the operators (NO/AN/SP), and for which LI has been activated in the standard way, can be intercepted. No standardized functions are available yet which would enable an SCF to request from the SSF the invocation of LI for a call.

Additional CC links are only required, if the target is the served user. IRI Records may also carry data from other parties being served users.

Clause 5.5 specifies details for relevant services:

– The procedures for CC links, depending on the call scenario of the target.

– Related to the IRI records, the point in time of sending and supplementary service specific information.

– Additional remarks for services with "no impact" on LI.

The specifications for supplementary services interactions are kept as far as possible independent of the details of the used signalling protocols; service related events are therefore described in more general terms, rather than using protocol dependent messages or parameters.

Interactions with services of the same family, like call diversion services, are commonly specified, if the individual services behaviour is identical, with respect to LI.

With respect to the IRI records, clause 5.5 specifies typical cases; the general rules for data which shall be included in IRI records are defined in clause 5.2, specifically in clause 5.4.3.

Services, which are not part of table 5.7, do not require the generation of LI information: No CC links are generated or modified, and no specific information on the service is present in the IRI records. That is, these services have "no impact" on LI, no special functions for LI are required. However, within the IIF, functions may be required to realize the principle, that the service behaviour shall not be influenced by LI.

"No impact" is not automatically applicable for new services. Each new service has to be checked for its impact on LI.

The present document does not intend to give a complete description of all possible cases and access types of interactions with supplementary services.

Table 5.7: Supplementary Services with impact on LI CC links or IRI records content;
see also clause 5.5

Suppl. Service	Abbr.	CC links: additional calls, impact	IRI items related to service
Call Waiting	CW	CC links for active or all calls (option A/B)	Target: call waiting indication, calling party address other party: generic notification indicator
Call Hold	HOLD	CC links for active or all calls (option A/B)	Target: call hold indication other party: generic notification indicator
Call Retrieve	RETRIEVE	CC links for active or all calls (option A/B)	Target: call retrieve indication other party: generic notification indicator
Explicit Call Transfer	ECT	Before transfer: see HOLD After transfer: LI may or may not be stopped	Target: components of Facility IE other party: generic notification indicator
Subaddressing	SUB	No impact on CC links	Subaddress IE, as available (calling, called, …)
Calling Line Identification Presentation	CLIP	No impact on CC links	CLI parameter: part of originating-Party information
Calling Line Identification Restriction	CLIR	No impact on CC links	Restriction indicator is part of CLI parameter
Connected Line Identification Presentation	COLP	No impact on CC links	COL parameter: part of terminating-Party information
Connected Line Identification Restriction	COLR	No impact on CC links	Restriction indicator is part of COL parameter
Closed User Group	CUG	No impact on CC links	CUG interlock code
Multi Party Conference	MPTY	Initially: held and active calls see HOLD Conf.: TX: signal from target; Rx call sum signal CC links depending on option A/B	Target: components of Facility IE other party: generic notification indicator
Call Forwarding Unconditional; see note	CFU	One CC link for each call, which is forwarded by the target Forwarding by other parties: no impact	Target: see clause 5.2.2.3, point 2, 3.; if redirecting no. = target DN: not included Other party (call to target is a forwarded call): See clause 5.2.2.3, point 1 Other party (call from target gets forwarded): See clause 5.2.2.3, point 3
Call Forwarding No Reply; see note	CFNRy	1) basic call with standards CC links, released after time-out (incl. CC links) 2) forwarding: same as CFU	1) basic call, released after time-out, standard IRI 2) forwarding: same parameters as for CFU
Call Forwarding Not Reachable; see note	CFNRc	See CFU	See CFU
Call Forwarding Busy; see note	CFB	Network determined user busy: see CFU User determined user busy: see CFNR	Network determined user busy: see CFU user determined user busy: see CFNR
Call Deflection	CD	See CFNR	See CFNR
User-to-User Signalling 1, 2, 3	UUS	No impact on CC links	User-to-user information, more data IE (part of HI2 information, see clause B.3a). In ETSI HI3 was used. Optionally, ETSI’s HI3 interface for UUS may be maintained for backwards compatibility reasons.
Fallback procedure (not a supplemen-tary service)	FB	No impact on CC links	Target or other party: new basic service IE
NOTE: Other variants of Call Forwarding, like Forwarding to fixed numbers, to information services, etc. are assumed to be covered by the listed services.

5.4.2 CC link Impact

The column "CC links: additional calls, impact" (see table 5.7) defines, whether:

– for the related service CC links shall be set up, in addition to the CC links for a basic call;

– already existing calls are impacted, for example by disconnecting their information flow.

The CC link impact relates always to actions of a target being the served user. Services invoked by other parties have no CC link impact.

5.4.3 IRI Impact, General Principle for Sending IRI records

The column "IRI items related to service" (see table 5.7) specifies, which parameters may be transmitted to the LEA within the IRI records. For several services, it is differentiated, whether the target or the other party is the served user.

The table specifies, which parameters are applicable in principle. That is, these parameters are normally sent to the LEA, immediately when they are available from the protocol procedures of the service. In many cases, additional IRI-CONTINUE records, compared to a basic call, will be generated. However, not each service related signalling event needs to be sent immediately within an individual record. Exceptions may exist, where several events are included in one record, even if this would result in some delay of reporting an event (this may be implementation dependent). Each record shall contain all information, which is required by the LEA to enable the interpretation of an action; example: the indication of call forwarding by the target shall include the forwarded-to number and the indication of the type of forwarding within the same record.

The complete set of parameters, which are applicable for IRI, is specified in clause 5.2.3 (see table 5.5).

If during procedures involving supplementary services protocol parameters, which are listed in table 5.5 become available, they shall be included in IRI Records.

IRI data are not stored by the IIF or MF for the purpose of keeping information on call context or call configuration, including complex multiparty calls. The LEMF (electronically) or the LEA’s agent (manually) shall always be able, to find out the relevant history on the call configuration, to the extent, which is given by the available signalling protocol based information, within the telecommunication network.

Service invocations, which result in invoke and return result components (as defined in table 5.5) need only be reported in case of successful invocations. One IRI record, containing the invoke component, possibly including additional parameters from the return result component, is sufficient.

With respect to the inclusion of LI specific parameters, see also the parameter specifications and example scenarios in clause J.2.3 for more details.

Details of e.g. the definition of the used record type, their content, the exact points in time of sending etc. follow from the according service specifications; in some cases, they are specified explicitly in clauses 5.5 and J.2.3.

5.4.4 Multi party calls – general principles, options A, B

5.4.4.0 General

Each network has to adopt option A or B according to local circumstances.

With respect to IRI, each call or call leg owns a separate IRI transaction sequence, independent of whether it is actually active or not.

With respect to the CC links, two options (A, B) exist, which depend on laws and regulations, see below. Active call or call leg means in this context, that the target is actually in communication with the other party of that call or call leg; this definition differs from the definition in ETSI EN 300 356 [30].

5.4.4.1 CC links for active and non-active calls (option A)

For each call, active or not, separate CC links shall be provided. This guarantees that:

– changes in the call configuration of the target are reflected immediately, with no delay, at the LEMF;

– the signal from held parties can still be intercepted.

It is a network option, whether the communication direction of a non-active call, which still carries a signal from the other party, is switched through to the LEMF, or switched off.

Figure 5.2: CC link option A (example for call hold supplementary service)

5.4.4.2 Reuse of CC links for active calls (option B)

CC links are only used for calls active in their communication phase. Changes in the call configuration may not be reflected at the LEMF immediately, because switching in the IIF/MF is required, and the signal from the held party is not available.

Each time, another target call leg uses an existing CC link, an IRI-CONTINUE record with the correct CID and CCLID shall be sent.

NOTE: Even when option B is used, more than one CC link may be required simultaneously.

Figure 5.3: CC link option B (example for call hold supplementary service)

5.4.5 Subscriber Controlled Input (SCI): Activation / Deactivation / Interrogation of Services

For user procedures for control of Supplementary Services (Activation/Deactivation/Interrogation), a special IRI record type (IRI-REPORT record) is defined to transmit the required information.

The IRI-REPORT record shall contain an indicator, whether the request of the target has been processed successfully or not.

5.5 Detailed procedures for supplementary services

5.5.1 Advice of Charge services (AOC)

No impact.

Advice of Charge information is not included in IRI records.

5.5.2 Call Waiting (CW)

5.5.2.1 Call Waiting at target: CC links

In case of option A "CC links for all calls", a CC link is set up for the waiting call, using the standard procedures for terminating calls. In case of option B "CC links for active calls", no CC link is set up for the waiting call, it is treated like a held call.

With respect to CC links, the same configurations as for Call Hold apply.

Procedure, when the target accepts the waiting call: see retrieve of a held call (see clause 5.5.3).

5.5.2.2 Call Waiting: IRI records

5.5.2.2.1 Target is served user

If Call Waiting is invoked at the target access by another (calling) party: the IRI-BEGIN record or a following IRI‑CONTINUE record for the waiting call shall contain the LI specific parameter call waiting indication.

5.5.2.2.2 Other party is served user

If Call Waiting is invoked at the other (called) party’s access: if a CW notification is received by the target’s switching node, it shall be included in an IRI-CONTINUE record; it may be a separate record, or the next record of the basic call sequence.

5.5.3 Call Hold/Retrieve

5.5.3.1 CC links for active and non-active calls (option A)

If an active call is put on hold, its CC links shall stay intact; as an option, the signal from the held party is not switched through to the LEMF.

If the target sets up a new call, while one call is on hold, this call is treated like a normal originating call, i.e. a new LI configuration (CC links, IRI records) is established.

5.5.3.2 Reuse of CC links for active calls (option B)

If an active call is put on hold, its CC links shall not immediately be disconnected; as an option, the signal from the held party is not switched through to the LEMF.

If the target sets up a new call, or retrieves a previously held call, while one target call, which still owns CC links, is on hold, these CC links shall be used for the signals of the new active call.

5.5.3.3 IRI records

5.5.3.3.1 Invocation of Call Hold or Retrieve by target

An IRI-CONTINUE record with the LI specific parameter hold indication or retrieve indication, respectively, shall be sent.

5.5.3.3.2 Invocation of Call Hold or Retrieve by other parties

An IRI-CONTINUE record with a call hold or retrieve notification shall be sent if it has been received by the signalling protocol entity of the target call.

5.5.4 Explicit Call Transfer (ECT)

5.5.4.1 Explicit Call Transfer, CC link

During the preparation phase of a transfer, the procedures for Call Hold/Retrieve are applicable.

If the served (transferring) user is the target, its original call is released. This terminates also the CC link, and causes an IRI-END record to be sent.

After transfer, two options exist:

1) For the transferred call, CC links (and IRI records) shall be generated, in principle like for a forwarded call (similar to procedures in clause 5.5.12.1.1, case b));

2) The transferred call shall not be intercepted.

5.5.4.2 Explicit Call Transfer, IRI records

In addition to the basic or hold/retrieve/waiting call related records and parameters, during the reconfiguration of the call, ECT-specific information at the target’s access is sent to the LEMF within IRI-CONTINUE records.

When the target leaves the call after transfer, an IRI-END record is sent, and the LI transaction is terminated. Options for the new call, after transfer: see clause 5.5.4.1.

5.5.5 Calling Line Identification Presentation (CLIP) (IRI Records)

5.5.5.1 Call originated by target (target is served user)

The standard CLI parameter of an originating target is included as a supplementary service parameter in the IRI records.

5.5.5.2 Call terminated at target (other party is served user)

The CLI sent from the other party is included in the IRI-BEGIN record (originating-Party information), irrespective of a restriction indication. An eventually received second number (case two number delivery option) is included in the IRI record as supplementary services information (Generic Number parameter).

5.5.6 Calling Line Identification Restriction (CLIR)

For use by LI, the restriction is ignored, but copied within the CLI parameter to the IRI record.

5.5.7 COnnected Line identification Presentation (COLP)

5.5.7.1 Call terminated at target (target is served user)

A connected number parameter received from the target shall be included in an IRI record (terminating-Party information).

5.5.7.2 Call originated by target (other party is served user)

If available, a connected number parameter as received from the other (terminating) party shall be included in an IRI record (terminating-Party information). Any additional number, e.g. a Generic Number, shall also be included in the IRI record.

5.5.8 COnnected Line identification Restriction (COLR)

For use by LI, the restriction is ignored, but copied within the COL parameter to the IRI record.

5.5.9 Closed User Group (CUG)

In case of a CUG call, the closed user group interlock code shall be included in an IRI.

5.5.10 Completion of Call to Busy Subscriber (CCBS)

No impact.

The first call, which meets a (terminating) busy subscriber, and is released subsequently, is treated like a standard busy call, with no CCBS related IRI information.

The procedures for CCBS, until starting a new call attempt from the served user to the terminating user, including the CCBS recall, are not subject of LI.

5.5.11 Multi ParTY call (MPTY)

5.5.11.1 General

a) Target is conference controller:
The MPTY conference originates from a configuration with two single calls (one active, one held). When joining the calls to a conference, the CC links, which have carried the signals of the active target call are used to transmit the conference signals; that is, the Rx call contains the sum signal of the conference, the Tx call contains the signal from the target.

The second CC link set, for the previously held call stays intact. If the conference is released, and the initial state (1 held, 1 active call) is re-established, the required CC links are still available.

b) Target is passive party of conference:
No impact on CC links.

5.5.11.2 IRI records

For the events indicating the start and the end of the MPTY conference, IRI records are generated.

5.5.12 DIVersion Services (DIV)

5.5.12.0 General

Calls to a target, with a called party number equal to the intercepted target DN(s), but forwarded, are intercepted, i.e. CC links are set up, and IRI records are sent to the LEA. This applies for all kinds of call forwarding.

For calls forwarded by the other party (calling or called), the available diversion-related information is sent to the LEA.

5.5.12.1 Call Diversion by Target

5.5.12.1.1 Call Diversion by Target, CC links

In order to handle call diversion services by applying, as far as possible, common procedures, the following two cases are differentiated:

a) Call Forwarding Unconditional (CFU), Call Forwarding Busy (NDUB):
In these cases, forwarding is determined, before seizing the target access. CC links are set up, immediately, for the forwarded call.

Other variants of Call Forwarding with immediate forwarding, i.e. without first seizing the target access, are handled in the same way (e.g. unconditional Selective Call Forwarding).

b) Call Forwarding No Reply, Call Forwarding Busy (UDUB), Call Deflection:
Initially, the target call is set up, and the call is intercepted like a basic call.

When forwarding takes place (e.g. after expiry of the CFNR timer), the original call is released; this may cause also a release of the CC links. In such case two optional IRI record handling may apply:

1) For the original call an IRI-END record is sent. For the forwarded call a new set up procedure, including new LI transaction may take place with new set of IRI records (starting with IRI-BEGIN record sent to the LEA).

2) For the forwarded call the IRI-CONTINUE record is generated and sent to a LEA, indicating the CFNR invocation.

Other variants of Call Forwarding with forwarding after first seizing the target access, are handled in the same way.

In case of multiple forwarding, one call may be intercepted several times, if several parties are targets. Considering the maximum number of diversions for one call of 5 (3GPP recommended limit), one call can be intercepted 7 times, from the same or different LEAs. In principle, these procedures are independent of each other.

5.5.12.1.2 Call Diversion by Target, IRI records

See clause 5.2.2.3, case 2, related to the target’s information, and case 3, related to the forwarded-to-party information.

As above for the CC links, the diversion types a) and b1, 2) are differentiated: For case a) and b2) diversions, the IRI is part of one transaction, IRI-BEGIN, -CONTINUE, -END, for case b1) diversions, a first transaction informs about the call section, until diversion is invoked (corresponding to a basic, prematurely released call), a second transaction informs about the call section, when diversion is invoked (corresponding to case a).

5.5.12.2 Forwarded Call Terminated at Target

The CC link is handled in the standard way. The IRI-BEGIN record contains the available call diversion information, see clause 5.2.2.3 case 1.

5.5.12.3 Call from Target Forwarded

The CC link is handled in the standard way. The IRI-BEGIN and possibly IRI-CONTINUE records contain the available call diversion related information, see clause 5.2.2.3 case 3.

5.5.13 Variants of call diversion services

Variants of the above "standard" diversion services are treated in the same way as the corresponding "standard" diversion service.

5.5.14 SUBaddressing (SUB)

The different types of subaddress information elements are part of the IRI records, in all basic and supplementary services cases, where they are present.

5.5.15 User-to-User Signalling (UUS)

User-to-User parameters of services UUS1, UUS2 and UUS3 shall be reported as HI2, see clause 5.4.

If User-User information is not delivered from a target to the other party (e.g. due to overload in the SS No.7 network), no notification is sent to the LEA.

5.5.16 Incoming Call Barring (ICB)

No impact.

a) Case terminating call to a target with ICB active:
In general, the barring condition of a target is detected before the target access is determined, consequently, an IRI-REPORT records is generated.
If the access would be determined, a standard IRI-END record is generated, with the applicable cause value.

b) Case target calls a party with ICB active:
In general, an IRI-BEGIN record has been sent already, and CC links have been set up. Consequently, a standard IRI-END record is generated, with the applicable cause value.

5.5.17 Outgoing Call Barring (OCB)

No impact.

For a barred call, a standard record may be generated; its type and content are depending on the point in the call, where the call was released due to OCB restrictions.

5.5.18 Tones, Announcements

No impact.

If the normal procedures, depending on the call state, result in sending the tone or announcement signal on the Rx CC link channel, this shall be transmitted as CC.

5.6 Functional architecture

The following picture contains the reference configuration for the lawful interception (see TS 33.107 [19]).

There is one Administration Function (ADMF) in the network. Together with the delivery functions it is used to hide from the 3G MSC server and 3G GMSC server that there might be multiple activations by different Law Enforcement Agencies (LEAs) on the same target.

Figure 5.4: Reference configuration for Circuit switched

The reference configuration is only a logical representation of the entities involved in lawful interception and does not mandate separate physical entities. This allows for higher levels of integration.

A call could be intercepted based on several identities (MSISDN, IMSI, IMEI, Non-Local ID) of the same target.

Interception based on IMEI could lead to a delay in start of interception at the beginning of a call and interception of non-call related events is not possible.

For the delivery of the CC and IRI the 3G MSC server or the 3G GMSC server provides correlation number and target identity to the DF2 and DF3 which is used there in order to select the different LEAs where the product shall be delivered to.

5.7 IP-based handover interface for CC

5.7.1 General

When IP-based delivery interface is used for HI3, the CC of intercepted Circuit Switched (CS) voice calls shall be delivered to the LEMF using the ASN.1 module defined in Annex B.17.

As illustrated in figure 5.5, the communication between target and the other party will still be over circuit-switched network connections.

Figure 5.5: IP based handover interface for the CC of a CS intercepts

The method used to deliver the CS-voice contents from ICE to DF3 (i.e. the details of X3 reference point, see TS 33.107 [19]) can be implementation specific and therefore, related details are outside the scope of the present document. Some examples are illustrated in TS 33.107 [19].

5.7.2 Identifiers

The identifiers are used to establish a correlation between the CC and the IRI messages. The following identifiers are used to correlate the CC with the associated IRI messages:

Lawful Interception Identifier (see sub-clause 5.1.1)

Communication Identifier (see sub-clause 5.1.2)

CC-Link-Identifier (see sub-clause 5.1.3).

The Communication Identifier includes two identifiers:

Network Identifier (see sub-clause 5.1.2.1)

Communication Identity Number (see sub-clause 5.1.2.2).

When a target is involved in multi-party calls, each call-leg will have a separate Communication Identity Number. The Lawful Interception Identifier, Network Identifier can be the same for multiple legs of the call. The CC-Link-Identifier is used when single circuit-link is used to deliver the CC of all call-legs of multi-party calls. The details of this are described in sub-clause 5.1.5.

With IP-based handover interface option for CC, the use of CC-Link-Identifier may not be applicable for HI3. However, to avoid any backward compatibility issues, the inclusion of CC-Link-Identifier in the HI3 even for IP-based handover interface is encouraged if the same is sent over the HI2.

5.7.3 Voice Content Direction

Voice content direction shall be included within the CC delivered to the LEMF and it allows the LEMF to distinguish between multiple voice media streams received. Within the ASN.1 module, this is identified as TPDU-direction and can have the following values:

– From the target: indicates that the voice content is sent from the target.

– To the target: indicates that the voice content is sent to the target.

– Combined: indicates that the voice content sent to, and received from, the target is delivered to the LEMF in a combined form.

– Unknown: indicates that the direction cannot be determined.

Basically, this information helps the LEMF to identify whether the voice content is delivered in a stereo form or mono-form. In the former case, it further helps the LEMF to distinguish the voice content sent to the target from the voice content received from the target.

5.7.4 Payload Description

The intercepted voice-content delivered over HI3 is identified within the ASN.1 module as payload. The information necessary for the LEMF to decode the payload shall be included within the CC. Within the ASN.1, this is identified as payload description that contains the media format (RFC 3551 [93]) and media attributes (RFC 4566 [94]) using the SDP (RFC 4566 [94]).

NOTE: When IP-based handover interface is used to deliver the CC, the payload can be in the RTP (RFC 3550 [95]) form. The codec information associated with that RTP can be delivered over HI2 or HI3. However, former approach will require changes to the IRI messages and hence, causing a backward compatibility issue.

In support of backward compatibility, the delivery of payload description (i.e. media format and media attributes when the payload is in RTP form) over HI2 shall be discouraged. In other words, the pay-load description shall be delivered over HI3.

Table 5.8 below describes the usage of Media Format and Media Attributes.

Table 5.8: usage of media format and media attributes

Field name	Status	ASN.1 field	Information
Media Format	Mandatory	mediaFormat	This field signals the codec used, as defined in RFC 3551 [93].
Media Attributes	Conditional (i.e. mandatory under the conditions listed)	mediaAttributes	If any extra information (beyond the Media Format) is needed to understand the delivered CC then it shall be sent here, in the format defined in the a= field of SDP (see RFC 4566 [94]). Typically, media attributes shall be present if and only if the media format is 32 or above.

5.7.5 Sequence Number

Sequence Number is an integer incremented each time a T-PDU is delivered. Handling of sequence number is done according to national requirements.