Content for  TS 33.108  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   9…   12…   14…   16…   A…   C…   L…


4  Generalp. 22

4.0  Introduction |R12|p. 22

The present document focuses on the handover interface related to the provision of information related to LI between a network operator, access provider and/or service provider and a Law Enforcement Agency (LEA).

4.1  Basic principles for the handover interfacep. 22

The network requirements mentioned in the present document are derived, in part, from the requirements defined in ETSI ES 201 158 [2].
Lawful interception may require functions to be provided in the switching or routing nodes of a telecommunications network.
The specification of the handover interface is subdivided into three logical ports each optimised to the different purposes and types of information being exchanged.
The interface is extensible. (i.e. the interface may be modified in the future as necessary).

4.2  Legal requirementsp. 23

It shall be possible to select elements from the handover interface specification to conform with:
  • national requirements;
  • national law;
  • any law applicable to a specific LEA.
As a consequence, the present document shall define, in addition to mandatory requirements, which are always applicable, supplementary options, in order to take into account the various influences listed above. See also ETSI TS 101 331 [1] and ETSI ETR 330 [3].

4.3  Functional requirementsp. 23

A lawful authorization shall describe the kind of information IRI only, or IRI with CC that is required by an LEA, the identifiers for the target, the start and stop time of LI, and the addresses of the LEAs for delivery of CC and/or IRI and further information.
A single target may be the target by different LEAs. It shall be possible strictly to separate these interception measures.
If two targets are communicating with each other, each target is dealt with separately.

4.4  Overview of handover interfacep. 23

4.4.0  Introduction |R12|p. 23

The generic handover interface adopts a three port structure such that administrative information (HI1), intercept related information (HI2), and the content of communication (HI3) are logically separated.
Figure 4.1 shows a block diagram with the relevant entities for Lawful Interception.
The outer circle represents the operator's (NO/AN/SP) domain with respect to lawful interception. It contains the network internal functions, the internal network interface (INI), the administration function and the mediation functions for IRI and CC. The inner circle contains the internal functions of the network (e.g. switching, routing, handling of the communication process). Within the network internal function the results of interception (i.e. IRI and CC) are generated in the Internal Interception Function (IIF).
The IIF provides the CC and the IRI, respectively, at the Internal Network Interface (INI). For both kinds of information, mediation functions may be used, which provide the final representation of the standardized handover interfaces at the operator's (NO/AN/SP) domain boundary.
Reproduction of 3GPP TS 33.108, Fig. 4.1: Functional block diagram showing handover interface HI

4.4.1  Handover interface port 2 (HI2)p. 24

The handover interface port 2 shall transport the IRI from the operator's (NO/AN/SP) IIF to the LEMF.
The delivery of the handover interface port 2 shall be performed via data communication methods which are suitable for the network infrastructure and for the kind and volume of data to be transmitted. From the operator (NO/AN/SP) to LEMF delivery is subject to the facilities that may be procured by the government.
The delivery can in principle be made via different types of lower communication layers, which should be standard or widely used data communication protocols.
The individual IRI parameters shall be coded using ASN.1 and the basic encoding rules (BER). The format of the parameter's information content shall be based on existing telecommunication standards, where possible.
The individual IRI parameters have to be sent to the LEMF at least once (if available).
The IRI records are transmitted individually. As an option, IRI records can be aggregated for delivery to the same LEA (i.e. in a single delivery interaction). As there are time constraints associated with the delivery of IRI, the use of this optional feature is subject to national or regional requirements. As a general principle, IRI records shall be sent immediately and shall not be withheld in the MF/DF in order to use the IRI record aggregation option.
The IRI records shall contain information available from normal provider (NO/AN/SP) operating procedures. In addition the IRI records shall include information for identification and control purposes as specifically required by the HI2 port.
The IIF is not required to make any attempt to request explicitly extra information which has not already been supplied by a signalling system.

4.4.2  Handover interface port 3 (HI3)p. 25

The port HI3 shall transport the CC of the intercepted telecommunication service to the LEMF. The CC shall be presented as a transparent en-clair copy of the information flow during an established, frequently bi-directional, communication of the target. However, in case MIKEY ticket based solution is used for IMS media security as specified in TS 33.328 and CC is presented in encrypted format, the decryption keys and the associated information shall be delivered to the LEMF via appropriate IRI over the HI2.
As the appropriate form of HI3 depends upon the service being intercepted, HI3 is described in relevant annexes.
The HI2 and HI3 are logically different interfaces, even though in some installations the HI2 and HI3 packet streams might also be delivered via a common transmission path from a MF to a LEMF. It is possible to correlate HI2 and HI3 packet streams by having common (referencing) data fields embedded in the IRI and the CC packet streams.

4.5  HI2: Interface port for intercept related informationp. 25

4.5.0  General |R12|p. 25

