F.3 HI3 Delivery Content of Communication(CC)
F.3.1 GPRS LI Correlation Header
F.3.1.3 Exceptional procedure
With UDP and GLIC: the delivering node does not take care about any problems at LEMF.
With TCP and GLIC: TCP tries to establish a connection to LEMF and resending (buffering in the sending node) of packets is also supported by TCP.
In both cases it might happen that call content gets lost (in case the LEMF or the transit network between MF and LEMF is down for a long time).
F.3.1.4
Other considerations
The use of IPsec for this interface is recommended. The required functions in LEMF are:
- Collecting and storing of the incoming packets inline with the sequence numbers. - Correlating of CC to IRI with the use of the correlation number in the GLIC header.
F.3.2
FTP
F.3.2.1
Introduction
At HI3 interface FTP is used over the internet protocol stack for the delivery of the result of interception. FTP is defined in [46]. The IP is defined in [51]. The TCP is defined in [52].
FTP supports reliable delivery of data. The data may be temporarily buffered in the sending node (MF) in case of link failure. FTP is independent of the payload data it carries.
F.3.2.2
Usage of the FTP
In the packet data LI the MF acts as the FTP client and the receiving node (LEMF) acts as the FTP server . The client pushes the data to the server.
The receiving node LEMF stores the received data as files. The sending entity (MF) may buffer files.
Several smaller intercepted data units may be gathered to bigger packages prior to sending, to increase bandwidth efficiency.
The following configurable intercept dta collection (= transfer package closing/file change) threshold parameters should be supported:
- frequency of transfer, based on send timeout, e.g. X ms; - frequency of transfer, based on volume trigger, e.g. X octets.
There are two possible ways how the interception data may be sent from the MF to the LEMF. One way is to produce files that contain interception data only for one observed target (ref: "File naming method A)"). The other way is to multiplex all the intercepted data that MF receives to the same sequence of general purpose interception files sent by the MF (ref: "File naming method B)").
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.
File naming:
The names for the files transferred to a LEA are formed according to one of the 2 available formats, depending on the delivery file strategy chosen (e.g. due to national convention or operator preference).
Either each file contains data of only one observed target (as in method A) or several targets' data is put to files common to all observed target traffic through a particular MF node (as in method B).
The maximum set of allowed characters in interception file names are "a"…"z", "A"…"Z", "-", "_", ".", and decimals "0"…"9".
File naming method A):
<LIID>_<seq>.<ext>
LIID = as defined in the present document. This field has a character string value, e.g. "ABCD123456". This is a
unique interception request identifier allocated by the ADMF. It will be given by the ADMF to the LEA via the HI1 interface after the ADMF has been authorized to command the start of the interception of a specific target. The possible network operator identifier part used should be agreed with (and allocated by) the regulatory organization
administrating the local telecommunication practises.
Seq = integer ranging between [0..2^64-1], in ASCII form (not exceeding 20 ASCII digits), identifying the sequence
number for file transfer from this node per a specific target.
Ext = ASCII integer ranging between ["1"..."7"] (in hex: 31H…37H), identifying the file type. The possible file type
Table F.3.4: Possible file types
File types that the LEA may get Intercepted data types
"2" (in binary: 0011 0010) CC (MO) "4" (in binary: 0011 0100) CC (MT) "6" (in binary: 0011 0110) CC (MO&MT)
(The least significant bit that is "1" in file type 1, is reserved for indicating IRI data.) The bit 2 of the ext tells whether the Mobile Originated (MO) Content of Communication (CC) is included to the intercepted data.
The bit 2 of the ext tells whether the Mobile Originated (MO) Content of Communication (CC) is included to the intercepted data.
The bit 3 of the ext tells whether the Mobile Terminated (MT) Content of Communication (CC) is included to the intercepted data.
Thus, for Mobile Originated Content of Communication data, the file type is "2", for MT CC data "4" and for MO&MT CC data "6".
This alternative A is used when each target's intercepted data is gathered per observed target to dedicated delivery files. This method provides the result of interception in a very refined form to the LEAs, but requires somewhat more resources in the sending node than alternative B. With this method, the data sorting and interpretation tasks of the LEMF are considerably easier to facilitate in near real time than in alternative B.
File naming method B):
The other choice is to use monolithic fixed format file names (with no trailing file type part in the file name):
<filenamestring> (e.g. ABXY00041014084400006)
where:
ABXY = Source node identifier part, used for all files by the mobile network operator "AB" from this MF node named "XY". 00 = year 2000 04 = month April 10 = day 10 14 = hour 08 = minutes 44 = seconds 0000 = extension
6 = file type. Coding: "2" = CC (MO), "4" = CC (MT), "6" = CC (MO&MT). (The type "1" is reserved for IRI data files).
This alternative B is used when several targets' intercepted data is gathered to common delivery files. This method does not provide the result of interception in as refined form to the LEAs as the alternative A, but it is faster in performance for the MF point of view. With this method, the MF does not need to keep many files open like in alternative A.
F.3.2.3
Exceptional procedures
Overflow at the receiving end (LEMF) is avoided due to the nature of the protocol.
In case the transit network or receiving end system (LEMF) is down for a reasonably short time period, the local buffering at the MF will be sufficient as a delivery reliability backup procedure.
In case the transit network or receiving end system (LEMF) is down for a very long period, the local buffering at the MF may have to be terminated. Then the following intercepted data coming from the intercepting nodes towards the MF would be discarded, until the transit network or LEMF is up and running again.
F.3.2.4
CC contents for FTP
F.3.2.4.1
Fields
The logical contents of the CC-header is described here.
CC-header = (Version, HeaderLength, PayloadLength, PayloadType, PayloadTimeStamp, PayloadDirection,
CCSeqNumber, CorrelationNumber, LIID, PrivateExtension).
The Information Element CorrelationNumber forms the means to correlate the IRI and CC of the communication session intercepted.
The first column indicates whether the Information Element referred is Mandatory, Conditional or Optional. The second column is the Type in decimal.
The third column is the length of the Value in octets.
Table F.3.5: Information elements in the CC header
Mode Type Length Value
M 130 2 Version = the version number of the format version to be used. This field has a decimal value, this enables version changes to the format version. The values are allocated according to national conventions.
O 131 2 HeaderLength = Length of the CC-header up to the start of the payload in octets. (This field is optional since it is useful only in such cases that these information elements would be transferred without a dynamic length encapsulation that contains all the length information anyway. This field could be needed in case of e.g. adapting to a local encapsulation convention.)
O 132 2 PayloadLength = Length of the payload following the CC-header.
(This field is optional since it is useful only in such cases that these information elements would be transferred without a dynamic length encapsulation that contains all the length information anyway. This field could be needed in case of e.g. adapting to a local encapsulation convention.)
M 133 1 PayloadType = Type of the payload, indicating the type of the CC. Type of the payload. This field has a decimal value. The possible PDP Type values can be found in the standards, e.g. GSM 09.60 [45]. The value 255 is reserved for future PDP Types and means: "Other". O 134 4 PayloadTimeStamp = Payload timestamp according to intercepting node. (Precision: 1 s,
timezone: UTC). Format: Seconds since 1970-01-01 as in e.g. Unix (length: 4 octets).
C 137 1 PayloadDirection = Direction of the payload data. This field has a decimal value 0 if the payload data is going towards the target (i.e. downstream), or 1 if the payload data is being sent from the target (i.e. upstream). If this information is transferred otherwise, e.g. in the protocol header, this field is not required as mandatory. If the direction information is not available otherwise, it is mandatory to include it here in the CC header.
O 141 4 CCSeqNumber = Identifies the sequence number of each CC packet during interception of the target. This field has a 32-bit value.
M 144 8 or 20 CorrelationNumber. Identifies an intercepted session of the observed target. This can be implemented by using e.g. the Charging Id (4 octets, see [49]) with the (4-octet/16-octet) Ipv4/Ipv6 address of the PDP context maintaining GGSN node attached after the first 4 octets.
<Possible future parameters are to be allocated between 145 and 253>.
O 254 1-25 LIID = Field indicating the LIID as defined in the present document. This field has a character string value, e.g. "ABCD123456".
O 255 1-N PrivateExtension = An optional field. The optional Private Extension contains vendor or LEA or operator specific information. It is described in the document GSM 09.60 [45].
F.3.2.4.2
Information element syntax
The dynamic TypeLengthValue (TLV) format is used for ist ease of implementation and good encoding and decoding performance. Subfield sizes: Type = 2 octets, Length = 2 octets and Value = 0…N octets. From Length the T and L subfields are excluded. The Type is different for every different field standardized.
The octets in the Type and Length subfields are ordered in the little-endian order, (i.e. least significant octet first). Any multioctet Value subfield is also to be interpreted as being little-endian ordered (word/double word/long word) when it has a (hexadecimal 2/4/8-octet) numeric value, instead of being specified to have an ASCII character string value. This means that the least significant octet/word/double word is then sent before the more significant octet/word/double word. TLV encoding:
Type (2 octets) Length (2 octets) Value (0-N octets) TLV encoding can always be applied in a nested fashion for structured values.
(The small "v" refers to the start of a Value field that has inside it a nested structure.)
In the following figure the TLV structure for GPRS HI3 transfer is presented for the case that there is just one intercepted packet inside the CC message. (There can be more CC Header IEs and CC Payload IEs in the CC, if there are more intercepted packets in the same CC message.)
(2 octets)
MainElementID CC Length CC
(2 octets) (N octets)
(2 octets)
HeaderElem.ID HeaderLength Header Value
(2 octets) (N octets)
(2 octets)
PayloadElem.ID PayloadLength Payload Value
(2 octets) (N octets)
CC Payload IE CC Header IE
(2 octets)
VersionID Length Version
(2 octets) (2 octets) (2 octets)
PrivateExt.ID Length PrivateExtension
(2 octets) (N octets)
PrivateExtension IE Version IE
Intercepted data packet
(The other IEs inside the CC Header Value field are here between)
CC Information Element
Figure F.3.1: IE structure of a CC message that contains one intercepted packet
The first octet of the first TLV element will start right after the last octet of the header of the protocol that is being used to carry the CC information.
The first TLV element (i.e. the main TLV IE) comprises the whole dynamic length CC information, i.e. the dynamic length CC header and the dynamic length CC payload.
Inside the main TLV IE there are at least 2 TLV elements: the Header of the payload and the Payload itself. The Header contains all the ancillary IEs related to the intercepted CC packet. The Payload contains the actual intercepted packet. There may be more than one intercepted packet in one GPRS HI3 delivery protocol message. If the Value of the main TLV IE is longer than the 2 (first) TLV Information Elements inside it, then it is an indication that there are more than one intercepted packets inside the main TLV IE (i.e. 4 or more TLV IEs in total). The number of TLV IEs in the main TLV IE is always even, since for every intercepted packet there is one TLV IE for header and one TLV IE for payload.
F.3.2.5
Other Considerations
• The FTP protocol mode parameters used:
• Transmission Mode: stream;
• Format: non-print;
• Structure: file-structure;
• Type: binary.
The FTP client- (= user - FTP process at the MF) uses e.g. the default standard FTP ports 20 (for data connection) and 21 (for control connection), "passive" mode is supported. The data transfer process listens the data port for a connection from a server-FTP process.
For the file transfer from the MF to the LEMF(s) e.g. the following data transfer parameters are provided for the FTP client (at the MF):
- transfer destination (IP) address, e.g. "194.89.205.4"; - transfer destination username, e.g. "LEA1";
- transfer destination directory path, e.g. "/usr/local/LEA1/1234-8291"; - transfer destination password;
- interception file type, e.g. "2" (this is needed only if the file naming method A is used).
LEMF may use various kind directory structures for the reception of interception files. It is strongly recommended that at the LEMF machine the structure and access and modification rights of the storage directories are adjusted to prevent unwanted directory operations by a FTP client.
The use of IPSec services for this interface is recommended.
Timing considerations for the FTP transmission:
The MF and LEMF sides control the timers to ensure reliable, near-real time data transfer. The transmission related timers are defined within the lower layers of the used protocol and are out of scope of the present document. The following timers may be used within the LI application:
Name Controlled by Units Description
T1 inactivity timer LEMF Seconds Triggered by no activity within the FTP session (no new files). The FTP session is torn down when the T1 expires. To send another file the new connection will be established. The timer avoids the FTP session overflow at the LEMF side.
T2 send file trigger MF Milliseconds Forces the file to be transmitted to the LEMF (even if the size limit has not been reached yet in case of volume trigger active). If the timer is set to 0 the only trigger to send the file is the file size parameter (see C.2.2).
Annex G (informative):
LEMF requirements - handling of unrecognized fields and
parameters
During decoding of a record at the LEA, the following exceptional situations may occur:
1) Unrecognized parameter: The parameter layout can be recognized, but its name is not recognized: The parameter shall be ignored, the processing of the record proceeds.
2) The parameter content or value is not recognized or not allowed: The parameter shall be ignored, the processing of the record proceeds. 3) The record cannot be decoded (e.g. it seems to be corrupted):
The whole record shall be rejected when using ROSE delivery mechanism or ignored.
NOTE: In cases 2 and 3, the LEMF may wish to raise an alarm to the NWO/AP/SvP administration centre. For case 1, no special error or alarm procedures need be started at the LEA, because the reason may be the introduction of a new version of the specification in the network, not be an error as such security aspects.
Annex H (informative):
Bibliography
• ETSI ETS 300 121: "Integrated Services Digital Network (ISDN); Application of the ISDN User Part (ISUP) of ITU-T Signalling System No.7 for international ISDN interconnections (ISUP version 1)".
• ETSI EN 300 052-1: "Integrated Services Digital Network (ISDN); Multiple Subscriber Number (MSN) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 055-1: "Integrated Services Digital Network (ISDN); Terminal Portability (TP) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 058-1: "Integrated Services Digital Network (ISDN); Call Waiting (CW) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 064-1: "Integrated Services Digital Network (ISDN); Direct Dialling In (DDI) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 092-1 including Amendment 2: "Integrated Services Digital Network (ISDN); Calling Line Identification Presentation (CLIP) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 093-1: "Integrated Services Digital Network (ISDN); Calling Line Identification Restriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 141-1: "Integrated Services Digital Network (ISDN); Call Hold (HOLD) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 210-1: "Integrated Services Digital Network (ISDN); Freephone (FPH) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 359-1: "Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 300 745-1: "Integrated Services Digital Network (ISDN); Message Waiting Indication (MWI) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 301 001-1 (V1.1): "Integrated Services Digital Network (ISDN); Outgoing Call Barring (OCB) supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ETSI EN 301 065-1 (V1.1): "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
• ITU-T Recommendation Q.699: "Interworking between ISDN access and non-ISDN access over ISDN User Part of Signalling System No. 7".
• ITU-T Recommendation I.210: "Principles of telecommunication services supported by an ISDN and the means to describe them".
History
Document history
V1.1.1 July 1999 Publication