The HI2 interface port shall be used to transport all IRI, i.e. the information or data associated with the communication services of the target identity apparent to the network. It includes signalling information used to establish the telecommunication service and to control its progress, time stamps, and, if available, further information such as location information. Only information which is part of standard network signalling procedures shall be used within communication related IRI.
For all UE locations obtained, generated or reported to the LEMF, the MF/DF shall report the time at which the location was established by the location source (e.g. MME or HSS) and provide this to the MF/DF along with the location information. If this information cannot be provided to the MF/DF, then the MF/DF shall indicate that the time is not available. If the information in the MME received over S1 (TS 36.413) includes one or more cell IDs, then all cell IDs shall be reported to the LEMF whenever location reporting is triggered at the MME.
Sending of the IRI to the LEMF shall in general take place as soon as possible, after the relevant information is available.
In exceptional cases (e.g. data link failure), the IRI may be buffered for later transmission for a specified period of time.
Within this clause only, definitions are made which apply in general for all network technologies. Additional technology specific HI2 definitions are specified in related Annexes.

4.5.1  Data transmission protocolsp. 25

The protocol used by the "LI application" for the encoding and the sending of data between the MF and the LEMF is based on already standardized data transmission protocols.
The specified data communication methods provide a general means of data communication between the LEA and the operator's (NO/AN/SP) mediation function. They are used for the delivery of:
  • HI2 type of information (IRI records);
  • Certain types of content of communication (e.g. SMS).
The present document specifies the use of the several possible methods for delivery: FTP or TPKT/TCP/IP (specifications for this specific protocol are in Clause G.2 - "HI2 delivery methods". This protocol is defined by RFC 2126: "ISO Transport Service on top of TCP (ITOT)" on the application layer and the BER on the presentation layer. The lower layers for data communication may be chosen in agreement with the operator (NO/AN/SP) and the LEA.
As an alternative, ETSI TS 102 232-1 [104] and ETSI TS 102 232-7 [105] may be used for the encoding and the sending of data between the MF and the LEMF.
The delivery to the LEMF should use the internet protocol stack.

4.5.2  Application for IRI (HI2 information)p. 26

The handover interface port 2 shall transport the IRI from the operator's (NO/AN/SP) MF to the LEMF.
The individual IRI parameters shall be coded using ASN.1 and the basic encoding rules (BER). Where possible, the format of the information content shall be taken over from existing telecommunication standards, which are used for these parameters with the network already (e.g. IP). Within the ASN.1 coding for IRI, such standard parameters are typically defined as octet strings.

4.5.3  Types of IRI recordsp. 26

Intercept related information shall be conveyed to the LEMF in messages, or IRI data records, respectively. Four types of IRI records are defined:
IRI-BEGIN record
at the first event of a communication attempt, opening the IRI transaction.
IRI-END record
at the end of a communication attempt, closing the IRI transaction.
at any time during a communication attempt, within the IRI transaction.
IRI-REPORT record, used in general for non-communication related events.
For information related to an existing communication case, the record types 1 to 3 shall be used. They form an IRI transaction for each communication case or communication attempt, which corresponds directly to the communication phase (set-up, active or release).
For packet oriented data services, the first event of a communication attempt shall be the PDP context activation or a similar event and an IRI-BEGIN record shall be issued. The end of the communication attempt shall be the PDP context deactivation and an IRI-END record shall be issued. While a PDP context is active, IRI-CONTINUE records shall be used for CC relevant IRI data records, IRI-REPORT records otherwise.
Record type 4 is used for non-communication related subscriber action, like subscriber controlled input (SCI) for service activation. For simple cases, it can also be applicable for reporting unsuccessful communication attempts. It can also be applicable to report some subscriber actions which may trigger communication attempts or modifications of an existing communication, when the communication attempt or the change of the existing communication itself is reported separately.
Record type 4 is also used to convey the LALS reports.
For the IMS domain the IRI record types are used in a different way than described in this clause. Details on the IRI type usage in the IMS domain are defined in clause 7.5.
The record type is an explicit part of the record. The 4 record types are defined independently of target communication events. The actual indication of one or several communication events, which caused the generation of an IRI record, is part of further parameters within the record's information content. Consequently, the record types of the IRI transactions are not related to specific messages of the signalling protocols of a communication case, and are therefore independent of future enhancements of the intercepted services, of network specific features, etc. Any transport level information (i.e. higher-level services) on the target communication-state or other target communication related information is contained within the information content of the IRI records.
For packet oriented data services, if LI is being activated during an already established PDP context or similar, an IRI-BEGIN record will mark the start of the interception. If LI is being deactivated during an established PDP context or similar, no IRI-END record will be transmitted. The end of interception can be communicated to the LEA by other means (e.g. HI1).
The DF2 shall not send the BEGIN with Start of Interception to the LEMFs that were already intercepting the target communication due to a previous LI activation on the same target.

4.6  Reliability |R12|p. 27

The reliability associated with the result of the interception of the content of communication should be (at least) equal to the reliability of the original content of communication. For intercepted packet data communications, this may be derived from the QoS class used for the original intercepted session, TS 23.107.
The reliability associated with the result of interception of signalling should be (at least) equal to the the reliability of the original signalling.
Reliability from the operator (NO/AN/SP) to the LEMF is determined by what operators (NO/AN/SP) and law enforcement agree upon.

Up   Top   ToC