Draft of 11 October 2021
R E G U L AT I O N
O F T H E M I N I S T E R O F D I G I T A L I S A T I O N 1), 2)
of ..................... 2021
on broadcasting or broadcasting and receiving radio equipment which may be used without a radio
authorisation
Pursuant to Article 144(3) of the Telecommunications Act of 16 July 2004 (OJ of 2021, item 576) the
following shall be ordered:
§ 1. The present Regulation extends the scope of the broadcasting or broadcasting and receiving radio
equipment, hereinafter referred to as “equipment”, which can be used without a radio authorisation,
hereinafter referred to as “authorisation”, and specifies:
1) the conditions of use of this equipment, including:
a) the frequency bands used by it,
b) the maximum radiated power or the maximum magnetic field strength,
c) the area of use of this equipment;
2) the types of radiocommunication services where the equipment may be used.
§ 2. The terms, indications, abbreviations and symbols used in the Regulation and the Annexes to the
Regulation shall mean:
1) [-] — no restrictions;
2) AFA (Adaptive Frequency Agility) — the ability to adaptively select a transmission channel from a
set defined for a given equipment, in order to avoid interference;
3) duty cycle — the percentage reflecting the ratio of transmission time to observation period, with any
one-hour continuous time interval to be understood as an observation period;
4) dedicated antenna — an antenna intended to be used with a given equipment with the possibility of
its detaching, but designed and supplied as an essential part of the equipment, the testing of which and
the assessment of conformity with the essential requirements referred to in Article 153(a)(1) of the
Telecommunications Act of 16 July 2004 (OJ of 2021, item 576), were carried out with this antenna;
1)
The Minister for Digitisation manages the government computerisation department pursuant to § 1(2) of the Prime Ministerial
Order of 6 October 2020 concerning the specific scope of activities of the Minister for Digitisation (Journal of Laws
[Dziennik Ustaw], item 1716).
2)
This regulation was notified to the European Commission on ................, under No ...................., pursuant to § 4 of the
Regulation of the Council of Ministers of 23 December 2002 concerning the manner in which the national notification system
of standards and legal acts functions (Journal of Laws, item 2039; 2004, item 597), which implements the provisions of
Directive (EU) 2015/1535 of the European Parliament and of the Council of 9 September 2015 laying down a procedure for
the provision of information in the field of technical decrees and of rules on Information Society services (OJ EU L 241 of
17.9.2015, p. 1).
5) external antenna — an antenna attached to the equipment by means of a connector with which the
equipment is fitted, used with the equipment the tests of which and the assessment of conformity with
the essential requirements referred to in Article 153(a)(1) of the Telecommunications Act of
16 July 2004 were carried out without this antenna;
6) integrated antenna — an antenna designed as an integral part of the device in such a way that it cannot
be disconnected;
7) AES — an Aircraft Earth Station;
8) AVI — Automatic Vehicle Identification;
9) balise — a piece of equipment installed near the track of railway vehicles for the transmission of data
between that equipment and the vehicle or between the vehicle and that equipment;
10) BSS — broadcasting satellite service;
11) CEPT — the European Conference of Postal and Telecommunications Administrations;
12) DEC — the Decision;
13) DSB-AM — the two-band emission of an amplitude modulated signal;
14) ECC — Electronic Communications Committee;
15) e.i.r.p. — equivalent isotropically radiated power;
16) e.r.p. — effective radiated power;
17) ESIM — Earth Stations In-Motion;
18) ESOMP — Earth Stations on Mobile Platforms;
19) ESV — Earth Stations on board Vessels;
20) ETSI — European Telecommunications Standard Institute;
21) Eurobalise — a train traffic information system forming a part of the European Rail Traffic
Management System;
22) Euroloop — a system forming part of the European Rail Traffic Management System;
23) FDD — frequency division duplexing;
24) FHSS — Frequency Hopping Spread Spectrum;
25) FSS — Fixed Satellite Service;
26) GSO — Geostationary Satellite Orbit;
27) GSM — global system for mobile communications;
28) HDAFSS — High Density Applications in the Fixed Satellite Service;
29) HEST — High e.i.r.p. Satellite Terminal;
30) HIPERLAN — High Performance Radio Local Area Network;
31) HIRF — high-intensity radiated field;
32) ISM (Industrial, Scientific, Medical) — equipment generating and using radio wave energy, in
particular for industrial, scientific, medical or domestic purposes, excluding telecommunication ones;
33) RFID tag — a piece of radio equipment used for RFID purposes placed on live or non-living objects;
34) interrogator — a piece of radio equipment used for RFID purposes that activates a tag and receives
the data transmitted by this tag;
35) LEST — Low e.i.r.p. Satellite Terminal;
36) LTE — Long-Term Evolution of mobile communications standards;
37) MCA (Mobile Communication on Aircraft) — a telecommunications service provided to enable
persons on board an aircraft to use public telecommunications networks without establishing direct
connections to mobile public telecommunications networks operating on land;
38) MCV (Mobile Communication on Vessels) — a telecommunications service provided to enable
persons on board a ship to use public telecommunications networks without establishing direct
connections to mobile public telecommunications networks operating on land;
39) NGSO — Non-Geostationary-Satellite Orbit;
40) NCF — Network Control Facility;
41) NCU — Network Control Unit;
42) NMR — Nuclear Magnetic Resonance;
43) PFD — Power Flux Density;
44) PMP — a Point to MultiPoint system;
45) PMR (Professional Mobile Radio/Private Mobile Radio) — a dispatching network radiotelephone;
46) PMSE (Programme Making and Special Events) — communication systems used in the broadcasting
or production of radio or television programmes or used for real-time transmission of audiovisual
information, in particular during mass events, sporting events or performances;
47) RLAN — Radio Local Area Network;
48) RFID — Radio Frequency Identification;
49) TTT — Transport and Traffic Telematics;
50) SSB-AM — the single-band emission of amplitude modulated signal;
51) TDD — Time Division Duplex;
52) TDMA — Time Division Multiple Access;
53) EU — the European Union;
54) UESFSS — Uncoordinated Earth Stations of the Fixed-Satellite Service (Earth-to-space);
55) UMTS — Universal Mobile Telecommunications System;
56) UWB — Ultra Wideband;
57) VSAT (Very Small Aperture Terminals) — subscriber stations in a fixed satellite radio service
equipped with small aperture antennas;
58) WAS — Wireless Access System;
59) EC — the European Community.
§ 3. 1. An authorisation is not required for the usage of the following equipment:
1) functioning as terminal equipment on mobile land-based radio communications networks where
publicly available telecommunications services are not provided;
2) which are the end points of telecommunications network in the Point to MultiPoint system (PMP);
3) with an interface enabling the connection, cooperation and exchange of information by radio between
the base station and the telecommunications terminal equipment operating in the mobile or fixed
public telecommunications network by:
a) a telecommunications undertaking holding a nationwide frequency license used for the provision
of services through base stations,
b) another undertaking or entity using that interface in the public interest which has concluded a
written contract specifying at least the identification of the equipment, its location, the conditions
of installation and its use in order to avoid harmful interference, relating to that interface, with a
telecommunications undertaking holding a nationwide frequency license used for the provision
of services through base stations;
4) low power base stations operating in the following frequency bands:
a) 791–821 MHz (broadcast) and 832–862 MHz (reception) with power not exceeding 21 dBm
e.r.p.,
b) 876–915 MHz (reception) and 921–960 MHz (broadcasting) with power not exceeding 20 dBm
e.r.p.,
c) 1 710–1 785 MHz (reception) and 1 805–1 880 MHz (broadcasting) with power not exceeding
20 dBm e.r.p.,
d) 1 920–1 980 MHz (reception) and 2 110–2 170 MHz (broadcasting) with power not exceeding
21 dBm e.r.p.,
e) 2 500–2 570 MHz (reception) and 2 620–2 690 MHz (broadcasting) with power not exceeding
21 dBm e.r.p.,
f) 2 570–2 620 MHz (broadcasting and reception) with power not exceeding 21 dBm e.r.p.,
g) 3 400–3 800 MHz (broadcasting and reception) with power not exceeding 24 dBm e.r.p. for each
carrier 20 MHz wide
— used for the provision of services by a telecommunications undertaking holding a frequency
license;
5) intended for use only in the 26.96–27.41 MHz frequency band:
a) of type PR27, meeting the requirements specified in the ETSI EN 300 433 standard,
b) with angular modulation or DSB-AM emission or SSB-AM emission meeting the requirements
of standards introducing the ETSI EN 300 433 standard, where the permissible output power of
an angular modulated transmitter is up to 4 W of carrier wave power, with DSB-AM up to 4 W
of carrier wave power and from SSB-AM up to 12 W of peak envelope power;
6) of close range:
a) of the general application, irrespective of the use or intended use of the equipment referred to in
Annex 1 to the Regulation, used in particular in telemetry, remote control, alarm systems and
data transmission,
b) broadband data transmission systems, including equipment using broadband modulation
techniques to access spectrum, as defined in Annex 2 to the Regulation, used in particular in
wireless access systems such as radio local area networks (WAS/RLANs) or in data broadband
data transmission equipment,
c) used in rail transport, in particular for AVI systems: Eurobalise and Euroloop, as defined in
Annex 3 to the Regulation,
d) for radiodetermination, including equipment used in particular to determine the position, speed
or other characteristics of the object, as defined in Annex 4 to the Regulation,
e) used for model control, including those that use remote control and telemetry, which are used to
remotely control the motion of models in air, on land, in water or underwater, as defined in
Annex 5 to the Regulation,
f) for wireless microphones and hearing aids, whether pinned or worn, professional or intended for
general use, and wireless acoustic equipment, in particular wireless loudspeakers, cordless
headphones, cordless headphones for portable devices, hands-free sets, in-ear listening monitors
used for the transmission of sound at concerts and stage performances, as defined in Annex 6 to
the Regulation,
g) for RFID purposes, used in tag- and interrogator-based radio communication systems as defined
in Annex 7 to the Regulation,
h) wireless, used for the health care purposes, constituting a radio component of active implantable
medical devices within the meaning of the Medical Devices Act of 20 May 2010 (OJ of 2021,
item 1565), as defined in Annex 8 to the Regulation,
i) for inductive applications, where such equipment uses a magnetic field with inductive loop
systems for proximity communication, as defined in Annex 9 to the Regulation,
j) using ultra-wideband technology, based on technical solutions for short-range radio
communications intended to generate and emit radio wave energy in the frequency band
exceeding 50 MHz as defined in Annex 10 to the Regulation;
7) automotive short-range radars, the use conditions of which are laid down in Annex 11 to the
Regulation;
8) terrestrial satellite stations, the types of which are specified in Annex 12 to the Regulation;
9) base stations used for the provision of MCV services, located on board vessels, for which the
conditions of use are laid down in Annex 13 to the Regulation;
10) base stations used for the provision of MCA services, located on board aircraft for which the
conditions of use are laid down in Annex 14 to the Regulation;
11) of the close range operating in the 874–874.4 MHz and 916.1–919.4 MHz frequency bands, for which
the conditions of use are laid down in Annex 15 to the Regulation;
12) used in PMSEs for which the conditions of use are laid down in Annex 16 to the Regulation;
13) operating in the 29.7 MHz–3 GHz frequency band in underground mining excavations with power not
exceeding 500 mW e.r.p. deeper than 100 m below ground level and at a distance of no less than
100 m from a vertical shaft tunnel.
2. The equipment referred to in paragraph 1 shall not cause harmful interference to the operation of
other equipment. The equipment referred to in paragraph 1(5)–(13) shall not be protected against harmful
interference caused by other equipment.
3. The equipment referred to in paragraph 1(1)–(7) and (9)–(13) is used in terrestrial
radiocommunications services. The equipment referred to in paragraph 1(8) is used in satellite
radiocommunications services.
4. The territory of the Republic of Poland is the area of use of the equipment referred to in
paragraph 1(1)–(9), (12) and (13). The area of use of the equipment referred to in paragraph 1(6)(j), (9) and
(10) shall be, respectively, the deck of the vessel or aircraft on which the network access service is offered
with which the equipment may operate.
§ 4. The Regulation of the Minister of Administration and Digitisation of 12 December 2014 on
broadcasting or broadcasting and receiving radio equipment which may be used without a radio
authorisation is repealed (OJ of 2017, item 96).
§ 5. This Regulation shall enter into force 30 days after its publication.
THE MINISTER OF DIGITALISATION
Certified for legal,
legislative and editorial compliance
Aleksandra Wrochna
Deputy Director of the Legal Department
in the Chancellery of the Prime Minister
Annexes
to the Regulation of the Minister of
Digitisation
of........... (item …)
Annex 1
SHORT-RANGE EQUIPMENT OF GENERAL USE
Maximum
radiated power or
Channel
Frequency band maximum Duty cycle Notes
spacing
magnetic field
strength
24.00–24.15 GHz 100 mW e.i.r.p. [-] [-] Applies to the
equipment that meets
the requirements laid
down in the standard
introducing the ETSI EN
300 440 standard.
The range is also
designed for ISM
equipment. Equipment
functioning in this
range accepts harmful
interferences, which
may occur during the
operation of the ISM
equipment.
Annex 2
SHORT-RANGE EQUIPMENT FOR BROADBAND DATA TRANSMISSION SYSTEMS
Maximum power
radiated or Channel
Frequency band Duty cycle Notes
maximum magnetic spacing
field strength
5 150– 200 mW e.i.r.p3) [-] [-] The use of equipment is
5 350 MHz permitted only inside the
premises.
It is obligatory to use the
techniques to access the
radio spectrum and to
mitigate harmful
interference of a
performance level at least
equivalent to those laid
down in harmonised
standards adopted pursuant
to Directive 2014/53/EU of
the European Parliament
and of the Council of
16 April 2014 on the
harmonisation of the laws of
the Member States relating
to the making available on
the market of radio
equipment and repealing
Directive 1999/5/EC (OJ EU L
153, 22.5.2014, p. 62 and OJ
EU L 212, 22.8.2018, p. 1).
Equipment operating in the
range of 5 250–5 350 MHz
shall use transmitter power
control which ensures an
attenuation coefficient of at
least 3 dB at the maximum
permissible output power of
the systems. If the
transmitter power control is
not used, the maximum
permissible e.i.r.p. average
and corresponding average
e.i.r.p. density limits at
5 250–5 350 MHz shall be
reduced by 3 dB.
Equipment operating in the
range of 5 250–5 350 MHz
3) Average e.i.r.p. — equivalent isotopic radiated power during transmission that corresponds to the highest power if power control is used.
shall use interference
mitigation techniques that
provide at least protection
consistent with the
detection, operation and
response requirements
described in ETSI EN 301 893
to ensure compatible
operation with radar
systems. Such mitigation
techniques compensate for
the probability of selecting a
specific channel from all
available channels so as to
ensure as uniform spread of
spectrum loading as
possible.
The maximum average
density power e.i.r.p. is
limited to 10 mW/MHz in
each 1 MHz band. This
applies to the equipment
that meets the requirements
laid down in the standard
introducing the ETSI EN
301 893 standard.
Annex 3
SHORT-RANGE EQUIPMENT USED IN RAIL TRANSPORT
Maximum radiated
power or maximum Channel
Frequency band Duty cycle Notes
magnetic field spacing
strength
27.09–27.10 MHz 42 dBA/m [-] [-] Applies to the magnetic field
strength measured at a
distance of 10 m.
Applies to remote power or
downlink transmission for
track balise, in particular in
the Eurobalise system.
This range can be optionally
used by inductive loop
activation devices, in
particular in the Euroloop
system.
The centre frequency is
27.095 MHz.
Applies to equipment that
meets the requirements laid
down in the standard
introducing the
ETSI EN 300 330
and ETSI EN 302 608
standards.
Annex 4
SHORT-RANGE RADIOLOCATION EQUIPMENT
Maximum
radiated power or
Channel
Item Frequency band maximum Duty cycle Notes
spacing
magnetic field
strength
Applies to the magnetic
field strength measured
at a distance of 10 m
from the NMR
equipment at the
frequency of 100 Hz.
Above 100 Hz, the
magnetic field strength
decreases by 10 dB per
1 100 Hz–148 kHz [-] [-] decade.
46 dBμA/m
In the case of the NMR
equipment, the tested
object is placed inside
the enclosure of the
NMR equipment.
This application does not
include nuclear magnetic
resonance imaging and
tomography systems.
Only applicable to
ground and wall probe
see: see: radars. Applies to the
30–12 400 MHz see: Decision Decision Decision equipment that meets
2
ECC/DEC/(06)08 ECC/DEC/( ECC/DEC/(0 the requirements of the
06)08 6)08 standard introducing the
ETSI EN 302 066
standard.
Applies to power
density. Conditions of
use apply only to the
filling level probe radar.
7 dBm/50 MHz The exclusion zones
peak power e.i established around radio
r.p. astronomical facilities
3 6 000–8 500 MHz and [-] [-] shall not be affected.
-3 dBm/1 MHz Automatic power control
average power and antenna
e.i r.p. requirements, as well as
requirements for
spectrum access and
harmful interference
mitigation techniques
shall be applied in order
to ensure the adequate
compliance with the
essential requirements
of Directive 2014/53/EU
of 16 April 2014 on the
harmonisation of the
laws of the Member
States relating to the
making available on the
market of radio
equipment and repealing
Directive 1999/5/EC (OJ
EU L 153, 22.5.2014, p.
62 and OJ EU L 212,
22.8.2018, p. 1).
Where relevant
restrictions are specified
in harmonised standards
(or parts thereof) the
references of which have
been published in the
Official Journal of the
European Union on the
basis of
Directive 2014/53/EU,
performance at least
equivalent to those
limitations shall be
ensured.
4 9 200–9 500 MHz 25 mW e.i.r.p. [-] [-] Applies to the
equipment that meets
the requirements of the
standard introducing the
ETSI EN 300 440
standard.
5 9 500–9 975 MHz 25 mW e.i.r.p. [-] [-] Applies to equipment
that meets the
requirements of the
standard introducing the
ETSI EN 300 440
standard.
6 10.5–10.6 GHz 500 mW e.i.r.p. [-] [-] Applies to equipment
that meets the
requirements of the
standard introducing the
ETSI EN 300 440
standard.
7 13.4–14.0 GHz 25 mW e.i.r.p. [-] [-] Applies to equipment
that meets the
requirements of the
standard introducing the
E
TSI EN 300 440 standard.
8 24.05–24.25 GHz 100 mW e.i.r.p. [-] [-] Applies to equipment
that meets the
requirements of the
standard introducing the
ETSI EN 300 440
standard.
9 24.05–26.5 GHz 26 dBm/50 MHz [-] [-] Applies to power
peak power density. Conditions of
e.i.r.p. use apply only to the
and -14 dBm/1 M filling level probe radar.
Hz average power The exclusion zones
e.i.r.p. established around the
radio astronomy
premises shall
not be affected.
Automatic power control
and antenna
requirements, as well as
the requirements for
spectrum access and
mitigation of harmful
interference mitigation
techniques shall be
applied in order to
ensure the adequate
compliance with the
essential requirements
of Directive 2014/53/EU
of the European
Parliament and of the
Council of 16 April 2014
on the harmonisation of
the laws of the Member
States relating to the
making available on the
market of radio
equipment and repealing
Directive 1999/5/EC (OJ
EU L 153, 22.5.2014, p.
62 and OJ EU L 212,
22.8.2018, p. 1). Where
relevant restrictions are
specified in harmonised
standards (or parts
thereof) the references
of which have been
published in the Official
Journal of the European
Union on the basis of
Directive 2014/53/EU,
performance at least
equivalent to those
limitations shall be
ensured.
10 75–85 GHz 34 dBm/50 MHz [-] [-] Applies to power
peak power density. Conditions of
e.i.r.p. use apply only to the
and -3 dBm/1 MH filling level probe radar.
z average power The exclusion zones
e.i.r.p. established around the
radio astronomy
premises shall
not be affected.
Automatic power
control and antenna
requirements, as well as
the requirements for
spectrum access and
mitigation of harmful
interference mitigation
techniques shall be
applied in order to
ensure the adequate
compliance with the
essential requirements
of Directive 2014/53/EU
of the European
Parliament and of the
Council of 16 April 2014
on the harmonisation of
the laws of the Member
States relating to the
making available on the
market of radio
equipment and repealing
Directive 1999/5/EC (OJ
EU L 153, 22.5.2014, p.
62 and OJ EU L 212,
22.8.2018, p. 1). Where
relevant restrictions are
specified in harmonised
standards (or parts
thereof) the references
of which have been
published in the Official
Journal of the European
Union on the basis of
Directive 2014/53/EU,
performance at least
equivalent to those
limitations shall be
ensured.
Annex 5
CLOSE-RANGE EQUIPMENT FOR MODEL CONTROL
Maximum
radiated power or
Ite Frequency band or maximum Channel
Duty cycle Notes
m frequency magnetic field spacing
strength
1 34.995–35.225 MHz 100 mW e.r.p. 10 kHz [-] Applies to the control of flying
models.
Applies to equipment that
meets the requirements of the
standard introducing the ETSI
EN 300 220 standard.
2 40.665 MHz; 100 mW e.r.p. 10 kHz [-] Applies to equipment that
40.675 MHz; meets the requirements of the
40.685 MHz; standard introducing the ETSI
40.695 MHz EN 300 220 standard.
Frequencies are also designed
for the ISM equipment. The
equipment operating on these
frequencies accepts harmful
interference that may occur
during the operation of ISM
equipment.
Annex 6
CLOSE-RANGE EQUIPMENT FOR THE WIRELESS MICROPHONES, HEARING AID DEVICES AND WIRELESS
AUDIO PMSE EQUIPMENT
Maximum
radiated power or Duty cycle
Ite maximum Channel
Frequency band Notes
m magnetic field spacing
strength
1 100 Hz–9 kHz 120 dBμA/m [-] [-] Applies to the magnetic field
strength measured at a
distance of 10 m.
Applies to inductive loop
systems used in hearing
impaired aid systems. The
maximum antenna size shall
not exceed 1/20 λ.
The size of the antenna is
determined by the
maximum distance between
any two points placed on the
antenna (e.g. for a rectangle-
shaped antenna it is its
diagonal and for an antenna
in a circular shape it is its
diameter).
2 29.7–47.0 MHz 10 mW e.r.p. 50 kHz [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment in line
with the requirements of the
ETSI EN 300 422 standard.
The 40.66–40.70 MHz sub-
range is also designed for
ISM equipment. Equipment
operating in this sub-range
accepts harmful interference
that may occur during the
operation of ISM equipment.
3 169.4–172.0 MHz 10 mW e.r.p. ≤ 50 kHz [-] Applies to hearing aid
equipment.
Applies to equipment in line
with the requirements of the
ETSI EN 300 422 standard.
4 174–216 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to the equipment
that meets the requirements
of the standard introducing
ETSI EN 300 422 standard.
5 470–694 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
6 694–703 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
The equipment shall not be
used after 1 July 2022.
7 703–733 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
The equipment shall not be
used after 1 July 2022.
8 733-758 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
The equipment shall not be
used after 1 July 2022.
9 758–786 MHz 50 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
The equipment shall not be
used after 1 July 2022.
10 786-789 MHz 12 mW e.r.p. [-] [-] Applies to equipment with
fine-tuning of the service
range.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 422 standard.
The equipment shall not be
used after 1 July 2022.
Annex 7
SHORT-RANGE RFID IDENTIFICATION EQUIPMENT
Frequency band Maximum radiated Channel Duty cycle Notes
power or spacing
maximum
magnetic field
strength
2 446–2 454 MHz 4 W e.i.r.p. [-] 15% The width of the main beam
of the antenna in the
horizontal plane shall not
exceed 90 degrees ( 45
degrees) and the
attenuation of the side lobes
shall be at least 15 dB.
Operation with a level of
radiated power e.i.r.p.
greater than 500 mW is
allowed only inside buildings
and only if the duty cycle
does not exceed 15% in any
200 ms period. When power
greater than 500 mW is
used, the FHSS spectrum
dissipation mechanism shall
be used.
Any RFID equipment, the
power of which may exceed
500 mW, shall be equipped
with an automatic power
control system to reduce
radiation power below
500 mW in cases when the
equipment is transported
and used outside the user’s
building or premises. The
level of each emission,
determined by the value of
the electric field strength
produced by RFID
equipment located inside a
building, measured outside
the building at a distance of
10 m, shall not exceed the
equivalent value of the
electric field strength
produced by a 500 mW RFID
equipment located outside
the building and measured
outside the building at the
same distance. If a building
consists of several premises,
measurements are carried
out from up to the limits of
the premises inside the
building.
Applies to equipment that
meets the requirements of
the standard introducing the
ETSI EN 300 440 standard.
The range is also designed
for ISM equipment.
Equipment functioning in
this range accepts harmful
interferences, which may
occur during the operation
of the ISM equipment.
Annex 8
SHORT-RANGE WIRELESS EQUIPMENT USED FOR HEALTH CARE PURPOSES
Maximum
radiated power or
Ite Channel
Frequency band maximum Duty cycle Notes
m spacing
magnetic field
strength
1 12.5–20 MHz -7 dBµA/m in the [-] ≤ 10% Applies to the magnetic
10 kHz band field strength measured at
a distance of 10 m.
Applies to animal implants.
These conditions of use
apply only to indoor
equipment.
Applies to equipment that
meets the requirements of
the standards introducing
the ETSI EN 300 330
standard.
The equipment shall not be
used after
31 December 2022.
2 2 483.5–2 500 MHz 10 mW e.i.r.p. 1 MHz ≤ 10% Applies only to the active
medical devices of small
implantable power.
External peripherals can be
used indoor only.
It is obligatory to use the
techniques to access the
radio spectrum and to
mitigate harmful
interference of a
performance level at least
equivalent to those laid
down in harmonised
standards adopted
pursuant to
Directive 2014/53/EU of the
European Parliament and of
the Council of 16 April 2014
on the harmonisation of the
laws of the Member States
relating to the making
available on the market of
radio equipment and
repealing
Directive 1999/5/EC (OJ EU
L 153, 22.5.2014, p. 62 and
OJ EU L 212, 22.8.2018, p.
1).
Applies to equipment that
meets the requirements of
the standard introducing
the ETSI EN 301 559
standard.
3 2 483.5–2 500 MHz 1 mW e.i.r.p. ≤ 3 MHz ≤ 10% Only medical network
sensors placed on or in the
patient’s body and used in
healthcare facilities.
It is obligatory to use the
techniques to access the
radio spectrum and to
mitigate harmful
interference of a
performance level at least
equivalent to those laid
down in harmonised
standards adopted
pursuant to
Directive 2014/53/EU of the
European Parliament and of
the Council of 16 April 2014
on the harmonisation of the
laws of the Member States
relating to the making
available on the market of
radio equipment and
repealing
Directive 1999/5/EC (OJ EU
L 153, 22.5.2014, p. 62 and
OJ EU L 212, 22.8.2018, p.
1).
Applies to equipment that
meets the requirements of
the standard introducing
the ETSI EN 301 559
standard.
4 2 483.5–2 500 MHz 10 mW e.i.r.p. ≤ 3 MHz ≤ 2% Applies only to the medical
network sensors placed on
or in the patient’s body and
used in the patient’s home.
It is obligatory to use the
techniques to access the
radio spectrum and to
mitigate harmful
interference of a
performance level at least
equivalent to those laid
down in the harmonised
standards adopted
pursuant to
Directive 2014/53/EU of the
European Parliament and of
the Council of 16 April 2014
on the harmonisation of the
laws of the Member States
relating to the making
available on the market of
radio equipment and
repealing
Directive 1999/5/EC (OJ EU
L 153, 22.5.2014, p. 62 and
OJ EU L 212, 22.8.2018, p.
1).
Applies to equipment that
meets the requirements of
the standard introducing
the ETSI EN 301 559
standard.
Annex 9
CLOSE-RANGE EQUIPMENT FOR INDUCTIVE APPLICATIONS
Maximum
radiated power or Duty cycle
maximum Channel
Frequency band Notes
magnetic field spacing
strength
100 Hz–9 kHz 82 dBμA/m [-] [-] Applies to magnetic field
strength measured at a
distance of 10 m. Applicable
to <1/20 λ antenna.
The size of the antenna is
determined by the
maximum distance between
any two points placed on the
antenna (e.g. for a rectangle-
shaped antenna it is its
diagonal and for an antenna
in a circular shape it is its
diameter).
Annex 10
CLOSE-RANGE EQUIPMENT USING UWB TECHNOLOGY
The conditions of use of the equipment, in particular the frequency bands, regulatory limits such as
maximum power spectral density (e.i.r.p.) or maximum peak power (e.i.r.p.) measured in the 50 MHz
band and requirements for mitigation techniques, as well as the area of use of this equipment shall comply
with Commission Implementing Decision (EU) 2019/785 of 14 May 2019 on the harmonisation of radio
spectrum for equipment using ultra-wideband technology in the Union and repealing
Decision 2007/131/EC (OJ EU L 127, 16.5.2019, p. 23).
Annex 11
THE CONDITIONS OF USE OF AUTOMOTIVE SHORT-RANGE RADAR EQUIPMENT
The conditions of use of equipment, in particular the frequency bands, maximum radiated power or
maximum magnetic field strength and area of use of the equipment, shall comply with the conditions of
use of radio equipment as defined in Commission Decision 2005/50/EC of 17 January 2005 on the
harmonisation of the 24 GHz radio spectrum band for the time-limited use by automotive short-range
radar equipment in the Community (OJ EU L 21, 25.1.2005, p. 15 and OJEU L 295, 14.11.2017, p. 75).
The 24 GHz band may be used by automotive short-range radar equipment installed only in motor vehicles
for which an application for type-approval has been submitted in accordance with Article 6(6) of
Directive 2007/46/EC of the European Parliament and of the Council of 5 September 2007 establishing a
framework for the approval of motor vehicles and their trailers, and of systems, components and separate
technical units intended for such vehicles (OJ EU L 263, 9.10.2007, p. 1, as amended4)) and type-approval
granted before 1 January 2018.
Under Article 7 of Commission Decision 2005/50/EC, in order to protect radio astronomy stations
operating in the 22.21–24.00 GHz radio spectrum band, the following exclusion zones shall be established
where the use of 24 GHz short-range radar is prohibited:
1) in Krakow — the zone around the Astronomical Observatory of the Jagiellonian University, the
centre of which is defined by the following geographical coordinates 19E49‘36“and 50N03’18”
as set out in the WGS-84 reference system, with a radius of 1 km;
2) in Piwnice near Toruń, a zone around the Astronomy Centre of Nicolaus Copernicus University,
the centre of which is defined by the following geographical coordinates 18E33‘30“and
52N54’48” as set out in the WGS-84 reference system, with a radius of 1 km.
4)
Amendments to this Directive were announced in OJ EU L 292, 31.10.2008, p. 1, OJ EU L 35, 4.2.2009, p. 1 and 32, OJ EU
L 118, 13.5.2009, p. 13, OJ EU L 188, 18.7.2009, p. 1, OJ EU L 200, 31.7.2009, p. 1, OJ EU L 320, 5.12.2009, p. 36, OJ EU
L 339, 22.12.2009, p. 60, OJ EU L 72, 20.3.2010, p. 17, OJ EU L 110, 1.5.2010, p. 1, OJ EU L 53, 26.2.2011, p. 4, OJ EU L
167, 25.6.2011, p. 1, OJ EU L 185, 15.7.2011, p. 30 and 76, OJ EU L 28, 31.1.2012, p. 24, OJ EU L 126, 15.5.2012, p. 15,
OJ EU L 353, 21.12.2012, p. 1 and 31, OJ EU L 47, 20.2.2013, p. 51, OJ EU L 55, 27.2.2013, p. 9, OJ EU L 65, 8.3.2013, p.
1, OJ EU L 158, 10.6.2013, p. 172, OJ EU L 43, 13.2.2014, p. 12, OJ EU L 47, 18.2.2014, p. 1, OJ EU L 69, 8.3.2014, p. 3,
OJ EU L 158, 27.5.2014, p. 131, OJ EU L 315, 1.11.2014, p. 3, OJ EU L 9, 15.1.2015, p. 1, OJ EU L 28, 4.2.2015, p. 3, OJ
EU L 123, 19.5.2015, p. 77, OJ EU L 308, 25.11.2015, p. 11, OJ EU L 175, 7.7.2017, p. 1 and 708, OJ EU L 192, 24.7.2017,
p. 1, OJ EU L 349, 29.12.2017, p. 1, OJ EU L 301, 27.11.2018, p. 1, OJ EU L 58, 26.2.2019, p. 1, OJ EU L 95, 4.4.2019, p.
1, OJ EU L 44, 18.2.2020, p. 43 and OJ EU L 263, 12.8.2020, p. 1.
Annex 12
TYPES OF EARTH STATION EQUIPMENT
1. The use of the following types of Earth stations shall not be subject to authorisation:
1) LEST type, operating in accordance with ECC Decision of 24 March 2006 on Exemption
from Individual Licensing of low e.i.r.p. Satellite Terminals (LEST) operating within the
frequency bands 10.70–12.75 GHz or 19.70–20.20 GHz Space-to-Earth and 14.00–
14.25 GHz or 29.50–30.00 GHz Earth-to-Space (ECC/DEC/(06)02), approved on
24 March 2006, the general conditions of use of which are specified in list 1,
2) of the HEST type operating in accordance with ECC Decision of 24 March 2006 on
Exemption from Individual Licensing of High e.i.r.p. Satellite Terminals (HEST) with e.i.r.p.
above 34 dBW operating within the frequency bands 10.70–12.75 GHz or 19.70–
20.20 GHz space-to-Earth and 14.00–14.25 GHz or 29.50–30,00 GHz Earth-to-space
(ECC/DEC/(06)03), approved 24 March 2006, amended 8 March 2019, the general
conditions of use of which are specified in list 2,
3) of the AES type, operating in accordance with ECC Decision ‘The free circulation and use
of Aircraft Earth Stations (AES) in the frequency bands 14.0–14.5 GHz (Earth-to-space),
10.7–11.7 GHz (space-to-Earth) and 12.5–12.75 GHz (space-to-Earth)’ (ECC/DEC/(05)11),
approved on 24 June 2005, amended on 8 March 2019, the general conditions of use of
which are specified in list 3,
4) of the ESV type operating in accordance with ECC Decision on the free circulation and use
of Earth Stations on board Vessels (ESV) operating in fixed satellite service networks in the
frequency bands 14–14.5 GHz (ECC/DEC/(05)10), approved on 24 June 2005, amended on
8 March 2019, the general conditions of use of which are specified in list 4,
5) of the HDAFSS type operating in accordance with ECC Decision on the availability of
frequency bands for high density applications in the Fixed-Satellite Service (space-to-Earth
and Earth-to-space), (ECC/DEC/(05)08) approved on 24 June 2005, amended on
8 March 2013, the general conditions of use of which are specified in list 5,
6) of the UESFSS type operating in accordance with ECC Decision on the use of the band
27.5–29.5 GHz by the Fixed Service and uncoordinated Earth stations of the Fixed-Satellite
Service (Earth-to-space) (ECC/DEC/(05)01), approved on 18 March 2005, amended on
18 March 2019), the general conditions of use of which are specified in list 6,
7) of the NGSO FSS type operating in accordance with ECC Decision(17)04 ‘The harmonised
use and exemption from individual licensing of fixed earth stations operating with NGSO
FSS satellite systems in the frequency bands 10.7–12.75 GHz and 14.0–14.5 GHz’,
approved on 30 June 2017, amended on 8 March 2019, the general conditions of use of
which are specified in list 7,
8) of the ESOMP type operating in accordance with ECC Decision (13)01 ‘The harmonised
use, free circulation and exemption from individual licensing of Earth Stations On Mobile
Platforms (ESOMPs) within the frequency bands 17.3–20.2 GHz and 27.5–30.0 GHz’,
approved on 8 March 2013, amended on 26 October 2018, the general conditions of use
of which are specified in list 8,
9) of the NGSO ESOMP type operating in accordance with ECC Decision (15)04 ‘The
harmonised use, free circulation and exemption from individual licensing of Land,
Maritime and Aeronautical Earth Stations On Mobile Platforms (ESOMPs) operating with
NGSO FSS satellite systems in the frequency bands 17.3–20.2 GHz, 27.5–29.1 GHz and
29.5–30.0 GHz’, approved on 3 July 2015, amended on 20 November 2020, the general
conditions of use of which are specified in list 95,
10) of the type GSO ESIM operating in accordance with ECC Decision (18)04 ‘The harmonised
use, exemption from individual licensing and free circulation and of use of land based Earth
Stations In-Motion (ESIM) operating with GSO FSS satellite systems in the frequency bands
10.7–12.75 GHz and 14.0–14.5 GHz’, approved on 6 July 2018, the general conditions of
use of which are specified in list 10,
11) of the type NGSO ESIM operating in accordance with ECC Decision (18)05 ‘The
harmonised use, exemption from individual licensing and free circulation and use of Earth
Stations In-Motion (ESIM) operating with NGSO FSS satellite systems in the frequency
bands 10.7–12.75 GHz and 14.0–14.5 GHz’, approved on 6 July 2018, the general
conditions of use of which are specified in list 11,
12) of the type VSAT operating according to ECC Decision (03)04 on Exemption from
Individual Licensing of Very Small Aperture Terminals (VSAT) operating in the frequency
bands 14.25–14.50 GHz Earth-to-space and 10.70–11.70 GHz space-to-Earth, approved on
5) The list also includes ECC Decision (05)01 The use of the band 27.5–29.5 GHz by the Fixed Service and uncoordinated Earth
stations of the Fixed-Satellite Service (Earth-to-space), approved on 18 March 2005, amended on 8 March 2019.
17 October 2003, amended on 8 March 2019, the general conditions of use of which are
specified in list 12
— except that the powers specified in the lists are peak powers.
2. If the antenna is coupled to more than one transmitter or the transmitter produces more
than one carrier wave, e.i.r.p. specified in lists 1–12 is the sum of the power of all emissions
radiated by the main beam of the antenna.
List 1
LEST equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.25 GHz
space) 29.50–30.00 GHz
2 Receiving frequency band(space-to-Earth) 10.70–12.75 GHz 1)
19.70–20.20 GHz
3 Acceptable e.i.r.p. Lower than or equal to 34 dBW
1) Use of the 10.70–11.70 GHz reception frequency band is associated with the risk of harmful interference from fixed service point-to-point
(radio lines) equipment operating on the basis of radio licensing.
List 2
HEST equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.25 GHz
space) 29.50–30.00 GHz
2 Receiving frequency band(space-to-Earth) 10.70–12.75 GHz1)
19.70–20.20 GHz
3 Acceptable e.i.r.p. Higher than 34 dBW and lower than or equal to 60 dBW
4 Additional restrictions For isotropically radiated replacement power (e.i.r.p.)
higher than 34 dBW, the requirements that ensure
compliance with the aircraft HIRF security criteria shall
be met using maximum field strength of 190 V/m at
14.00–14.25 GHz and 150 V/m at 29.50–30.00 GHz.
HEST equipment operating at maximum e.i.r.p. power on
TDMA networks are allowed to operate after the work
cycle has been taken into consideration.
1) Use of the 10.70–11.70 GHz reception frequency band is associated with the risk of harmful interference from fixed service point-to-point
(radio lines) equipment operating on the basis of radio licensing.
List 3
AES equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.50 GHz
space)
2 Receiving frequency band (space-to-Earth) 10.70–11.70 GHz1)
12.50–12.75 GHz
3 Acceptable e.i.r.p. Lower than or equal to 50 dBW
4 Additional restrictions AES stations may be used if the following conditions are
met:
1) are authorised by the administration of the country in
which the aircraft is registered;
2) comply with the requirements of the ETSI EN 302 186
standard;
3) comply with Recommendation ITU-R M.1643, including
the essential requirements for the protection of the
standing corps (FS) and the shared use of ranges by the
radio astronomy service (RAS) and AES stations, taking
into account the requirements contained in the Annexes
to Decision ECC/DEC/(05)11;
4) operate under the control of the network control
system.
1) The use of the frequency band 10.70–11.70 GHz for reception is associated with the risk of harmful interference from fixed point-to-point
(radio lines) equipment operating on the basis of issued radio authorisations.
List 4
ESV equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.50 GHz
space)
2 Receiving frequency band (space-to-Earth) 10.70–11.70 GHz1)
12.50–12.75 GHz
3 Acceptable e.i.r.p. [-]
4 Additional restrictions ESV stations operating in a fixed satellite service may be
used when the following conditions are met:
1) they are compliant with Resolution 902 (WRC-03);
2) they are compliant with the requirements of the ETSI EN
302 340 standard;
3) they are equipped with an antenna of 0.6 m or more;
4) they operate under the control of the network control
system;
5) the ESV network operator controlling the transmissions
of the ESV station has notified the competent authority and
provided the required contact and technical details.
1) Use of the 10.70–11.70 GHz reception frequency band is associated with the risk of harmful interference from fixed service point-to-point
(radio lines) equipment operating on the basis of radio licensing.
List 5
HDAFSS equipment
Ite Specification Frequency bands, technical parameters
m
1 Broadcasting frequency band (Earth-to- 29.50-30 GHz
space)
2 Receiving frequency band (space-to-Earth) 17.30–17.70 GHz
19.70–20.20 GHz
3. Acceptable e.i.r.p. [-]
4 Additional restrictions The HDAFSS equipment operating in a fixed satellite service
may be used if the following conditions are met:
1) use of frequency bands specified in points 1 and 2 by other
applications within the FSS service or other services for which
these scopes are intended shall not give priority to users of
the same services;
2) the equipment operates in the 17.30–17.70 GHz frequency
band, which remains available for backhaul lines operating
within the BSS service;
3) the additional requirements set out in Decisions
ECC/DEC/(06) 02 and ECC/DEC/(06) 03 for the frequency
bands 19.7–20.2 GHz and 29.5–30.0 GHz have been taken into
account.
List No 6
UESFSS equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 27.5–27.8285 GHz,
space) 28.4445–28.9485 GHz
29.4525–29.5 GHz
2 Receiving frequency band (space-to-Earth) [-]
3 Acceptable e.i.r.p. Lower than or equal to 60 dBW
4 Additional restrictions Non-coordinated Earth stations of the fixed satellite services
broadcasting in the 27.5 to 29.5 GHz band shall comply with
the following requirements:
1) the level of off-axis e.i.r.p. power density spectrum radiated
by any UESFSS Earth station in the frequency bands dedicated
to the fixed service (27.8285–28.4445 GHz, 28.8365–
28.9485 GHz and 28.9485–29.4525 GHz) is limited to
35 dBW/MHz. This limit shall be respected in any case by the
UESFSS radiating at an angle of 3 degrees or less in relation to
the horizontal plane;
2) the antenna elevation angle is higher than 3 degrees;
3) the FSS services using uncoordinated UESFSS stations in the
following frequency bands: 27.5–27.8285 GHz, 28.4445–
28.9485 GHz and 29.4525–29.5 GHz implement automatic
power control or automatic satellite gain control mechanisms
at these stations;
4) the UESFSS stations shall not use frequencies closer than
10 MHz to the edge of the band used by the fixed service;
5) to ensure compliance with the HIRF security criteria, a
maximum HIRF field strength of 150 V/m shall be applied for
the aircraft;
6) UESFSS type equipment operating with maximum e.i.r.p.
power on TDMA networks is allowed to operate after a work
cycle has been taken into account.
List 7
NGSO FSS equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.50 GHz
space)
2 Receiving frequency band (space-to-Earth) 10.70–12.75 GHz 1)
3 Acceptable e.i.r.p. Lower than or equal to 60 dBW
4 Additional restrictions For compliance with the HIRF security criteria, a maximum
HIRF field strength of 190 V/m in the range 14.00-14.5 GHz
shall be applicable for the aircraft.
Earth stations operating with maximum e.i.r.p. power on
TDMA networks are allowed to operate after the work cycle
has been taken into consideration.
1)
Use of the 10.70–11.70 GHz reception frequency band is associated with the risk of harmful interference from fixed service point-to-point (radio lines) equipment operating on the basis of radio licensing.
List No 8
ESOMP equipment
Item Specification Frequency bands, technical parameters and the equipment
area of use
1 Broadcasting frequency band (Earth-to- 27.5–27.8285 GHz,
space) 28.4445-28.9485 GHz,
29.4525–30.00 GHz
2 Receiving frequency band (space-to- 17.30–20.20 GHz
Earth)
3 Acceptable e.i.r.p. 1) the maximum e.i.r.p. power of ESOMP equipment installed
on aircraft operating within the aerodrome boundaries,
including on the ground, is equal to 58.4 dBW;
2) the maximum e.i.r.p. power of ESOMP land-based
equipment operating within the aerodrome is limited to
52.4 dBW;
3) the maximum e.i.r.p. power of ESOMP equipment not
covered by points 1 and 2, outside the airport or on seagoing
ships, is limited to 60 dBW.
4 Additional restrictions The ESOMP equipment operating in the 17.3–19.7 GHz and
27.5–29.5 GHz frequency bands shall additionally meet the
following requirements:
1) on the territory of a given state the level of off-axis e.i.r.p.
power density spectrum radiated by any ESOMP Earth station
in the frequency bands dedicated to the fixed service (27.8285–
28.4445 GHz, 28.8365–28.9485 GHz and 28.9485–29.4525 GHz)
is limited to 35 dBW/MHz. This limit shall be respected in any
case by equipment operating on ESOMP platforms on land, in
territorial waters or in internal waters, radiating at an angle of 3
degrees or less in relation to the horizontal plane;
2) ESOMP stations shall not use frequencies closer than 10 MHz
to the edge of the band used by the fixed service;
3) the elevation angle of the antenna is higher than 3 degrees;
4) for ESOMP terminals installed on the aircraft, the PFD values
(dB (W/m2) in the reference width of 14 MHz) on the ground
are as follows:
-124.7 for 0° ≤ ≤ 0.01°
–120.9+ 1.9 log10() for 0.01° < ≤ 0.3°
–116.2 + 11.0 log10() for 0.3° < ≤ 1.0°
–116.2 + 18.0 log10() for 1.0° < ≤ 2.0°
–117.9 + 23.7 log10() for 2.0° < ≤ 8.0°
-96.5 for 8.0° < ≤ 90.0°
where () is the angle of incidence on the Earth surface
(degrees).
The PFD values above are not defined for conditions ‘in the free
space’. Therefore, when assessing the compliance of the
ESOMP terminal with the PFD mask, atmospheric absorption
and any attenuation caused by the design of the aircraft should
be taken into account;
5) for ESOMP terminals installed on seagoing vessels, the
threshold PFD value equals -109 dB (W/m2) at a reference
bandwidth of 14 MHz at an altitude of 20 metres above sea
level during the run-off;
6) to ensure the compliance with the PFD requirements set out
in points 4 and 5, ESOMP terminals shall be equipped with self-
control functions and automatic mechanisms (local or under
the control of the NCF) to reduce their e.i.r.p. or stop
transmission.
List No 9
NGSO ESOMP equipment
Item Specification Frequency bands, technical parameters and the equipment
area of use
1 Broadcasting frequency band (Earth-to- 27.5–27.8285 GHz,
space) 28,4445-28.8365 GHz,
29.5–30.00 GHz
2 Receiving frequency band (space-to- 17.30–20.20 GHz
Earth)
3 Acceptable e.i.r.p. 1) the maximum e.i.r.p. power for ESOMP stations operating on
aircraft within aerodromes is limited to 58.4 dBW;
2) the maximum e.i.r.p. power for ESOMP stations operating on
land within aerodromes is limited to 52.4 dBW;
3) the maximum e.i.r.p. power for ESOMP stations operating on
land outside the aerodromes is limited to 70 dBW;
4) the maximum e.i.r.p. power for ESOMP stations on seagoing
vessels is limited to 70 dBW.
4 Additional restrictions 1) the e.i.r.p. density level outside of the direction of maximum
radiation for each ESOMP station in the fixed service frequency
bands (27.8285–28.4445 GHz and 28.9485-29.1 GHz) is limited
to -35 dBW/MHz. This limit shall be respected in any case by
ESOMP equipment on land, in territorial waters or in internal
waters, radiating at an angle of 3 degrees or less in relation to
the horizontal plane;
2) ESOMP stations shall not use frequencies closer than 10 MHz
to the edge of the band used by the fixed service;
3) the antenna elevation angle is higher than 3 degrees;
4) for ESOMP stations installed on seagoing vessels, the
threshold value of the PFD is -109 dB(W/m2) with the reference
bandwidth of 14 MHz at an altitude of 20 metres above sea
level during drainage;
5) for ESOMP stations installed on aircraft, the PFD values at the
reference 14 MHz bandwidth on the surface of the Earth are as
follows:
-124.7 for 0° ≤ δ ≤ 0.01°
-120.9+ 1.9 log10(δ) for 0.01° < δ ≤ 0.3°
-116.2+ 11.0 log10(δ) for 0.3° < δ ≤ 1.0°
-116.2+ 18.0 log10(δ) for 1.0° < δ ≤ 2.0°
-117.9 + 23.7 log10(δ) for 2.0° < δ ≤ 8.0°
-96.5 for 8.0° < δ ≤ 90.0°
where () is the angle of incidence on the Earth surface
(degrees);
6) to ensure the compliance with the PFD requirements set out
in point 4, ESOMP terminals shall be equipped with self-control
functions and automatic mechanisms (local or under the
control of the NCF) to reduce their e.i.r.p. or stop transmission.
List 10
GSO ESIM equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.50 GHz
space)
2 Receiving frequency band (space-to- 10.70–12.75 GHz 1)
Earth)
3 Acceptable e.i.r.p. Lower than or equal to 54.5 dBW
1)
Use of the 10.70–11.70 GHz reception frequency band is associated with the risk of harmful interference from fixed service point-to-point (radio lines) equipment operating on the basis of radio licensing.
List 11
NGSO ESIM equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.00–14.50 GHz
space)
2 Receiving frequency band (space-to- 10.70–12.75 GHz1)
Earth)
3. Acceptable e.i.r.p. Lower than or equal to 54.5 dBW.
4 Additional restrictions 1. for the 14.25–14.5 GHz frequency band, the PFD thresholds
set out in points 2–4 shall apply in order to protect the systems
of the fixed service;
2) for ESIM installed on aircraft, the threshold values for PFD on
the ground are as follows:
-122 dB(W/(m² • MHz)) for ≤ 5°
–127 + dB(W/(m² • MHz)) for 5° < ≤ 40°
–87 dB(W/(m² • MHz)) for 40° < ≤ 90°
where is the radio wave angle (degrees above the horizontal
plane);
3) for ESIM terminals installed on seagoing vessels, the threshold
value of PFD is -116 dBW/m2/MHz at an altitude of 80 meters
above sea level during drainage;
4) for onshore ESIM terminals, the threshold value of PFD is -
116 dBW/m2/MHz at an altitude of 30 meters above ground
level;
5) for the 14.47–14.5 GHz frequency band, ESIM terminals
installed on aircraft shall be capable of ceasing emissions when
they are in the direct visibility of a RAS station carrying out
observations in that frequency band;
6) for the 14.47–14.5 GHz frequency band, the PFD thresholds
set out in points 7 and 8 shall not be exceeded;
7) for ESIM terminals installed on seagoing vessels, the threshold
PFD of -169 dBW/m2/(150 kHz) shall not exceed for more than
for 2% of the time;
8) for onshore ESIM terminals, the threshold PFD of -
169 dBW/m2/(150 kHz) shall not exceed for more than for 2% of
the time;
9) ESIM terminals have self-control functions and automatic
mechanisms (locally or under the control of NCF) to reduce their
e.i.r.p. or stop transmission.
1)
The use of 10.70–11.70 GHz for the reception frequency band is associated with the risk of harmful interference from fixed point-to-point (radio lines) equipment operating on the basis of radio licensing.
List 12
VSAT equipment
Item Specification Frequency bands, technical parameters
1 Broadcasting frequency band (Earth-to- 14.25–14.50 GHz
space)
2 Receiving frequency band (space-to- 10.70–11.70 GHz1)
Earth)
3 Acceptable e.i.r.p. Lower than or equal to 50 dBW
4 Additional restrictions For compliance with the HIRF security criteria, a maximum HIRF
field strength of 190 V/m in the range 14.25-14.5 GHz shall be
applicable for the aircraft.
Earth stations operating with maximum e.i.r.p. power on TDMA
networks are allowed to operate after the work cycle has been
taken into consideration.
VSAT equipment shall comply with the requirements of the ETSI
EN 301 428 standard.
1)
The use of 10.70–11.70 GHz for the reception frequency band is associated with the risk of harmful interference from fixed point-to-point (radio lines) equipment operating on the basis of radio licensing.
Annex 13
CONDITIONS OF USE OF BASE STATION EQUIPMENT USED FOR THE PROVISION OF MCV SERVICES ON
BOARD VESSELS
Conditions for the use of GSM, UMTS and LTE equipment on board vessels, in particular the frequency
bands they use, maximum radiated power or maximum magnetic field strength, the area of use of this
equipment, comply with the conditions of use of radio equipment as laid down in Commission
Decision 2010/166/EU of 19 March 2010 on harmonised conditions of use of radio spectrum for mobile
communication services on board vessels (MCV services) in the European Union (OJ EU L 72, 20.3.2010,
p. 38 and OJ EU L 26, 3.2.2017, p. 63).
Annex 14
CONDITIONS OF USE OF BASE STATION EQUIPMENT USED FOR THE PROVISION OF MCA SERVICES ON
BOARD AIRCRAFT
Conditions for the use of GSM, UMTS and LTE equipment on board aircraft, in particular the frequency
bands they use, maximum radiated power or maximum magnetic field strength, the area of use of this
equipment, comply with the conditions of use of radio equipment as laid down in Commission
Decision 2008/294/WE of 7 April 2008 on harmonised conditions of spectrum use for the operation of
mobile communication services on aircraft (MCA services) in the Community (OJ UE L 98 of 10.4.2008, p.
19, OJ UE L 303 of 14.11.2013, p. 48 and OJ UE L 345 of 20.12.2016, p. 67).
Annex 15
CONDITIONS OF USE OF SHORT-RANGE EQUIPMENT OPERATING IN FREQUENCY BANDS OF 874–
874.4 MHz AND 916.1–919.4 MHz
Conditions for the use of short-range equipment operating in the 874–874.4 MHz and 916.1–919.4 MHz
frequency bands, in particular the frequency bands they use, the maximum radiated power or the
maximum magnetic field strength and the area of use of these devices, shall be compliant with the
conditions of use of radio equipment as defined in Commission Implementing Decision (EU) 2018/1538 of
11 October 2018 on the harmonisation of radio spectrum for short-range devices within the 874–876 MHz
and 915–921 MHz frequency bands (OJ UE L 257 of 15.10.2018, p. 57).
These conditions apply to short-range equipment of general use, radio frequency identification (RFID)
equipment and broadband data equipment.
Annex 16
CONDITIONS OF USE OF PMSE EQUIPMENT
The conditions of use of PMSE equipment, in particular the frequency bands used by it, their maximum
radiated power or maximum magnetic field strength and their area of use are compliant with the
conditions of use of radio equipment set out in Commission Implementing Decision 2014/641/EU of
1 September 2014 on harmonised technical conditions of radio spectrum use by wireless audio
programme making and special events equipment in the Union (OJ EU L 263, 3.9.2014, p. 29) and
Commission Implementing Decision (EU) 2016/339 of 8 March 2016 on the harmonisation of the 2 010–
2 025 MHz frequency band for portable or mobile wireless video links and cordless cameras used for
programme and special events (OJ EU L 63, 10.3.2016, p. 5).
German Federal
Network Agency
Federal Network Agency for Electricity,
Gas, Telecommunications, Post and
Railway
__________________________________________
Technical Guideline
for the implementation of legal measures for the
surveillance of telecommunications
and the disclosure of information
(TR TKÜV) *
Edition 8.0
As at: Draft
Editor and publisher:
Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway
Telecommunications and Postal Services Security Unit, technical implementation of surveillance
measures
Canisiusstraße 21
55122 Mainz
Germany
* Notified in accordance with Directive (EU) 2015/1535 of the European Parliament and of the Council of 9 September 2015 laying
down a procedure for the provision of information in the field of technical regulations and of rules on Information Society services
(OJ L 241, 17.9.2015, p. 1).
TR TKÜV, edition 8.0 (draft) Page 3
Table of contents
1 Scope of regulation ....................................................................................................6
2 Content of the present edition of the Technical Guideline.........................................6
3 Definitions ..................................................................................................................6
4 Normative references ................................................................................................7
Part A Technical implementation of legal measures for the surveillance of telecommunications ... 12
1 Basic principles ....................................................................................................... 13
2 Structure ................................................................................................................. 13
3 Fundamental requirements ..................................................................................... 14
4 Other requirements ................................................................................................. 21
Annex A Fundamental stipulations concerning data transmission........................................ 24
Annex A.1 FTP and TCP/IP specifications ............................................................................... 25
Annex A.2 Stipulations regarding participation in a VPN ......................................................... 28
Annex A.3 Transmission of HI1 and additional events............................................................. 30
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s
lines......................................................................................................................... 38
Annex B (Deleted: Transmission point for circuit-switched networks (national)) .................. 39
Annex C Provisions for PSTN and ISDN (ETSI ES 201 671 and TS 101 671) ............................... 40
Annex C.1 Selection of options and stipulation of additional technical requirements .............. 42
Annex C.2 Explanations of the ASN.1 descriptions ................................................................. 45
Annex D Specifications regarding mobile telephony networks and mobile-based IMS
platforms (3GPP TS 33.108 and TS 33.128).......................................................... 46
Annex D.1 Selection of options and stipulation of additional technical requirements .............. 48
Annex D.2 Explanations of the ASN.1 descriptions ................................................................. 55
Annex E Transmission point for storage systems for voice, facsimile and data (voicemail
systems, Unified Messaging Systems, etc.) ........................................................... 56
Annex E.1 Definitions ............................................................................................................... 56
Annex E.2 General explanations .............................................................................................. 56
Annex E.3 Basic forwarding methods and determination of relevant events ........................... 57
Annex E.4 Requirements for surveillance of voice and fax messages and SMS according to
Annexes B, C or D .................................................................................................. 60
Annex E.5 Requirements for surveillance of voice and fax messages, SMS and MMS in an
XML-encoded file .................................................................................................... 61
Annex F Stipulations for storage systems for the email service ........................................... 65
Annex F.1 Definitions, fundamentals ....................................................................................... 65
Annex F.2 Nationally specified email transmission point ......................................................... 66
Annex F.3 Email transmission point according to ETSI TS 102 232-02 (from Version 2.1.1) . 71
Annex G Stipulations regarding the internet gateway (ETSI TS 102 232-03, 102 232-04 and
TS 101 909-20-2) .................................................................................................... 75
Annex G.1 Selection of options and stipulation of additional technical requirements .............. 76
Annex G.2 Explanations of the ASN.1 descriptions ................................................................. 79
Annex H Determinations for VoIP, other fixed multimedia services and fixed network IMS platforms
(ETSI TS 102 232-05, -06 and 101 909-20-1) ........................................................ 80
TR TKÜV, edition 8.0 (draft) Page 4
Annex H.1 Fundamental requirements for use of ‘Service-specific details for IP multimedia
services´ (TS 102 232-05 and TS 101 909-20-1) ................................................... 81
Annex H.2 Fundamental requirements for use of ‘Service-specific details for
PSTN/ISDN services’ (ETSI TS 102 232-06) ......................................................... 82
Annex H.3 Selection of options and stipulation of additional technical requirements .............. 82
Annex H.3.1 Basis: ETSI TS 102 232-01 .................................................................................... 82
Annex H.3.2 Basis: ETSI TS 102 232-05 .................................................................................... 85
Annex H.4 Explanations of the ASN.1 descriptions ................................................................. 88
Annex I Provisions for messaging services (ETSI TS 103 707 and ETSI TS 102 232-02) . 90
Part B Technical implementation of legal measures for the disclosure of information ...... 92
1 Basic principles ....................................................................................................... 93
2 Transmission methods ETSI-ESB and Email-ESB ................................................ 93
3 Guaranteeing data security and data quality .......................................................... 94
Annex A ETSI-ESB transmission method ............................................................................. 98
1.1 Basic description of the procedure ......................................................................... 98
1.2 Procedural requirements ........................................................................................ 99
1.3 Specifics of the different applications ................................................................... 100
1.4 Secure electronic transmission of the surveillance order ..................................... 106
2 Provisions for the transmission point according to ETSI specification TS 102 657
.............................................................................................................................. 107
2.1 Selection of options for ETSI TS 102 657 ............................................................ 107
2.2 Supplementary technical requirements for the interface specification under ETSI
TS 102 657 ........................................................................................................... 109
3 Definition of national parameters .......................................................................... 113
3.1 General ................................................................................................................. 113
3.2 Description of the national XML module ‘Natparas2’ (for requests) ..................... 114
3.3 Description of the national XML module ‘Natparas3’ (for responses) .................. 119
3.3.2 Specification of additional data in the national XML module Natparas3 .............. 120
4 Transmission of accounting information and submitting claims for compensation
pursuant to § 23(1) of the German Judicial Remuneration and Compensation Act
.............................................................................................................................. 124
4.1 Basic principles ..................................................................................................... 124
4.2 Methods of electronic transmission ...................................................................... 124
4.3 Description of the national XML module ‘Natparas2’ (for accounting data) ......... 124
Annex A.1 Explanatory notes on the procedure ..................................................................... 126
Annex A.1.1 Fundamental flow of communication ................................................................... 126
Annex A.1.2 Stipulations regarding participation in the IP VPN using a cryptobox ................. 130
Annex B Email-ESB transmission procedure ...................................................................... 132
1. Basic description of the procedure ....................................................................... 132
Part X Informative Annex ................................................................................................. 134
Annex X.1 Proposed changes to the TR TKÜV ..................................................................... 135
Annex X.2 Assignment of identifiers for authorised agencies to ensure uniqueness of
reference numbers................................................................................................ 138
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal
Network Agency, Department IS16 (Policy) ......................................................... 139
TR TKÜV, edition 8.0 (draft) Page 5
1 General ................................................................................................................. 139
2 Services provided by the TKÜV-CA ..................................................................... 139
3 Requirements for participants ............................................................................... 140
4 Rules for registration............................................................................................. 140
5 Rules for certification ............................................................................................ 141
6 Disabling a smart card .......................................................................................... 144
7 Revocation of certificates...................................................................................... 144
8 Distribution and handling of smart cards .............................................................. 145
9 Card content ......................................................................................................... 145
10 Management of cryptoboxes/selection of options ................................................ 146
11 Selection of options/values ................................................................................... 147
12 Other applicable documents ................................................................................. 148
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1
modules ................................................................................................................ 149
Annex X.5 Standard concept for the preparation of verification documents, test records and
test reports for verification testing ......................................................................... 151
Updates .............................................................................................................................. 152
Edition list .............................................................................................................................. 152
TR TKÜV, edition 8.0 (draft) Page 6
1 Scope of regulation
On the basis of § 170(6) Telecommunications Act (Telecommunications Act) [21] in conjunction with § 36
TKÜV (Order on monitoring telecommunications) [14], the Technical Guideline (TR TKÜV) describes,
taking into account §§ 9 and 12 TTDSG (Telecommunications and Telemedia Privacy Act) [41] and §
174(7) and § 177(3) Telecommunications Act, technical details for the implementation of legal measures
for the interception of telecommunications and the provision of information.
In accordance with § 170(6) TKÜV in conjunction with § 36 TKÜV, the TR TKÜV is drawn up by the
Federal Network Agency in consultation with the authorised bodies and with the participation of the
associations of obliged entities and the manufacturers of the monitoring facilities and the recording and
evaluation facilities. International standards are to be taken into account, with reasons given for
deviations from the standards. The Technical Guideline is to be published on the website of the Federal
Network Agency; the agency must announce the publication in its official journal.
Amendments to the TR TKÜV to conform with the current state of the art are to be undertaken by the
Federal Network Agency in the same process.
The TR TKÜV can normally define the dates up to which previous technical regulations may still be
applied. It also lays down the types of identifiers for which the prevailing legislation on the surveillance of
telecommunication systems requires additional measures for the technical implementation of orders to be
undertaken in certain types of telecommunication systems in addition to the target and source addresses
used in them. In cases where recent technical developments have not yet been incorporated into the TR
TKÜV, the obligated party shall coordinate the design of his surveillance systems with the Federal
Network Agency.
2 Content of the present edition of the Technical Guideline
The first edition of the Technical Guideline was published in December 1995 as TR FÜV, edition 1.0.
Over the past 20 years, it has been continuously amended in line with fresh legislation and to adapt to
new technological developments; the current 18th edition of the Technical Guideline is published as TR
TKÜV, edition 8.0.
The issue 8.0 differs from its previous version, TR TKÜV, issue 7.2, by formal changes to the references
to the individual obligations under §§ 170 et seq. Telecommunications Act new edition which became
necessary as a result of the entry into force of the amended Telecommunications Act and the
correspondingly adapted TKÜV on 01.12.2021.
The TR TKÜV, edition 8.0, includes the following three Parts A, B and X:
Part A – Technical implementation of legal measures for the surveillance of
telecommunications
This section describes the technical details of the surveillance equipment and the required
technical characteristics of recording lines.
Part B – Technical implementation of legal measures for the disclosure of information
This section contains the technical details of the devices for subscriber and traffic data retrieval,
and particularly the optional procedure for transmission of the copy of the order to implement
such measures.
Part X – Informative Annex
This informative section contains the planned further changes to the TR TKÜV, forming the basis
for a discussion of the next edition, supplementary information relating to Parts A and B of this
edition, regulations for the registration and certification body TKÜV-CA and a history of the
individual editions of the TR TKÜV published so far.
3 Definitions
In addition to the definitions in the TKÜV, the following definitions also apply in this Guideline:
3.1 Content of telecommunications (informational content, content of
communication, CC)
The portion of telecommunication under surveillance containing informational content exchanged
between the subscribers or their end devices (e.g. voice, email or IP traffic).
TR TKÜV, edition 8.0 (draft) Page 7
3.2 Event data (Intercept Related Information, IRI)
Data to be supplied pursuant to § 7 TKÜV on detailed circumstances associated with the
telecommunication under surveillance. These data should also be supplied if the telecommunication
content fails to be transmitted (e.g. on user busy).
3.3 Surveillance copy
Pursuant to § 2 point 14 TKÜV, the copy of the telecommunication under surveillance required to be
transmitted (content of communication and event data).
3.4 internet gateway
The transmission channel which provides direct subscriber access to the internet, as defined in § 2 point
12, in conjunction with § 3(2) point 3, TKÜV.
3.5 Subject’s telecommunication system (STS)
Normally the subject’s (obligated party’s) telecommunication system, in which the telecommunications on
the line under surveillance originates – in the case of outgoing traffic – or terminates – in the case of
incoming traffic (e.g. subscriber switching centre, UMS, email server).
3.6 Transit network
The network through which the surveillance copy (informational content and/or event data) is transmitted
from the obligated party’s telecommunication system to the authorised agency.
3.7 Concept
Documents according to § 170(1) sentence 1 point 4a Telecommunications Act.
4 Normative references
The following table contains the references used in the TR TKÜV:
[1] ETS 300 007 Integrated Services Digital Network (ISDN); Support of packet-mode
(ITU- X.31) terminal equipment by an ISDN
[2] ETS 300 011 ISDN; Primary rate user-network interface, Layer 1 specification and test
principles
[3] ETS 300 012 ISDN; Basic user-network interface, Layer 1 specification and test
principles
[4] ETS 300 090 ISDN; Calling line identification restriction (CLIR) supplementary service;
Service description
[5] ETS 300 094 ISDN; Connected line identification presentation (COLP) supplementary
service; Service description
[6] EN 300 403-1 ISDN; User network interface layer 3, specification for basic connection
control procedures
[7] ETS 300 108 ISDN; Circuit-mode 64 Kbit/s unrestricted 8 kHz structured bearer service
category; Service description
[8] ETS 300 133-X Paging Systems (PS); European Radio Message System (ERMES) Parts 1
-4
[9] ETS 300 136 ISDN; Closed User Group (CUG) supplementary service; Service
description
[10] ETS 300 383 ISDN; File transfer over the ISDN EUROFILE transfer profile
[11] ETS 300 409 ISDN; Eurofile transfer teleservice; Service description
[12] ETS 300 485 ISDN; Use of cause and location in DSS1 and ISUP (ITU-T Rec. Q.850
(1993, modified)
[13] ETS 300 523 European digital cellular telecommunications system (Phase 2);
Numbering, addressing and identification (GSM 03.03)
TR TKÜV, edition 8.0 (draft) Page 8
[14] TKÜV Ordinance on the technical and organisational implementation of measures
for the surveillance of telecommunications (Telecommunications
Surveillance Ordinance [Telekommunikations-Überwachungsverordnung,
TKÜV])
[15] ISO/IEC 8571 File Transfer, Access and Management
[16] ISO/IEC ISP 10607-1 File Transfer, Access and Management; Part 1: Specification of ACSE,
Presentation and Session Protocols for the use of FTAM
[17] ISO/IEC ISP 10607-3 File Transfer, Access and Management; Part 3: Simple File Transfer
Service (unstructured)
[18] ITU-T G.711 Pulse Code Modulation (PCM) of Voice Frequencies
[19] ITU-T H.221 Line Transmission of non-Telephone Signals; Frame Structure for a 64 to
1920 Kbit/s Channel in audiovisual teleservices
[20] ITU-T X.25 Interface between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the packet mode
and connected to public data networks by dedicated circuit
[21] Telecommunications Telecommunications Act [Telekommunikationsgesetz]
Act
[22] ES 201 671/TS 101 Telecommunications security; Lawful Interception (LI); Handover interface
671 for the lawful interception of telecommunications traffic
[23] 3GPP TS 33.108 3G security; Handover interface for Lawful Interception (LI) (ETSI TS 133
108)
[24] RFC 822 Standard for the Format of ARPA internet Text Messages
[25] RFC 2822 internet Message Format
[26] RFC 2045 Multipurpose internet Mail Extensions, (MIME) - Format of internet
Message Bodies
[27] RFC 2060 internet Message Access Protocol - Version 4rev1
[28] RFC 3261 SIP: Session Initiation Protocol. June 2002.
[29] TS 102 232 or Telecommunications security; Lawful Interception (LI); Handover
TS 102 232-01 specification for IP delivery
[30] TS 102 233 or Telecommunications security; Lawful Interception (LI); Service specific
TS 102 232-02 details for email services
[31] TS 102 234 or Telecommunications security; Lawful Interception (LI); Service-specific
TS 102 232-03 details for internet access services
[32] TS 102 815 or Telecommunications security; Lawful Interception (LI); Service-specific
TS 102 232-04 details for Layer 2 Lawful Interception
[33] TS 101 909-20-2 Digital Broadband Cable Access to the Public Telecommunications
Network;
IP Multimedia Time Critical Services;
Part 20: Lawful Interception; Sub-part 2: Streamed multimedia services
[34] TS 102 232-05 Telecommunications security; Lawful Interception (LI); Service specific
details for IP Multimedia Services
[35] TS 102 232-06 Telecommunications security; Lawful Interception (LI); Service specific
details for PSTN/ISDN services
[36] TS 101 909-20-1 Digital Broadband Cable Access to the Public Telecommunications
Network;
IP Multimedia Time Critical Services;
Part 20: Lawful Interception; Sub-part 1: CMS based Voice Telephony
Services
[37] TS 102 657 Telecommunications security; Lawful Interception (LI); Retained data
handling; Handover interface for the request and delivery of retained data
[38] TS 103 120 Lawful Interception (LI); Interface for warrant information
[39] TS 103 707 Lawful Interception (LI); Handover for messaging services over HTTP/XML
[40] 3GPP TS 33.128 Security; Protocol and procedures for Lawful Interception (LI); Stage 3
(ETSI TS 133 128)
TR TKÜV, edition 8.0 (draft) Page 9
[41] TTDSG Law regulating data and privacy protection in telecommunications and
telemedia (Telecommunications and Telemedia Privacy Act
[(Telekommunikation-Telemedien-Datenschutz-Gesetz)])
5 Abbreviations
The following abbreviations are used in the TR TKÜV:
3GPP Third Generation Partnership Project
5G 5th Generation Mobile Network
ASCII American National Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
BA ISDN basic connection [Basisanschluss, BA]
BC Bearer Capability
BMWi Federal Ministry for Economic Affairs and Energy
bS Authorised agency [berechtigte Stelle]
BSI Federal Office for Information Security
BSS Base Station Subsystem
CC Content of Communication
CLIP/R Calling Line Identification Presentation / Restriction
COLP/R Connected Line Identification Presentation / Restriction
CUG Closed User Group
DCF77 ‘Mainflingen’ time code transmitter broadcasting the official time for the Federal Republic
of Germany as produced by the National Metrology Institute of Germany [Physikalisch-
Technische Bundesanstal, PTB] at a frequency of 77.5 kHz
DCS Digital Cellular System
DDI Direct Dialling In
DM Service attribute
DSS1 Digital Subscriber Signalling System No. 1
DTD Document Type Definition
ERMES European Radio Message System
ESB Specification of the electronic interface for information and connection data disclosure
requests and telecommunications surveillance and tracing
ETSI European Telecommunications Standards Institute
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
GLI Global Line Identifier
GLIC GPRS Lawful Interception Correlation
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GUTI Globally Unique Temporary UE Identity
HI Handover Interface
HLC High Layer Compatibility
HTTP HyperText Transfer Protocol
IMAP internet Message Access Protocol
IMEI International Mobile station Equipment Identity
IMPI IP Multimedia Private Identity
IMPU IP Multimedia PUblic Identity
TR TKÜV, edition 8.0 (draft) Page 10
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IN Intelligent network
IP internet Protocol
IPS internet Protocol Stack
IRI Intercept Related Information
ISDN Integrated Services Digital Network
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
LDAP Lightweight Directory Access Protocol
LEA Law Enforcement Agencies
LI Lawful Interception
LLC Low Layer Compatibility
LTE Long Term Evolution
LTMP Local Mail Transfer Protocol
MAP Mobile Application Part
MMS Multimedia Messaging Service
MSC Mobile Switching Centre
MSISDN Mobile Subscriber ISDN Number
MSN Multiple Subscriber Number
NCI NR Cell Identity
NEID Network Element Identifier
NR New radio
OID Object Identifier
PEI Permanent Equipment Identifier
PMXA ISDN primary rate interface
POP3 Post Office Protocol 3
PSTN Public Switched Telephone Network
(analogue telephone network or analogue connections to digital hubs)
PTB National Metrology Institute of Germany
SIP Session Initiation Protocol
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SUB SUBaddressing (supplementary service)
SUCI Subscriber Concealed Identifier
SUPI Subscriber Permanent Identifier
TCP Transport Control Protocol
TFTS Terrestrial Flight Telecommunication System
STS Subject Telecommunication System (TKA-V)
Telecommun Telecommunications Act [Telekommunikationsgesetz]
ications Act
TKÜV Telecommunications Surveillance Ordinance [Telekommunikations-
Überwachungsverordnung]
TTDSG Telecommunications and Telemedia Privacy Act [Telekommunikation-Telemedien-
Datenschutz-Gesetz]
UDI Unrestricted Digital Information
UMS Unified-Messaging-System
UMTS Universal Mobile Telecommunications System
TR TKÜV, edition 8.0 (draft) Page 11
UPT Universal Personal Telecommunication
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTF-8 8-bit Unicode Transformation Format (RFC 3629, ISO 10646)
UTM Universal Transversal Mercator Projection (Coordinates)
VoIP Voice over IP
VoLTE Voice over LTE
VMS Voice Mail System
VPN Virtual Private Network
WGS World Geographic System
XML Extensible Markup Language
ZGS Signalling system
züA Line or identifier under surveillance [zu überwachender Anschluss]
TR TKÜV, edition 8.0 (draft) Part A, page 12
Part A Technical implementation of legal
measures for the surveillance of
telecommunications
TR TKÜV, edition 8.0 (draft) Part A, page 13
1 Basic principles
This Part A of the Technical Guideline (TR TKÜV) describes the technical details of surveillance systems
and the required technical characteristics of recording lines, pursuant to § 170(6) Telecommunications
Act [21], in conjunction with § 36 TKÜV [14].
Finally, it lays down the types of identifiers for which the prevailing legislation on the surveillance of
telecommunication systems requires additional measures for the technical implementation of surveillance
actions to be taken in certain types of telecommunication systems in addition to the target and source
addresses used in them.
In cases where recent technical developments have not yet been incorporated into the TR TKÜV, the
obligated party shall coordinate the design of his surveillance systems with the Federal Network Agency.
2 Structure
Dividing Part A into the following sections assists in the most straightforward possible allocation of the
technical requirement to the various telecommunication systems or services. To this end, the system- or
service-specific requirements (such as for ISDN networks, internet gateways, or servers for the email
service) are described in separate Annexes, which can be used in conjunction with the basic
requirements and others, as a separate description of the requirement for a specific transmission point:
Basic requirements
These requirements apply equally to all transmission points and are presented in Chapters 5 and
6.
Other requirements
Where required, the other regulatory areas mentioned in § 36 TKÜV, in addition to the technical
requirements for transmission points, may be included in the provisions of the TR TKÜV. These
can be found in Chapter 6.
Installation- or service-specific requirements
The exact requirements for the design of the installation- or service-specific transfer points are
included in the respective attachments. Annex A contains provisions on permitted transmission
methods.
2.1 Overview of the installation- and service-specific facilities and the
informative part
This part of the TR TKÜV describes the transmission point for services in landline and mobile networks
(e.g. GSM, UMTS, VoLTE and VoIP), other multimedia services, email and the internet gateway.
The description of the relevant transmission point is given in the following Annexes to the TR TKÜV:
Annex Contents
Annex A.1 The FTP transmission method (file name, parameters)
Annex A.2 Participation in a VPN via a cryptobox
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Annex B This Annex has been deleted; the descriptions can be found in the TR TKÜV editions up to
edition 7.0. Existing implementations according to Annex B shall only be permitted until
31 December 2021 if these were converted to forwarding via FTP. Forwarding via
X.25/X.31 in accordance with this Annex has not been permitted since 1 January 2018.
Circuit-switched networks are subject to the descriptions under Annex C.
Annex C Specifications for circuit-switched fixed-line networks (PSTN and ISDN) according to the
ETSI standard ES 201 671 or the ETSI specification TS 101 671 [22]. This implementation
shall only be permitted until 31 December 2021; between now and then, it must be
converted to forwarding in accordance with Annex H.
Annex D Specifications for mobile networks and mobile-based IMS platforms in accordance with
3GPP Specification TS 33.108 [23] and TS 33.128 [40].
Annex E Provisions for storage systems (UMS, VMS etc.) for voice, fax, SMS, MMS etc. As these
types of systems are not taken into account in the provisions in Annexes A to D, these
requirements may also need to be complied with.
TR TKÜV, edition 8.0 (draft) Part A, page 14
Annex F Specifications for the email service under national requirements or the ETSI specification
TS 102 232-02 [30]
Annex G Specifications for direct subscriber access to the internet according to the ETSI
specifications TS 102 232-03 [31], TS 102 232-04 [32] or TS 101 909-20-2 [33]
Annex H Specifications for VoIP, other multimedia services in landline networks and landline-based
IMS platforms according to ETSI specifications TS 102 232-05 [34], TS 102 232-06 [35] and
TS 101 909-20-1 [36]
Annex I Specifications for messaging services according to ETSI specifications TS 102 232-2 [30]
and TS 103 707 [39]
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex Contents
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of identifiers for authorised agencies to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
3 Fundamental requirements
This Technical Guideline lays down the technical details required to ensure comprehensive recording of
telecommunication under surveillance and to set up appropriate transmission points to the authorised
agencies.
The requirements arising directly from the provisions of the TKÜV must also be complied with.
3.1 Transmission of the surveillance copy
The telecommunication under surveillance is composed of informational content and event data.
Telecommunications should fundamentally also be monitored even when they are rerouted or forwarded
to another target address.
Note:
This requirement applies, for example, to telephony service attributes such as call forwarding or call
deflection, where the connection is forwarded either by the network or the terminal of the LuS. Here,
the surveillance copy should be forwarded to the authorised agency for as long as the forwarded
connection remains. Email messages must also be monitored when automatically forwarded to
another email address of a different mailbox.
When the transmission of an existing telecommunication is individually instigated by the line under
surveillance (LuS) (e.g. by explicit call transfer (ECT)), the transmission of the copy of the
telecommunication to the authorised agency has to cease as soon as the connection between
network and LuS is triggered.
The event data must be compiled and transmitted to the authorised agency in real time, i.e. immediately
after the relevant event (e.g. beginning of a telecommunication, use of a service attribute for data
transmission). Where required, several similar events (e.g. in sequential dialling) may be combined into a
single data set for transmission. Specifically, an event data set with the relevant data should be
transmitted at the start and end of a telecommunication under surveillance, as well as with each event
during the telecommunication (e.g. activities in connection with a service attribute).
Events also include registration/activation operations of service features, insofar as the control of such
operating possibilities takes place directly (e.g. by means of the monitored telephone connection).
In addition to the standard case, i.e. transmission of the informational content together with real-time
transmission of event data, it should be possible, at the request of the authorised agency, in the case of a
particular surveillance action, to transmit only the event data to the authorised agency, but not the copy of
the associated informational content. In this case, no ISDN connections to the authorised agency should
be made when, for instance, monitoring circuit-switched telecommunications.
TR TKÜV, edition 8.0 (draft) Part A, page 15
The connections made for transmission of the surveillance copy should be closed immediately after
successful transmission, i.e. access lines to the authorised agency should not be kept occupied for longer
than necessary.
In transmissions, informational content and associated event data should be labelled such that they can
be unambiguously matched to each other (§ 7(2) TKÜV). To this end, each surveillance action is
assigned a reference number. In addition, individual connections made in the context of a surveillance
action should be assigned an allocation number which is unique for the relevant connection.
In case of difficulties in transmission of the surveillance copy, at least the event data should be
transmitted later (Annex A.4).
3.1.1 General requirements for circuit-switched networks (PSTN and ISDN)
The requirements for the design of the transfer point for PSTN and ISDN are based on Annex C and refer
to the ETSI standard ES 201 671 and the ETSI specification TS 101 671 [22].
To transmit the copy of the informational content, it should be forwarded via the internet (RTP) or dial-up
connections may still be used until 31 December 2021.
In accordance with Annex C, the event data are sent online via FTP in an ASN.1-encoded file.
The special requirements below shall apply when carrying out ISDN-based forwarding under
Annexes C and D (and former Annex B where the forwarding has been converted to FTP): For the
transmission of the copy of the informational content, the STS sets up two transparent dial-up
connections to the authorised agency (circuit mode 64 kbit/s unrestricted, ETS 300 108 [7]),
independent of the service requested by the line under surveillance or its telecommunication partner
upon call origination requests; one of these connections transmits to the technical installations of
the authorised agency a copy of the informational content sent by the LuS, the other a copy of the
informational content sent to the LuS. Thus, transmission to the authorised agency of the copy of the
informational content is separated directionally.
Note: When using the ‘large conference (CONF)’ service attribute, the informational content sent to
the LuS shall be considered to comprise the informational content sent by all the other participants
(sum signal). The copy of the telecommunications sent by the LuS (individual signal of the LuS)
should be transmitted to the authorised agency over the second connection.
If the user information of the LuS language is provided, it must be offered to the authorised entity in
accordance with ITU-T-Recommendation G.711 A-law. Network encodings should be removed.
Note 1: If other technologies are used by the STS to transmit the voice information (e.g. using ‘half
rate speech transcoding’ in GSM), or if compression technology is used to allow multiplexed use of
channels, then the STS should transcode such voice information to an encoding in accordance with
ITU-T Recommendation G.711, A-law [18] for use by the authorised agency.
Note 2: Voice transmission is not only possible in the (3.1-kHz) voice communication service, but
also in other services such as image telephony and 7-kHz voice communication service. Here, the
user’s end device sets up a frame in the 64 kbit/s B channel(s) (e.g. according to
ITU-T Recommendation H.221 [19]), which is then filled with the relevant information (voice, image,
data). This content is not decoded by the STS, but by the technical installations of the authorised
agency.
The connections to the lines of the relevant authorised agency used to transmit the copy of the
informational content should always be created by the STS immediately after detection of the start of
a telecommunication under surveillance, i.e. nearly concurrently with the creation of the connection
to or from the LuS, and closed immediately after detection of the end of the telecommunication under
surveillance.
Note: As an example, the start of an ISDN connection should be taken not as the time when the
called line replies and the content channel is transferred, but already from the start of signalling
(receipt of a SETUP message by the STS for outgoing connections in ISDN or GSM, circuit closure
on the subscriber line in PSTN). Only by creating a connection to the authorised agency early on,
TR TKÜV, edition 8.0 (draft) Part A, page 16
from the start of signalling, can a potential loss of parts of the content at the beginning of the
connection be avoided.
The creation of a connection from the LuS to its telecommunication partner or vice versa should not
be delayed, even if the creation of the connection to the authorised agency is delayed (e.g. due to
repeated connection attempts).
The lines of the STS on which the surveillance copy is transmitted to the authorised agency should
be set up for outgoing connections only on the side of the obligated party. In order to ensure the
transmission of the monitoring copy at any time, the connectors of the authorised entities may only
be operated for future connections.
The lines of the authorised agency should be designed in accordance with the technology used to
transmit the surveillance copy. Where technically possible for the particular type of
telecommunication under surveillance, the telecommunication under surveillance (informational
content and event data) should be directed to the EURO ISDN primary rate interfaces (PRIs) or
EURO ISDN basis lines (BA) according to ETS 300 012 [3] available at the authorised agencies. In
addition, the authorised agency will set up automated answering systems so that the calling phase is
not required for these connections.
The connections used to transmit the copy of the telecommunication under surveillance to the
relevant authorised agency are created by the STS as needed. The creation of the connection is
initiated by the STS. If (a) circuit-switched connection(s) to the authorised agency for the
transmission of the content should fail to be created, three further connection attempts will be
undertaken at intervals of 5 to 10 seconds.
3.1.2 General requirements for mobile networks and mobile-based IMS
platforms
The requirements for designing the transfer point are in accordance with Annex D and refer to the 3GPP
specifications TS 33.108 [23] and TS 33.128 [40].
Existing systems must be converted to TCP-based forwarding in accordance with 3GPP TS 33.108 or
33.128 by 31 December 2021 at the latest. For packet-switched voice services (e.g. VoLTE), combined
forwarding in accordance with 3GPP TS 33.108 or TS 33.128 and ETSI TS 102 232-5 (Annex H) may be
used temporarily.
3.1.3 General requirements for storage systems for voice, fax and data
(voicemail systems, Unified Messaging Systems,...)
If the obligated party offers his customers the option to store messages in voice memory or similar
storage systems associated with the LuS, copies of all messages stored in such systems or retrieved
from them, including the associated event data, should always be transmitted to the authorised agency.
Changes in settings, such as the generation of mailing lists, should also be reported.
Copies of informational content sent from these storage systems to the authorised agency are normally
transmitted to the same target number as the copy of the informational content sent by or to the LuS. If
the technical installations of the STS allow, the authorised agency should have the technical option, for
individual surveillance actions, of directing a copy of the informational content from such storage systems
to a different target number upon request from the authorised agency.
The technical details of the transmission point are contained in Annex E.
3.1.4 General requirements for the email service
Annex F contains two alternative descriptions of a transmission point for surveillance of the email service:
transmission point under national rules pursuant to Annex F.2
transmission point according to ETSI specification TS 102 232-02 [30] pursuant to Annex F.3.
3.1.5 General requirements for the internet gateway
Pursuant to § 3 TKÜV, operators of transmission channels used to provide immediate subscriber internet
access (e.g. internet gateways over xDSL, CATV, WLAN) are required to implement measures for
surveillance of the entire IP traffic.
TR TKÜV, edition 8.0 (draft) Part A, page 17
To ensure this, Annex G comprises three options, based on ETSI specifications for forwarding monitored
IP data in layer 2, layer 3, or based on the IP Cablecom architecture.
3.1.6 General requirements for VoIP and other multimedia services
Annex H addresses services based on the Session Initiation Protocol (SIP) and the Realtime Transport
Protocol (RTP) or the ITU-T standards H.323 and H.248, and also offers a possibility for so-called
emulated PSTN/ISDN services to transmit copies of telecommunications content over RTP instead of
ISDN dial-up connections.
In addition, this Annex addresses multimedia services provided via the IP Cablecom architecture.
3.1.7 General requirements for messaging services
Annex I refers to messaging services provided over the internet. The technical details described in this
Annex, which are necessary to ensure the interception of these telecommunications services, shall
become mandatory after the entry into force of Article 1 (Telecommunications Act) of the Act
implementing Directive (EU) 2018/1972 of the European Parliament and of the Council of 11 December
2018 establishing the European Electronic Communications Code (recast) and modernising
telecommunications law (Telecommunications Modernisation Act) in conjunction with the transitional
period set out in Annex I.
3.2 Standard values
Pursuant to § 5(6) TKÜV, the administration system and capacities for forwarding the surveillance copies
to the authorised agency should be appropriately dimensioned in terms of the number of surveillance
actions expected to be implemented.
Implementing this requirement normally requires monitoring of the available surveillance and forwarding
capacity (interception point to internet transmission point), particularly for bandwidth-based services. In
case of a large difference between the average bandwidth requirement of a connection and the maximum
available bandwidth, a higher level of utilisation of the monitored lines must be taken into account.
The relevant technical and organisational measures shall be described in the concept in accordance with
§ 19(2) point 5 TKÜV.
As a planning aid for initial dimensioning in the area of line provision, based on statistical data under the
assumptions given below, it is recommended allowing for at least the following:
1. that M independent surveillance actions can be simultaneously accommodated; and
2. that at least A of these can have their surveillance copies transmitted to the authorised agencies
at the same time.
Furthermore, any additional requirements should be detected in sufficient time (e.g. when a particular
load level is continuously reached) and the system should be extended accordingly.
The relationship is as follows:
M = a * x 0.45
A=V*M
where: M = number of surveillance actions which can be activated a = system-specific
factor
x = number of potential LuS
A = number of simultaneously transmittable surveillance copies
V = factor incorporating the traffic intensity on the relevant telecommunications
lines
TR TKÜV, edition 8.0 (draft) Part A, page 18
The following assumptions apply to various types of telecommunication system:
a) for circuit-switched fixed networks (ISDN/PSTN) and systems for VoIP and other multimedia
services:
a= 0.75
x= total number of line units (LU), (e.g. analogue subscriber lines or B-channels of an
ISDN Basis or PRI) in a hub.
V= for the traffic intensity on monitored lines, it is recommended to assume three times the
traffic intensity on an average LU in a hub at peak times.
This formula should be applied separately to each hub.
b) for circuit-switched services in mobile telephony networks (GSM and UMTS CS):
a= 0.75
x= total number of mobile lines supporting circuit-switched services.
V= for the traffic intensity on monitored lines, it is recommended to assume three times the
traffic intensity on an average mobile line at peak times.
Example of a switching centre according to letter a)
a = 0.75
x = 5 000 ISDN basis lines = 10 000 B-channels
M = 0.75 * 10.000 0,45
M = 47 surveillance measures which can be activated simultaneously
V = 0.24 if the average traffic intensity is 0.08
A = 0.24 * 47
A = 11 ISDN Basis lines to be simultaneously forwarded (two ISDN stubs each to the authorised agency)
3.3 Actions to provide the complete surveillance copy at the IP-based
transmission point
In accordance with § 5(2) TKÜV, the obliged entity must provide the authorised body with a complete
copy of the telecommunications to be monitored at the handover point. The system must be designed
pursuant to § 8(2) to ensure the quality of the surveillance copy provided at the transmission point is no
poorer than that of the telecommunication under surveillance. In addition to the copy of the
telecommunications to be monitored, the obliged entity must also provide the event data at the handover
point (§ 7 TKÜV).
The obligated party must use suitable precautions to ensure that the data concerned are complete
at the recording point of the copy of the telecommunication and of the event data,
on the transmission channel to the transmission point and
at the transmission point
(e.g. by means of adequate transmission capacity, redundancies, network-typical buffer
mechanisms, selection of the transmission procedure, monitoring of the transmission line, load-
balancing at the incoming delivery function, agreement of the MTU size).
The delivery function here refers to the technical system receiving and processing the internal network
data and making it available at the transmission point.
In the exceptional event that transmission of the data from the recording point to the transmission point is
impossible, the obligated party must transmit the event data later without delay, as is also foreseen under
§ 10 of the TKÜV for the transmission of the data from the transmission point to the recording line. Where
the transmission protocol used on the line allows it (e.g. TCP), at the very least, a short-term buffering at
the recording point is to be provided for the copy of the telecommunication which is orientated to the
availability and load on the transmission line from the recording point up to the input for the delivery
TR TKÜV, edition 8.0 (draft) Part A, page 19
function (DF3). If buffering is not possible (e.g. when using UDP), the transmission line should be
designed (e.g. by adequate dimensioning, redundancies) to ensure peak loads do not lead to loss of data.
Adequate dimensioning of the incoming bandwidth of the delivery function (DF3) is present when the
average data stream measured in 24 hours does not exceed 60 % of the maximum incoming bandwidth.
The incoming bandwidth available in the obligated party’s data network must also not be less than three
times the value of the customer line with the highest bandwidth. This should guarantee that a short-term
rise in bandwidth resulting from high use of a line under surveillance does not result in loss of data.
If the data are multiplied in the event of a multiple forwarding to the delivery function (DF3), the
corresponding additional requirements for processing and transmission capacity must be taken into
account when dimensioning. Otherwise multiple forwarding has to take place in the recording point.
The transmission point is defined in the TR TKÜV in accordance with § 8(1) of the TKÜV. Provision of the
copy of the telecommunication and the event data takes place in a TCP/IP-based transmission point via a
VPN-secured transmission channel to the recording lines of the authorised agency. To secure this
TCP/IP-based transmission, at least the precautions mentioned below must be taken, referring to
forwarding in accordance with Annexes D, G and H (these precautions do not concern the transmission of
IRI by FTP).
3.3.1 Buffering
If, exceptionally, due to transmission problems between the transmission interface of the obligated party
and the authorised agency, it is impossible to transmit the surveillance copy to the recording line, the
transmission must take place immediately afterwards. For these reasons, the surveillance copy may be
buffered (§ 10 sentence 3 of the TKÜV). This kind of buffering must meet the following requirements:
The buffer size must be designed to fulfil a buffer period of 5 minutes. This corresponds to the
downtime until the VPN connection is re-established and also covers peak loads on the
transmission line that may arise in the internal network.
The size of buffer has to be dimensioned to enable the double volume of data transmitted on
average at the transmission point to be buffered.
After the connection is re-established, data from the buffer must be transmitted by the FIFO
principle. The entire data stream is transmitted via a buffer by the FIFO principle. If the maximum
buffer size is reached or the buffer cannot be emptied, the oldest data in the buffer are to be
discarded after no more than 5 minutes. In case data have to be discarded, this will ensure that this
is done in a coherent block.
The buffering must be designed so that the buffer time can be achieved for each TCP connection
created for the authorised agency (independently of the VPN connection) without the buffers of all
connections influencing each other (e.g. the simultaneous utilisation of another buffer in the event
of one buffer being overloaded). The design of a buffer whose size is adjusted dynamically, and
thereby achieves the same target as above, is also made possible, but has to be agreed with the
Federal Network Agency.
3.3.2 Determination of the MTU size
To avoid data packets becoming fragmented, which can result in increased load on the bandwidth, the
relevant packet sizes on the way from creation in the recording point of the obligated party must be
defined up to transmission of the prepared data to the secured transmission channel in such a way that
fragmentation is prevented, particularly at the transmission point to the internet (SINA Box).
The manufacturer Secunet specifies for transmission via the SINA Box an 80-byte overhead; an
additional 30 bytes must be taken into account when using NAT-T and 8 bytes when using PPPoE.
Based on the assumption that these circumstances regularly exist, the rule value for the MTU size of the
delivery function is set to 1380 bytes. However, the obligated party must check whether a lower or higher
MTU size must be set in order to optimise data transmission as well as to reduce fragmentation.
However, the MTU size must not exceed 1420 bytes (1500 bytes of data minus 80 bytes of SINA
overhead). A test (Federal Network Agency, LEMF) in order to also take account of possible
fragmentation in the internal network is urgently recommended. The recording ports of the authorised
agencies must be capable of accepting data packets up to this maximum size of 1420 bytes for the MTU
size.
Where a joint interface is required for linking the network elements under surveillance and the SINA Box,
the respective values need to be harmonised and also agreed with the Federal Network Agency where
relevant.
TR TKÜV, edition 8.0 (draft) Part A, page 20
The same applies if the network element supports jumbo frames because the MTU size used for this
cannot be used no later than between the delivery function and the SINA Box. Although jumbo frames are
supported by the SINA Boxes from version 3.x upwards, this support is currently unnecessary with the
use of the internet as a transport network.
3.3.3 ‘Alive’ test of the availability of the transmission line
In order to monitor the availability of the transmission line between the obligated party and the authorised
agency, an "alive" test must be carried out in accordance with the requirements for the "keep alive" (ETSI
TS 102 232-1). The ‘alive’ test has to be activated for those authorised agencies which require it from the
obligated undertakings. In deviation from the ETSI rules, it must be possible for the authorised agency not
to send a ‘Response’ message. This is necessary because it is not always possible for the authorised
agency to send such messages for security reasons. The obligated party must therefore implement the
following options, which can be configured for each of the monitoring centres of an authorised agency:
The "alive" test is not used if requested by the authorised agency.
The ‘alive’ test is used and is answered by a ‘response’ message from the authorised agency;
The obligated party will acknowledge the lack of a ‘response’ message with a corresponding error
message.
The ‘alive’ test is used and is in principle not answered by a ‘response’ message from the
authorised agency; The evaluation is carried out by the authorised body; the obligated party does
not normally generate a error message. In this case, the authorised agency notifies the obligated
party of the malfunction.
The ‘alive’ test must be carried out independently of any possible forwarding.
The following times must be accounted for:
sending an "alive" test: every 60 minutes,
answering an "alive" test by a "response" message: within 30 seconds,
period during which the obligated party may expect a "response" message after sending an
"alive" test: 60 seconds.
3.3.4 Standardised error messages (HI1 messages)
To achieve improved analysis of the error messages, their content and format are specified as follows:
1. In the event of data loss (where it can be established):
Data losses attributable to an action or connection have to be notified to the authorised agency as
follows:
initial report at start of data loss and at subsequent intervals of 5 minutes as long as the data
loss continues during this interval,
statement of the point in time of the initial loss of data and details of the data loss (quantitative)
since the last message and the total quantity (MByte),
details of the LIID concerned if such information is available,
Format: first missing data: DDMMYYhhmmss; data loss: value; total data loss: value (based on
an existing restriction of the ETSI parameter to 256 places, details of the values in the following
format only: 'DDMMYYhhmmss;value;value', value stands as the placeholder for details of the
data loss in Mbyte as a whole number (integer)).
2. In the case of a missing connection (error in ‘alive’ test)
In the case of missing ‘response’ messages (if this option has been chosen by the authorised agency),
the interval of the ‘alive’ test is reduced to 1 minute. This allows better verification of the continuing
interruption. The error message takes place for the first and last establishment of the interruption with
an indication:
of the time of the first absence of the ‘response’ message,
of the number of ‘response’ messages not received so far,
of optional details of an ID for the sending DF,
Format: first missing response: DDMMYYhhmmss; value missing responses; DF-ID value
(due to an existing restriction on the ETSI parameter to 256 places, details of the values in the
TR TKÜV, edition 8.0 (draft) Part A, page 21
following format only: ‘DDMMYYhhmmss;value;value’, value stands as the placeholder for
details of the responses not received as a whole number (integer) and/or as a placeholder for
details of the DF-ID).
After the connection is restored, the regular interval is used and the counter for the error messages is
reset.
3. In the case of insufficient receiving capacity on the part of the authorised agencies
If the Monitoring Centre (MC) of an authorised agency is incapable of receiving the data stream from
the obligated party’s transmission point in full (e.g. remote terminal with insufficient incoming capacity
to allow it to receive all the data correctly) and therefore causes buffering on the part of the obligated
party, the error message ‘MC is blocking’ has to be sent.
In the event of the complete blocking of the remote terminal, there would be data losses which would
be reported by error messages as in point 1.
Note: The error messages should be evaluated by the authorised agency.
4 Other requirements
In addition to the technical requirements for design of transmission points to authorised agencies, the TR
TKÜV contains other requirements to be complied with in the technical and organisational implementation
of surveillance actions.
4.1 Provisions on identifiers for implementation of surveillance actions
Based on § 36 sentence 6 TKÜV, the provisions below lay down the types of identifiers for which the
prevailing legislation on the surveillance of telecommunication systems requires additional measures for
the technical implementation of surveillance measures to be taken in certain types of telecommunication
systems in addition to the target and source addresses used in them.
Identifiers in landline-based telephony networks and IMS platforms
- Target and source address according to E.164 including service numbers (e.g. 0700)
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
Identifiers in mobile telephony networks and mobile-based IMS platforms
- MSISDN
- IMSI
- IMEI
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
- PEI, SUPI, IMPI, IMPU, 5G-GUTI, GLI (identifiers related to 5G according to 3GPP TS
33.128)
Identifiers for the email service
- Email address according to RFC 822 [24], RFC 2822 [25] (target and source address)
- Access identifier (login name without password, e.g. 'user name', 'phone number', 'email
address') of the mailbox
Identifiers of the internet gateway
- Identifier of the associated telephone line
- Fixed assigned IP address
- User ID allocated to the internet gateway
- MAC address according to the following instructions
- Other title for the transmission channel, e.g. postal identifier (installation address) of the
customer side of the internet connection
Note on cable networks:
Surveillance actions can normally be implemented technically only on the basis of a cable modem
identifier (MAC address). However, a MAC address need not be specified in the surveillance
order if another definable identifier (e.g. identifier of the associated telephone line, system
address) provides equivalent unambiguous identification of the transmission channel. This
obviates the need for issuing a new order in case of replacement of a cable modem.
If the identifier of the associated telephone line is mentioned in the order, organisational
precautions must be taken so that
TR TKÜV, edition 8.0 (draft) Part A, page 22
- without further explanations on the scope of the monitoring measure, only the voice
communication service or
- - where there is a more detailed definition of the scope of surveillance (e.g. "internet access
only" or "telephony service and internet access"), the specific domain can be monitored.
If the cable modem address or installation address is mentioned in the order, organisational
precautions must be taken so that
- without further explanations on the scope of the monitoring measure, the entire connection
with voice communication and internet access service or
- where there is a more detailed definition of the scope of surveillance (e.g. "internet access
only" or "telephony service only") the specific domain can be monitored.
Note for WLAN networks:
If none of the above identifiers is available for a publicly available internet access service via
wireless local area networks (WLAN networks or WLAN hotspots), the identifier of the terminal
relevant for internet access (e.g., MAC address) shall be used in accordance with § 6(3) TKÜV. If
the users of public WLAN networks are not registered users, the number of regularly and
simultaneously connected users (terminal equipment) in the overall access network (i.e., not only
in the respective hotspot) is to be used as a basis for determining the relevant marginal limit
pursuant to § 3(2) TKÜV or to be assessed by corresponding empirical values.
If this type of internet access service is provided by the interaction of two or more
telecommunications installations of one or more operators, reference is made to the provision of §
170(1), first sentence, point 2 Telecommunications Act, after that it must nevertheless be possible
to monitor the service as if the service were provided only by one installation (normal case). The
requirement is based on the assumption that, if necessary, control must be exercised between
installations in order to achieve this objective.
Content that is offered internally within the network by the operator of the WLAN is not affected by
the obligation to monitor the internet access channel. This may, for example, be the landing page
which contains a particular offer of information (internal to the operator) and from which the user
then has the option to download other content from the internet. In this case, only the access to
the internet or the retrieval of restricted services connected over the internet should be capable of
being monitored.
Should the design of the technical equipment only allow the surveillance of the entire offer, in
other words, internal content and access to the internet, this may be tolerated after consulting the
Federal Network Agency.
Implementation of surveillance orders for internet gateways:
In the Federal Network Agency’s view and from the interpretation of the legislation, the
implementation of such actions in relation to unbundled lines typically requires a two-tier
procedure:
1. Request to the supplier of the internet gateway concerning the identity of the operator
responsible and the identifier required for implementation,
2. Issuance of the order to the obligated operator stating the relevant identifier of the internet
gateway (the operation does not have to be the supplier, nor does he have to provide
relevant customer data).
In case the connection is known to be a so-called ‘non-unbundled connection’, the obligated
operator and the DSL transmission channel are unambiguously identified by the telephone
number. In this case, step 1 may be dispensed with.
Identifiers for the VoIP service and other multimedia services based on SIP, H.323 or H.248
in connections with the media stream (e.g. RTP)
- Target and source address according to E.164 including service numbers (e.g. 0700)
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
- H.323 URL, H.323 ID
- Access identifier (login name without password, e.g. ‘user name’, ‘phone number’, SIP-URI)
of the VoIP account
TR TKÜV, edition 8.0 (draft) Part A, page 23
4.2 Transmission procedure for notifications and confirmations of
functional tests for recording and analysis devices used by the
authorised agencies
In accordance with § 23(1)(3) TKÜV, a functional test of recording and analysis devices used by
authorised agencies requires prior notification by the authorised agency and confirmation by the Federal
Network Agency. On the basis of § 23(1) sentence 9 of the TKÜV, the form and transmission procedure
for login and confirmation are set out below:
1. The Federal Network Agency provides the authorised agencies with an electronically editable
form, which after verification and adding of a check note is sent in electronic form to the obligated
party and the requesting authorised agency as a confirmation.
2. The form shall be sent between the authorised agency and the Federal Network Agency and
between the Federal Network Agency and the obligated party using a transmission procedure
stipulated in Part B.
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 24
Annex A Fundamental stipulations concerning
data transmission
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 25
Annex A.1 FTP and TCP/IP specifications
This annex lays down specifications for the FTP and TCP/IP methods of transmission.
ASN.1-encoded sets of event data according to Annex C can still be sent to the authorised agency online
using the FTP protocol until 31 December 2021. Annexes D, E and F contain specifications stating that
the transmission copy is also sent via FTP.
To secure the sets of event data being sent, a VPN shall be used if these are being sent via the internet.
In addition to the FTP transmission method, Annexes C, D, F, G, and H contain requirements for
transmission via TCP/IP. The national stipulations required to this end concerning the port addresses to
be used are contained in the respective Annexes.
Annex A.1.1 File name
Files shall be transported using the FTP transmission method. The format of the file name is essentially
derived from file naming method B of ETSI standard ES 201 671 or ETSI specification TS 101 671 [22];
an identical description is found in the 3GPP Specification TS 33.108 [23].
In case of implementation pursuant to Annex B, the file name may be freely chosen from the fifth position
onwards.
File name according to file naming method B:
<File name> according to the format ABXYyymmddhhmmsseeeet
where:
AB : two ASCII characters as identifier of the obligated party (see note)
XY : two ASCII characters as identifier of the sending mediation function (see note)
yy : two ASCII characters [“00”...“99”] to denote the year (last two digits)
mm : two ASCII characters [“01”...“12”] to denote the month
dd : two ASCII characters [“01”...“31”] to denote the day
hh : two ASCII characters [“00”...“23”] to denote the hour
mm : two ASCII characters [“00”...“59”] to denote the minute
ss : two ASCII characters [“00”...“59”] to denote the second
eeee : four alphanumeric ASCII characters (A-Z, 0-9) to prevent otherwise identical file names during
the same second within a single mediation function; small alphabetic ASCII characters are not
allowed (a-z)
t: one ASCII character to identify the content (see note)
Note on ‘AB’:
The identifiers of the obligated parties are assigned by the Federal Network Agency to prevent duplicates.
The Federal Network Agency assigns this identifier as part of the installation of the surveillance
technology. At the same time, a five-digit operator ID is defined for the obligated party, which is
transmitted as a parameter in the event data (see Annex X.2).
Note on ‘XY’:
File naming method B essentially provides that different sending mediation functions (e.g. two different
FTP clients) of the same obligated party can be distinguished at least by this identifier even if they should
send files with otherwise identical file names to a particular authorised agency.
‘X’ (3rd position of the file name) should essentially be used in accordance with file naming method B to
distinguish between different mediation functions. To this end, the ASCII characters of upper-case letters
A-Z and the numbers 0-9 are available. However, if the obligated party only has a single mediation
function (e.g. operation of a single FTP client for the entire telecommunication system), then a different
value can be used for "X" in consultation with the Federal Network Agency.
However, as it is possible to transmit both ASCII-encoded and ASN.1-encoded files using the FTP
protocol in accordance with the above provision, it is necessary to include a distinguishing criterion in the
file name. This is represented by the selection of a corresponding value for ‘Y’ (4th position of the file
name). In addition, the value used for ‘Y’ can also serve to distinguish between the encodings in the
different ETSI standards or ETSI and 3GPP specifications.
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 26
Table A.1.1-1 below assumes the use of ASN.1 modules with an Object Identifier (OID) used in
accordance with Annex X.4. Table A.1.1-2 applies additionally, but only if ASN.1 modules withoutObject
Identifier (OID) are used, and for older implementations pursuant to Annexes C and D.
‘Y’ (4th Meaning
position)
N Encoding in accordance with existing implementations under Annex B (optional, mandatory for new
implementations from 1 January 2003 and when using FTP as the transfer protocol).
E Encoding pursuant to Annexes C, E, F.3, G and H (mandatory).
ASN.1 or TLV-coded Records according to ETSI standard or ETSI specification.
G Coding in accordance with Annex D (mandatory) ASN.1 or TLV coded records coded in
accordance with 3GPP specification TS 33 108.
X Encoding pursuant to Annex E.5 or F.2 (mandatory).
XML-encoded content of a monitored email.
Table A.1.1-1: Stipulations regarding 'Y' (modules with OID)
‘Y’ (4th Meaning
position)
E Encoding pursuant to Annex C (mandatory).
Individual records encoded according to ETSI standard ES 201 671 or the ETSI specification TS 101
671.
M Encoding pursuant to Annex C (mandatory).
Packetised records in a file encoded according to ETSI standard ES 201 671 or the ETSI
specification TS 101 671.
G Encoding pursuant to Annex D (mandatory).
Individual records encoded according to the 3GPP specification TS 33.108.
U Encoding pursuant to Annex D (mandatory).
Packetised records in a file encoded according to the 3GPP specification TS 33.108.
Table A.1.1-2: Additional stipulations regarding 'Y' (modules without OID)
Note on ‘t’:
The ASCII characters used as values for ‘t’ (21st position of the file name) can be used to identify the
contents of the file. The file may contain the following:
IRI: Event data (Intercept Related Information)
HI1: Administration data; the file type can be freely selected for implementations according to
Annex B
CC(MO): Mobile Originated (MO) Content of Communication (CC) is included for the intercepted
data
CC(MT): Mobile Terminated (MT) Content of Communication (CC) is included for the intercepted
data
CC(MO&MT): Mobile Originated and Terminated (MO&MT) Content of Communication (CC) is
included for the intercepted data
national use: Transmission of event data and informational content according to Annexes E and F
Table A.1.1.-3 below shows the possible values for 't' and their interpretations.
‘t’ (21st position) ‘t’ in binary File contains data in the form:
representation
1 0011 0001 IRI / HI1
2 0011 0010 CC(MO)
4 0011 0100 CC(MT)
6 0011 0110 CC(MO&MT)
8 0011 1000 national use
Table A.1.1-3: Stipulations regarding 't'
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 27
Example of a file name: VPEX06050410431200018
where:
VP : Identifier of the obliged entity (assigned by the Federal Network Agency)
E: identifier for email surveillance (as only a single mediation function (FTP client) is used)
X: XML-encoded content according to Annexes E.5 and F.2
06 : Year 2006
05 : Month May
04 : Day 04
10 : Hour: 10
43 : Minute: 43
12 : Second 12
0001 : Extension 0001 to distinguish file names
8: Transmission of event data and informational content in a file according to Annexes E or F
Annex A.1.2 Parameters
When transmitting over FTP, the obligated party’s system operates as the sender (e.g. as an FTP client)
and the authorised agency’s system as the recipient (e.g. as the FTP server). The parameters (e.g. user
name and password for each FTP account) must be chosen such that they can be pre-assigned by an
obligated party for each recipient at the authorised agency in the preparatory phase of a surveillance
action. This also enables combined transmission of the event data sets for several actions in a single file
to a single FTP account.
The following then applies:
Multiple event records and, where applicable, copies of the useful information to be sent to a
recipient of the same authorised entity may be treated as one file; in the case of ASN.1-encoded
data sets, for instance, this is done in an ‘IRISequence’.
In the context of a connection between the STS and the recipient at an authorised agency, one or
several files may be transmitted if these files are already available in the STS. However, the
connection should be closed immediately after transmission of the files if there are no more data sets
present in the STS at such time.
The FTP servers of the authorised agency should allow files to be overwritten so as to enable
resending of files in case of failure.
Table A.1.2-2 contains the most critical FTP parameters.
FTP parameters Values/stipulations Remarks
document type binary binary
filename Length: 21 positions refer to the stipulations pursuant to
(up to 25 positions in the case of Annex A.1.1
implementations according to Annex B)
Characters: The following ASCII characters are
permitted:
Upper-case letters and numbers (A-
Z, 0-9), no umlauts
LEA user name for each Length: Maximum 8 posts no encryption necessary as VPN used
FTP account at an
authorised agency Characters: Alphanumeric characters (a-z,
A-Z, 0-9), no umlauts
LEA password for each Length: Maximum 8 posts no encryption necessary as VPN used
FTP account at an
authorised agency Characters: Alphanumeric characters (a-z,
A-Z, 0-9), no umlauts.
Special characters ‘.’, ‘%’, ‘*’, ‘!’,
‘?’, ‘@’, ‘#’
Directory change no requirement Directory changes by the FTP client
within the predetermined target directory
are not required
port for data connection 20 (default value)
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 28
FTP parameters Values/stipulations Remarks
port for control 21 (default value)
connection
mode passive mode should be supported The extended passive mode does not
need to be supported by the authorised
entity; i.e. the obliged entity must offer
the “simple” active or passive mode.
Table A.1.2-2: Important parameters for FTP
Annex A.2 Stipulations regarding participation in a VPN
To protect the IP-based transmission point, dedicated cryptoboxes based on the IPSec protocol family
are used to connect the subnetworks of the authorised agencies and obligated parties in a Virtual Private
Network (VPN). To administer the cryptographic keys used for authentication, a Public Key Infrastructure
(PKI) is set up, for which the Federal Network Agency operates as the central certification and registration
authority. In addition, the Federal Network Agency administers the possible security relationships in an
Access Control List (ACL) made available via a directory service.
The cryptoboxes are positioned as dedicated systems in front of the subnetworks of the authorised
agencies and obligated parties which they are intended to protect. These systems ensure authenticity,
integrity and confidentiality.
More extensive mechanisms to protect the transmission point, such as measures against denial of
service attacks on authorised agencies, are only addressed to a limited extent by cryptoboxes and should
be independently resolved by the operator of the relevant subnetworks.
The respective cryptoboxes are, on the part of the authorised body, components of the technical facilities
of the authorised body and, on the part of the obliged entity, components of the obliged entity’s technical
facilities; their planning and operation (e.g. operation of a syslog server), maintenance and
troubleshooting are therefore the responsibility of the operator of the relevant subnetwork.
The requirements for cryptoboxes may need to be updated in future to reflect the current state of the art
in order to ensure continued protection. The relevant extensions (e.g. use of different key lengths) or
necessary short-term changes in the existing implementations in the case of security issues arising later
should be implemented by the operator of the relevant cryptobox within a period laid down for each case
individually — in the context of extensions or updates made available by the manufacturer of the
cryptobox — according to the requirements set by the Federal Network Agency.
Network architecture
The cryptoboxes of the authorised agencies and the obliged entities constitute a meshed network, where
directed security relationships (point-to-point connections) are created between the telecommunication
systems of the obliged entities and the subnetworks of the authorised agencies. Links between obliged
entities are not permitted.
The required cryptographic keys for authentication of the cryptoboxes are created by the Federal Network
Agency and, after registration, stored on the smart card of each cryptobox as supplied by the operators of
the relevant subnetworks. The keys for encrypting the data to be transmitted are generated and updated
independently by the cryptoboxes, so they are not available to anyone involved.
After the cryptoboxes are put into operation, they autonomously set up a secure connection to the
directory service at the Federal Network Agency in order to retrieve the current ACL. Further update
processes for the ACL either take place automatically or are controlled by the Federal Network Agency.
The log data generated by the cryptoboxes (e.g. success of an ACL update, fault) are forwarded to the
log server of the affected obliged entity or the authorised entity concerned in the standard syslog format
(UDP port 514) for further processing.
Design of the internet access or transmission point
To ensure unambiguous addressing of VPN endpoints and of sending and receiving systems on the
connection used to transmit the surveillance copy and the IRI, public IP addresses are used. Where
existing internet structures are used, separate tunnelling should usually be employed to fulfil the security
requirements of § 14 of the TKÜV. However, various different network configurations are possible in
principle.
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 29
These requirements shall be taken into account when describing the design of the internet access and
the transfer point in the context of the concept to be submitted.
Use scenarios and procedures
In normal situations, cryptoboxes are a fixed component of subnetworks and are identified unambiguously
in the ACL, amongst other things by their IP configuration. After registration and key creation, the
directory service is updated.
A list of data needed to administer the ACL, together with a description of the total process (policy), is
made available to all participants in the procedure.
A concept to be submitted by the participant to the Federal Network Agency should mention all the
relevant details (e.g. the proposed IP address for the transmission) to enable the ACL to be maintained
appropriately. This also applies where operators of smaller telecommunication systems make use of
cryptoboxes in so-called pool solutions as referred to in § 21 TKÜV.
Other rules and guidelines
In addition to the above provisions for participation in the VPN, the following normative individual
provisions and guidelines apply:
Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy).
Annex X.3 reflects the situation at the time of publication of this version of the TR TKÜV.
Overview "Description of the overall process for participating in the VPN procedure".
Application for participation in the VPN for the obligated parties and authorised agencies
(registration and technical description of the infrastructure of the subnetwork with IP addresses
and selection of options).
The documents are published on the Federal Network Agency’s website at
http://www.bundesnetzagentur.de/tku
Overview of the cryptoboxes that can be deployed
The cryptoboxes fulfilling the basic technical system and interoperability requirements are listed in the
following table.
No. Manufacturer Product name Contact person
1 secunet Security Networks AG SINA Box Division Public Authorities
Ammonstraße 74 Email:
[email protected]
01067 Dresden Tel.: 0201/5454-0
www.secunet.com
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 30
Annex A.3 Transmission of HI1 and additional events
The international standards and specifications underlying this TR TKÜV describe the transmission and
content of the event data sets to be transmitted.
This also includes the transmission of so-called HI1 event data, which should be transmitted to the
authorised agency upon activation, deactivation and modification of surveillance actions as well as
following alarm signals. This is essentially achieved using the ETSI-specified ASN1 module
‘HI1NotificationOperations’ (ETSI TS 101 671, Annex D.4, Version 3 and up) or the nationally specified
ASN.1 module pursuant to Annex A.3.2. For transmission of the actual identifier involved in the activation
of a surveillance action pursuant to § 5(5) TKÜV, the ASN.1 module ‘HI1NotificationOperations’ has been
extended by a corresponding parameter from Version 6 onwards.
In addition, the national ASN.1 module should be used to transmit the following events, since the
international specifications and standards do not define any parameters for them:
manufacturer-specific services and service attributes (if not covered by the HI2 modules of the
relevant standards or specifications),
events related to activation, deactivation or modification of services and service attributes (e.g.
creation of a mailing list in a UMS by means of web access),
events related to settings for surveillance of the email service when applying ETSI TS 102 232-02
(see Annex F.3).
The ASN1 module ‘HI1NotificationOperations’ and the national ASN.1 module are integrated in different
ways, depending on the standard or specification applied.
Annex A.3.1 Transmission options
The following table explains the basic possibilities for integration of the ASN1 module
‘HI1NotificationOperations’ and the national ASN.1 module:
Standard or Method Note
specification
ES 201 671 / Transmission of the ASN.1 Module Using the ASN.1 module, the above HI1 events can be
TS 101 671 1) 'HINotificationOperations' with the transmitted direct to the authorised agency; it also
integrated parameter contains the parameter ‘National-HI1-ASN1parameters’,
'National-HI1-ASN1parameters' which can also transmit the additional events mentioned
above.
The required specifications are contained in Annex
A.3.2.1.
Transmission of the ASN.1 parameter The ASN.1 parameter enables direct integration of HI1
‘National-HI2-ASN1parameters’ using events and additional events into the HI2 module.
the HI2 module ‘HI2Operations’ The required specifications are contained in Annex
A.3.2.2.
3GPP Transmission of the ASN.1 parameter The ASN.1 parameter enables direct integration of HI1
TS 33.108 1) ‘National-HI2-ASN1parameters’ using events and additional events into the HI2 module. Before
the HI2 module ‘HI2Operations’, which transmission, this HI2-module is imported into the
in turn is imported into the modules relevant UMTS module.
‘UmtsHI2Operations’ and ‘UmtsCS- The required specifications are contained in Annex
HI2Operations’. A.3.2.2.
Transmission of the ASN.1 The ASN.1 parameter enables direct integration of HI1
parameter ‘National-HI3- events and additional events into the HI2 module.
ASN1parameters’ by the HI2 module The required specifications are contained in Annex
‘Umts-HI3-PS’ A.3.2.3.
TS 102 232-01 Import of the entire ASN.1 module By importing the entire module, the above HI1 events
‘HI1NotificationOperations’ by the can be transmitted direct to the authorised agency; in
module ‘LI-PS-PDU’ addition, the HI1 module contains the parameter
‘National-HI1-ASN1parameter’, which can also transmit
the additional events mentioned above.
The required stipulations with regard to the HI1 module
are contained in Annex A.3.2.1
Table A.3-1 Transmission of HI1 and additional events
1) According to ES 201 671/TS101671 or 3GPP TP 33.108, there is also the functional possibility to transmit the
events through the HI2 module ‘HI2Operations’ by means of the ASN.1 parameter ‘National-parameters’. The
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 31
ASN.1 parameter defines an octet string into which the HI1 events and additional events are indirectly incorporated
by means of an additional ASN.1 module. As this method is very time-consuming in terms of programming and
analysis, it may no longer be used in new implementations (see Annex A.3.2.4).
Annex A.3.2 The national ASN.1 module 'Natparas'
This Annex contains the ASN.1 description of the national module 'Natparas' for the transmission of
HI1 events and additional events according to Table A.3-1. If this module is used inside the HI1 module
'HINotificationOperations', the parameters for the HI1 events need only be transmitted once.
As this ASN.1 description is subject to relatively frequent updates with new additional parameters, the
present Annex only reflects the state of affairs at the time of publication of the relevant version of the TR
TKÜV. The Federal Network Agency will coordinate proposed new parameters with the parties involved
and will then update the ASN.1 module. The current version of the ASN.1 description of the national
parameters will be made available for download on the website of the Federal Network Agency after
consultation:
http://www.bundesnetzagentur.de/tku
ASN.1 module ‘Natparas’, Version 8
-- National parameters (Content defined by national law)
-- Version of this ASN.1 specification of the national parameters: '8',
-- to be inserted in the parameter ‘specificationVersion’
-- Newer versions are downward-compatible.
NatParameter
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
Natparas ::= SEQUENCE {
application [0] ENUMERATED
{ hI2-201671 (1),
-- When using the HI2/3 modules of ES 201 671 or TS 101 671
hI2-33108 (2),
-- When using the HI2/3 modules of 3GPP TS 33 108
hI2-101233 (3),
-- When using the HI2/3 modules of TS 102,233 or TS 102 232-3
hI2-101234 (4),
-- When using the HI2/3 modules of TS 102,234 or TS 102 232-3
...,
hi2-102232 (5),
-- When using the transmission method according to TS 102 232 or TS 102 232-1
-- This use comprises tags 3 and 4 and all other HI2/3-modules which
-- are transmitted via TS 102 232 or TS 102 232-1
hi1-201671 (6)
-- When using the HI1 module of ES 201 671 or TS 101 671
} OPTIONAL,
-- This parameter was first introduced in Version 3
-- This parameter is optional for implementations based on Version 1 or 2;
-- This parameter is mandatory for implementations based on Version 3 and above
natVersion [1] SEQUENCE {
country [0] OCTET STRING (SIZE (1..4)),
-- coded in the same format as country codes [EN 300 356-1 to 20]
-- e.g. 49 for Germany
specificationVersion[1] INTEGER (0..255)
},
notification [2] SEQUENCE {
liOperation-type [1] ENUMERATED {
liActivated (1),
liDeactivated (2),
liModified (3)
} OPTIONAL,
-- Not required in conjunction with the HI1 module of TS 101 671,
-- as this provides for an operation-type
alarm indicator [2] Alarm-Indicator OPTIONAL,
-- values for Alarm-Indicator, all characters in ASCII format
-- Not required in conjunction with the HI1 module of TS 101 671,
-- as this provides for an alarm-indicator
li-end [3] TimeStamp OPTIONAL,
-- 'time of expiry of the monitoring order'(liActivated-, liModified-
-- Records)
target [4] OCTET STRING (SIZE (1..256)) OPTIONAL
-- in the format: free ASCII-encoded text
-- actually monitored identifier pursuant to § 5(5) TKÜV
-- optional for reasons of backward compatibility
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 32
} OPTIONAL,
sCIGerman [3] SEQUENCE {
typeOfData [0] SciType OPTIONAL,
sciResult [1] SciResultMode OPTIONAL,
sciData [2] OCTET STRING (SIZE (1..256)) OPTIONAL
} OPTIONAL,
common [4] CommonMode OPTIONAL,
-- moduls of the manufactures
alcatel [5] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
ericsson [6] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
lucent [7] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
nortel [8] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
siemens [9] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
gten [10] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-nokia [20] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-comverse [21] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-motorola [22] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-siemens [23] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-unisys [24] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-ericsson [25] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-nortel [26] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
...,
e-mail-type [100] ENUMERATED
-- In the case of implementations based on Version 5.1 and above of the TR TKÜV
-- this parameter does not need to be used
{
iMAP (1),
webmail (2),
...,
lMTP (3),
iMAPS (4),
sSMTP (5),
pOP3S (6)
} OPTIONAL,
e-mail-add [101] SEQUENCE
{
event [1] Event,
explain [2] Explain,
...
} OPTIONAL
}
-- **************************** Parameter begin **********************
Event ::= ENUMERATED
{
grouplist-create (0),
grouplist-change (1),
grouplist-delete (2),
-- Einstellungen zu Versandlisten
messaging-create (3),
messaging-active (4),
messaging-change (5),
messaging-delete (6),
-- Einstellungen zum Messaging-Dienst
forwarding-create (7),
forwarding-active (8),
forwarding-change (9),
forwarding-delete (10),
-- Einstellungen zum Weiterleitungs-Dienst
email-new (11),
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 33
email-change (12),
email-delete (13),
-- Einstellung zu E-Mail-Addressen
sonstiges (14),
-- This parameter should be used in addition to the above categories whenever a
-- further, different parameter is necessary
...
-- If, when using a messaging or forwarding service, a new setting is indeed
-- activated, only the active event needs to be reported;
}
Explain ::= OCTET STRING (SIZE (1..256))
-- Designation of the chosen settings (parameters)
-- in the format: free ASCII-encoded text
Alarm-Indicator ::= OCTET STRING (SIZE (1 .. 25))
--Provides information about alarms (free format)
-- CC-F:ccc = CC-Link Failure, ccc is the Cause Value of the Release Message
-- as decimal value
-- MD-OFF:DDMMYYhhmm = date and time of failure or power-off of the
-- mediation device (optional)
-- MD-ON:DDMMYYhhmm = date and time of (re)activation of the
-- mediation device (optional)
-- LEMF-IRI-OFF:DDMMYYhhmm = date and time of start of unreaxhability
-- of the LEMF for IRI (optional)
-- LEMF-IRI-ON:DDMMYYhhmm = date and time of (restored) reachability of the
-- LEMF for IRI (optional)
CommonMode ::= SEQUENCE {
inControlled [0] InControlMode OPTIONAL,
-- spvInfo [1] SpvInfoMode OPTIONAL
...
}
InControlMode ::= SEQUENCE {
correlationNumber [0] INTEGER (0..65535) OPTIONAL,
dataContent [1] OCTET STRING (SIZE (1 .. 100))
}
SciType ::= ENUMERATED {
undefined (0),
analogSubscriber (1),
dss1FunctionalProt (2),
dss1KeypadProt (3),
einsTr6FunctionalProt (4),
mobileNetProt (5),
systemSpecific (6)
}
SciResultMode ::= ENUMERATED {
undefined (0),
successful (1),
unsuccessful (2),
rejected (3),
intermediateInfo (4)
}
TimeStamp ::= CHOICE
{
localTime [0] LocalTimeStamp,
utcTime [1] UTCTime
-- TimeStamp wie in ETSI ETS 201 671
}
LocalTimeStamp ::= SEQUENCE
{
generalizedTime [0] GeneralizedTime,
winterSummerIndication [1] ENUMERATED {
notProvided(0),
winterTime(1),
summerTime(2),
...
}
}
END -- Natparas
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 34
Annex A.3.2.1Transmission using the ASN.1 module 'HI1NotificationOperations'
This Annex contains the method for transmission of HI1 and additional events via the ASN.1 module
'HINotificationOperations' from Version 3 onwards. Earlier versions of this module are not permitted as
they do not yet include an OID.
The same description is used if the entire module ‘HI1NotificationOperations’ is imported into the
module ‘LI-PS-PDU’ for the internet gateway as described in Annex G.
HI1NotificationOperations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi1(0)
notificationOperations(1) version5(5)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
OPERATION,
ERROR
FROM Remote-Operations-Information-Objects
{joint-iso-itu-t(2) remote-operations(4) informationObjects(5) version1(0)}
CommunicationIdentifier,
TimeStamp,
LawfulInterceptionIdentifier
FROM HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)
hi2(1) version8(8)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
National-HI1-ASN1parameters ::= SEQUENCE
{
domainID [0] OBJECT IDENTIFIER (hi1OperationId) OPTIONAL,
-- Once using FTP delivery mechanism.
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [67],
-- the country to which the parameters inserted after the extension marker apply.
...,
-- In case a given country wants to use additional national parameters according to
-- its law, these national parameters should be defined using the ASN.1 syntax and
-- added after the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter"
–- are included in the national parameters definition. Vendor identifications can be
-- retrieved from IANA web site (see annex H). Besides, it is recommended to avoid
-- using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import von TR TKÜV, Teil A, Anlage A.3.2
natparas2 [3] Natparas2
-- Import von TR TKÜV, Teil C, Abschnitt 3.2
}
END -- HI1NotificationOperations
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 35
Annex A.3.2.2Implementation in the ASN.1 module ‘HI2Operations’
This Annex contains the implementation in the ASN.1 module ‘HI2Operations’. The same description is
used if the entire module ‘HI2Operations’ is imported into the modules ‘UmtsHI2Operations’ and
‘UmtsCS-HI2Operations’ as described in Annex D.
HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1)
version8(8)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS OPERATION,
ERROR
FROM Remote-Operations-Information-Objects
{joint-iso-itu-t(2) remote-operations(4) informationObjects(5) version1(0)}
UmtsQos,
IMSevent
FROM UmtsHI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2)
threeGPP(4) hi2(1) r6(6) version-5(5)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
IRI-Parameters ::= SEQUENCE
{
domainID [0] OBJECT IDENTIFIER (hi2OperationId) OPTIONAL,
-- for the sending entity the inclusion of the Object Identifier is mandatory
national-HI2-ASN1parameters [255] National-HI2-ASN1parameters OPTIONAL
}
National-HI2-ASN1parameters ::= SEQUENCE
{
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [67],
-- the country to which the parameters inserted after the extension marker apply.
...
-- In case a given country wants to use additional national parameters according to
-- its law, these national parameters should be defined using the ASN.1 syntax and
-- added after the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter"
-- are included in the national parameters definition. Vendor identifications can be
-- retrieved from the IANA web site (see annex H). Besides, it is recommended to
-- avoid using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import von TR TKÜV, Teil A, Anlage A.3.2
natparas2 [3] Natparas2
-- Import von TR TKÜV, Teil C, Abschnitt 3.2
}
END -- HI2Operations
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 36
Annex A.3.2.3Implementation in the ASN.1 module ‘Umts-HI3-PS’
This Annex contains the implementation in the ASN.1 module ‘Umts-HI3-PS’:
Umts-HI3-PS
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2) threeGPP(4)
hi3(2) r6(6) version-3(3)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
GPRSCorrelationNumber
FROM UmtsHI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2)
threeGPP(4) hi2(1) r6(6) version-6(6)}
LawfulInterceptionIdentifier,
TimeStamp
FROM HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1)
version7(7)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
National-HI3-ASN1parameters ::= SEQUENCE
{
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [39],
-- the country to which the parameters inserted after the extension marker apply
...,
-- In case a given country wants to use additional national parameters according to its
-- law, these national parameters should be defined using the ASN.1 syntax and added after
-- the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter" are
-- included in the national parameters definition. Vendor identifications can be
-- retrieved from IANA web site. It is recommended to avoid
-- using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import von TR TKÜV, Teil A, Anlage A.3.2
natparas2 [3] Natparas2
-- Import von TR TKÜV, Teil C, Abschnitt 3.2
}
END-- OF Umts-HI3-PS
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 37
Annex A.3.2.4Transmission using the ASN.1 parameter ‘National-Parameters’
This Annex contains the method for transmission of HI1 and additional events via the ASN.1 parameter
‘National-Parameters’ in the module HI2Operations of ES 201 671/TS 101 671 up to Version 4, or in the
module UmtsHI2Operations up to Version 6.6.0.
The ASN.1 parameter defines an octet string into which the HI1 events and additional events are
indirectly incorporated by means of an additional ASN.1 module. As this method is very time-consuming
in terms of programming and analysis, it has been replaced in the standards and specifications by the
method as described in Annex A.3.2.3, and is therefore no longer available for new implementations.
Explanation using a concrete example:
The data encoded according to the Basic Encoding Rules (BER) should be included after encoding in the
following container, created according to the ASN.1 type
‘National-Parameters::= SET SIZE (1..40) OF OCTET STRING (SIZE (1..256))’
of at most 40 x 256 octets (see also the diagram below).
An example using SIZE (3):
TT L V (see green area)
SET = 'B0 xx
TT L V (see red area)
OCTETSTRING= Y1 ASN.1-encoded national parameter, starting with ‘Natparas::=
‘04 SEQUENCE { ’, where the individual octets are inserted
sequentially:
T('30)LV1 TLV2 TLV3 ... TLVm (also nested)
‘04 Y2 TLVm+1 TLVm+2 TLVm+3…TLVn
‘04 Y3 TLVn+1 TLVn+2 TLVn+3…TLVo
Coding SET SIZE (3) OF
Coding OCTET STRING
Coding of national parameters, beginning with SEQUENCE = '30
Concrete example: Report record upon activation of a surveillance action:
This example shows the content of the national parameter for the event ‘Activation of a surveillance
action- liActivated’ and its embedding into a Report record.
The next line contains the full OCTET STRING of the national parameter, corresponding to the red area
in the above diagram: 30 0E A1 07 80 02 34 39 81 01 01 A2 03 81 01 01
The individual bytes are explained below:
30 0E sequence, length 14 (universal type, constructed)
A1 07 natVersion (context specific type, constructed)
80 02 34 39 country code (context specific type primitive, filled with ASCII code ‘49’)
81 01 01 version-number (context specific type, primitive, integer ‘1’)
A2 03 notification (context specific type, constructed)
81 01 01 liOperation-type (context specific type, primitive, liActivated)
The lines below comprise the entire Report record including the national parameter:
A4 44 97 01 02 81 09 42 4B 41 2D 31 32 33 34 35 A2 09 A1 07 80 05 34 39 31 32 33 A3 15
A0 13 80 0E 32 30 30 32 30 38 30 39 31 35 33 35 31 32 81 01 00 B0 12 04 10 30 0E A1 07
80 02 34 39 81 01 01 A2 03 81 01 01
TR TKÜV, edition 8.0 (draft) Part A, Annex A, page 38
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised
agency’s lines
If the transmission of the monitoring copy to the authorised body is not possible (e.g. due to a malfunction
in the STS transmission facility, overload in the transit network or when the ports of the authorised entity
are occupied), the requirement of § 10 TKÜV, according to which the event records must be transmitted
immediately afterwards, shall apply.
For these reasons, it is not permitted to disable or delay the monitored telecommunications or to store the
contents of the surveillance copy. Contents of communications may only be buffered to the extent
necessary for a smooth operation due to technical, particularly transmission-related, considerations.
In case of monitoring of subsequent telecommunications events, a renewed connection attempt should be
made for transmission of the surveillance copy, unless other arrangements have been made with the
authorised agency on a case-by-case basis (e.g. in case of prolonged failure).
Technical implementation
First repeated connection attempts
If an obstacle arises when attempting to transmit the surveillance copy, three further connection
attempts should be made in the first instance. When using circuit-switched connections, these
attempts should be made at intervals of 5 to 10 seconds each, and at intervals of up to a few minutes
when using FTP or TCP/IP. If the link to the authorised entity can be restored in these three
experiments, the buffered and newly generated event data as well as the copy of the
telecommunication content shall be transmitted from the date of recovery.
If the connection cannot be restored during these repeated connection setup attempts, the buffered
and accruing event records must be stored for subsequent transmission.
Further connection attempts
After the three repeated connection setup tests, further connection setup tests shall be repeated for a
period of 24 hours at appropriate time intervals until a connection set-up test is successful.
If a transmission has not been made during this extended period, it must be possible to print out the
stored event data or to store it on a storage medium (e.g. CD) and to transmit it in an appropriate
manner to the authorised entity immediately (e.g. by secure email) and then to delete it in the STS.
The above-mentioned 24-hour period may be extended to 1 week by the obliged entity, provided that it
is ensured that the event data stored can also be provided to the authorised entity during the
extension period at its request (e.g. on the replacement route foreseen for the error).
If the connection to the authorised agency is restored during this extended period, transmission should
include the copy of the content of the communication in addition to the event data from the time of
restoration.
In circuit-switched fixed and mobile telephony networks, however, no additional connection attempts
should be made to transmit the copy of the content of communication to the authorised agency after
the above three further connection attempts, if the transmission point follows the design pursuant to
Annex B or C.
Detected failure or error situations affecting the surveillance of the telecommunications or the
transmission of the surveillance copy should be immediately sent to the authorised agency as alarm
reports in a separate event data set or reported to it through other means. If the transmission of the
relevant event data sets itself is affected by a failure, these alarms should still be generated so that they
can be transmitted after restoration of the transmission function or sent on a storage medium in order to
document the failure. In mobile telephony networks, the details of failures affecting only regionally defined
parts of the network need only be provided upon request from the authorised agencies, using suitable
means (e.g. via fax or email).
TR TKÜV, edition 8.0 (draft) Part A, Annex B, page 39
Annex B (Deleted: Transmission point for
circuit-switched networks (national))
Note: Since all forwarding via X.25 was discontinued as of 31 December 2017, existing implementations
under Annex B are now only permitted until 31 December 2021 if these have been converted to
forwarding via FTP. New implementations are no longer permitted. The descriptions under this Annex B
can be found in the TR TKÜV versions up to version 7.0.
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 40
Annex C Provisions for PSTN and ISDN (ETSI ES
201 671 and TS 101 671)
Note on the use of existing systems based on forwarding via ISDN:
Due to the medium-term foreseeable shutdown of ISDN-based technology, the corresponding
forwarding based on this technique also needs to be adapted in the medium term. New
implementations with forwarding based on ISDN are no longer permitted. Existing systems are to
be converted by 31 December 2021 at the latest to forwarding in accordance with Annex H. If the
service via the existing provider is no longer possible within this period, a switch to an alternative
provider, which continues to offer ISDN, may also take place. Forwarding via X.25/X.31 is no
longer permitted; it was replaced by FTP on 31 December 2017.
This Annex describes the conditions in case the transmission point for circuit-switched fixed networks
(PTSN and ISDN) is designed according to ETSI Standard ES 201 671 or
ETSI Specification TS 101 671 [22]. The transmission point for mobile networks must comply with Annex
D.
This includes the decisions made with respect to options contained in the standard or specification, as
well as additional technical requirements.
Telecommunications surveillance activation in existing telecommunications links
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy provided.
Data pursuant to § 7(1) TKÜV, which exists on the net at the time of activation of the surveillance action
and is no longer forwarded via future event data (e.g. codecs of the existing telecommunication), must
also be reported. Since there is currently no standard dictating the technical implementation in detail, the
compulsory implementation of this requirement is deferred for the time being, as long as signalling
information and informational content are provided in various network elements, and provided that no
information for operational purposes regarding the points at which the voice data can be forwarded and
correlated is kept back.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.1 FTP transmission method
For PSTN and ISDN, the copy of the informational content is sent via an ISDN dual stub
according to this Annex C or in an IP-based manner according to Annex H. The event data
are sent via FTP/internet. The stipulations required to this end are contained in Annex A.1
Annex A.2 Participation in a VPN via a cryptobox
If the copy of the content or the event data is transmitted over FTP or TCP/IP, the
procedure for participation in VPN should also be followed
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 41
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 42
Annex C.1 Selection of options and stipulation of additional technical
requirements
The following table describes, on the one hand, the selection of options for the different chapters and
paragraphs of ETSI specification TS 101 671 or ETSI Standard 201 671 and, on the other, specifies
additional requirements. Unless otherwise indicated, the references in the table relate to the respective
sections of the ETSI specification or ETSI standard:
Section Description of the option or problem point and Supplementary requirement, background or
ES 201 671 / definitions for the national application additional information
TS 101 671
5.1 Manual/Electronic Handover Interface 1 (HI1)
There is no electronic interface from the LEA to the For the transmission of events (e.g.
installation of the obligated party for direct activation/deactivation/modification of an action, error
administration of actions. reports) from the installation of the obligated party to
the LEA, the HI1 may be used (see Annex A.3 TR
The events for administration of an action (e.g. TKÜV in this regard).
about activation) and fault reports should be
reported.
6.2.1 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
NWO/AP/SvP identifier (Operator Identifier). In
Germany, the first digits are set to '49' while the
remaining 3 digits are determined by the Federal
Network Agency for each obligated party.
8.1 Data transmission protocol (HI2)
To transmit the event data (IRI) over the HI1 and
HI2 interfaces, FTP is used; ROSE is not permitted.
The FTP connection should be closed immediately
after transmission of the event data.
10.1 Timing (Buffering of IRI)
For buffering of IRI, the requirement given in the see Annex A.4 of the TR TKÜV.
adjacent column applies.
11 Security aspects
When using an IP-based transmission point, IPSec To protect IP-based transmission points, dedicated
is applied. IP cryptoboxes should be used, based on IPSec in
conjunction with a PKI as referred to in Annex A.2 of
the TR TKÜV.
For transmission of content over ISDN, the service Where a COLP check cannot always be carried out
attributes CLIP, COLP and CUG are used. reliably, particularly for newer network technologies, it
may be disabled permanently or dispensed with after
consulting with the Federal Network Agency.
12 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the guidelines
as per § 5.2 of the TR TKÜV.
Annex A: Circuit-switched network handover
A.1.3 Usage of Identifiers
The options ‘IRI and CC’ and ‘only IRI’ should be The option ‘only CC’ is part of the specification up to
supported; the option ‘only CC’ need not be Version 2.5.1.
supported.
A.3.2.1 Control information for HI2
All times (TimeStamp) should normally be given as The GeneralizedTime parameter is not encoded as
local time based on the official time. universal time and without time difference. The
winterSummerIndication must be specified as either
wintertime or summertime.
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 43
Section Description of the option or problem point and Supplementary requirement, background or
ES 201 671 / definitions for the national application additional information
TS 101 671
A.4.1 Delivery of Content of Communication
Correlation of the informational content (CC) with As the user-to-user service has not been implemented
the other HI Interfaces should not be done via the in all networks in Germany, correlation should
user-to-user service but instead via the subaddress exclusively use the subaddress service.
service.
Annex E describes this use.
A.4.2 Delivery of packetised Content of
Communication For transmission of this content, a choice may be
For the SMS and UUS services, informational made between either the ASN.1 module
content is transmitted as event data. ‘HI2Operations’ as described in Annex D.5 or the
module ‘HI3CircuitDataOperations’ as described in
Annex D.6. Both modules provide the relevant
parameters for UUS and SMS.
A.4.3 Control information for circuit switched Content
of Communication
As described above, the terminal equipment of the
authorised entities responds to a SETUP message
immediately with a CONNECT message, i.e.
without an Alerting message.
A.4.4.1 Failure of CC links
In case a connection fails to be created, three see Annex A.4 of the TR TKÜV.
renewed attempts should be made.
A.4.4.2 Fault Reporting
Fault reports are transmitted as event data as Fault reports may be transmitted as national
described in Annex D.5 (IRI) (see Annex A.4 of the parameters or alternatively via the HI1 interface. The
TR TKÜV). minimum error events which should be transmitted are
derived from the national parameters (see Annex A.3
In mobile telephony networks, the details of failures of the TR TKÜV).
affecting only regional parts of the network need
only be provided upon request from the authorised
agency.
A.4.5 Security Requirements at the interface port HI3
When creating the CC links to the LEMF (LEA), the Where a COLP check cannot always be carried out
ISDN service attributes CLIP, COLP and CUG reliably, particularly for newer network technologies, it
should be used. may be disabled permanently or dispensed with after
consulting with the Federal Network Agency.
The provision of target addresses for the authorised
Routing to the target addresses of the authorised agencies by the Federal Network Agency shall ensure
agencies shall take place in such a way that the a routing such that only appropriately ‘secure’ transit
aforementioned service attributes are transmitted networks are used, and for example any IP networks
securely. considered insecure, or wider foreign networks, are
avoided.
A.4.5.3 Authentication
No specific authentication procedure is used in the
ISDN B-channel or the subaddresses.
A.5 LI procedures for circuit switched
supplementary services
For non-standardised (proprietary) surveillance-
relevant service attributes, the required information
should be transmitted in the national parameters.
The content of the parameters should be agreed
with the Federal Network Agency.
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 44
Section Description of the option or problem point and Supplementary requirement, background or
ES 201 671 / definitions for the national application additional information
TS 101 671
A.5.4 Multi party calls — general principles
A.6.11 For large conferences (CONF) with more than six
participants, the option B according to A.5.4.2
should be implemented.
A.6.2, A.6.3, For CW, HOLD, 3PTY and CONF up to six users:
A.6.12 For CW, HOLD, 3PTY and CONF with up to 6 As multiplexed use of ISDN channels to the authorised
participants, either option A or option B may agency as described in option B lead to more complex
alternatively be used. analysis and more difficult analysis of the content (no
differentiation of speaker per channel), use of option A
should be preferred.
A.6.3 Call Hold/Retrieve
When HOLD is activated, both CC links should be
muted during the HOLD phase.
In addition, the option where only the held identifier
(held party) is muted is accepted.
A.5.5 Subscriber Controlled Input The obligation to report controls regarding operation
options in accordance with § 5(1)(4) TKÜV is lifted.
However, systems in operation before TR TKÜV 7.1
enters into force may still use these parameters.
A.6.4 Explicit Call Transfer (ECT)
After transfer, option 2 should be implemented
(‘The transferred call shall not be intercepted.’).
A.6.22 User-to-User Signalling (UUS)
Informational content for the UUS service is See § A.4.2 in this table.
transmitted as event data.
A.8.3 HI3 (delivery of CC)
Informational content for the SMS service is See § A.4.2 in this table.
transmitted as event data.
Correlation of the informational content (CC) with See § A.4.1 in this table.
the other HI interfaces should be done via the
subaddress service as described in Annex E.
Annex C: HI2 delivery mechanisms and procedures
C.1 / C.2 ROSE / FTP
For transmission of the event data (IRI) over the
HI2 interface, FTP is used; ROSE is not permitted.
C.2.2 Usage of FTP
File naming method B must be used.
The provisions of Annexes A.1 and A.2 of the TR
TKÜV also apply.
Annex D: Structure of data at the Handover Interface
D.3 to D.8 ASN.1 modules
When using FTP to transmit the IRI, the ROSE Since not all modules have been specified as being
operations are not relevant in the Annexes and do error-free or do not contain all the required parameters,
not need to be implemented. the Federal Network Agency will publish on its website
a list of the modules which may be used for
implementations (see also Annex X.4 to TR TKÜV).
Annex E: Use of subaddress and calling party number to carry correlation information
TR TKÜV, edition 8.0 (draft) Part A, Annex C, page 45
Section Description of the option or problem point and Supplementary requirement, background or
ES 201 671 / definitions for the national application additional information
TS 101 671
E.3.2 Field order and layout
The parameters for assigning CC and IRI according
to Tables E.3.2 and E.3.3 should be used
accordingly.
National specifications for circuit-switched networks
Also, the octets 17-23 of the Called Party (former Annex B) stipulate that subaddresses are also
Subaddress (Table E.3.4 and E.3.6) should contain used, but with a different content. To enable the
the fixed bit pattern analysis device of the authorised agency to make a
‘45 54 53 49 20 56 32' hex = ETSI V2’ to distinction, this differentiating attribute is mandatory.
differentiate it from the subaddresses according to
the specifications of the former Annex B to
TR TKÜV.
Annex C.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 TKÜV, on
the applicable ETSI and 3GPP standards and specification, including the associated ASN.1 modules. Use
of the different versions of the national ASN.1-module is also regulated. Annex X.4 contains further
explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Annex C should be
taken from the various versions of ETSI standard ES 201 671 or ETSI specification TS 101 671, taking
care to correct any errors in the ASN.1-modules contained in them (e.g. incorrect domainID). Because
FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Without a corresponding update on the side of the
authorised body, it may not be possible to interpret all parameters.
The parameters referred to in the standard or in the specification as “conditional” and “optional” should be
transmitted insofar as they are available and no other rules have been laid down in the standard,
specification or Annex C.1.
For the associated ASN.1 types of the “OCTET STRING” format, the following rules apply:
if the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
if no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Annex A.3.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 46
Annex D Specifications regarding mobile
telephony networks and mobile-based
IMS platforms (3GPP TS 33.108 and TS
33.128)
Note on the use of existing systems based on forwarding via ISDN and the combined use of
standards for forwarding packet-switched voice services:
Due to the anticipated closing down of ISDN-based technology, the corresponding forwarding
based on this technology must also be adapted. New implementations with forwarding based on
ISDN are no longer permitted. Existing installations shall be converted to TCP-based forwarding
according to 3GPP TS 33.108 by 31.12.2021 at the latest. For packet-switched voice services (e.g.
VoLTE), combined forwarding in accordance with 3GPP TS 33.108 or TS 33.128 and ETSI TS 102
232-5 (Annex H) may be used temporarily (see guidelines in Annex X.1.1).
This Annex describes the requirements for the transmission point formobile telephony networks and
mobile-based IMS platforms according to 3GPP Specifications TS 33.108 [23] and TS 33.128 [40]. The
specifications include the technical description for the switching and packet switching sector and for
multimedia services.
The 3GPP Specification TS 33.128 uses the IP-based transmission procedure according to the ETSI
specifications TS 102 232-1 and 102 232-7, in which the data is encapsulated according to 3GPP TS
33.128. At the latest when both forwarding methods are implemented in a network as part of the
successive migration of forwarding from 3GPP TS 33.108 to 3GPP TS 33.128, forwarding in accordance
with 3GPP TS 33.108 shall also be carried out via ETSI specifications TS 102 232-1 and 102 232-7.
According to this version of the TR TKÜV, the forwarding of 3GPP TS 33.108 via the ETSI specifications
TS 102 232-1 and 102 232-7 is also possible after consultation with the Federal Network Agency,
irrespective of the above-mentioned successive migration of forwarding to 3GPP TS 33.128.
For forwarding via ETSI TS 102 232-1 the previously defined port number (destination port number)
50100 applies, for direct forwarding according to 3GPP TS 33.108 the port number 50010 continues to
apply.
The use of 3GPP TS 33.108 shall be in accordance with the conditions set out in Annex D.1. 3GPP TS
33.128 [40] will be used until further notice after consultation with the Federal Network Agency.
Section 4 in Part A of this TR TKÜV lists those identifiers on which basis the surveillance of
telecommunications should be implemented. If the order specifies an IMEI as identifier of the LuS, the
data sets should contain this IMEI and the associated MSISDN.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.1 The FTP transmission methods (file name, parameters)
In the circuit-switched domain, the informational content shall be transmitted via ISDN dual
stubs or via the internet (RTP). For ISDN-based forwarding described in this Annex D: The
event data (ASCII data) are sent via FTP/IP. The stipulations required to this end are
contained in Annex A.1.
In packet-switched networks as well as for multimedia services, transmission of both the
copy of the content and the event data takes place via FTP/internet or TCP/IP. In the case
of transmission via FTP, this Annex is also applicable.
Annex A.2 Participation in a VPN via a cryptobox.
If the data are transmitted over the internet via FTP or TCP/IP, the procedure for
participation in VPN should also be followed.
Annex A.3 Transmission of HI1 events and additional events
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 47
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
Requirements for specification of the location in mobile telephony networks
When monitoring an identifier whose use is not fixed to a particular location, the location of the end device
as known to the relevant network should be indicated with the greatest possible accuracy, pursuant to §
7(1) point 7 TKÜV.
When carrying out instructions to provide the location of the end device on standby to receive which is
associated with the identifier being monitored, the available surveillance system must be used
accordingly.
The following provisions apply in this case:
The location must be encoded in a form enabling the authorised agency to determine the geographical
location of the radio cell without network-specific documentation from the network operator.
To this end, the location coordinates of the radio cell (e.g. BTS in GSM, NodeB in UMTS, eNodeB for LTE
or gNodeB for 5G NR) and the cell identifier CGI (Cell Global Identification, pursuant to
ETS 300 523 [13]), ECI (E-UTRAN Cell Identifier, pursuant to ETSI TS 123 003) or NCI (NR Call Identity,
pursuant to ETSI TS 123 003) are to be indicated.
Geographical angular coordinates based on WGS84 are to be used.
If the mobile network does not record the exact location of the mobile device, at least the cell through
which the connection is processed should be given.
The location information or cell identifiers shall also be reported if information is not available in the core
network, but only in the access network. Taking into account the functions so far available from the
networks, the information must at least be indicated for the following events:
Circuit Switched Service
Idle Mode: Periodic Location Update
Connected Mode: Call origination and termination, handover between cells and SMS messaging
Data Service, 2.5G
Standby Mode: Periodic Routing Area Update, Routing Area Update
Ready Mode: GPRS Attach and Detach, Cell Updates (in the active PDP Context) and Routing
Area Update
Data Service, 3G
Idle Mode: Periodic Routing Area Update, Routing Area Update
Connected Mode: GPRS Attach and Detach and Routing Area Update,
Cell Updates (with activated PDP Context in CELL_DCH mode)
Data Service, 4G
Idle Mode: Periodic Tracking Area Update, Tracking Area Update
Connected Mode: Attach and Detach, Tracking Area Update
Inter-eNodeB-Handover
Data Service, 5G NSA
see Data Service 4G
Data Service, 5G SA
To be defined in a subsequent edition of the TR TKÜV
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 48
Telecommunications surveillance activation in existing telecommunications links
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy delivered
(see Annex H.3.2, point 5.3). Data pursuant to § 7(1) TKÜV, which exists on the net at the time of
activation of the surveillance action and is no longer forwarded via future event data (e.g. codecs of the
existing telecommunication), must also be reported. Since there is currently no standard dictating the
technical implementation in detail, the compulsory implementation of this requirement is deferred for the
time being, as long as signalling information and informational content are present in various network
elements, and provided that no information for operational purposes regarding the points at which the
voice data (e.g. IP address, port number) can be forwarded and correlated is kept back.
Exceptions for IMEI monitoring
Owing to the network architecture, the IMEI is generally only recorded when logging onto the network and
is not available for monitoring at the corresponding network elements. It is therefore not possible to report
IMEI in all cases. Until these situations are standardised, this limitation is tolerated by the Federal
Network Agency, on condition that these cases are recorded in full as part of telephone number
monitoring. Once relevant standards have been drawn up, their specifications must be complied with in
full.
Annex D.1 Selection of options and stipulation of additional technical
requirements
The following table describes, on the one hand, the selection of options for the different chapters and
paragraphs of 3GPP Specification TS 33.108 and, on the other, specifies the respective additional
requirements. Unless otherwise indicated, the references in the table relate to the respective sections of
the 3GPP specification:
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
4.3 Functional requirements
The options ‘IRI and CC’ and ‘only IRI’ must be
supported; the option ‘only CC’ need not be
supported.
4.4 Overview of handover interface
There is no electronic interface from the LEA to the For the transmission of events (e.g.
installation of the obligated party for direct activation/deactivation/modification of an action, fault
administration of actions. reports) from the installation of the obligated party to
the LEA, the HI1 may be used (Annex A.3 of the
The events for administration of an action (e.g. TR TKÜV).
about activation) and fault reports should be
reported.
4.5 HI2: Interface port for intercept related
information
For buffering of IRI, the requirement given in the See Annex A.4 of the TR TKÜV.
adjacent column applies.
4.5.1 Data transmission protocols (HI2)
To transmit the event data (IRI) over the HI1 and
HI2 interfaces, FTP is used; ROSE is not permitted.
The FTP connection should be closed immediately
after transmission of the event data.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 49
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
Addendum 1 Security aspects
When using an IP-based transmission point, IPSec To protect IP-based transmission points, dedicated
is applied. IP cryptoboxes should be used, based on IPSec in
conjunction with a PKI as referred to in Annex A2 of
the TR TKÜV.
For transmission of content over ISDN, the service Where a COLP check cannot always be carried out
attributes CLIP, COLP and CUG are used. reliably, particularly for newer network technologies, it
may be disabled permanently or dispensed with after
consulting the Federal Network Agency.
Addendum 2 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the guidelines
as per § 5.2 of the TR TKÜV.
Addendum 3 Failure of CC links
In case a connection fails to be created, three See Annex A.4 of the TR TKÜV.
renewed attempts should be made.
Chapter 5: Circuit-switch domain
5.1.2.1 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany, the
first digits are set to '49' while the remaining 3 digits
are determined by the Federal Network Agency for
the relevant obligated party.
5.2.2.1 Control Information for HI2
All times (TimeStamp) should normally be given as The GeneralizedTime parameter is not encoded as
local time based on the official time. universal time and without time difference. The
winterSummerIndication must be specified as either
wintertime or summertime.
5.3.1 Delivery of Content of Communication
Correlation of the informational content (CC) with As the user-to-user service has not been implemented
the other HI Interfaces should not be done via the in all networks in Germany, correlation should
user-to-user service but instead via the subaddress exclusively use the subaddress service.
service. Annex E describes this use.
5.3.1, 5.4 For the SMS and UUS services, informational For transmission of this content, a choice may be
content is transmitted as event data. made between either the ASN.1 module
‘HI2Operations’ as described in Annex D.5 or the
module ‘HI3CircuitDataOperations’ as described in
Annex D.6. Both modules provide the relevant
parameters for UUS and SMS.
5.3.2 Control information for Content of
Communication
As described above, the terminal equipment of the
authorised entities responds to a SETUP message
immediately with a CONNECT message, i.e.
without an Alerting message.
Addendum 4 Fault Reporting
Fault reports are transmitted as event data (IRI) Fault reports may be transmitted as national
(see Annex A.4 of the TR TKÜV). parameters or alternatively via the HI1 interface. The
minimum error events which should be transmitted are
In mobile telephony networks, the details of failures derived from the national parameters (as determined in
affecting only regional parts of the network need Annex A.3 of the TR TKÜV).
only be provided upon request from the authorised
agency.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 50
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
5.3.3 Security requirements at the interface port of
HI3
When creating the CC links to the LEMF (LEA), the Where a COLP check cannot always be carried out
ISDN service attributes CLIP, COLP and CUG reliably, particularly for newer network technologies, it
should be used. may be disabled permanently or dispensed with after
consulting the Federal Network Agency.
5.3.3.3 Authentication
No specific authentication procedure is used in the
ISDN B-channel or the subaddresses.
5.4 LI procedures for supplementary services
For non-standardised (proprietary) surveillance-
relevant service attributes, the required information
should be transmitted in the national parameters.
The content of the parameters should be agreed
with the Federal Network Agency.
5.4.4 Multi party calls — general principles
5.5.2, 5.5.3, For CW, HOLD and MPTY (with up to 6 For CW, HOLD, MPTY up to six users:
5.5.11 participants), either option A or option B may be As multiplexed use of ISDN channels to the authorised
used alternatively. For large conferences with more agency as described in option B lead to more complex
than 6 participants, option B should be analysis and more difficult analysis of the content (no
implemented. differentiation of speaker per channel), use of option A
should be preferred.
5.4.5 Subscriber Controlled Input The obligation to report controls regarding operation
options in accordance with § 5(1)(4) TKÜV is lifted.
However, systems in operation before TR TKÜV 7.1
enters into force may still use these parameters.
5.5.3 Call Hold/Retrieve
When HOLD is activated, both CC links should be
muted during the HOLD phase.
In addition, the option where only the held identifier
(held party) is muted is accepted.
5.5.4 Explicit Call Transfer (ECT)
After transfer, option 2 should be implemented
(‘The transferred call shall not be intercepted.’).
5.5.15 User-to-User Signalling (UUS)
Informational content for the UUS service is See §§ 5.3.1 and 5.4 in this table.
transmitted as event data.
Chapter 6: Packet data domain
6.4 Quantitative aspects
The dimensioning of the administration and See Addendum 2 in this table.
transmission capacities is subject to the guidelines
as per § 5.2 TR TKÜV.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 51
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
6.5.0 PacketDirection
The unambiguous designation of the path taken by
content data shall be tracked with to target and
from target.
IP addresses and port numbers
The parameters sourceIPAddress,
destinationIPAddress, sourcePortNumber and
destinationPortNumber shall be used to transmit
the source and destination IP addresses and the
corresponding port numbers of the participating
users.
6.5.1.1 REPORT record information
The REPORT record shall be triggered when, as a This option cannot be realised in Germany.
national option, a mobile terminal is authorised for Note: Where roaming between network operators is
service with another network operator or service possible in Germany, an action for any given LuS
provider. should be implemented on all the relevant networks.
6.6 IRI reporting for packet domain at GGSN
As a national option, in the case where the GGSN This option need not be implemented in Germany.
is reporting IRI for an intercept subject, the Note: Where roaming between network operators is
intercept subject is handed off to another SGSN possible in Germany, an action for any given LuS
and the same GGSN continues to handle the should be implemented on all the relevant networks.
content of communications subject to roaming
agreements, the GGSN shall continue to report the
following IRI of the content of communication:
- PDP context activation;
- PDP context deactivation;
- Start of interception with PDP context active.
6.7 Content of communication interception for
packet domain at GGSN
As a national option, in the case where the GGSN This option may only be realised in Germany if the
is performing interception of the content of requirement under § 4(1) TKÜV is met.
communications, the intercept subject is handed off Note: Where roaming between network operators is
to another SGSN and the same GGSN continues to possible in Germany, an action for any given LuS
handle the content of communications subject to should be implemented on all the relevant networks.
roaming agreements, the GGSN shall continue to
perform the interception of the content of
communication.
Chapter 7: Multimedia domain
7.1.2 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany, the
first digits are set to '49' while the remaining 3 digits
are determined by the Federal Network Agency for
each obligated party.
7.2.1 Timing
All time stamps should normally be given as local The GeneralizedTime parameter is not encoded as
time based on the official time. universal time and without time difference. The
winterSummerIndication must be specified as either
wintertime or summertime.
For buffering of IRI, the requirement given in the See Annex A.4 of the TR TKÜV.
adjacent column applies.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 52
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
7.3 Security aspects.
When using an IP-based transmission point, IPSec To protect IP-based transmission points, dedicated
is applied. IP cryptoboxes should be used, based on IPSec in
conjunction with a PKI as referred to in Annex A2 of
the TR TKÜV.
7.4 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the guidelines
as per § 5.2 TR TKÜV
7.5 IRI for IMS
In case of IRI-only surveillance, the content of
communication, for example SMS content or other
messaging content (e.g. instant messaging), shall
be removed from the ‘SIPmessage’ parameter
before forwarding.
7.5.1 Events and information If the obligated party used encryption on the network
side or it is involved in generating or exchanging keys,
The Correlation number and Correlation thereby allowing it to decrypt the telecommunication,
parameters in accordance with Table 2 shall be the encryption at the handover point must be lifted
reported. (§ 8(3) TKÜV).
The parameter mediaDecryption-info. If the obligated party supports encryption of peer-to-
CCKeyInfo.cCSalt must be reported if it is available peer-communications over the internet by means of
to the obligated party. key management provided by him, without involving
his network elements or those of his partners in the
transmission of the content, he should at least inform
the authorised agency of the key initially exchanged by
him with his telecommunication system.
Transmission of the exchanged key is not required if
the obligated party can still remove the encryption by
means of additional network elements.
Chapter 8: 3GPP WLAN Interworking
In Germany, where publicly accessible services as
defined in § 8 of 3GPP Specification TS 33.108 are
offered, the associated requirements must always be
fulfilled. Further details as to the form of the
surveillance functionality for these services shall be
agreed with the Federal Network Agency.
Chapter 9: Interception of Multimedia Broadcast /MultiCast Service (MBMS)
In Germany, where publicly accessible services as
defined in § 9 of 3GPP Specification TS 33.108 are
offered, the associated requirements must always be
fulfilled. Further details as to the form of the
surveillance functionality for these services shall be
agreed with the Federal Network Agency.
Chapter 10: Evolved Packet System (EPS)
10.1.2 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany, the
first digits are set to '49' while the remaining 3 digits
are determined by the Federal Network Agency for
each obligated party.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 53
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
10.2.1 Timing
All time stamps should normally be given based on The GeneralizedTime parameter is not encoded as
the official time. universal time and without time difference. The
winterSummerIndication must be specified as either
wintertime or summertime.
For buffering of IRI, the requirement given in the See Annex A.4 of the TR TKÜV.
adjacent column applies.
10.3 Security aspects.
When using an IP-based transmission point, IPSec To protect IP-based transmission points, dedicated
is applied. IP cryptoboxes should be used, based on IPSec in
conjunction with a PKI as referred to in Annex A2 of
the TR TKÜV.
10.4 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the guidelines
as per § 5.2 TR TKÜV
10.5.0 PacketDirection
The unambiguous designation of the path taken by
content data shall be tracked with to target and
from target.
IP addresses and port numbers
The parameters sourceIPAddress,
destinationIPAddress, sourcePortNumber and
destinationPortNumber shall be used to transmit
the source and destination IP addresses and the
corresponding port numbers of the participating
users.
10.5.1.1.5 Tracking Area Update (REPORT)
old location information
This parameter shall be reported if it is available in the
Provide (only by the old MME), when authorised obligated party’s surveillance functionality.
and if available, to identify the old location
information for the intercept subject’s MS.
10.5.1.4.1 Bearer Deactivation (END)
EPS bearer id
This parameter shall be reported if it is available in the
obligated party’s surveillance functionality.
10.6 IRI reporting for evolved packet domain at PDN-
GW
This option need not be implemented in Germany.
In certain circumstances (e.g. roaming), the PDN-
GW may constitute the only surveillance possibility. Note: Where roaming between network operators is
In these cases, the surveillance functionality for possible in Germany, an action for any given LuS
event data capture and forwarding (IRIs) shall be should be implemented on all the relevant networks.
implemented at the PDN-GW in accordance with §
10.6 of 3GPP Specification 33.108.
10.7 CC interception for evolved packet domain at
PDN-GW
This option may only be implemented in Germany if
In certain circumstances (e.g. roaming), the PDN- the requirement under § 4(1) of the TKÜV has been
GW may constitute the only surveillance possibility. fulfilled.
In these cases, the surveillance functionality for
content-of-communication (CC) capture and Note: Where roaming between network operators is
forwarding shall be implemented at the PDN-GW in possible in Germany, an action for any given LuS
accordance with § 10.7 of 3GPP Specification should be implemented on all the relevant networks.
33.108.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 54
Section Description of the option or problem point and Supplementary requirement, background or
3GPP definitions for the national application additional information
TS 33.108
Chapter 11: 3GPP IMS Conference Services
Chapter 12: 3GPP IMS-based VoIP Services
Chapter 13: Interception of Proximity Services (ProSe)
Chapter 14: Invocation of Lawful Interception (LI) for Group Communications System Enablers (GCSE)
Chapter 15: Interception of Messaging Services
In Germany, where publicly accessible services as
defined in §§ 11 to 15 of 3GPP Specification TS
33.108 are offered, the associated requirements must
be fulfilled. Further details as to the form of the
surveillance functionality for these services shall be
agreed with the Federal Network Agency.
Annex A: HI2 delivery mechanisms and procedures
A.1.2.3.1 Data link establishment
Optionally a Data link test procedure may be used This option is not relevant in view of the decision to
to verify periodically the data link. use FTP as the transfer protocol for the IRI.
A.2 FTP
For the transmission of the IRI, FTP must be used
in Germany. File naming method B must be used.
The provisions of Annexes A.1 and A.2 of the TR
TKÜV also apply.
Annex C: UMTS HI3 interface
C UMTS HI3 Interface
The choice between use of the ULIC-header All options (ULIC Version 0 and Version 1 and FTP)
Version 0 or Version 1 or FTP is left to the should be supported on the side of the authorised
obligated parties. agency.
C.1.1 Introduction
In Germany, transmission method TCP/IP is For transmission, port number 50010 is chosen on the
envisaged. part of the authorised agency (destination port
number).
C.1 UMTS LI correlation header
Option ULICv1 must be implemented in Germany.
When using the ULIC header Version 1, the
parameters LIID and timeStamp should be used
(mandatory).
Annex J: Use of sub-address and calling party number to carry correlation information
J.2.3.2 Field order and layout
The parameters for assigning CC and IRI according
to Tables J.2.3 and J.2.4 should be used
accordingly.
Under purely national stipulations for circuit-switched
Also, the octets 17–23 of the Called Party networks (Annex B of the TR TKÜV), subaddresses
Subaddress (Table E.3.4 and E.3.6) should contain are also used, but with a different content. To enable
the fixed bit pattern ‘45 54 53 49 20 56 32' hex = the analysis device of the authorised agency to make a
ETSI V2’ to differentiate it from the subaddresses distinction, this differentiating attribute is mandatory.
according to the provisions of Annex B of the TR
TKÜV.
TR TKÜV, edition 8.0 (draft) Part A, Annex D, page 55
Annex D.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 TKÜV, on
the applicable ETSI and 3GPP standards and specification, including the associated ASN.1 modules. Use
of the different versions of the national ASN.1-module is also regulated. Annex X.4 contains further
explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Annex D should be
taken from the various versions of 3GPP Specification TS 33.108, taking care to correct any errors in the
ASN.1-modules contained in them (e.g. incorrect domainID). Because FTP is used as the transfer
protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Without a corresponding update on the side of the
authorised body, it may not be possible to interpret all parameters.
Parameters designated as ‘conditional’ or ‘optional’ in the specification should be transmitted if they are
available and the relevant specification, or Annex D.1 where applicable, does not contain any contrary
provisions.
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
if the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
if no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Annex A.3.
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 56
Annex E Transmission point for storage
systems for voice, facsimile and data
(voicemail systems, Unified
Messaging Systems, etc.)
This Annex describes the national requirements for the transmission point in storage systems (UMS,
VMS, etc.). As the stipulations contained in Annexes B to D do not take account of these types of
systems, these requirements should be fulfilled additionally where applicable.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.1 The FTP transmission methods (file name, parameters)
The copy of the informational content is transmitted in accordance with this annex E
together with the event data in an XML-encoded file, which can be transmitted over
FTP/internet. The stipulations required to this end are contained in Annex A.1.
Annex A.2 Participation in a VPN via a cryptobox
If the surveillance copy is transmitted via FTP/internet, the procedure for participation in
VPN should also be followed.
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
Annex E.1 Definitions
Unified Messaging System All variants of storage facilities operated on telecommunications
(UMS) networks which are generally intended for multiple types of
telecommunications, such as language, fax, email, short messages,
multimedia messaging service (MMS) etc.
(UMS)Box The part of the Unified Messaging System which is allocated to a
particular subscriber – the LuS in the cases under consideration here.
Annex E.2 General explanations
In the technical implementation of ordered surveillance actions for telecommunications, it should be noted
with regard to UMS that this system has the particular property that it does not provide real-time
communication between the LuS and its communication partner. This property affects several aspects of
the technical implementation of such surveillance actions, particularly with regard to the transmission of
the surveillance copy to the authorised agency:
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 57
it is not necessary to separate the telecommunication under surveillance into sending and
receiving directions and to transmit these separately,
in view of the absence of the real-time requirement in these cases, new - useful as well as
economical - options for transmission of the telecommunication under surveillance can be
considered.
The copy of the content taken from the aforementioned storage systems may be transmitted to
the authorised agency with a small time delay, but should still be sent as close to real time as possible: no
later than immediately after storing a message in the storage system, or with a delay not exceeding
10 seconds when retrieving a message.
When a full copy of a given message has already been transmitted, it suffices to send only the event data
in the case of further events (e.g. subsequent listening to the message). To enable correct grouping of the
different transmissions at the authorised agency in these cases, the allocation number field should
contain a unique identifier.
Since a surveillance order covers only the telecommunication which is stored, retrieved or copied in the
relevant UMS during the specified period, any messages which were already present in the UMS before
such period may not be monitored. These should only be included when they are for example retrieved
from the system.
Annex E.3 Basic forwarding methods and determination of relevant events
Annex E.3.1 Basic forwarding methods for the telecommunication under
surveillance
The types of voice, fax and SMS stored in unified messaging systems can be recorded and routed in
conjunction with an implementation according to Annexes B, C, D, F, H or I. Alternatively, it is possible to
transfer these types of telecommunication in an XML-encoded file to the authorised entity via FTP.
Multimedia messages (MMS) stored in UMSs are also transmitted to the authorised agency in an XML-
encoded file via FTP. In addition, MMS may normally be transmitted to the authorised agency using the
transmission point described in Annex H.
If the UMS additionally provides functionality of the email service, or if the email service is used to
transmit messages, then the transmission point for this telecommunication type should be designed
according to Annex F. In addition, it is permitted, in principle, for all telecommunication types to effect
forwarding according to Annex F, e.g. if they are stored in the UMS in the form of email.
The following table shows the various possibilities:
Content Forwarding methods
via an ISDN 64 kbit/s connection with the ISDN Bearer Service ‘Unrestricted Digital Information
(UDI)’ according to Annex B, or Annex C or D. This method is only allowed until 31 December
2021; new implementations are no longer possible.
via RTP connections pursuant to Annex H (the encoding used 1) should be agreed with the
Voice Federal Network Agency).
In wav or mp3 format in an XML-encoded file 2) together with the event data according to Annex
E.5, which may be transmitted via FTP.
in email format according to Annex F.
in XML format in accordance with Annex I.
via an ISDN 64 kbit/s connection supporting the procedures as described in ITU-
T Recommendation T.30 and the ISDN Teleservice ‘Facsimile Gr. 2/3’ as described in Annex B, C
or D. This method is only permitted until 31 December 2021; new implementations are no longer
possible.
Fax via RTP connections pursuant to Annex H (the encoding used 1) should be agreed with the
Federal Network Agency).
in tif, jpg or png format in an XML-encoded file1) together with the event data according to Annex
E.5, which may be transmitted via FTP.
in email format according to Annex F.
in XML format in accordance with Annex I.
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 58
in an event data set according to Annex B, C or D.
via RTP connections or SIP messages pursuant to Annex H (the method and encoding used 1)
should be agreed with the Federal Network Agency).
SMS 3)
as SMS in an XML-encoded file 1) together with the event data according to Annex E.5, which
may be transmitted via FTP.
in email format according to Annex F.
in XML format in accordance with Annex I.
Multimedia in email format in an XML-encoded file 1) together with the event data according to Annex E.5,
messages (MMS) which may be transmitted via FTP.
in email format according to Annex F.
via RTP connections or SIP messages pursuant to Annex H (the method and encoding used 1)
should be agreed with the Federal Network Agency).
Email in an XML-encoded file together with the event data via FTP, as described in Annex F.
in XML format in accordance with Annex I.
Annex E.3.1-1 - Table: Forwarding methods for UMS
1) Exclusively open encoding algorithms should be used for the encoding.
2) Transmission of the XML-encoded file to the authorised agency is subject to the requirements for the event data
pursuant to Annexes B, C, D and H in terms of transmission and the security requirements
If the file with the copy of the content and the event data cannot be transmitted to the authorised agency during the
first connection attempt, then three further transmission attempts should be made within a few minutes. Further
details are given in Annex A.4.
3) The message text of an SMS or MMS should be sent to the authorised agency as text in the UTF-8 character set.
Alternatively, when sending the message content of an SMS, the content of the entire PDU (incl. SM Header, User
data Header, User data) may be sent in hexadecimal form, as per Specification 3GPP TS 23.040. This
corresponds to the requirement set out in Annex B, C, D and H.
Annex E.3.2 Basic determination of relevant events
For the following basic events, a copy of the informational content as well as the event data should be
forwarded. If the UMS has service attributes not covered by these events (e.g. callback in response to a
stored voice message), the relevant requirements should be agreed with the Federal Network Agency:
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 59
Event Remarks
Recording or posting Recording or posting a message (language, fax or SMS) to the UMS using:
call forwarding via the identifier of the LuS, or
dialling or sending from an arbitrary connection (e.g. dialling directly into the
UMS via a service number or via web access)
Query or reading Querying or reading a message (language, fax or SMS) from the UMS via:
the identifier of the LuS, or by dialling this identifier with subsequent call
forwarding to the UMS
an arbitrary connection (e.g. dialling directly into the UMS via a service
number or via web access)
Copying memory contents Copying memory contents from one box associated with the identifier of the LuS
to another box, and vice versa
Access to the box and The possible events (e.g. storing a notification number, generating mailing lists)
modification of settings should be agreed in individual cases with the Federal Network Agency.
Table Annex E.3.2-1 Events in UMSs
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 60
Annex E.4 Requirements for surveillance of voice and fax messages and SMS
according to Annexes B, C or D
Due to the foreseeable shutdown of ISDN-based technology, the corresponding forwarding, which
is based on this technique, also needs to be adapted. New implementations with forwarding
based on ISDN are no longer permitted. Existing installations shall be switched to an IP-based
forwarding according to Annex D or H by 31.12.2021 at the latest.
The following deviating requirements or clarifications apply to the forwarding of voice and fax messages
via ISDN connections and SMS by means of an event data set designed according to the principles
described in Annexes B, C or D for circuit-switched networks.
Item No Deviating requirements or clarifications Remarks
A. Forwarding of a copy of voice messages
1 The information to be transmitted to the authorised agency As an alternative, if the welcome message
consists of the entire voice message, including any and/or end delimiter are always the same, they
welcome message (announcement) and any end delimiter may be transmitted once at the start of the
(e.g. a sound or text message). surveillance action.
Whenever the content changes, it should be
transmitted to the authorised agency again.
2 Transmission takes place via an ISDN 64 kbit/s For transmission, an ISDN stub (mono mode) is
connection using the ISDN bearer service ‘Unrestricted adequate, i.e. a dual stub for sending and
digital information (UDI)’. receiving directions, as in surveillance of a
telephone line, is not necessary here.
If transmission to the authorised agency should
fail, three other connection attempts should be
Call origination by the UMS is automatic; the copy of the made at intervals of a few minutes, e.g. 3
voice message may be copied prior to calling into a box minutes (see also Annex A.4).
associated with the authorised agency.
Pursuant to the requirements of Annexes B, C or D, the
matching criteria are transmitted in the subaddress.
3 The security requirements as described in Annexes B, C This is necessary so that the authorised agency
or D (CLI, CUG) should be complied with. A ‘Connected can be redirected to other identifiers for
Number’ sent by the authorised agency may not be receiving fax messages.
verified.
4 Both content and transmission of event data sets are
subject to Part D of this table
B. Forwarding of a copy of fax messages
1 The copy of a fax message as transmitted to the
authorised agency consists of the entire fax message as
received by the LuS or the latter’s communication partner.
2 Transmission takes place with support for the procedures For transmission, an ISDN stub (mono mode) is
as described in ITU-T Recommendation T.30 and the adequate, i.e. a dual stub for sending and
ISDN Teleservice 'Facsimile Gr. 2/3', i.e. Bearer Capabilityreceiving directions, as in surveillance of a
BC = 'audio 3.1 kHz' and High Layer Compatibility telephone line, is not necessary here.
HLC = 'Facsimile Gr 2/3'. In this context, the recording devices of the
authorised agencies support the procedures of
ITU-T Recommendation T.30
If the first transmission to the authorised entity
Call origination by the UMS is automatic; the copy of the is not successful, three further connecting tests
voice message may be copied prior to calling into a box will be carried out at intervals of a few minutes,
associated with the authorised agency. e.g. 3 minutes (see also Annex A.4).
Transmission of the matching criteria in both
Pursuant to the requirements of Annexes B, C or D, the the subaddress and the header enables
matching criteria are transmitted in the subaddress. the authorised agency to use both integrated
Additionally, the reference number (or, in case of Annex B, devices with facilities for automatic analysis of
the phone number of the LuS) and the allocation number subaddresses and common commercial fax
are sent to the authorised agency in the header of the fax devices with manual matching.
message
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 61
Item No Deviating requirements or clarifications Remarks
3 The security requirements as described in Annexes B, C This is necessary so that the authorised agency
or D (CLI, CUG) should be complied with. A ‘Connected can be redirected to other identifiers for
Number’ sent by the authorised agency may not be receiving fax messages.
verified.
4 Both content and transmission of event data sets are
subject to Part D of this table
C. Forwarding of a copy of SMS messages
1 The copy of an SMS message as transmitted to the
authorised agency consists of the message content in
UTF-8 format or the entire PDU (incl. SM Header, User
data header, User data).
2 Transmission is in a single event data set. Parameters are envisaged each time in the
corresponding Annexes.
The connection is automatically established by the UMS, If the first transmission to the authorised entity
whereby the copy of the SMS message can be copied to a is not successful, three further connecting tests
box assigned to the authorised body. will be carried out at intervals of a few minutes,
e.g. 3 minutes (see also Annex A.4).
3 The security requirements as described in Annexes B, C
or D (CUG or VPN) should be complied with when
transmitting event data.
4 Both content and transmission of other event data sets are
subject to Part D of this table
D. Content and transmission of ancillary event data
1 For every event listed in the table of Annex E-1.1, an Possible events are:
event data set is created and transmitted according to the recording of a voice message
requirements of Annexes B, C or D.
listening to a voice message
The event to be reported is included in field 13 (Service
Attribute) for implementations pursuant to Annex B, and in access to the box
the national parameter for implementations pursuant to receipt of a box-to-box message
Annexes C or D.
notifications of stored messages via SMS
or email
modification of notification number
creation or modification of mailing lists
Table Annex E.1,3-2 Deviating requirements or clarifications for UMS
Annex E.5 Requirements for surveillance of voice and fax messages, SMS and
MMS in an XML-encoded file
As an alternative to forwarding according to Annex E.4, copies of the various telecommunication types
voice, fax, SMS and MMS may be transmitted in unified form by means of an XML-encoded file over FTP.
In this case, the different telecommunication types should be converted into a file format corresponding to
the table below. This table will be extended as new technologies are introduced. Any new parameters to
be defined should be agreed with the Federal Network Agency.
Parameter (tag) Application
<audio-wav> Sprachnachricht im wav-Format
<audio-mp3> Sprachnachricht im mp3-Format
<fax-tif> Faxnachricht im TIFF-Format
<fax-jpg> Faxnachricht im JPEG-Format
<fax-png > Faxnachricht im PNG- Format
<sms> Short Message
<mms> Multimedia Message
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 62
The MMS to be monitored is expressed in the form of email such that the message
text is given in the text field and the associated images as attachments. No
parameters are given in the email header.
Table Annex E.5-1 Parameters (day) of file formats
Annex E.5.1 Parameters for event data
The individual parameters for event data, which are typically combined with the copy of the content into
an XML-encoded file for transmission to the authorised agency, are listed in the following table:
Parameters Values/definition/explanation
<version identifier> identifier allocated by the operator of the STS, which designates the relevant interface
version, in ASCII format (max. 20 characters)
<data set type> ‘report’ as identifier of a unique event
<reference number> identifier of the surveillance action pursuant to § 7(2) sentence 1 of the TKÜV, in
ASCII format
<allocation number> number enabling allocation to content, in ASCII format (values of 1 to 65 535)
<identifier of the LuS> attribute of the identifier under surveillance pursuant to § 7(1) sentence 1 point 1 TKÜV
(e.g. telephone service or fax number associated with the UMS pursuant to E.164, email
address)
<partner identifier> 1) identifier pursuant to §7(1) sentence 1 points 2 to 4 TKÜV, from which a message is stored
or retrieved, or settings are made (e.g. phone number of the line with which the UMS is
associated, service number)
<IP> 1) The IP-address transmitted to the UMS, pursuant to § 7(1) sentence 1 points 2 to 4 TKÜV
(IP address of the telecommunication partner, e.g. when retrieving or storing messages via
web access, if there is no phone number which serves as the partner identifier)
<start> start of monitored telecommunication (e.g. time of storing a message) according to § 7(1)
sentence 1 point 8 of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
The file with event data and/or informational content should not be transmitted to
authorised agencies until after completion of the monitored telecommunications procedure.
<settings> 1. Details of the settings made in the UMS, starting with the event:
‘access’ (to the box by its owner), ‘create mailing lists’,
‘messaging’ (settings in the notification service), ‘welcome text’,
‘change’ (other box settings),
2. And then specification of the settings (parameters) in the format: free ASCII coded
text
These details should be separated by ‘;’ (ASCII character no 59).
<direction> Details of the event being reported, e.g.:
‘received’, ‘called’, ‘listen’ (to messages), ‘receipt box-to-box’, ‘set’, ‘sent’, ‘recording’ (of
messages), ‘send-box-to-box’, ‘notification’ (about existing messages)), 'callback'2). If
several events are almost simultaneous, e.g. storing and sending, two values may be
inserted, separated by ‘;’ (ASCII character no 59).
<cause of termination at Indication of the reason why the monitored connection was closed, e.g.
monitored line> ‘successful’ or
error message from the system as a text string, e.g. interruption of a download. The
text string may contain only the ASCII characters of the Base64 alphabet.
<Start of surveillance Once for each action, with the time of activation of the action (not of administration in case
action> of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
<end of surveillance Once for each action, with the time of deactivation of the action (not of administration in
action> case of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
Table E.5.1-1: Parameters for event data in the XML file
1) This serves to enable transmission of at least the IP address if a unique <partner identifier> is not available.
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 63
2) If the owner of the box in a VMS/UMS is able, based on a received message, to initiate a call to the line from which
the message was stored, this event should be reported, and additionally it should be ensured that such a call is
also monitored. It is not necessary to relate the ‘callback’ event to the stored message using the <allocation
number> parameter.
Annex E.5.2 The XML structure and DTD for voice, fax, SMS and MMS
The XML-encoded file should be created in UTF-8 format.
The following example of an XML structure has values included for all tags. These tags should, however,
only be transmitted if the relevant event requires them. If there are no parameters for the relevant event
data, an empty tag should be used in accordance with XML syntax, e.g. “<Start of surveillance action/>”.
The comment lines are not needed and may be omitted.
XML structure (with example entries):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE hi3-ums SYSTEM "hi3-ums_v1.dtd">
<?xml-stylesheet href="ums_v1.xsl" type="text/xsl"?>
<hi3-ums>
<Versionskennung>ABC1234</Versionskennung>
<Datensatzart>report</Datensatzart>
<Referenznummer><![CDATA[123456789 in Base64-Kodierung 1]]></Referenznummer>
<Zuordnungsnummer><![CDATA[123 in Base64-Kodierung 1]]></Zuordnungsnummer>
<Kennung-des-zueA><![CDATA[987654#E.164#national number in Base64-Kodierung 1]]></Kennung-des-zueA>
<IP>111.222.63.254</IP>
<Partner-Kennung><![CDATA[123456#E.164#national number in Base64-Kodierung 1]]></Partner-Kennung>
<Beginn>31/12/06 10:10:05</Beginn>
<Einstellungen><![CDATA[Ansagetext;freier Text in Base64-Kodierung 1]]></Einstellungen>
<Richtung><!CDATA[abgerufen in Base64-Kodierung 1]]</Richtung>
<Ausloesegrund-zueA><![CDATA[normal call clearing in Base64-Kodierung 1]]></Ausloesegrund-zueA>
<Beginn-UEM>01/12/06 01:00:00</Beginn-UEM>
<Ende-UEM>01/02/07 01:00:00</Ende-UEM>
<fax-tif>
<!-- Beginn fax-tif -->
<![CDATA[Kopie des kompletten zu ueberwachenden Fax in Base64-Kodierung 1]]>
<!-- Ende fax-tif -->
</fax-tif>
<fax-jpg>
<!-- Beginn fax-jpg -->
<![CDATA[Kopie des kompletten zu ueberwachenden Fax in Base64-Kodierung 1]]>
<!-- Ende fax-jpg -->
</fax-jpg>
<fax-png>
<!-- Beginn fax-png -->
<![CDATA[Kopie des kompletten zu ueberwachenden Fax in Base64-Kodierung 1]]>
<!-- Ende fax-png -->
</fax-png>
<audio-wav>
<!-- Beginn audio-wav -->
<![CDATA[Kopie des kompletten zu ueberwachenden Audiosignals in Base64-Kodierung 1]]>
<!-- Ende audio-wav -->
</audio-wav>
<audio-mp3>
<!-- Beginn audio-mp3 -->
<![CDATA[Kopie des kompletten zu ueberwachenden Audiosignals in Base64-Kodierung 1]]>
<!-- Ende audio-mp3 -->
</audio-mp3>
<sms>
TR TKÜV, edition 8.0 (draft) Part A, Annex E, page 64
<!-- Beginn SMS -->
<![CDATA[Kopie der kompletten zu ueberwachenden SMS in Base64-Kodierung 1]]>
<!-- Ende SMS -->
</sms>
<mms>
<!-- Beginn MMS -->
<![CDATA[Kopie der kompletten zu ueberwachenden MMS wird hier im E-Mail-Format in Base64-Kodierung
1
eingefügt]]>
<!-- Ende MMS -->
</mms>
</hi3-ums>
Doctype definition:
<!ELEMENT hi3-ums (version identifier,data set type,reference number,sequence number,identifier-of the-
monitored-line,IP,partner identifier,start,settings,direction,cause-of-termination-at-monitored-line,start-of-
surveillance-action,end-of-surveillance-action,fax-tif,fax-jpg,fax-png,audio-wav,audio-mp3,sms,mms)>
<!ELEMENT version identifier (#PCDATA)>
<!ELEMENT data set type (#PCDATA)>
<!ELEMENT reference number (#PCDATA)>
<!ELEMENT sequence number (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT IP (#PCDATA)>
<!ELEMENT partner identifier (#PCDATA)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT settings (#PCDATA)>
<!ELEMENT direction (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT start-of-surveillance-action (#PCDATA)>
<!ELEMENT end-of-surveillance-action (#PCDATA)>
<!ELEMENT fax-tif (#PCDATA)>
<!ELEMENT fax-jpg (#PCDATA)>
<!ELEMENT fax-png (#PCDATA)>
<!ELEMENT audio-wav (#PCDATA)>
<!ELEMENT audio-mp3 (#PCDATA)>
<!ELEMENT sms (#PCDATA)>
<!ELEMENT mms (#PCDATA)>
1
The values of the individual tags or the copy of the monitored message should be included in Base64 encoding as
per RFC 822 or RFC 2045 [26]. Please note that the Base64 encoding requires a line break to be inserted every 76
characters.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 65
Annex F Stipulations for storage systems for
the email service
This Annex contains two alternative descriptions of the transmission point for surveillance of the email
service:
Annex F.2 defines a national transmission point from which the copy of the email is transmitted to
the authorised agency together with the event data in an XML file via FTP.
The alternative description of the transmission point of Annex F.3 is derived from
ETSI Specification TS 102 233 or TS 102 232-02 [30] and describes an ASN.1 file which also
contains the entire surveillance copy and uses TCP/IP for transmission.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.1 The FTP transmission methods (file name, parameters)
If the transmission of the copy of the email in accordance with this Annex F.2 is carried out
together with the event data in an XML-encoded file via FTP/internet, the terms set out in
Annex A.1 shall apply.
Annex A.2 Participation in a VPN via a cryptobox.
If the surveillance copy is transmitted by FTP/internet in accordance with Annex F.2, the
procedure for participating in the VPN should also be followed.
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
Annex F.1 Definitions, fundamentals
Email server Any kind of telecommunications equipment which stores or transmits email service
messages, irrespective of how it is accessed by the user, e.g. SMTP, POP3, IMAP,
WEB or WAP.
Email address Address according to RFC 822, RFC 2822.
The email address is an identifier used to denote the telecommunication under
surveillance.
Mailbox Storage space for email-messages of a given user (email account), where both
sent and received messages are kept. A monitored email mailbox may sometimes
contain several email addresses.
Login Process in which a user’s access permission to his email mailbox is checked.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 66
Login name The login name used at login as part of the access data is, in addition to the email
address, also an identifier used to denote the telecommunication under
surveillance.
An order for surveillance of telecommunications in the email service may contain, as a technical attribute:
an email address, or
the access identifier (login name without password) of a mailbox.
To implement surveillance of the entire telecommunication which takes place under the given identifier,
care should be taken especially for outgoing traffic (e.g. sending emails via SMTP) that the monitored
telecommunication is actually associated with the LuS by using suitable authentication methods. This
should prevent situations where, for example, sending an email which should be monitored fails to be
recorded because the sender address was manipulated by the user.
Whereas this requirement is typically fulfilled in login name-based surveillance by the login authentication
procedure (login name and password), email address-based surveillance can only be implemented if the
authentication methods used by the particular protocol also fulfil this requirement. Annex F.2 contains
further details on the permitted authentication methods in this context.
If this requirement cannot be fulfilled (e.g. due to an unsuitable authentication method) for one of the
protocols SMTP, POP3 or IMAP, an email address-based order for the entire mailbox should be
implemented for the relevant protocol instead, which should include the telecommunications of all email
addresses of this mailbox. If no integrated authentication procedure is in place for access to the mailbox,
then another authentication procedure, or another procedure enabling only the telecommunications on
the LuS to be monitored, shall be agreed with the Federal Network Agency.
The informational content, consisting of a complete copy of the monitored email (header, body and
attachment), is combined with the associated event data into a file. This file should be transmitted to the
authorised agency via FTP immediately after the occurrence of the relevant event. However, in certain
usage scenarios, such as multipart messages, it is possible that the email to be monitored is not
transmitted in a single file, provided that the requirements for the non-caching of user information and the
provision of unmodified, monitored telecommunications are met. This ensures that even individual parts
of an email that has not been completely transmitted are transferred to the recording lines of the
authorised agencies.
In cases where surveillance of only the event data has been ordered, only these should be transmitted to
the authorised agency (without the content).
Annex F.2 Nationally specified email transmission point
When a full copy of a given email has already been transmitted to the authorised agency, it suffices to
send only the event data in the case of further events as described in Tables F.2-1-1 to F.2-1-4 (e.g.
subsequent retrieval of the email). To enable correct grouping of the different transmissions at the
authorised agency in these cases, the allocation number field should contain a unique identifier.
The list given in Tables F.2-1-1 to F.2-1-4 may need to be supplemented or modified depending on the
actual possibilities of the specific email server.
For the following events, a copy of the informational content as well as the event data should normally be
forwarded to the authorised agency:
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 67
Simple Mail Transfer Protocol (SMTP)
Event Remarks Value of the XML Notes regarding the value of the XML
parameter parameter <partner identifier>
<direction>
Receipt of an Regardless of whether it is ‘received’ In emails intended for the monitored
email delivered directly to the email address, the event data field
monitored user or stored in the <partner identifier> should contain only
mailbox. the sender (Envelope: MAIL FROM as
per RFC 2822), but not the other
recipients (Envelope: RCPT TO as per
RFC 2822).
The identifier of the LuS should be given
in an a RCPT TO field of the envelope or
in the TO field of the header of the email.
Storing an email An email is transferred from the ‘stored’ In emails originating from the monitored
1) monitored user to the email email address, the event data field
server. <partner identifier> should contain the
values of all address fields apart from
Transmission of The email server transmits a ‘sent’ the LuS (ENVELOPE: RCPT TO as per
an email stored email. RFC 2822)
Forwarding of an Emails which are received and ‘sent’
email subsequently forwarded.
Table F.2-1-1 Events for ‘SMTP’
1) The event ‘storing an email’ is also available for stored or modified drafts of an email, irrespective of the protocol
used, even if such drafts are e.g. initially stored without an email address or subject line.
Permissible methods of authentication:
Upon connection, the SMTP server normally performs explicit authentication by means of SMTP-
AUTH.
The subscriber first logs into his mailbox via the POP server, authenticating himself by means of
his access details (user name and password). He is then given a limited time window to send
emails via SMTP. (‘SMTP after POP’). The requirement for authentication as per Annex F.1.2 is
only fulfilled for appropriately small time windows.
The subscriber is assigned an IP address which serves as the authentication criterion.
If an email provider is also an access provider, it is permitted to use the authentication performed
at network login for the email service as well.
Authentication is not relevant for the ‘received’ event, as incoming emails should always be forwarded in
monitored telecommunications.
Post Office Protocol Version 3 (POP3)
Event Remarks Value of the XML Notes regarding the value of the XML
parameter parameter <partner identifier>
<direction>
Retrieval of an The monitored user retrieves a ‘retrieved’ In emails intended for the monitored
email complete or partial email from his email address, the event data field
mailbox (e.g. only the header, <partner identifier> should contain only
subject or attachment). the sender, not the other recipients. The
value to be inserted is found in the
MAIL-BODY.
Table F.2-1-2 Events for ‘POP3’
Permissible methods of authentication:
The user logs in to his email mailbox, by login to the website1 or on the POP3 server and
authenticates himself with his login data (login name and password) before emails can be
retrieved.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 68
internet Message Access Protocol (IMAP)
Event Remarks Value of the XML Notes regarding the value of the XML
parameter parameter <partner identifier>
<direction>
Storing an email A message produced by an email ‘stored’ For these emails, the event data field
2) client is stored in an IMAP <partner identifier> should contain the
directory (using the IMAP combined values of all address fields,
command APPEND) and then apart from the LuS. The value to be
synchronised with the server. inserted is found in the MAIL-BODY.
Retrieval of an The user to be monitored ‘retrieved’ In emails intended for the monitored
email retrieves an email from his email email address, the event data field
mailbox; in whole or in part (e.g. <partner identifier> should contain only
only the header, ‘subject’ or the sender, not the other recipients. The
attachment). However, in IMAP, value to be inserted is found in the
only those emails should be MAIL-BODY.
monitored which are transmitted
between client and server as part
of a synchronisation of folders (as
new email).
Table F.2-1-3 Events for ‘IMAP’
2) The event ‘storing an email’ is also available for stored or modified drafts of an email, irrespective of the protocol
used, even if such drafts are e.g. initially stored without an email address or subject line.
Permissible methods of authentication:
The subscriber first logs into his mailbox by logging onto the website1 or the IMAP server,
authenticating himself by means of his access details (login name and password), before emails
may be retrieved, stored or moved.
1 applies to webmail services based on IMAP or POP3.
Notes on the above tables:
Repeated transmission to the authorised agency of data sets with identical content between
different physical parts of a logical IMAP server is only permitted if this is the result of Fetch or
Append commands for synchronisation of server or client folders.
Email received by the SMTP server and then immediately forwarded to an email address
predefined by the user of the mailbox should also be monitored. The parameter <direction>
should have the value ‘received’ upon receipt, and ‘sent’ upon subsequent transmission.
The copy of each email being monitored must be combined relating to the event with the
associated event data corresponding to Table F.2-1 in Annex F.2.1 in a single XML-encoded file
each time. The full copy of the email, i.e. address fields, subject, main text and possibly
attachments, must be coded according to Base64. After the Base64 encoding, a line break must
be included after 76 characters.
The XML-encoded file is transmitted to the authorised agency via FTP. With regard to the layout
of the file name, FTP parameters, security using a VPN, and the procedure in case of difficulties
in transmission, see Annexes A1 to A4.
Annex F.2.1 Parameters for event data
The individual parameters for event data, which are typically combined with the copy of the content into
an XML-encoded file for transmission to the authorised agency, are listed in the following table:
Parameters Definition/explanation
<version identifier> identifier allocated by the operator of the STS, and which designates the relevant interface
version
<data set type> ‘report’ as identifier of a unique event
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 69
Parameters Definition/explanation
<reference number> identifier of the surveillance action, pursuant to § 7(2) sentence 1 of the TKÜV, in
ASCII format (1 to 25 positions, character subset 'a'…'z', 'A'…'Z', '-', '_', '.', and '0'…'9').
The permitted character subset corresponds to the implementations as per ETSI or 3GPP.
<allocation number> Matching to the informational content
Here, the Message ID (according to RFC 2822) of the monitored email should be used. It can
be copied from the email header or envelope data.
<identifier of the LuS> attribute of the identifier under surveillance pursuant to § 7(1) sentence 1 point 1 TKÜV (e.g.
email address or user id of the mailbox)
<partner identifier>1 identifier pursuant to §7(1) sentence 1 points 2 to 4 TKÜV
The value of the parameter depends on the particular protocol (see Table F.2-1-1 to F.2-1-3).
More than one partner identifier should be included, separated by ‘;’ (ASCII character no 59).
<IP> The known IP address of the email client from the point of view of the email server, from
which email is set or retrieved or settings are made.
<port> The identifier of the transfer protocol used (e.g. HTTP, SMTP, POP3).For implementations
based on edition 4.1 of the TR TKÜV, port numbers (e.g. 80, 25, 110) may only continue to be
used if these details are given corresponding to the respective well-known ports.
<start> start of monitored telecommunication (e.g. time of receipt of an email message) according to
§ 7(1) sentence 1 point 8 of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
The file with event data and/or informational content should not be transmitted to authorised
agencies until after completion of the monitored telecommunications procedure.
<settings> Contains two details which should be separated by ‘;’ (ASCII character no 59).
1. Details of the following settings:
‘access’ (successful login by the mailbox owner), ‘mailing lists (including changes)’,
‘messaging’ (e.g. settings for the notification service ), ‘forwarding’ (e.g. settings for
forwarding of email), ‘email address’ (e.g. creation or deletion of an additional email
address in the monitored mailbox)
2. followed by specification of the settings (parameters) in the format: free ASCII-encoded
text.
<direction> Details of the event being reported pursuant to Tables F.2-1-1 to -4:
‘received’, ‘retrieved’, ‘sent’, ‘stored’, ‘delivered’.
If several events are almost simultaneous, e.g. storing and sending, two values may be
inserted, separated by ‘;’ (ASCII character no 59).
<cause of termination at Indication of the reason why the monitored connection was closed, e.g.
monitored line> ‘successful’ or
error message from the system as a text string, e.g. interruption of a download. The
text string may contain only the ASCII characters of the Base64 encoding.
<Start of surveillance Once for each action, with the time of deactivation of the action (not of administration in case
action> of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
<end of surveillance Once for each action, with the time of deactivation of the action (not of administration in case
action> of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
Table F.2.1: Parameters for event data in the XML file
1 During evaluation, the receiving authorised agency must take account of the fact that amended Other party
identifications cannot in principle be recognised (e.g. ‘
[email protected]’ instead of the actual email
address).
Annex F.2.2 XML structure and DTD
The XML-encoded file should be created in UTF-8 format.
The following example of an XML structure has values included for all tags. These tags should, however,
only be transmitted if the relevant event requires them. If there are no parameters for the relevant event
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 70
data, an empty tag should be used in accordance with XML syntax, e.g. “<Start of surveillance action/>”.
Comment lines are not required and may be omitted.
XML structure:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE hi3-email SYSTEM "hi3-email_v1.dtd">
<?xml-stylesheet href="Email_v1.xsl" type="text/xsl"?>
<hi3-email>
<version identifier>ABC1234</version identifier>
<data set type>report</data set type>
<reference number><![CDATA[123456789 in Base64 encoding 1]]></reference number>
<sequence number><![CDATA[0474745765656 in Base64-encoding 1]]></sequence number>
<identifier-of the-monitored-line><![CDATA[
[email protected] in Base64 encoding 1]]></identifier-of
the-monitored-line>
<IP>111.222.63.254</IP>
<port>SMTP</port>
<partner identifier><![CDATA[
[email protected];
[email protected] in Base64 encoding 1]]></partner
identifier>
<start>31/12/06 10:10:05</start>
<settings><![CDATA[forwarding; free text in Base64 encoding 1]]></settings>
<direction><![CDATA[retrieved in Base64 encoding 1]]></direction>
<cause-of-termination-at-monitored-line><![CDATA[successful in Base64 encoding 1]]></cause-of-termination-at-
monitored-line>
<start-of-surveillance-action>01/12/06 01:00:00</start-of-surveillance-action>
<end-of-surveillance-action>01/02/07 01:00:00</end-of-surveillance-action>
<email>
<!-- start email-->
<![CDATA[ the copy of the monitored email in Base64 encoding 1]]>
<!-- end email-->
</email>
</hi3-email>
Doctype definition:
<!ELEMENT hi3-email (version identifier,data set type,reference number,sequence number,identifier-of the-
monitored-line,IP,port,partner identifier,start,settings,direction,cause-of-termination-at-monitored-line,start-of-
surveillance-action,end-of-surveillance-action,email)>
<!ELEMENT version identifier (#PCDATA)>
<!ELEMENT data set type (#PCDATA)>
<!ELEMENT reference number (#PCDATA)>
<!ELEMENT sequence number (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT IP (#PCDATA)>
<!ELEMENT port (#PCDATA)>
<!ELEMENT partner identifier (#PCDATA)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT settings (#PCDATA)>
<!ELEMENT direction (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT start-of-surveillance-action (#PCDATA)>
<!ELEMENT end-of-surveillance-action (#PCDATA)>
<!ELEMENT email (#PCDATA)>
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 71
1
The values of the individual tags and the copy of the email to be monitored must be integrated base64-encoded
according to RFC 822 or RFC 2045. Please note that the Base64 encoding requires a line break to be inserted every
76 characters.
Annex F.3 Email transmission point according to ETSI TS 102 232-02 (from
Version 2.1.1)
As an alternative to the nationally specified transmission point pursuant to Annex F.2, it is also permitted
to design the transmission point according to ETSI TS 102 232-02 [30].
The principles as per Annex F.1 apply in this regard.
When a full copy of a given email has already been transmitted to the authorised agency, it suffices to
send only the event data in the case of further eVENTs (email events) as described in Section 6,
ETSI TS 102 232-02 (e.g. subsequent retrieval of the email). To enable correct grouping of the different
transmissions at the authorised agency in these cases, a unique identifier should be assigned.
In addition to the events defined in TS 102 232-02, changes in settings for the email address or mailbox
should be notified where they occur within the effective period of the surveillance order. The relevant
values should be entered in the ASN.1 field National-EM-ASN1parameters of the ASN.1 module as
defined in TS 102 232-02. Annex A.3 defines the associated national ASN.1 module (see requirement to
report settings as per Annex F.3.1.2).
Depending on the event recorded, the ASN.1 parameter 'Email Recipient List' should be assigned the
relevant value (see requirement as described in Annex F.3.1.2).
Annex F.3.1 Selection of options and stipulation of additional technical
requirements
Annex F.3.1.1 Basis: ETSI TS 102 232-01
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-01 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
Section Description of the option or problem point and Supplementary requirement, background or
TS 102 232- definitions for the national application additional information
01
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
5.2.3 Authorisation country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ should The communication identity number identifies the IRI
be used. The operator identifier is assigned by the and CC of a communication process: this corresponds
Federal Network Agency pursuant to Annex A.1 to the allocation number pursuant to § 7(2) sentence 2
and always begins with ‘49...’. TKÜV.
The network element identifier is assigned by the
network operator. It identifies the network element
on which the telecommunication is recorded.
5.2.5 Sequence number
The allocation number should already be created If this condition cannot be met - in exceptional cases -
when the surveillance copy is produced for the first it should be ensured that this function is created in the
time (interception point). Delivery Function at the latest. However, if the
sequence number is not created until then, it should
reflect the exact counting method at the place of origin.
If UDP is used on this segment, additional measures
should be taken to prevent potential package losses
and secure the sequence order.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 72
Section Description of the option or problem point and Supplementary requirement, background or
TS 102 232- definitions for the national application additional information
01
5.2.6 Payload timestamp
All times (TimeStamp) should normally be given From TR TKÜV edition 7.0 and later, only the Micro-
based on the official time (local time) as: SecondTimeStamp should now be used.
MicroSecondTimeStamp (with maximum resolution If the time stamp is not available at the interception
and accuracy). point in the format of the MicroSecondTimeStamp, the
The MicroSecondTimeStamp must be created time stamp must be generated in this format as closely
where the surveillance copy is produced for the first as possible to the recording point of the surveillance
time (interception point). copy.
5.2.11 Interception point identifier
The interception point identifier is assigned by the
network operator. It identifies the logical point
(inside a network element) at which the data (IRI
and/or CC) are recorded in the network.
6.2.2 Error Reporting
The transmission is in accordance with Annex A.4
of the TR TKÜV.
6.2.3 Aggregation of payloads
Combined transmission of monitored IP packets is However, it should not span more than a few seconds
foreseen in order to avoid an unnecessary and should be agreed with the Federal Network
overhead. Agency.
6.2.5 Padding Data
May optionally be implemented by the obligated Action-specific use of padding must be agreed with the
party. relevant authorised agency.
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Normally based on § 3.1 of the TR TKÜV, under
which the Delivery Function should trigger to avoid
unnecessarily keeping the lines of the authorised
agency busy.
6.3.4 Keep-alives
May optionally be implemented by the obligated After the successful transmission of data, the TCP
party. connection should normally be closed by means of a
timer. Action-specific use of Padding Keep-alives,
where the TCP connection is kept alive indefinitely,
must be agreed by the relevant authorised agency.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen on The port number applies to applications of the service
the part of the authorised agency (destination port). specifications TS 102 232-02, TS 102 232-03,
TS 102 232-04, TS 101 909-20-2, TS 102 232-05 and
TS 102 232-06.
7.1 Type of Networks
Forwarding occurs over the public internet.
7.2 Security requirements
The requirements as per Annex A.2 of the TLS and signatures and hash codes may not be used.
TR TKÜV apply.
7.3.2 Timeliness
Any use of separate managed networks should be
agreed between the obligated party and the
authorised agencies.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 73
Annex F.3.1.2 Basis: ETSI TS 102 232-02
The following table describes the selection of options for the different chapters and sections of ETSI
specification TS 102 232-02 and also specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
Section Description of the option or problem point and Supplementary requirement, background or
TS 102 232- provisions for national application additional information
02
6.2.3, 6.3.3, IRI information
6.4.3 The IRI informations for the events ‘email send’, See also the point 'email format'
‘email receive’ and ‘email download’, as described
in Tables 1, 2 and 3, should always be transmitted.
7 Email attributes
The email attributes should be sent according to 7.3 Email recipient list
the requirements of the specification. This applies, In emails intended for the monitored identifier, only the
in particular, to the attribute “AAAInformation”. In sender should be included, not the other recipients
addition, the following requirements should be such as CC and/or BCC recipients.
complied with.
7.10 AAAInformation
Parameters of POP3 or SMTP authentication, such as
‘user name’, ‘password’, ‘authMethod’, etc. should also
be reported.
A.4, B.4, C.2 HI2 event-record mapping
In addition to the events described here, the The transmission of settings should use the national
settings for the following service attributes should ASN.1 module pursuant to Annex A.3.2 of this
be reported: TR TKÜV, which should be sent to the authorised
agency by means of the ASN.1 module of TS 102 232-
- Mailing lists (including changes), 02.
- Messaging (e.g. settings for a notification
service)
- Forwarding (automatic forwarding of emails)
When monitoring a mailbox, the following should
also be reported:
- Email address (e.g. addition or deletion of an
additional email address in the mailbox)
Annex D Email format
When using well-known ports and when For IRI-Only actions, they should nevertheless be
implementing the email format ‘ip-packet’, the parts included.
of the IRI information ‘client address’, ‘server
address’, ‘client port’ and ‘server port’ need not be
reported as they can be deduced from the relevant
IP or TCP header data.
Annex F.3.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 TKÜV, on
the applicable ETSI and 3GPP standards and specification, including the associated ASN.1 modules. Use
of the different versions of the national ASN.1-module is also regulated. Annex X.4 contains further
explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Annex F.3 should
be taken from the various versions of ETSI Specifications TS 102 232-01 and TS 102 232-02, taking care
to correct any errors in the ASN.1-modules contained in them (e.g. incorrect domainID). Because FTP is
used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Without a corresponding update on the side of the
authorised body, it may not be possible to interpret all parameters.
Parameters designated as 'conditional' or 'optional' in the specifications should be transmitted if they are
available and the relevant specifications, or Annex F.3 where applicable, does not contain any contrary
provisions.
TR TKÜV, edition 8.0 (draft) Part A, Annex F, page 74
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Annex A.3.
TR TKÜV, edition 8.0 (draft) Part A, Annex G, page 75
Annex G Stipulations regarding the internet
gateway (ETSI TS 102 232-03, 102 232-
04 and TS 101 909-20-2)
This Annex describes the conditions for the transmission point according to ETSI specifications TS 102
232-03 [31], TS 102 232-04 [32] and TS 101 909-20-2 [33] for those transmission channels (e.g. xDSL,
CATV, WLAN) which are intended for direct subscriber access to the internet.
Each of these ETSI specifications uses the relevant general IP-based transmission point as described in
ETSI specification TS 102 232-01 [29].
The Annex addresses the decision made with respect to options contained in the specifications, as well
as additional technical requirements.
If, in addition to the internet access service, broadcast distribution services or similar services intended for
the general public (e.g. IP television, video on demand) are provided through this internet gateway by
means of platforms or feed points operated by the operator of the internet gateway, for which no
measures need to be taken under § 3(2) point 4 of the TKÜV, then the relevant telecommunication
portions should - if possible - be left out of the surveillance copy of the internet access.
If, on the other hand, personalised distribution services are provided which are not provided to the
general public (e.g. distribution of privately produced content to closed user groups), then such
telecommunication portions are not covered by the exemption under § 3(2) point 4 TKÜV and should
therefore be recorded as part of the surveillance action.
Under § 7(1)(9), the public IP addresses of the users involved, as known by the obligated party’s
telecommunications system, must be reported.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.2 Participation in a VPN via a cryptobox.
As the surveillance copy is transmitted over the internet via TCP/IP, the procedure for
participation in VPN should also be followed.
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
TR TKÜV, edition 8.0 (draft) Part A, Annex G, page 76
Annex G.1 Selection of options and stipulation of additional technical
requirements
Annex G.1.1 Basis: ETSI TS 102 232-01
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-01 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
Section Description of the option or problem and Additional requirement, background and
TS 102 232- stipulations regarding national application supplemental information
01
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
5.2.3 Authorisation country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ should The communication identity number identifies the IRI
be used. and CC of a communication process: this corresponds
The operator identifier is assigned by the Federal to the allocation number pursuant to § 7(2) sentence 2
Network Agency pursuant to Annex A.1 and always TKÜV.
begins with ‘49...’.
The network element identifier is assigned by the
network operator. It identifies the network element
on which the telecommunication is recorded.
5.2.5 Sequence number
The allocation number should already be created If this condition cannot be met - in exceptional cases -
when the surveillance copy is produced for the first it should be ensured that this function is created in the
time (interception point). Delivery Function at the latest. However, if the
sequence number is not created until then, it should
reflect the exact counting method at the place of origin.
If UDP is used on this segment, additional measures
should be taken to prevent potential package losses
and secure the sequence order.
5.2.6 Payload timestamp
All times (TimeStamp) should normally be given From TR TKÜV edition 7.0 and later, only the Micro-
based on the official time (local time) as: SecondTimeStamp should now be used.
MicroSecondTimeStamp (with maximum resolution If the time stamp is not available at the interception
and accuracy). point in the format of the MicroSecondTimeStamp, the
time stamp must be generated in this format as closely
The MicroSecondTimeStamp must be created as possible to the recording point of the surveillance
where the surveillance copy is produced for the first copy.
time (interception point). .
5.2.7 Payload direction
The unambiguous designation of the path taken by
content data shall be tracked with to target and
from target.
5.2.11 Interception point identifier
The interception point identifier is assigned by the
network operator. It identifies the logical point
(inside a network element) at which the data (IRI
and/or CC) are recorded in the network.
6.2.2 Error Reporting
The transmission is in accordance with Annex A.4
of the TR TKÜV.
TR TKÜV, edition 8.0 (draft) Part A, Annex G, page 77
Section Description of the option or problem and Additional requirement, background and
TS 102 232- stipulations regarding national application supplemental information
01
6.2.3 Aggregation of payloads
Combined transmission of monitored IP packets is However, it should not span more than a few seconds
foreseen in order to avoid an unnecessary and should be agreed with the Federal Network
overhead. Agency.
6.2.5 Padding Data
May optionally be implemented by the obligated Action-specific use of padding must be agreed with the
party. relevant authorised agency.
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Normally based on § 3.1 of the TR TKÜV, under
which the Delivery Function should trigger to avoid
unnecessarily keeping the lines of the authorised
agency busy.
6.3.4 Keep-alives
The basic requirements set out in Part A, § 3.3, are After the successful transmission of data, the TCP
to be observed for the obligatory use of keep- connection should normally be closed by means of a
alives. timer. Action-specific use of keep-alives, where the
TCP connection is kept alive indefinitely, is subject to
approval by the relevant authorised agency.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen on The port number applies to applications of the service
the part of the authorised agency (destination port). specifications TS 102 232-02, TS 102 232-03,
TS 102 232-04, TS 101 909-20-2, TS 102 232-05 and
TS 102 232-06.
7.1 Type of Networks
Forwarding occurs over the public internet.
7.2 Security requirements
The requirements as per Annex A.2 of the TR TLS and signatures and hash codes may not be used.
TKÜV apply.
7.3.2 Timeliness
Any use of separate managed networks should be
agreed between the obligated party and the
authorised agencies.
Annex G.1.2 Basis: ETSI TS 102 232-03
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-03 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
03
4.3.1 Target Identity
The requirements under Part A, § 4 TR TKÜV For instance, implementations of surveillance based on
apply. Any deviating technical implementation a cable modem identifier are possible, but should take
should behave accordingly. into account that another cable modem could be
connected to the monitored internet gateway, or the
“monitored” cable modem could be connected to
another internet gateway.
TR TKÜV, edition 8.0 (draft) Part A, Annex G, page 78
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
03
4.3.2 Result of interception
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded as
based on the official time (local time). universal time and without time difference.
6.1 Events
The events and HI2 attributes from Version 1.4.1 of Version 1.4.1 supplemented the event
the ETSI specification should be used. ‘startOfInterceptionWithSessionActive’.
8 ASN.1 for IRI and CC
For these cases, defined in § 7(3) TKÜV, the For these cases, only the ASN.1 data of the
ASN.1 description for ‘IRIOnly’ need not be ‘IPIRIContents’ need be transmitted in addition to the
implemented. administrative data (e.g. LIID). This complies with the
requirement that in this type of surveillance order, only
the CC part need not be transmitted.
Annex G.1.3 Basis: ETSI TS 102 232-04
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-04 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
04
4.2.1 Target Identity
The requirements under Part A, § 4 TR TKÜV For instance, implementations of surveillance based on
apply. Any deviating technical implementation the MAC address of a modem are possible, but should
should behave accordingly. take into account that another modem could be
connected to the monitored internet gateway, or the
“monitored” modem could be connected to another
internet gateway.
4.3.2 Result of interception
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded as
based on the official time (local time). universal time and without time difference.
6.1 Events
The events and HI2 attributes of Version 1.3.1 of In Version 1.3.1, the event ‘End of Interception
the ETSI Specification should be used. Session_Active’ was deleted.
8.2 ASN.1 specification
For the cases described in § 7(3) TKÜV, the ASN.1 In these cases, opening and closing a Layer2 tunnel is
description for ‘IRIOnly’ may be implemented the only known option.
instead of the description of the ASN.1 data
‘L2IRIContents’.
Annex G.1.4 Basis ETSI TS 101 909-20-2
The following table describes the selection of options for the different chapters and sections of ETSI
specification TS 101 909-20-2 and also specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
TR TKÜV, edition 8.0 (draft) Part A, Annex G, page 79
§ of TS 101 Description of the option or problem point, Supplementary requirement, background or
909-20-2 definitions for national application additional information
4.2 Architecture
An implementation based on EuroDOCSIS is Depending on the design of the STS, particularly of the
assumed. service scope, the Federal Network Agency may
prescribe the use of a particular version of the
standard.
5 LI architecture for IP multimedia Time Critical
Services
The specification refers to the remarks in ES/TS The exact details of the surveillance device,
101 671. particularly the events and their associated
parameters, should be agreed with the Federal
Network Agency.
Annex A ASN.1 modules
The module used, ‘TS101909202’, has syntax A corrected version is available at
errors. http://www.bundesnetzagentur.de/tku.
Addendum 1 Target Identity
The provisions of Part A, § 4 TR TKÜV apply. Implementations of surveillance based on the MAC
address of a modem are possible in principle, but
should take into account that another modem could be
connected to the monitored internet gateway, or the
‘monitored’ modem could be connected to another
internet gateway.
Addendum 2 Timestamps
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded as
based on the official time (local time) universal time and without time difference.
Annex G.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 TKÜV, on
the applicable ETSI and 3GPP standards and specification, including the associated ASN.1 modules. Use
of the different versions of the national ASN.1-module is also regulated. Annex X.4 contains further
explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Annex G should be
taken from the various versions of ETSI Specifications TS 102 232-01, TS 102 232-03, TS 102 232-04
and TS 101 909-20-2, taking care to correct any errors in the ASN.1-modules contained in them (e.g.
incorrect domainID). Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Without a corresponding update on the side of the
authorised body, it may not be possible to interpret all parameters.
Parameters designated as 'conditional' or 'optional' in the specifications should be transmitted if they are
available and the relevant specifications, or Annex G.1 where applicable, does not contain any contrary
provisions.
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
if the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Annex A.3.
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 80
Annex H Determinations for VoIP, other fixed
multimedia services and fixed network
IMS platforms (ETSI TS 102 232-05, -06
and 101 909-20-1)
This Annex describes the conditions for the transmission point according to the
ETSI Specifications TS 102 232-05 [34] for IP multimedia services and TS 101 909-20-1 for the
IP Cablecom architecture, and according to ETSI Specification TS 102 232-06 [35] for emulated
PSTN/ISDN services. This ETSI specification uses the general IP-based transmission point as described
in ETSI Specification TS 102 232-01 [29]. Where use of an IMS platform is shared, or when identical IMS
platforms are used for mobile and landline telecommunications, the use of an interface in accordance with
Annex D must be agreed upon with the Federal Network Agency.
So far, it has also been permissible for VoIP services to set up the surveillance technology based on the
circuit-switched technology described in Annex C. The use of this interface, including for multimedia
services beyond that, is no longer permitted for new implementations. The time limits set out in Annex C
must be observed for existing implementations.
Offers of VoIP and other multimedia services within GPRS and UMTS networks remain unaffected by this
installation, as Annex D already describes transfer points in this respect.
The Annex addresses the decision made with respect to options contained in the specifications, as well
as additional technical requirements.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.2 Participation in a VPN via a cryptobox.
As the surveillance copy is transmitted over the internet via TCP/IP, the procedure for
participation in VPN should also be followed.
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 81
Annex H.1 Fundamental requirements for use of ‘Service-specific details for IP
multimedia services´ (TS 102 232-05 and TS 101 909-20-1)
The ETSI specification TS 102 232-05 describes a transmission point for VoIP and other multimedia
services which are based on the Session Initiation Protocol (SIP), the ITU-T Standards H.323 and H.248
and the Realtime Transport Protocol (RTP).
The ETSI Specification TS 101 909-20-1 may be used in networks designed according to the
IP Cablecom architecture.
Annex H.1.1 Definitions
Multimedia server Telecommunication systems based on SIP, H.323 or H.248, in conjunction
(VoIP server) and with the media stream (e.g. RTP), which participate in the provision of the
participating network VoIP service or another multimedia service.
elements
VoIP identifier The VoIP identifier designates the telecommunication under surveillance.
This term is used as a general designation for the various types of possible
identifiers.
VoIP account An account set up for the user in order to manage a number of VoIP
identifiers collectively. A monitored VOIP account may sometimes contain
several VoIP identifiers.
Login Process in which a user’s access permission to his VoIP account is checked.
The login name used at login as part of the access identifier is also an
Login name identifier used to denote the telecommunication under surveillance.
Annex H.1.2 Basic principles
An order for surveillance of telecommunications may contain, as a technical identifier:
a VoIP identifier; or
the access identifier (login name without password) of a VoIP account.
To implement surveillance of the entire telecommunication which takes place under the given VoIP
identifier, care should be taken that the monitored telecommunication is actually associated with the LuS
by using suitable authentication methods. This should prevent situations where, for example, a VoIP
communication which should be monitored fails to be recorded because the sender address was
manipulated by the user.
If this requirement cannot be fulfilled (e.g. due to an unsuitable authentication method), a VoIP identifier-
based surveillance order for the entire VoIP account should be implemented, which should include the
telecommunication of all VoIP identifiers pertaining to this account.
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy delivered
(see Annex H.3.2, point 5.3). Data pursuant to § 7(1) TKÜV that exists on the net when the surveillance
action is activated and is no longer forwarded as future event data (e.g. codecs of the existing
telecommunication) must also be reported. Since there is currently no standard dictating the technical
implementation in detail, the compulsory implementation of this requirement is deferred for the time being,
as long as signalling information and informational content are present in various network elements, and
provided that no information for operational purposes regarding the points at which the voice data (e.g. IP
address, port address) can be forwarded and correlated is provided.
Under § 7(1)(9) and (10), the public IP addresses of involved users known by the obligated party’s
telecommunications system and the known encoding used when transmitting the telecommunication
under surveillance must be reported.
Annex H.1.3 Completeness of event data
When using the two ETSI specifications, it is assumed that the signalling information used for the service
is sufficient to describe the monitored events. Where this cannot be achieved, the event data should be
transmitted via the HI2Operations module as described in Annex C, which contains more parameters in
addition to the transmission of a copy of the SIP signalling, which can be used to supplement the missing
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 82
information. Such information may, for example, be available in network elements (e.g. SIP proxy,
conference server, web interface for user settings).
When setting up the surveillance technology, it should be kept in mind that pursuant to § 5(1) TKÜV,
every signalling message associated with the monitored identifier should be included. To prevent multiple
registration of signalling messages without producing new information with regard to the event data as
described in § 7 of the TKÜV (e.g. identifiers, services used), the number of surveillance points used
should be kept to the minimum required. This should prevent, for example, repeated registration of an
INVITE message at different hops within the network, which merely add the details of the various hops.
However, it is not required to include logic for filtering and, where needed, suppression of the messages
recorded at the relevant surveillance points before delivering them to the transmission point.
Annex H.1.4 Delivery of informational content in case of separate transmission
of signalling
The event data and informational content produced on the basis of the signalling messages should
normally be delivered to the transmission point. According to ETSI Specification TS 102 232-05, the
informational content consists of the totality of RTP and RTCP packets as well as any other protocols
conveying the media stream (e.g. gateway protocols). In some cases, however, the content is transmitted
separately from the signalling by other operators, particularly in the case of VoIP. The following options
are available for providing informational content:
1. The VoIP provider himself operates network elements through which the content is transmitted.
These network elements may include the following:
a) the internet gateway, regardless of whether it is based on a dedicated or leased subscriber line
(but not including entire resale products such as Resale DSL from DTAG),
b) the hub which contains the connection point to the internet,
c) the transport or connection network for the content, or
d) the transmission point to and from the PSTN (e.g. Media Gateway).
This Annex H prescribes the more detailed requirements for this.
2. The provider of VoIP uses a particular operator of network elements as described in 1. for
transmitting the content. In addition to rules in Annex H, there is also a possibility of
implementation pursuant to § 170(1) sentence 1 point 2 of the Telecommunications Act.
However, the task of arranging the corresponding interaction is reserved for the obligated
supplier of the VoIP.
Where the content and event data are delivered separately, it should be ensured - pursuant to § 7(2) of
the TKÜV - that these parts contain a uniform reference number and allocation numbers.
If the user information is to be monitored by means of a special routing, e.g. to a central network node,
particular attention must be paid to the fact that this cannot be determined by the VoIP users involved in
the telecommunications pursuant to § 5(4) TKÜV.
Annex H.2 Fundamental requirements for use of ‘Service-specific details for
PSTN/ISDN services’ (ETSI TS 102 232-06)
ETSI Specification TS 102 232-06 creates a possibility for emulated PSTN and ISDN services to use a
purely IP-based transmission point. In this option, the copy of the telecommunication is transmitted as an
RTP data stream over the general IP-based transmission point according to TS 102 232-01. In addition,
the event data, which are encoded in the HI2Operatons module according to Annex C, are also
transmitted using TS 102 232-01; here, FTP transmission as described in Annex C should not be used.
Annex H.3 Selection of options and stipulation of additional technical
requirements
Annex H.3.1 Basis: ETSI TS 102 232-01
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-01 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 83
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- provisions for national application additional information
01
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
5.2.3 Authorisation country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ should The communication identity number identifies the IRI
be used. and CC of a communication process: this corresponds
to the allocation number pursuant to § 7(2) sentence 2
The operator identifier is assigned by the Federal TKÜV.
Network Agency pursuant to Annex A.1 and always
begins with ‘49...’.
The network element identifier is assigned by the
network operator. It identifies the network element
on which the telecommunication is recorded.
5.2.5 Sequence number
The allocation number should already be created If this condition cannot be met - in exceptional cases -
when the surveillance copy is produced for the first it should be ensured that this function is created in the
time (interception point). Delivery Function at the latest. However, if the
sequence number is not created until then, it should
reflect the exact counting method at the place of origin.
If UDP is used on this segment, additional measures
should be taken to prevent potential package losses
and secure the sequence order.
5.2.6 Payload timestamp From TR TKÜV version 7.0, only the Micro-
SecondTimeStamp now has to be used.
All times (TimeStamp) should normally be given
based on the official time (local time) as: If the time stamp is not available at the interception
MicroSecondTimeStamp (with maximum resolution point in the format of the MicroSecondTimeStamp, the
and accuracy). time stamp must be generated in this format as closely
as possible to the recording point of the surveillance
The MicroSecondTimeStamp must be created copy.
where the surveillance copy is produced for the first
time (interception point).
5.2.7 Payload direction
The unambiguous designation of the path taken by
content data shall be tracked with to target and
from target.
Encoding information
As a rule, there are various optional encodings for In practice, the codec used (if known to the network)
the audio data available to the terminal. The codec must be reported as an event datum with simple
actually used for transferring the audio data and forwarding of the IRI data. If the IRI data is recorded at
known to the network has to be transmitted as an different points in the network and if different codecs
event datum pursuant to § 7(1) TKÜV. happen to be forwarded (e.g. change of codec in the
(The reference to the existing legal situation was network), the Interception Point Identifier should help
included in the TR TKÜV owing to the use of to bring together the relevant IRI data set and the
different codecs in part unknown to the analysis forwarded informational content (audio data) (see
system.) 5.2.11).
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 84
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- provisions for national application additional information
01
5.2.11 Interception point identifier
The interception point identifier is assigned by the The Interception Point Identifier serves to help improve
network operator. It identifies the logical point the labelling of the coherent IRI data in the event of
(inside a network element) at which the data (IRI multiple forwarding of IRI data (e.g. via different
and/or CC) are recorded in the network. recording points) and, if possible, to merge the codec
described via the IRI data set with the forwarded
informational content (audio data) If more than one
codec is reported in the IRI data, this requirement
should be implemented as follows:
If the audio data codec is changed within the network,
the CC data for forwarding should be provided with the
same Interception Point Identifier as the associated IRI
data set containing the correct codec.
Should the above-described correction not be possible,
then alternative methods should be agreed with the
Federal Network Agency.
6.2.2 Error Reporting
The transmission is in accordance with Annex A.4
of the TR TKÜV.
6.2.3 Aggregation of payloads
Combined transmission of monitored IP packets is However, it should not span more than a few seconds
foreseen in order to avoid an unnecessary and should be agreed with the Federal Network
overhead. Agency.
6.2.5 Padding Data
May optionally be implemented by the obligated Action-specific use of padding must be agreed with the
party. relevant authorised agency.
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Normally based on § 3.1 of the TR TKÜV, under
which the Delivery Function should trigger to avoid
unnecessarily keeping the lines of the authorised
agency busy.
6.3.4 Keep-alives
May optionally be implemented by the obligated After the successful transmission of data, the TCP
party. connection should normally be closed by means of a
timer. Action-specific use of keep-alives, where the
TCP connection is kept alive indefinitely, is subject to
approval by the relevant authorised agency.
The basic requirements set out in Part A, § 3.3, are
to be observed for the obligatory use of keep-
alives.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen on The port number applies to applications of the service
the part of the authorised agency (destination port). specifications TS 102 232-02, TS 102 232-03,
TS 102 232-04, TS 101 909-20-2, TS 102 232-05 and
TS 102 232-06.
7.1 Type of Networks
Forwarding occurs over the public internet.
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 85
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- provisions for national application additional information
01
7.2 Security requirements
The requirements as per Annex A.2 of the TLS and signatures and hash codes may not be used.
TR TKÜV apply.
7.3.2 Timeliness
Any use of separate managed networks should be
agreed between the obligated party and the
authorised agencies.
Annex H.3.2 Basis: ETSI TS 102 232-05
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-05 and, on the other, specifies the respective additional
requirements. Unless otherwise indicated, the references in the table relate to the respective sections of
the ETSI specification:
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
05
4.3 General Requirements
Copies of the signalling messages (e.g. SIP The concept should explain the parameters denoting
Messages) are normally transmitted as event data. the various individual services (e.g. basic call, call
forwarding) or combinations of messages, with
examples. Individual services which can be controlled
by users’ terminals (clients) should also be explained
in terms of any known changes in their signalling or
RTP stream behaviour, e.g. simultaneous RTP
sessions in conferences; updates should be provided
for any subsequent extensions.
Event data which are not part of the signalling must For the transmission of all event data, the module
also be transmitted. HI2Operatons from Annex C shall be used, using a
separate parameter for the SIP messages; the module
itself should be transmitted according to the
requirements of TS 102 232-06.
No general mapping, such as is defined, for
example, by ANS T1.678, is included.
5.2.2 Provisioning of the H.323 IRI IIF
The exact signalling messages of the various
different protocols in the H.323 family which should
be sent as event data should be agreed with the
Federal Network Agency for individual cases.
5.3 Assigning a value to the CIN
The CIN is normally assigned at the start of a new The first signalling message (e.g. INVITE) shall be
session with the first signalling message (CC or designated as IRI-BEGIN and all subsequent signalling
IRI). messages (e.g. INVITE from SIP server for partner
identifier) shall be designated as IRI-CONTINUE. The
If a session already exists at activation of the last (expected) signalling message shall be designated
surveillance action, the CIN should be generated IRI-END.
together with the first IRI or CC message.
If a telecommunications link to the monitored identifier
already exists at the time of activation of a surveillance
action, then both telecommunication content and event
data should be recorded from this time onwards and a
copy delivered.
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 86
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
05
5.3., 5.3.1 Assigning a CIN value to SIP related IRI
The description assumes that the Call ID and the The requirement to generate a unified CIN for the
‘O’ field of the SDP are used to generate a uniform individual communication sessions applies regardless
CIN (allocation number) for the call as a whole. of whether the described parameters can in fact be
used.
For processing different media streams within one
session, the stream identifier as described in § 5.5
should be used.
5.4 Events and IRI record types
The different call-specific event data are reported The option to send all event data as REPORT is not
as IRI-BEGIN, IRI-CONTINUE and IRI-END; a later allowed.
event (after an IRI-END) should be reported as IRI- In certain exceptional cases which are to be agreed on
REPORT, as indicated. beforehand with the Federal Network Agency, it is
permissible to report data from an existing session
partially as REPORT. (This may, for example, be a call
forwarding scenario in which the session is initially
reported as BEGIN/CONTINUE/END and after
forwarding as REPORT.)
Only one event per session may be designated as IRI-
BEGIN and one as IRI-END.
In other words, the first signalling message (e.g.
INVITE) shall be designated as IRI-BEGIN and all
subsequent signalling messages (e.g. INVITE from SIP
server for partner identifier) shall be designated as IRI-
CONTINUE. The last (expected) signalling message
shall be designated IRI-END.
5.5 Interception of Content of Communication
If the obligated party used encryption on the If the obligated party supports encryption of peer-to-
network side or it is involved in generating or peer-communications over the internet by means of
exchanging keys, thereby allowing it to decrypt the key management provided by him, without involving
telecommunication, the encryption at the handover his network elements or those of his partners in the
point must be lifted (§ 8(3) TKÜV). This applies in transmission of the content, he should at least inform
cases according to H.1.4 where the informational the authorised agency of the key initially exchanged by
content needs to be provided. him with his telecommunication system. The required
procedure should be agreed with the Federal Network
Agency.
Transmission of the exchanged key is not required if
the obligated party can still remove the encryption by
means of additional network elements.
In case of several media streams within one
session, the stream identifier should be used.
7 ASN.1 specification for IRI and CC
The iPSourceAddress and iPDestinationAddress Reporting internal IP addresses of the network, e.g.
parameters shall be used to transmit the IP where the IP addresses of the communicating partners
addresses of the communicating partners as known are available at the network boundaries but not directly
to the obligated party’s network. on the VoIP server, does not comply with the provision.
If information on the location of the terminal as
defined in § 7(1) point 7 TKÜV cannot be reported,
then this IP address shall also be used as location
information. This temporary solution applies until
the transmission of the correct locational
information.
Annex H.3.3 Basis: ETSI TS 101 909-20-1
The following table describes the selection of options for the different chapters and sections of ETSI
specification TS 101 909-20-1 and also specifies additional requirements. Unless otherwise indicated, the
references in the table relate to the respective sections of the ETSI specification:
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 87
Section Description of the option or problem point, Supplementary requirement, background or
TS 101 909- definitions for national application additional information
20-1
Event data which are not part of the signalling must The concept should explain the parameters denoting
also be transmitted. the various individual services (e.g. basic call, call
forwarding) or combinations of messages, with
examples. Individual services which can be controlled
by subscribers’ terminals (clients) should also be
explained in terms of any known changes in their
signalling or RTP stream behaviour (e.g. simultaneous
RTP sessions in conferences); updates should be
provided for any subsequent extensions.
For the transmission of all event data, the module
HI2Operatons from Annex C shall be used, using a
separate parameter for signalling; the module itself
should be transmitted according to the requirements of
TS 101 232-06.
5 Functional Architecture
An implementation based on EuroDOCSIS is Depending on the design of the STS, particularly of the
assumed service scope, the Federal Network Agency may
prescribe the use of a particular version of the
standard.
5.2 Functional Components
The specification refers to the remarks in ES 201 The exact details of the surveillance device,
671 and TS 101 671. particularly the events and their associated
parameters, should be agreed with the Federal
Network Agency.
4.4 Interworking Considerations
If the obligated party used encryption on the If the obligated party supports encryption of peer-to-
network side or it is involved in generating or peer-communications over the internet by means of
exchanging keys, thereby allowing it to decrypt the key management provided by him, without involving
telecommunication, the encryption at the handover his network elements or those of his partners in the
point must be lifted (§ 8(3) TKÜV). This applies in transmission of the content, he should at least inform
cases according to H.1.4 where the informational the authorised agency of the key initially exchanged by
content needs to be provided. him with his telecommunication system. The required
procedure should be agreed with the Federal Network
Agency.
Transmission of the exchanged key is not required if
the obligated party can still remove the encryption by
means of additional network elements.
Annex A ASN.1 modules
The modules used, ‘PCESP’ and ‘TS101909201’, A corrected version is available at
have syntax errors. http://www.bundesnetzagentur.de/tku.
Addendum 1 ASN.1 specification for IRI and CC
When this interface is used, the IP addresses of the See in this regard the remarks on Chapter 7 in the
communicating partners must be reported. description of the use of this interface pursuant to
TS 102 232-05 in Annex H.3.2.
Addendum 2 Timestamps
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded as
based on the official time (local time) universal time and without time difference.
Annex H.3.4 Basis: ETSI TS 102 232-06
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 232-06 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the ETSI
specification:
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 88
Section Description of the option or problem point, Supplementary requirement, background or
TS 102 232- definitions for national application additional information
06
5.2 Structures
The event data are encoded using the
HI2Operations module as described in
Annex C and transmitted directly with
TS 101 232-01 using the ETSI671IRI
parameter.
The copy of the content is transmitted in the
form of RTP packets with UDP and IP headers
as per TS 102 232-06 and TS 102 232-01, by
means of the PstnIsdnCC parameter.
The necessary information for interpretation of
the RTP packets is also transmitted by means
of the PstnIsdnIRI parameter via TS 102 232-
06 with TS 102 232-01.
6.2 CC format
If the obligated party used encryption on the If the obligated party supports encryption of peer-to-
network side or it is involved in generating or peer-communications over the internet by means of
exchanging keys, thereby allowing it to decrypt the key management provided by him, without involving
telecommunication, the encryption at the handover his network elements or those of his partners in the
point must be lifted (§ 8(3) TKÜV). This applies in transmission of the content, he should at least inform
cases according to H.1.4 where the informational the authorised agency of the key initially exchanged by
content needs to be provided. him with his telecommunication system. The
associated procedure should be agreed with the
Federal Network Agency
Transmission of the exchanged key is not required if
the obligated party can still remove the encryption by
means of additional network elements.
6.2, 6.3.2 Supplementary information
G.711 should be used as the default
(mediaAttributes = ‘1’)
A copy of the entire SDP message should always Transmission of the entire SDP message provides the
be sent in the copyOfSDPMessage field authorised agency with a complete copy of the
(mandatory); the optional individual fields telecommunication; it also prevents any errors which
sessionName and sessionInfo are not required the obligated party might make when extracting the
(optional). individual parameters.
Addendum 1 ASN.1 specification for IRI and CC
When this interface is used, the IP addresses of the See in this regard the remarks on Chapter 7 in the
communicating partners must be reported. description of the use of this interface pursuant to
TS 102 232-05 in Annex H.3.2.
Annex H.4 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 TKÜV, on
the applicable ETSI and 3GPP standards and specification, including the associated ASN.1 modules. Use
of the different versions of the national ASN.1-module is also regulated. Annex X.4 contains further
explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Annex H should be
taken from the various versions of ETSI Specifications TS 102 232-01, TS 102 232-05, TS 102 232-06
and TS 101 909 20-1, taking care to correct any errors in the ASN.1-modules contained in them (e.g.
incorrect domainID). Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
Parameters referred to as ‘conditional’ or ‘optional’ in the specifications should normally be transmitted if
they are available and unless stipulated otherwise in the relevant specifications or Annex H.2.
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 89
if the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
if no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Annex A.3.
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 90
Annex I Provisions for messaging services
(ETSI TS 103 707 and ETSI TS 102 232-
02)
The use of the interface described in this Annex becomes mandatory one year after the entry into force of
the provisions of the Telecommunications Act in conjunction with the TKÜV and this Technical Guideline
to the TKÜV, which include an obligation to make arrangements for the implementation of legally
foreseen telecommunications surveillance measures also for number-independent interpersonal
telecommunications services.
For messaging services which are provided on the basis of proprietary and non-uniform protocols and for
which surveillance technology to be developed individually is also to be used regularly to meet the legal
requirements of another European country, it is specified that the interface described here must be
established no later than two years after the entry into force of the above-mentioned regulation in the
Telecommunications Act in conjunction with the TKÜV.
The Annex describes the conditions for the XML/HTTP based transmission point according to ETSI
specification TS 103 707 [39] and for the ASN.1/TCP based transmission point according to ETSI
specification TS 102 232-02 [30] for messaging services.
ETSI specification TS 103 707 [39] uses the IP-based transmission procedure described in ETSI
specification TS 103 120 [38]. The transmission of the order for the surveillance of telecommunications
and related messages, such as the specific activation of a measure, shall continue to be carried out in
accordance with Part B of this edition and not in accordance with the procedure described in ETSI
specification TS 103 120.
In addition, it is possible to use the ASN.1/TCP-based transmission point in accordance with the ETSI
specification TS 102 232-02 [30] in cases where the provisions in this specification and in Annex F are
sufficient to meet the requirements of the TKÜV. This ETSI specification uses the general IP-based
transmission point as described in ETSI Specification TS 102 232-01 [29].
When using the two methods, it may be necessary to additionally provide the transmission point
according to the ETSI specification TS 102 232-05 as specified in Annex H.
If the surveillance technology to be provided is also used to meet another country’s legal requirements, it
is possible to deviate from the requirements of Annex A.2. Intended deviations must be coordinated with
the Federal Network Agency before the surveillance technology is put into operation.
The use of ETSI specifications TS 103 707 [39] and TS 103 120 [38] is subject to consultation with the
Federal Network Agency until further notice. The use of the ETSI specification TS 102 232-02 [30] is
subject to the conditions of Annex F.3.
In addition to the requirements of Part A, §§ 3 and 4, the following Annexes are valid:
Annex Contents
Annex A.2 Participation in a VPN via a cryptobox.
As the surveillance copy is transmitted over the internet via TCP/IP, the procedure for
participation in VPN should also be followed. Intended deviations in accordance with Annex
I must be agreed with the Federal Network Agency prior to commissioning.
Annex A.3 Transmission of HI1 events and additional events
Annex A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following Annexes in Part X TR TKÜV:
Annex X.1 Proposed changes to the TR TKÜV
Annex X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference
numbers
TR TKÜV, edition 8.0 (draft) Part A, Annex I, page 91
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Annex X.5 Requirements for administration and logging in the organisational implementation of
surveillance actions
TR TKÜV, edition 8.0 (draft) Part B, page 92
Part B Technical implementation of legal
measures for the disclosure of
information
TR TKÜV, edition 8.0 (draft) Part B, page 93
1 Basic principles
This part B of the TR TKÜV describes, on the basis of § 170(6) Telecommunications Act [21] in
conjunction with §§ 9 and 12 TTDSG and § 174(7) and § 177(3) Telecommunications Act,
1. the technical details to be observed in connection with disclosure requests from authorised agencies
and the disclosure of information concerning subscriber and traffic data by the obligated service
providers and network operators,
2. the technical characteristics of the required sending and receiving lines of the obligated parties and
authorised agencies, and
3. the requirements to ensure a particularly high standard of data security and data quality pursuant to §
180(1) Telecommunications Act for the transmission of traffic data subject to storage pursuant to §
177(3) sentence 1 Telecommunications Act.
The use of the interface described in this Annex will also become mandatory for number-independent
interpersonal telecommunications services one year after the entry into force of the Telecommunications
Act regulations in conjunction with TKÜV and Guideline for the TKÜV, which maintain an obligation to
make arrangements to provide information on subscriber and traffic data.
For messaging services which are provided on the basis of proprietary and non-uniform protocols and for
which an information technology to be developed individually is also to be used regularly to meet the legal
requirements of another European country, it is stipulated that the interface described here must be
established no later than two years after the entry into force of the above-mentioned regulation in the
Telecommunications Act in conjunction with the TKÜV. In such cases, the requirements of Annex A.2
may be waived. Intended deviations must be agreed with the Federal Network Agency before the
information technology is put into operation.
Furthermore, additional optional applications for the interface are described in this Part B of the TR
TKÜV, which serve to enhance the effectiveness of the overall procedure.
This part also describes the technical details for the secure electronic transmission of orders for traffic
data disclosure and telecommunications surveillance pursuant to § 12(2) TKÜV, and for other
applications.
The transmission methods described in this Part B of the Guideline for the TKÜV must or can (identifier
‘optional’) be used for the following purposes:
a. subscriber data disclosure;
b. traffic data disclosure;
c. transmission in real time of the order for the forwarding of traffic data;
d. disclosure of the structure of radio cells1 (optional);
e. disclosure to identify the location (optional),
f. transmission of the telecommunications surveillance order;
g. transmission of data for accounting reconciliation in preparation for compensation pursuant to §
23(1) of the German Judicial Remuneration and Compensation Act (optional).
For better readability, the term ‘disclosure’ is used synonymously in this Guideline for the TKÜV for the
request to provide information (request), for the transmission of the order (warrant) and for the provision
of information (response).
2 Transmission methods ETSI-ESB and Email-ESB
The transmission methods described in Annexes A and B below must be used according to Part 4 of the
TKÜV as follows:
1 For the purposes of this Guideline, a radio cell is the area covered by a mobile radio antenna that has been
allocated its own cell identifier.
TR TKÜV, edition 8.0 (draft) Part B, page 94
The transmission method ETSI-ESB (Annex A) must be used for disclosing information on
subscriber data and traffic data and for receiving corresponding orders from obligated parties
pursuant to § 174(7) Telecommunications Act.
Other obligated parties according to Part 4 of the TKÜV may use this transmission method as an
alternative to the Email-ESB transmission method, with the possibility of mixed operation for
different applications (e.g. ETSI-ESB for traffic data information, including transmission of the
associated order, and Email-ESB for disclosing subscriber data), subject to agreement from the
Federal Network Agency.
The email-ESB transmission procedure (Annex B) must be used to respond to requests for
information on traffic data under Part 4 of the TKÜV by obliged entities who are not obliged under
§ 174(7) Telecommunications Act to maintain ETSI-ESB (Annex A).
As an alternative, obligated parties may use the ETSI-ESB transmission method as defined in the
above provision.
These transmission methods can be used for other applications in accordance with § 1.
The encrypted ESB transmission method still used previously can be provided in addition as an
alternative to Email-ESB subject to agreement from the Federal Network Agency, provided the relevant
requirements are adhered to similarly. Other transmission methods and a local transfer are excluded if
the systems are also available for traffic data disclosures pursuant to § 176 Telecommunications Act.
Unsafe transmission procedures, such as the unencrypted transmission by email or the postal sending of
unencrypted data carriers, are also inadmissible outside the use of the reserved systems for the
forwarding of traffic data pursuant to § 176 Telecommunications Act.
These requirements apply accordingly, pursuant to § 1(1) point 7 TKÜV, to the recording lines of the
authorised agencies, even in the case of the shared use of central incoming interfaces. In addition to this,
the operation of the Email-ESB outside the authorised agencies, the obligated parties or their agents is
not permitted.
3 Guaranteeing data security and data quality
3.1 Fundamental requirements
The requirements under § 14(1) TKÜV essentially apply, whereby the obligated party has to provide
state-of-the-art protection against unauthorised use in connection with the technical and organisational
precautions taken to implement measures and transmission to the receiving device of the authorised
agency.
Transmissions to the authorised agency must be encrypted; the relevant procedures are set out in the
following descriptions of the transmission procedures.
The requirements of § 14(3) TKÜV also apply to the administration of network elements via public
networks for the surveillance of telecommunications or for the retrieval of information data, including the
storage of necessary information in these network elements. When implementing these requirements, the
relevant international standards and the recommendations of the BSI must be followed.
3.2 Special requirements for the transmission of storage-required
traffic data according to § 176 Telecommunications Act
Pursuant to the first sentence of § 177(3) in conjunction with the first sentence of § 180(1)
Telecommunications Act, a particularly high standard of data security and data quality is to be ensured
when transmitting traffic data pursuant to § 176 Telecommunications Act.
The Federal Network Agency, together with BSI and BfDI, has developed the catalogue of requirements
pursuant to § 180 Telecommunications Act, which is presumed to comply with the legal requirements laid
down in §§ 176 to 179 Telecommunications Act.
These following special requirements apply to the transmission methods described for this, provided they
are used
exclusively for provision of traffic data according to § 176 Telecommunications Act or
TR TKÜV, edition 8.0 (draft) Part B, page 95
are used in addition to other content permitted under Section 1 above for disclosing information
on traffic data pursuant to § 176 Telecommunications Act.
The following image from the catalogue of requirements shows a possible version of the overall
architecture:
Netz des Verpflichteten Physisch zutrittgesicherte Umgebung für das
Verkehrsdatenspeichersystem
Datenquellen Ablage- Zugriffs
Datenspeicher Abfragesystem
system -system
Firewall Firewall
Schlüssel-
Kontroll- und
management
Filtereinrichtung
Rufnummern
nach § 11 TTDSG
Firewall Firewall ETSI-ESB
Bestandsdaten-
speicher, ...
Wartungszugänge
Berechtigte Stelle
Figure: Implementation example of the basic architecture (source: Catalogue of requirements according to § 180
Telecommunications Act)
Netz des Verpflichteten Network of the obligated party
Physisch zutrittgesicherte Umgebung für das Physically secure environment for the
Verkehrsdatenspeichersystem traffic data storage system
Ablagesystem Storage system
Datenspeicher Data storage
Zugriffs-system Access system
Abfragesystem Query system
Kontroll- und Filte reinrichtung Control and filter setting
Rufnummern nach § 11 TTDSG Call numbers under § 11 TTDSG
Schlüssel-management Key management
Wartungszugänge Maintenance access
Bestandsdaten-speicher, ... Subscriber data memory, ...
Berechtigte Stelle Authorised agency
In accordance with the requirements set out in § 180 Telecommunications Act, the following requirements
apply in particular to the transmission under § 177(3) Telecommunications Act:
3.2.1 Ensuring particularly high standards of data security
All the elements of the ETSI-ESB and Email-ESB transmission methods, starting from the query
system and as far as the transfer point for the encrypted transfer (dedicated internet connection)
to the authorised agency, have to fulfil the requirements for IT baseline protection of BSI with the
protection requirement "high" (see IT baseline protection approach, BSI Standard 100-2).
3.2.2 Use of particularly secure encryption methods, buffering in the transmission process
components and deletion of traffic data in the query system
During transmission, traffic data have to be encrypted using a suitable procedure. The following
descriptions of the two transmission methods include corresponding requirements.
No encryption methods other than those mentioned therein may be used.
As regards the forwarding of traffic data pursuant to § 176 Telecommunications Act, the
requirements set out in § 180 Telecommunications Act provide that traffic data should be
TR TKÜV, edition 8.0 (draft) Part B, page 96
decrypted in the access system. To transmit the query results through the query system as part
of the transmission procedure, they can be temporarily buffered unencrypted in the RAM or
encrypted in the persistent memory, with the requirement that the keys used should be renewed
regularly.
When the query system and the transmission method are used for additional disclosures of
information according to the above § 1, it must be ensured that the connection of further systems
necessary for this is secured using a firewall. The content relating to the firewall configuration and
the log files applies accordingly to paragraph 5.2.4 of the requirements catalogue pursuant to §
180 Telecommunications Act.
Plain data that arises when processing search queries in the query system and transmission
process (decrypted traffic data and other temporary data) must be deleted from the RAM directly
after transmission. In addition, unsecured outsourcing (swapping) of sensitive data from the RAM
must be prevented. Moreover, the requirements as per § 5.2.5 of the requirements catalogue
pursuant to § 180 Telecommunications Act must be observed.
3.2.3 Implementation of the four-eyes principle in the case of access to and transmission of
traffic data
To be able to process information requests from authorised agencies by employees specially
authorised by the obligated party, there must be controlled access to the query system according
to the four-eyes principle. The specially authorised persons must provide authentication with
individual user IDs to the query system. The relevant logging requirements set out in the TKÜV
should be met in doing so.
Depending on the method of transmission employed, the query system has to be designed so that
the two specially authorised persons are able to undertake the following checks:
a) ETSI-ESB transmission procedure
When using ETSI-ESB, the order and relevant query parameters are transmitted by the
authorised agency. The two persons with special access authorisation shall verify in separate,
independent stages the agreement of the query parameters contained in a judicial order or
public prosecutor’s order or in an information request by an authority with the query parameters
made ready for access.
Within the query system, it should be ensured that the query parameters prescribed by the
authorised agency cannot be altered by revision on the part of the obligated party. In the event
of any errors or a lack of clarity, feedback must be sent to the authorised agency in accordance
with the section on the treatment of errors. If there is an error on the part of the authorised
agency, the process must be restarted (it is not admissible to arrange a correction through the
obligated party by telephone, for example).
b) Email-ESB transmission procedure
When using Email-ESB, no predefined query parameters apart from the order and any further
explanatory notes are transmitted by the authorised agency. The query parameters for access
to the traffic data must be determined in a first step by the first of the two persons specially
authorised to do this.
The first person shall set the query parameters in accordance with the judicial or prosecutorial
order or the official request for information in the query system.
The second person shall verify in a separate, independent further stage the agreement of the
query parameters contained in the judicial order or information request by an authority with the
query parameters made ready for access.
If the outcome is positive, the second person shall initiate access to the traffic data and similarly
instigate transmission of the query results to the authorised agency.
TR TKÜV, edition 8.0 (draft) Part B, page 97
If the outcome is negative, the query parameters must be readjusted between the two verifiers.
If no clear result is possible, this must be fed back to the authorised agency with indication of
the flaws detected.
If there is an error on the part of the authorised body, the process must be restarted (a
correction by the obliged person, for example, by telephone consultation with the authorised
body is inadmissible).
3.2.4 Physically securing the transmission procedure
The query systems and other parts of the transmission process must be physically protected from
access by persons without special authorisation.
3.3 Time until traffic data is available
The systems for supplying traffic data from network elements of their own telecommunications network
must be designed in accordance with § 31(3), sentence 3 TKÜV such that data collected can be retrieved
by the authorised agency at the latest within 24 hours of the actual event. They may deviate from this in
individual cases.
It should be noted that the anticipated period between collection and availability for retrieval must be
stated in the supporting documents.
TR TKÜV, edition 8.0 (draft) Part B, page 98
Annex A ETSI-ESB transmission method
This Annex describes the national requirements for the ETSI-ESB transmission method based on the
ETSI specification, TS 102 657.
1.1 Basic description of the procedure
The procedure is essentially based on the mechanisms described in ETSI specification TS 102 657.
Since this specification requires further, nationally defined technical elaboration and has no defined
requirements in Germany (e.g. a surveillance order obligation), additional provisions are needed which go
beyond mere selection of options to address the specification as such.
The basic transmission mechanism requires one recipient and one sender each at both the authorised
agency and the obligated undertaking, through which an initial request message is sent by the authorised
agency to the undertaking, following which the requested data are transmitted in a separate response
message.
These protocols are typically initiated through electronic transmission of the surveillance order (AO) in a
warrant request, followed by one or more actual queries, contained in separate data requests. Since the
ETSI specification does not distinguish between warrant and data requests, these concepts relate to the
uniform request as described there.
The procedure is shown below for a single disclosure request and associated information on traffic data
for various identifiers and in different periods:
Authorised Businesses
agency
Authori Req Recipient Busines
sed s
Req (TIFF metadata)
agency
Sender
XML
Testing Req TIFF ord
HTTP OK er
Metadata
TIFF ord
er
Metadata
Other data Recipient
Response ReqAck
Sender
XML
Scanner
ReqAck Testing
HTTP OK
AO
SINA VPN
1. The administration of the request by the authorised agency includes entering all the required
metadata for the warrant request and an electronic copy of the order. The metadata contain the
information on the surveillance order for the various identifiers and periods for the actual electronic
processing. Where the metadata refer to several requested identifiers, they shall be assigned
consecutive numbers in the form of a targetNumber. In addition to this, other data not intended for
transmission (e.g. reference numbers, frequency of disclosure) may be administered. The warrant
request is automatically identified by a distinct request number (e.g. 4711).
2. The receipt of the warrant request and automatic verification of its legibility and completeness is
followed by manual verification and clearance of the metadata encompassed by the surveillance
order that are to be used for the disclosure of information by the person(s) expressly authorised for
this by the obligated party. Clearance must take place only if the metadata correspond to the
details of the surveillance order.
Clearance takes place with reference to the relevant surveillance order for all identifiers and periods
referred to by the latter; such clearance is identified by the request-Number of the warrant request
(here 4711).
Every specific request for traffic data requires a separate data request:
1. Based on the settings of the AA system, a separate data request is sent manually or automatically,
which contains the request with respect to a particular identifier and a particular period. This data
TR TKÜV, edition 8.0 (draft) Part B, page 99
request is in turn identified by a distinct requestNumber (e.g. 4922) and refers to the warrant
request through the latter’s requestNumber as a referencedRequestNumber (here 4711). In
addition, the targetNumber refers to the sequential number in the metadata of the warrant request.
2. The receipt of the data request and automatic verification of its legibility and completeness is
followed by automatic verification against the metadata and targetNumber as laid down through the
clearance. If the specific requested identifier and period are covered by the metadata, disclosure
then proceeds automatically.
The data collected with respect to the identifier on which the request is based is transmitted in a
separate response message identified through the requestNumber of the data request (here 4922).
Messages from the undertaking are transmitted using the same procedure but with the roles
reversed.
1.2 Procedural requirements
Use of ETSI definitions and national addenda
The delivery of an electronic surveillance order and associated metadata in the warrant request
and the subsequent data requests requires the use of a national XML definition Natparas2,
transmitted through the XML module of the ETSI specification.
Other uses (e.g. subscriber data, tracing) require the transmission of the additional XML definition
Natparas3 for the transmission of the response data using the response message.
Inconsistency of the metadata with the surveillance order If the metadata in the warrant
request does not correspond to the information in the surveillance order, the data for this part of
the warrant request shall not be cleared for disclosure. In this case, a ResponseIncomplete
message as defined in § 2.2.2.4 shall be returned with an automatically readable list
(TargetNumber) of the identifiers considered invalid.
Error-free requests with respect to other identifiers, which do correspond to the surveillance
order, shall be cleared for disclosure.
After approval from the authorised agency, the procedure shall be re-initiated with a separate
warrant request if there is still a need for the information covered by the incorrect entries. In this
case, the new warrant request may contain either:
- a corrected surveillance order with unchanged metadata for the relevant identifier, or:
- an unchanged surveillance order with corrected metadata for the relevant identifiers.
In case information requests are not issued for some identifiers listed in the surveillance order, no
metadata shall be entered for them (this does not require an error message).
Rejection of an entire warrant request is only required in cases where fundamental errors are
present or suspected (e.g. in case of a garbled electronic copy of the surveillance order, or
absent or incorrect metadata). This shall also be indicated by means of a FailureResponse
message as defined in § 2.2.2.3.
Parallel transmission of warrant and data request It is common for a warrant request to be
transmitted together with the first few associated data requests. The receiving system of the
undertaking should accordingly have a mechanism in place enabling it to immediately process
received data requests as soon as the associated warrant request is cleared.
Separate procedures for different uses of the interface
To achieve as simple a query system process as possible, any combination of the applications
listed in ‘1. Basic principles’ is not permitted. Different uses require different warrant-requests,
even if the same electronic arrangement is used and the same identifier is affected.
Several identifiers per warrant request, one identifier per subsequent request or
order Every actual request or order (e.g. data request, activation request, etc.) contains exactly
one specific identifier (where, in addition to the forms described in Chapter 4.1 of Part A of this
TR TKÜV, an identifier may also consist of several components, e.g. a name and address, if this
is needed for unambiguous identification), the meta-requests in the warrant request may contain
TR TKÜV, edition 8.0 (draft) Part B, page 100
several identifiers to reflect a possible multiple specification in the surveillance order.
Special issues when transmitting orders to implement surveillance measures
Parallel to the disclosure of traffic data, this interface can be used to transmit orders to implement
monitoring measures in accordance with § 1.3.6.
Use of unified formats and parameters
Similarly to the requirements of Part A of the TR TKÜV, the ETSI specification provides for
various options for the disclosure of data (e.g. IP address in ASCII or binary format). Where the
undertaking needs to convert available data into one of these formats before disclosure, the
encoding specified in Section 2.2.3 must be used. The authorised agencies must use the
encodings listed there in their requests. In Section 2.2.4, it is also specified which XML
parameters are used if the structure of the ETSI specification allows alternative parameters
(standardisation).
Use of newer versions and format requirements of the national XSD and of ETSI-XSD
Obligated parties may only routinely use newer versions of the national XML modules and of the
ETSI XSD six months after their publication. The Federal Network Agency will publish on its
website an overview of the usable modules and any differing transitional deadlines, as well as
details on which modules may not be used for first-time implementations. During the transitional
period, the data not yet defined in the previous version and the legal basis shall be disclosed
using the parameters <additionalInformation> and <other_LegalBasis>, respectively. In Section
2.2.3, the Federal Network Agency stipulates formats for data and shall publish on its website the
standardised information that should also be used from the legal bases.
The authorised agencies must support and use the versions used by the individual obligated
parties. Pursuant to § 170(8) Telecommunications Act, obligated parties must update older
versions. To this end, the aforementioned overview shall contain an implementation period
(optionally also based on requirements).
In the case of version conflicts, an error message is presented pursuant to Section 2.2.2.2,
containing the supported version.
Differences from the requirements of the ETSI specification In order to simplify the
procedure, and to meet the specific requirements in Germany, the following differences shall
apply with respect to the mechanism as defined in the ETSI specification:
1. In order to enable requests for traffic data from all services used (e.g. telephone service,
internet access) by a given identifier, the response message may contain the traffic data for
different services, contrary to Chapter 6.2.1 of the ETSI specification.
2. In order to have a standardised scheme for data requests, only the telephony part of the
ETSI specification is applied. Consequently, in order to request the traffic data for all processes
involving an email address, for example, this email address may be entered in the email
address field under partyInformation in the telephony area. Section 2.2.3.4 also permits
combined disclosure. Through an extension of the field 'nationalTelephonyServiceUsage', this
also enables disclosure of the internet access service via disclosure for the telephony service.
Requirements for the encryption procedure to be used
When using the ETSI-ESB transmission method, only the systems specified in Annex A.1 of this
part of the TR TKÜV and those in the current policy (Annex X.3) are provided for with the
encryption procedures mentioned therein.
The systems do not store the data to be transferred. The automated logging of the transfers does
not contain any indications of the nature of the data transferred.
1.3 Specifics of the different applications
The specifics of the different applications are described below.
TR TKÜV, edition 8.0 (draft) Part B, page 101
1.3.1 Traffic data disclosure
The disclosure of traffic data requires the transmission and verification of a warrant request before
automatic processing of data requests can begin. It is mandatory that the surveillance order be
transmitted over this interface. Separate transmission of data requests enables the authorised agency to
individually specify the frequencies and periods based on information from the obligated company on the
archival periods of the traffic data kept by them. Therefore, no set disclosure intervals are specified for
future queries. The data request shall only be sent once the query period provided therein has elapsed.
The information disclosure follows immediately.
Pursuant to the second sentence of § 177(3) Telecommunications Act, the identification of traffic data to
be reported is mandatory in accordance with §§ 9 and 12 TTDSG (operational traffic data) and § 176
Telecommunications Act (stored traffic data). For the disclosure of large data volumes, Section 5.1.7 of
the ETSI specification provides for transmission in several parts.
1.3.1.1 Forwarding of forward-looking traffic data for an urgent order
The needsConfirmation flag must always be set in the warrant request for the retrieval of future traffic
data initiated by an urgent order. The judicial confirmation is done by a warrant request in which the flag
isConfirmation is set.
1.3.1.2 Correction of a decision already implemented
In order to correct a decision that has been conditionally implemented - for example, due to suboptimal
readability of an original fax transmission - with a new decision, the authorised body sends a warrant-
request in which the flag isCorrection has been set.
1.3.1.3 Extension of an order
Active actions may be renewed only by a new decision. For this purpose, a warrant request with a new
end time is transmitted to the obligated party and DataRequests are sent as required.
1.3.1.4 Selection of the type of traffic data
For a better understanding of whether traffic data is to be reported with or without location data, each
warrant request contains a corresponding label (LocationCriteria). A further label specifies whether the
traffic data was generated before the decision date or after the decision date. If both elements are set to
false, no location data will be disclosed.
1.3.1.5 Data source
Each warrant-request contains unique information about the origin of the data source. The choice is
between operational traffic data and traffic data stored on the basis of a legal obligation (cf. ‘Act
introducing a storage obligation and maximum retention period for traffic data’).
1.3.1.6 Automatic delivery of late records after specification by the authorised
agency
As specified in Section 3.3, the obligated party’s systems must be designed such that data sets within the
network are available for retrieval by the authorised agencies at the latest within 24 hours of the actual
event. The exact time period, which in some cases may be longer, shall be announced by the obligated
party within its supporting documents and can be taken into account by the authorised agencies when
giving deadlines for data requests.
To also obtain external data sets that may become available later (e.g. roaming data), authorised
agencies may deviate from the practice of immediate information disclosure and specify that delayed
traffic data (late records) that only become available after the requested time period in the warrant
request and a waiting period specified by the obligated party for such data sets have elapsed, be
disclosed using a data request labelled accordingly (see Section 3.2.2.3). The waiting period to be agreed
with the Federal Network Agency has to be long enough for late records to be regularly recorded
completely. The disclosure is made in a regular response message and contains all the traffic data stored
at this point for the entire period. This specification may be withdrawn by the authorised agencies in a
cancel message.
TR TKÜV, edition 8.0 (draft) Part B, page 102
1.3.1.7 Selective disclosure of traffic data
Disclosure of traffic data must, in principle, be available in selective form (§ 101a(1) sentence 1 point 1 of
the Code of Criminal Procedure). This necessitates the parameters for disclosure to be provided in
XPATH notation with the aid of the XML element <requestedData> of the ETSI XSD. Contrary to non-
selective disclosure, only the parameters requested by the authorised agency are thereby provided.
When using this XML element, only the selectively requested data is to be transmitted, unlike the
procedure as described in Section 1.3.1.
If the chosen element contains ‘child nodes’, the entire XML subtree below it is deemed to be selected.
Only absolute paths are permissible, i.e. wildcard characters or other search operators or logical links
such as AND, OR or XOR may not be used.
1.3.1.8 Selective disclosure of traffic data in a destination dialling search
Further to the previous section, to disclose traffic data produced for a particular destination address or
from a known phone number (source address) for unknown destination addresses (destination dialling
search), the following parameters are to be filled in the Natparas2 of ETSI-XSD in addition to the labelling
(see Section 3.2.2.3):
Destination dialling search for a known target address:
TelephonyServiceUsage/partyInformation/partyNumber: Target phone number (E.164 format):
Indication of the known destination address
TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole:
Tag number 1, "terminating-Party"
Destination dialling search from a known phone number (source address):
TelephonyServiceUsage/partyInformation/partyNumber: Source address (E.164 format):
Indication of the known origin address
TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole:
Tag number 1, "originating-Party".
1.3.1.9 Early deactivation of individual identifiers of an existing order based on
traffic data
If the authorised agency does not intend to request any additional traffic data on a particular identifier for
the term of the surveillance order, it should inform the obligated party to this effect. To allow for early
deactivation of targets of a valid warrant related to traffic data, a WarrantTarget must be disabled. For this
purpose, the authorised agency sends a warrant in which the DeactivateTarget flag is set for each target
to be terminated prematurely. Targets not listed are not deactivated. As acknowledgement, this is
followed by either ResponseComplete (all changes implemented), ResponseIncomplete (some changes
rejected with error message per target) or ResponseFailed (all changes rejected, again with error
messages).
Any subsequent incoming data requests for deactivated targets are acknowledged with FailureResponse.
The DeactivateTarget flag cannot be used for other purposes.
1.3.2 Disclosure of traffic data in real time
In addition to the remarks in Section 1.3.1, the following applies:
In order to meet real-time requirements, any obligated undertakings under § 32(3) TKÜV with an interface
in place for transmitting the telecommunication under surveillance as defined in Part A shall implement
such disclosure requests by administering an IRI-Only action (provision of data pursuant to § 7 TKÜV). To
implement this, the surveillance technology shall be adapted such that
1. the data transmitted to the agency authorised to receive the information do not contain any
message content,
2. Location data are also collected for terminal equipment ready for reception and transmitted to
the authority authorised to provide information; and
3. the transmission of the location data according to point 2 can be limited such that, for criminal
prosecution authorities, the data is only transmitted in accordance with § 100g(1) of the Code of
TR TKÜV, edition 8.0 (draft) Part B, page 103
Criminal Procedure, or, for another authorised agency, the data is only transmitted in
accordance with the applicable statutory regulations.
Depending on the system, SMS short messages shall be transmitted in the signalling channel. Where
traffic data is disclosed in real time, this SMS informational content should be removed before the data is
forwarded to the authorised agency. Any parameter values, e.g. length information or test totals
describing the original packet size, should not be altered when doing so.
Alternative precautions for implementing such disclosure requests must be equivalent and in agreement
with the Federal Network Agency.
For the associated messages (warrantRequest and dataRequest), according to Section 2.2.1, the port for
transmitting the telecommunication surveillance order is to be used; the cited legal basis distinguishes
between the two uses.
1.3.3 Disclosure of the structure of radio cells
The described interface as well as the procedure described in Section 1.3.1 may optionally be used to
disclose information on the structure of radio cells.
1.3.4 Subscriber data disclosure
In accordance with § 174(7) Telecommunications Act, the use of the described interface as well as the
procedure described in section 1.3.1 is mandatory for all telecommunication providers with 100,000 or
more contractual partners.
The request for subscriber data is delivered with the transmission of the warrant request and data
request. The warrant request must comply with the formal requirements of § 174(2) Telecommunications
Act (including the text form and specification of the legal basis) and includes a respective WarrentTarget
(multiple disclosure is not possible). It also includes the optional list for selective requests. To implement
the required form, the XML element <warrantTIFF> or <warrantTextform> is available.
The data request is then to be sent with the warrant request or immediately afterwards. The content of the
data request does not differ from the warrant request (e.g. no extremely large quantities). For cases
where the ETSI XSD does not contain appropriate fields for request data, the national addendum defines
the necessary fields. If the warrantRequest does not follow a DataRequest (or vice versa) within one
hour, it is completed and a FailureResponse is sent for the warrentRequest (or DataRequest).
The request is processed starting with a formal check of the warrant request by a responsible employee
as soon as the data request is received. An automatic check is not permissible by law. The disclosure is
made after receipt of the data request.
1.3.4.1 Selective disclosure of subscriber data
The forwarding of stock data must also be possible in a selective form. This necessitates the parameters
for disclosure to be provided in XPATH notation with the aid of the XML element <requestedData> of the
ETSI XSD. In contrast to non-selective arrivals, this only answers the parameters requested by the
authorised entity. When using this XML element, only the selectively requested data is to be transmitted,
unlike the procedure as described in Section 1.3.4.
If the chosen element contains ‘child nodes’, the entire XML subtree below it is deemed to be selected.
Only absolute paths are permissible, i.e. wildcard characters or other search operators or logical links
such as AND, OR or XOR may not be used. Where the request includes the data field PUK of ETSI-XSD,
the PTN is also required, which must be reported by the obligated party in the appropriate field
of NatParas3. The data field scope of the type ScopeForSubscriberData specifies the scope of the
request.
The Federal Network Agency publishes on its homepage (www.bundesnetzagentur.de/tku) a table of
possible subscriber data that can be queried, an explanation of the expected result per parameter and the
corresponding x-path.
1.3.5 Disclosure of location
The interface described in the procedure described in Section 1.3.1 can optionally be used for disclosure
of location, for example to avert danger in connection with a surveillance measure or a traffic data
request:
a) location of mobile devices.
TR TKÜV, edition 8.0 (draft) Part B, page 104
b) determination of connection owner for the IP address;
c) disclosure of the name and address of a physical connection or customer ID (LineID);
d) determination of connection owner on the basis of another identifier (OtherID in combination with
OtherIDtype).
The requirements of earliest possible availability of the results of such requests issued at varying
locations (e.g. deployment sites in case of searches for missing persons) and based on locally defined
initiation points of the requests are not always compatible with this type of electronic procedure.
Accordingly, it is often necessary to follow a parallel ‘manual’ procedure, e.g. via telephone.
1.3.6 Transmission of surveillance orders and other telecommunications
surveillance actions
The use of this interface fulfils the requirements under § 12(2), sentence 1 TKÜV for secure electronic
transmission of a copy of the surveillance order. In this case, the original order or a certified copy thereof
need not be presented.
1.3.6.1 Implementation of surveillance actions
Similar to the procedure for traffic data disclosure, implementing surveillance actions initially requires
clearance based on a warrant request; the activation and deactivation of actions is sent in separate
activation and deactivation requests. Several relevant identifiers are referred to through sequential
numbers in the form of a targetNumber.
When using this option, it is necessary to comply with the obligation to log according to § 16 TKÜV,
according to which any application of the monitoring device must be recorded and the obligation thus
applies regardless of whether the application is manual or automated.
The figures below show the procedure for the implementation of a surveillance action with respect to two
different identifiers (Figure A) and for the extension of an action (Figure B):
Activation of ‘Early’
surveillance deactivation of
Order pursuant action for Change of
surveillance
to § 100a of the identifier A with surveillance
action with
Code of Criminal LIID 111222 action with
identifier A
Procedure identifier A
new requestNumber new requestNumber new requestNumber
requestNumber: 56789 referencedRequestNumber: 56789 refReqNumber: 56789 refReqNumber: 56789
LIID: 111222 LIID: 111222
Activation of ‘premature’
surveillance deactivation of
action for surveillance
identifier B with action with
LIID 55555 identifier B
new requestNumber new requestNumber
referencedRequestNumber: 56789 refReqNumber: 56789
LIID: 55555
Figure A: Implementation of a surveillance action for identifiers A and B
TR TKÜV, edition 8.0 (draft) Part B, page 105
Order Activation of
pursuant to § surveillance
100a of the action for
Code of identifier C with
Criminal LIID 454545
Procedure
new requestNumber
requestNumber: 56899 referencedRequestNumber: 56899
Order
pursuant to § ‘premature’
100a of the Renewal of
deactivation of
Code of surveillance
surveillance
Criminal action with
action with
Procedure, identifier C
identifier C
extension
new requestNumber: 57123 new requestNumber new requestNumber
referencedRequestNumber: 56899 refRequestNumber: 57123 refRequestNumber: 57123
LIID: 454545 LIID: 454545
Figure B: Implementation and extension of a surveillance action for identifier C
1.3.6.2 Implementation of urgent surveillance orders
If a surveillance action is to be implemented by means of an urgent surveillance order, the
needsConfirmation flag must be set in the warrant-request. The judicial confirmation is done by a warrant-
request with the flag isConfirmation set.
1.3.6.3 Corrections to the order on actions already implemented
A decision that has been implemented subject to reservation, for example due to suboptimal readability of
an initial fax notification, can be corrected by a new decision. For this purpose, a warrant-request should
be transmitted where the flag isCorrection is set.
1.3.6.4 Switching to actions already implemented
Changes to an active action which do not require an additional surveillance order are implemented
through a modify request.
1.3.6.5 Extension of an order
Active actions may be renewed only by a new decision. For this purpose, a warrant request with a new
end date is transmitted to the obligated party, as well as a renewal request.
Changes to an active action which do require another surveillance order are initiated through a second
warrant request and activated through a second activation request. The second warrant request initiating
the change must not contain the metadata of individual actions or identifiers from the first warrant request
which are not affected by the change.
Similar to the procedure for traffic data disclosure, activation, modification, modify and renewal requests
may be processed automatically after verification against the metadata of the warrant request.
1.3.7 Transmission of data for accounting reconciliation in preparation
for compensation pursuant to § 23(1) of the German Judicial
Remuneration and Compensation Act (optional)
See Section 4.
TR TKÜV, edition 8.0 (draft) Part B, page 106
1.4 Secure electronic transmission of the surveillance order
Processes for secure electronic transmission of the surveillance order as described in accordance with
Part B of the TR TKÜV which use a SINA VPN as defined in Annex A-2, do not require subsequent
transmission of the original or a certified copy of the surveillance order by post.
The stipulation of using a SINA VPN provides for a secure electronic transmission as defined in the
requirements under § 12(2) TKÜV.
When implementing this procedure and the thereby enabled preallocation of administrative areas, it
should, however, be ensured that the order cannot be implemented automatically. Rather, a ‘manual
verification’ must be undertaken for each individual case. Only after such manual verification and
subsequent clearance within the system may an action be activated, either manually or automatically
through further requests.
Format of the order
The order shall be converted into the multipage TIFF format (CCITT Group 4 Fax) for transmission. The
maximum file size is 5 MB. If a follow-up order does not contain all the required data (e.g. legal basis,
identifier, period), they must be transmitted in a single file together with the original order. Copies of the
telecommunications surveillance order that were sent previously via fax must meet minimum quality
requirements. This must correspond at least to the high resolution (203 or 204 dpi horizontally; 196 dpi
vertically) of commonly used fax devices (this usually corresponds to the ‘fine’ setting).
TR TKÜV, edition 8.0 (draft) Part B, page 107
2 Provisions for the transmission point according to ETSI specification
TS 102 657
This section describes the conditions for the transmission point according to
ETSI Specification TS 102 657 [37].
The Annex addresses the decision made with respect to options contained in the specification, as well as
additional technical requirements. Using the XML module described in the ETSI specification, one query
at a time is transmitted; packetisation of multiple queries is not envisaged.
The following Annexes of Part X of the TR TKÜV apply in addition to the requirements of this Part:
Annex Contents
Annex X.1 Proposed changes to the TR TKÜV
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
2.1 Selection of options for ETSI TS 102 657
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI specification TS 102 657 and, on the other, specifies the respective additional
requirements. Unless otherwise indicated, the references in the table relate to the respective sections of
the ETSI specification:
Section Description of the option or problem point Supplementary requirement, background or
TS 102 657 and definitions for the national application additional information
4.1 Reference model
No provision for different Authorized See in this regard the stipulations in this Table with
Organisations for HI-A and HI-B has been respect to Chapter 5.4
made.
4.5 Model used for the RDHI
XML/HTTP shall be used as the transmission See in this regard the stipulations in this Table with
mechanism. respect to Chapter 7, or immediately below this
Table.
5.1.2 Message flow modes
Only the variant General situation according to Requested data shall be transmitted by the obligated
Chapter 5.2 is provided. party directly to the authorised agency (push
procedure).
5.1.5 Errors and failure situations
Errors as defined in 5.1.5.2 shall be reported to See in this regard the stipulations in Section 2.2.2 of
the authorised agency together with a qualified this TR TKÜV immediately after this Table.
error message.
Transmissions with formal errors (errors as
defined in 5.1.5.3) shall be rejected by the
recipient.
5.1.7 Delivery of results
The option single shot delivery must be In the single shot delivery option, there will be exactly
implemented, the option multi-part delivery can one response for each request. For future-related
be implemented. orders for disclosure of information on traffic data,
the authorised agency shall send separate requests
to the undertaking for each relevant surveillance
order, taking account of the periods for which the
relevant data are archived by the undertaking.
The multi-part delivery option allows subdividing a
disclosure into several parts in case of a large
volume of traffic data to be transmitted. If this option
is implemented, the ResponseNumber parameter
TR TKÜV, edition 8.0 (draft) Part B, page 108
Section Description of the option or problem point Supplementary requirement, background or
TS 102 657 and definitions for the national application additional information
must be used. The use and its exact form must be
described in the concept.
For both options, the following additional
requirements apply:
1. The fundamental obligation of telecommunications
undertakings pursuant to §§ 9 and 12 TTDSG to
delete unused traffic data immediately after the
end of the connection remains unaffected,
2. The design of the technical procedure does not
give rise to any obligation or authorisation to store
traffic data within the framework laid down by §§ 9
and 12 TTDSG.
5.5 HI-A and HI-B addressing
The deliveryPointHIB field is not used. Different IP addresses for one Authorised
Organisation are not allowed within a request and the
corresponding response, i.e. source IP address for
HI-A and target IP address for HI-B must be identical.
6.1.2 RequestID field specification
The required Authorized Organization Code The Authorized Organization Code of the authorised
identifier of the authorised agency will be agency corresponds to the authorised agency ID
allocated by the Federal Network Agency. assigned as a unique reference number for
surveillance measures (see in this regard Annex X.2
TR TKÜV).
If the authorised agency fails to receive an ACK
message for a transmitted request, it may Acknowledgement of duplicate RequestNumbers by
resend the same request with the same the obligated party is limited to the information
RequestNumber. This procedure is described in available to him. It does not create any right to
Section 2.2.2.5 of this TR TKÜV. derogate from data protection deletions.
6.1.3 CSP Identifiers
The required identifiers of the obligated party, The CSP ID of the obligated party matches the
CSP ID and Third Party CSP ID, will be Operator ID allocated as part of the obligation under
allocated by the Federal Network Agency. Part A and/or Part B of this TR TKÜV.
6.1.4 Timestamp
The limitations under Section 2.2.3.1 of this TR
TKÜV shall apply
6.3.1 Information contained within a request
6.3.2 Identifiers shall be requested with equals. The following shall not be used:
The range parameters lessThanOrEqualTo and notEqualTo, lessThan, greaterThan, startsWith,
greaterThanOrEqualTo are to be used only for endsWith, isAMemberOf
timestamps.
6.3.3 Additional information in requests
All requests shall have the same priority.
The MaxHits parameter shall not be used.
6.4 Error messages
Error messages must be clear. In the case of
version conflicts, for example, the error
messages must at least contain the expected
version.
7 Data exchange techniques
XML/HTTP shall be used as the transmission See in this regard the stipulations in Section 2.2 of
mechanism. Transmission shall occur over the this TR TKÜV or those immediately after this Table.
public internet using a VPN in accordance with
Annex A-2.
7.2 HTTP data exchange
The Mutual client/server option shall be used. See in this regard the stipulations immediately
following this Table.
TR TKÜV, edition 8.0 (draft) Part B, page 109
Section Description of the option or problem point Supplementary requirement, background or
TS 102 657 and definitions for the national application additional information
7.2.3 Mutual client/server
Uri is uniform for HI-A and HI-B/etsi A host header is not needed.
8 Security Measures
The requirements as per Annex A-2 shall apply.
Annex A Data fields
The Annex describes the data fields used and Examples of common queries and the expected
the stipulations within an ASN.1 definition. The results can be consulted at the Federal Network
applicable XML definition shall be taken from Agency.
the ETSI website together with the ETSI
specification.
2.2 Supplementary technical requirements for the interface specification
under ETSI TS 102 657
The handshake mechanism as described in the ETSI specification requires more stringent national
stipulations than the HTTP transmission method described therein if an error-free interaction of the
various systems is to be ensured.
2.2.1 HTTP transmission method
For electronic transmission to participating undertakings, the latter shall inform the Federal Network
Agency of the addressing information required in this regard (IP address), which is then forwarded to the
authorised agencies.
The port numbers of the respective receiver (destination port) are identical for HI-A and HI-B identical and
are to be used as shown in the following table. If a surveillance order is necessary for the corresponding
request, this will be transmitted via the same port.
Application destination port
Traffic data disclosure 50200
Subscriber data disclosure 50210
Disclosure of location 50220
Transmission of the telecommunications surveillance order, 50230
Disclosure of traffic data in real time
Disclosure of the structure of radio cells 50250
Transmission of accounting information or submitting claims for 50260
compensation pursuant to § 23(1) of the German Judicial Remuneration
and Compensation Act
All messages (Req, ReqAck, Res, ResAck, etc.) shall be transmitted via the POST method each in its
own HTTP session. Successful transmission and server-side validation of the XML message shall be
acknowledged by the server by means of an HTTP 200 (OK). After transmitting the HTTP status codes,
the server shall terminate the connection.
Connection may be terminated after 60 seconds without any activity by the client or server. If the server
terminates the connection, it shall first send an HTTP 408 (request time-out) to the client.
Only one request per HTTP session is permitted; multiple requests must each be contained in their own
HTTP sessions.
Use of “Content-Encoding: gzip” within the client’s HTTP POST request is optional. The server must be
able to process the relevant requests and responses.
TR TKÜV, edition 8.0 (draft) Part B, page 110
In accordance with the XML standard, special characters shall be replaced by the corresponding escape
characters since the validation will otherwise fail.
2.2.2 Error handling
2.2.2.1 Error in encoding of request or disclosure (pursuant to ETSI TS 102
657, Section 5.1.5.3)
If a request/disclosure contains formal errors (invalid XML or missing obligatory parameter), the
HTTP server shall reject it with the HTTP status code 422 (Unprocessable Entity). A clear error message
is to be transmitted in the HTTP body. For example, if the version of the transmitted Natparas does not
correspond to the version expected from the obligated party, the version used by the obligated party is to
be notified in the HTTP body of the error message.
Annex A.4 of Part A of this TR TKÜV applies accordingly regarding the requirement of repeated
transmission attempts.
2.2.2.2 Status errors (pursuant to ETSI TS 102 657, Section 5.1.5.3)
In case of a status error (‘wrong messages at the wrong time’), an Error Message (ErrorAck) shall be
sent which refers to the RequestID of the relevant request and which may contain an optional comment.
2.2.2.3 Request cannot be implemented (pursuant to ETSI TS 102 657, Section
5.1.5.2)
If a request cannot be implemented (e.g. incorrect parameter, no corresponding surveillance order or data
request for a rejected warrant), a FailureResponse message shall be sent, structured as described in the
following example, with an explanation.
This procedure will be necessary when:
a) during manual verification of a request message (e.g. after transmission of a surveillance order or a
request for subscriber data) it is found that the entire request cannot be implemented, or
b) automatic verification (e.g. a request message of type usageData) finds an error in the parameters.
A new request typically then needs to be sent, with a new request number.
This FailureResponse message may also be used when technical or other errors on the part of the
obligated undertaking cause delays in disclosure of which the requesting agency needs to be informed.
2.2.2.4 Sending the ResponseComplete or ResponseIncomplete message
When there are no errors, a Request of the warrant type is confirmed with a ResponseComplete
message.
If parts of the order cannot be implemented, a ResponseIncomplete message shall be returned with an
automatically readable list of the identifiers considered invalid. A short error message
(RejectedTargetErrorMessage) can be added to each rejected identifier (RejectedTargetNumber).
2.2.2.5 Repeated transmission of the same message
Every request, response, or cancel message shall be acknowledged by a corresponding ACK message. If
such an ACK message is not received, the original message (e.g. a request) may be retransmitted with
the same request number. The receiving system must be able to recognise that the same message is
being resent, and
return an ACK message,
but nevertheless refrain from processing the second message (e.g. traffic data disclosure) if the
first message was in fact received and is already being processed.
TR TKÜV, edition 8.0 (draft) Part B, page 111
Repeated transmission of a message shall have the same content; if any discrepancy is found when
(optionally) comparing the original and repeat messages, processing shall be terminated and a
FailureResponse message shall be returned.
2.2.2.6 Transmission of a cancel message
By means of a cancel message, authorities can stop unprocessed data requests that are no longer
required. Data requests already being processed will still be disclosed.
2.2.3 Determination of formats
Wherever possible, the data to be disclosed shall be presented in the format in which they are available
to the obligated undertaking. Where individual available data need to be converted into a format specified
by the ETSI specification before disclosure, the encoding to be used shall be as listed below in Section
2.2.3.3. The authorised agencies must use the encodings listed therein in their requests.
Since these provisions will be subject to updates based on additional applications or eligible types of
traffic data, this section reflects the state of affairs at the time of publication of the relevant version of the
TR TKÜV. The Federal Network Agency will coordinate any new provisions with the parties involved and
update the list. The current version of the format provisions will be made available for download on the
website of the Federal Network Agency at (www.bundesnetzagentur.de/tku) after consultation.
2.2.3.1 Formats for date and time data
For this part of the TR TKÜV, the use of the GeneralisedTime encoding for date and time data is required
throughout. Here, the GeneralisedTime format is reduced to YYYYMMDDhhmmss.fraction +/- time
differential, where YYYY represents the year, MM the month, DD the day, hh the hour (00 to 23), mm the
minute (00 to 59) and ss the second (00 to 59). Data may optionally be specified to a higher accuracy
(fractions of seconds). Times should always be given as the official German time (local time). In order to
unambiguously represent different times at the transition between summer and winter time, the time
differential with respect to UTC must also be specified. This requirement applies equally to disclosed data
which are produced within the internal system or network of the obligated undertaking; for time data
received from foreign roaming partners, the time value as provided may alternatively be used.
2.2.3.2 Formats for geographical location information pursuant to ETSI TS 102
657
Coordinate data should normally be specified either as geographical coordinates in decimal notation
(‘geoCoordinatesDec’) or as geographical angular coordinates (‘geoCoordinates’).
Coordinates shall be specified within the ‘extended Location’ construct based on the WGS84 reference
system. If known, location information shall be provided with the main beam direction (‘azimuth’).
If a geographical location, for example a so-called radio cell disclosure request or location information
with respect to mobile terminals. has to be specified using postal address data, the ‘postalLocation’
parameter within the ‘extendedLocation’ construct must be used to communicate these data.
2.2.3.3 Formats for identification of radio cells for disclosure requests
For radio cell disclosure requests, the radio cell identifier from 2G to 4G (including 5G NSA) has to be
transmitted in the field ‘userLocationInformation’. Note in this regard that only one specification may be
contained in the userLocationInformation block. The use of other data fields such as GlobalCellID is not
permitted. For 5G SA radio cell identifiers, the nCGI field (already present in TS 102 657) must be used
instead.
For radio cell identifiers within traffic data disclosures, similarly, only the field ‘userLocationInformation’
should be used.
2.2.3.4 Formats for other identifiers pursuant to ETSI TS 102 657
Table A below lists the identifiers pursuant to ETSI TS 102 657 for which there is only a single format
option, and explains their application.
Table B lists identifiers for which the ETSI specification allows several format options or for which an
explanation seems appropriate, and explains those alternatives which should be used based on the
above explanation or which must be used for requests from the authorised agencies:
TR TKÜV, edition 8.0 (draft) Part B, page 112
Table A
Identifier Format pursuant to TS 102 Example of encoding pursuant to TS 102 657
657
(or national addendum)
PartyNumber E.164 in international format as Identifier 0123/4567890
(Phone number, a UTF-string
MSISDN, VLR) ETSI format 491234567890
IMSI Octet String Size 3–8 Identifier 262071234567890
pursuant to 3GPP TS 09.02
ETSI format 62021732547698F0
IMEI Octet String Size 8 Identifier 12345678901234
according to 3GPP TS 09.021
ETSI format 21436587092143F0
userLocationInformation Octet String Size 1-35
pursuant to 3GPP TS 29.274
emailAddress UTF8String Identifier
[email protected]
(Email Address)
ETSI format
[email protected]
1 Where only positions 1 to 14 are available for a given IMEI, the remaining positions shall be filled with padding
(11110000) or ‘F0’. When comparing IMEIs, an IMEI shall be deemed equivalent to the requested IMEI even if the
checksum or software version digits are different or missing.
Table B
Identifier Format pursuant to TS Example of encoding pursuant to TS 102 657
102 657
IPv4 address Octet String Size 4 Identifier 127.0.0.1
ETSI format 7F000001
IPv6 address Octet String Size 16 Identifier 2001:0db8:85a3:08d3:1319:8a2e:0370:7344
ETSI format 20010DB885A308D313198A2E03707344
For other necessary identifiers for which the ETSI specification does not specify a parameter, the national
XML module Natparas2 contains extensions to the ETSI parameter nationalTelephonyPartyInformation
(see Section 3.2.2 of this TR TKÜV ). The ETSI parameters TelephonyDeviceID and subscriberID should
therefore not be applied for those options.
2.2.3.5 Combination of traffic data for the voice communication and internet
access service of an identifier (optional)
The ETSI specification TS 102 657 distinguishes between inquiries for different services, such as voice
services and internet access services. Accordingly, disclosure of the traffic data for both telephony and
internet for a particular identifier (fixed or mobile telephony number) would require separate disclosure
requests.
To avoid the need for duplicate requests and disclosures, this TR TKÜV allows the following procedure to
be followed as an option:
1. Both the warrant request and the data request specify, using the usageData parameter, whether
the traffic data are to be disclosed for telephony or for internet access. If both possible values are
set to true, the request is understood to relate to a disclosure of the two combined.
2. To facilitate the transmission of traffic data with respect to combined requests, the field
‘nationalTelephonyServiceUsage’ in the ETSI specification is extended (as highlighted in bold
below) to enable a disclosure for telephony also to be used for a disclosure for internet access.
TR TKÜV, edition 8.0 (draft) Part B, page 113
TelephonyServiceUsage ::= SEQUENCE
{
partyInformation [1] SEQUENCE OF TelephonyPartyInformation OPTIONAL,
communicationTime [2] TimeSpan OPTIONAL,
-- Time and duration of the communication
nationalTelephonyServiceUsage[10] NationalTelephonyServiceUsage OPTIONAL
}
NationalTelephonyServiceUsage :: = SEQUENCE
{
countryCode [1] UTF8String (SIZE (2)),
version [2] UTF8String (SIZE (2)),
internetAccess [3] NAServiceUsage OPTIONAL}
The option to make use of this method shall be laid down in the concept. If the relevant obligated
undertaking does not support this option, a request to that effect shall be answered with an error
message as defined in Section 2.2.2.3.
2.2.4 Standardisation of response data in case of selective submission of
subscriber and traffic data
A national survey concerning the selection of suitable ETSI parameters for subscriber and traffic data
revealed that the specification does offer possibilities of interpretation and that for this reason, in some
cases, this may lead to different parameters being selected. In order to ensure a uniform level of
information in selective disclosure, tables should define the parameters to be used across manufacturers
(see also Sections 1.3.1.2 and 1.3.4.1 of this Annex).
The Federal Network Agency publishes on its website (www.bundesnetzagentur.de/tku) the tables to be
used, if applicable.
2.2.5 Flexible use of free text field ‘otherInformation’
For all possible parameters for which no unambiguous correspondences exist in the ETSI construct, the
free text field 'otherInformation' is to be used
(responseMessage/responsePayload/ResponseRecord/additionalInformation/otherInformation).
The syntax to be observed in this regard can be taken from Section 3.3.2.1.
3 Definition of national parameters
3.1 General
The international standards and specifications underlying this TR TKÜV have the possibility to transmit
national parameters.
The additional national XML modules ‘Natparas2’, used for transmission of the copy of the surveillance
order as well as the additional data in the warrant and data requests, and ‘Natparas3’, used for
transmission of the response for other uses (e.g. for determining the location of mobile telephony
terminals) are described below. Changes or extensions are only possible by the Federal Network Agency.
In accordance with the XML standard, special characters shall by replaced by the corresponding escape
characters since the validation will otherwise fail.
The module Natparas2 is inserted in the NationalRequestParameters field of the RequestMessage. The
module Natparas3 is inserted in the NationalResponsePayload field of the Response Message.
The current versions of the national modules are published on the website of the Federal Network Agency
(www.bundesnetzagentur.de/tku). The published Natparas versions are not linked to the current ETSI
XSD version. However, if versions of the national modules are not to be used, for example due to XML
compatibility problems with certain ETSI-XSD versions, a corresponding notice is made on the website of
the Federal Network Agency.
TR TKÜV, edition 8.0 (draft) Part B, page 114
3.2 Description of the national XML module ‘Natparas2’ (for requests)
This Annex contains the XML description of the national module ‘Natparas2’, used for transmitting the
copy of the surveillance order as well as the additional metadata in the warrant and data requests.
As this XML description will be subject to updates with new additional parameters, this Annex only
reflects the state of affairs at the time of publication of the relevant edition of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved (authorised agencies,
obligated parties) and will then update the XML module. The current version of the XML description of the
national parameters as well as the provisions below for the individual parameters will be made available
from time to time for download on the website of the Federal Network Agency
(www.bundesnetzagentur.de/tku) after consultation. To determine the standardised information to be
used from the legal bases, the elements of the ComplexType ‘LegalBasis’ shall be listed additionally in a
separate ‘LegalBasis’ list and published on the Federal Network Agency’s website. This list shall set out
the legal bases according to the Natparas2 version.
3.2.1 Determination of usage modes
The Natparas2 module is defined for the following usage modes:
Transmission of the surveillance order and metadata (type warrant);
here, the ETSI RequestMessage merely serves as a transmission envelope.
Transmission of actual inquiries on disclosure of subscriber and traffic data (subscriberData and
usageData types);
here, the national module merely contains supplementary data whilst the ETSI RequestMessage
contains the actual request through the content of the corresponding known parameters (e.g.
transmission of phone number and a period with the disclosure of traffic data).
Transmission of queries on determining the location of mode terminals (locating type) and the
structure of radio cells (radioStructure type);
here, the ETSI RequestMessage merely serves as a transmission envelope
Transmission of the activation or change messages for implementing surveillance actions
(lawfulInterception type);
here, the ETSI RequestMessage merely serves as a transmission envelope
Transmission of an early deactivation of individual targets (deactivateTarget type) of an existing
warrant related to traffic data.
Usage modes linked to a given surveillance order may contain several identifiers in their warrant
request (the various identifiers are identified by means of consecutive numbers through the
<targetNumber> parameter). For usage modes usageData, locating and radioStructure, each request
can relate to only a single identifier.
3.2.2 Specification of additional data in the national XML module
Natparas2
The XML module Natparas2 is inserted in the NationalRequestParameters field of the RequestMessage,
and is structured as follows:
3.2.2.1 Specifications for the header
NationalRequestParameters
Parameter Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas2 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where:
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
TR TKÜV, edition 8.0 (draft) Part B, page 115
01.26.01 07.2 01
ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version
version no TKÜV edition
01.26.01 7.2
<referencedRequestNumber> This refers to the request number (RequestID in the ETSI XSD) of a C
surveillance order previously transmitted in a warrant request; this is a
mandatory parameter for all requests following a warrant request.
<targetNumber> Consecutive number of the relevant identifier in the warrant request to C
which the subscriberData and lawfulInterception requests refer when
initiating a disclosure or surveillance action for that identifier. This
parameter is mandatory in these cases.
<groupID> The consecutive number serves only to group different requests for O
accounting purposes.
(e.g. to group 10 different inquiries on the same IP address pursuant
to § 23(1), Annex 3 point 201 of the German Judicial Remuneration
and Compensation Act)
<additionalInformation> Free text to be taken into account before processing the applications O
<subscriberData>, <locating> and<radioStructure>.
<requestDetails> Here, the possible application modules are specified as a choice M
requestDetails
Parameter Description M/C/O
<warrant> to transmit a surveillance order including metadata C
<usageData> for requests for traffic data, with the specific request data defined in C
the ETSI XSD; the national addendum as described in Section 3.2.2.3
additionally distinguishes between the service to which the request
relates (telephony or internet access service)
<subscriberData> for requests for subscriber data beyond the options of the ETSI XSD C
<locating> for site determinations according to Section 1.3.5 C
<radioStructure> for requests for the structure of radio cells, with the specific data
requested defined in the ETSI XSD
<lawfulInterception> for the activation/change/deactivation of a surveillance action, after C
the surveillance order itself has been transmitted
<compensation> data type for asserting compensation claims C
3.2.2.2 Specifications for warrant requests in the national XSD addendum
Warrant
Parameter Description M/C/O
<warrantTIFF> Order (base64-encoded TIFF document as described above) C
<warrantType> Parameters for determining the request format (warrantTIFF or M
warrantTextform) for subscriber data disclosure requests
<warrantDate> Date of the surveillance order in the format YYYYMMDD M
<warrantTargets> List of individual identifiers, numbered consecutively, M
see definition of <warrantTarget>
<legalBases> Legal basis for the surveillance order M
see XSD definition
<warrantTextform> Implementation of the required text form for subscriber data requests C
pursuant to § 174(2) Telecommunications Act, as an alternative to the
TIFF document
<needsConfirmation> If confirmation is still required, e.g. in the case of an urgent C
surveillance order (Sections 1.3.1 and 1.3.6)
<isConfirmation> Flag to confirm, for example, an (urgent) surveillance order previously C
sent with <needsConfirmation> (Sections 1.3.1 and 1.3.6)
<isCorrection> Flag to indicate that the new decision corrects a minor deficiency C
(Sections 1.3.1 and 1.3.6)
WarrantTarget
Parameter Description M/C/O
<targetNumber> Consecutive number identifying the identifier within the metadata and M
requests referring to them
<deactivateTarget> for prematurely terminating individual targets of an active warrant for O
traffic data information warrant
TR TKÜV, edition 8.0 (draft) Part B, page 116
<target> This contains the TelephonyPartyInformation element with related M
data field values from the ETSI XSD, and - if necessary - the
nationalTelephonyPartyInformation parameter with the national
addenda from the XSD module Natparas2
<startDateTime> Start of the time period specified in the surveillance order for this M
identifier, in the GeneralizedTime format
<endDateTime> End of the time period specified in the surveillance order for this M
identifier, in the GeneralizedTime format
<targetType> This field serves to distinguish whether: M
a traffic data enquiry or a telecommunication surveillance action is
requested for the identifier;
the traffic data disclosure in combination with the <usageData>
parameter refers to <telephonyService>, <data service> or a
combined request,
the surveillance action in combination with the
<interceptionCriteria> parameter refers to Voice+Data or IRIOnly.
<interceptionCriteria> Mandatory field for surveillance actions; specifies the potential scope C
of the surveillance action as defined in the surveillance order (CC+IRI
or IRIOnly). The actual scope that will be activated in this respect is
defined by the activation request (this enables, for example, an
existing surveillance order for CC+IRI to be implemented as an
IRIOnly action as deemed appropriate by the authorised agency).
WarrantTextform
Parameter Description M/C/O
<originator> Name of enquirer. M
<originatorContactDetails> Phone number of enquirer. M
<endOfText> The necessary text field to make the completion of the required form M
recognizable. 'This document is valid without a signature!' should be
entered as a parameter value.
NationalTelephonyPartyInformation
Parameter Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas2 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where:
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version
version no TKÜV edition
01.26.01 7.2
<partyNumberAKUE> The foreign phone number specified in the surveillance order, starting C
with the country code (e.g. 33 for France )
<voipID> VOIP identifier that is not in E.164 format (e.g. C
[email protected])
<lineID> Line identifier or technical key of an internet access route C
<userName> Account name of an internet connection C
<postBoxAddress> Mailbox address or account name of an email mailbox C
<macAddress> MAC address of a terminal used for internet access in cable networks C
<ipAddress> Fixed IP address of an internet connection C
<hostMacAddress> hostMacAddress for WIFI / hotspot C
<mailboxID> For mailbox queries such as retrieve, download, delete emails. C
TR TKÜV, edition 8.0 (draft) Part B, page 117
3.2.2.3 Specifications for usageData requests in the national XSD addendum
For traffic data disclosures, the request data for the actual traffic data to be disclosed are sent as part of
the ETSI XSD (e.g. phone number and period for traffic data disclosures).
The national XSD supplement contains, in addition to the information in the header (including the
reference to the warrant request and the relevant targetNumber), the requested service (voice
communication service, data service, combined request).
UsageData
Parameter Description M/C/O
<usageData> Indication whether the disclosure of traffic data from the fixed or M
mobile telephony number relates to the telephony service or to the
internet access service. Setting both options to true produces a
combined disclosure as defined in Chapter 2.2.3.5.
Possible values:
- telephonyService: true or false
- dataService: true or false
- lateRecordRequest: true or false
- destinationRequest: true or false
A special data request for the disclosure of delayed traffic data (late
records) which will only become available after a waiting period and
after the queried period in the warrant request has elapsed.
destination selectionRequest to identify a destination selection search.
locationCriteria
Parameter Description M/C/O
<retrogradLocation> The requested location data relate to a period prior to the decision M
date.
<anterogradLocation> The requested data refer to the period from the decision date to the M
end date.
typeOfData
Parameter Description M/C/O
<betrieblicheVerkehrsdaten> Traffic data available for operational reasons. C
<bevorrateteVerkehrsdaten> Traffic data stored on the basis of a legal obligation (cf. ‘Act C
introducing a storage obligation and a maximum retention period for
traffic data’).
3.2.2.4 Specifications for the subscriberData request in the national XSD
addendum
For subscriber data disclosures, the request properties for the actual subscriber data to be disclosed are
sent as part of the ETSI XSD (e.g. phone number or name and address).
3.2.2.5 Specifications for the locating request in the national XSD addendum
To disclose responses to requests for determining location in accordance with Section 1.3.5, the ETSI
XSD serves merely as an envelope for transmission and to define the requestNumber; The national XSD
supplement contained in ETSI-XSD contains the search criterion. Locating requests are subject to the
procedure under Section 1.3.1. The <referencedRequestNumber> field in the header of the location
request links it to the corresponding warrant request.
TR TKÜV, edition 8.0 (draft) Part B, page 118
If, in addition to the result, information on the structure of the relevant radio cell is also required, this shall
be done separately through an independent radioStructure request.
Locating
Parameter Description M/C/O
<mSISDN> Phone number of the mobile telephony terminal to be located, in C
E.164 format; refer to the stipulations in Section 2.2.3.4
<iMSI> IMSI of the mobile telephony terminal to be located, in 3GPP TS C
09.02 format; refer to the stipulations in Section 2.2.3.4
C
<legalBases> Legal basis for the disclosure C
see XSD definition
<iP> IP address of the connection to be located C
<lineID> Line identifier or technical key of an internet access path leading to C
the physical address of the connection
<otherID> Other ID, which in combination with otherIDtype leads to the physical C
address of the port
<otherIDtype> Defines the type of the other ID C
3.2.2.6 Specifications for the radioStructure request in the national XSD
addendum
The userLocationInformation parameter of the ETSI-XSD is used to provide information on the structure
of radio cells.
Only one specification may be contained in the userLocationInformation block in the case of radio cell
disclosure requests.
3.2.2.7 Specifications for the lawfulInterception request in the national XSD
addendum
The different variants of the lawfulInterception request enable the administration of the
telecommunications surveillance processes transmitted by means of warrant requests, and approved by
the undertaking, to be activated, modified, deactivated or renewed as well as resumed after an
interruption.
To this end, one of the ETSI XSD modules described below is inserted.
LawfulInterception
Parameter Description M/C/O
<activation> For activating a cleared surveillance action (warrant request) C
see definition of <Activation>
<renewal> For renewal of a surveillance action; presupposes clearance of a C
further warrant request.
see definition of <Renewal>
<modification> For modifications of a surveillance action, if this does not require a C
surveillance order (e.g. change of the forwarding address)
see definition of <Modification>
<deactivation> For early deactivation of a surveillance action C
see definition of <Deactivation>
Activation
Parameter Description M/C/O
<target> identifier to be monitored M
For this parameter, the telephonyPartyInformation parameter of the
ETSI XSD is used
<lIID> Contains the LIID to be used. C
Obligated undertakings expressly permitted by the Federal Network
Agency to use the LIID because of their older transmission equipment
shall report the actually activated LIID in the response message.
<interceptionCriteria> Details of the scope of surveillance, M
see definition of <InterceptionCriteria>
<monitoringCenter> Details of the forwarding targets, M
see definition of <MonitoringCenter>
<startDateTime> 2 Time of the proposed activation of the action, in GeneralizedTime C
format. Non-specification indicates immediate activation
<endDateTime> 2 Time of proposed deactivation, in GeneralizedTime format. M
TR TKÜV, edition 8.0 (draft) Part B, page 119
2 These values may differ from the original values defined in the warrant request but must be within the time period
defined by these original values.
Renewal
Parameter Description M/C/O
<lIID> LIID of the action M
<endDateTime> The new end time, in GeneralizedTime format M
Modification
Parameter Description M/C/O
<lIID> LIID of the action M
<newLIID> New LIID, if it is to be changed C
<newInterceptionCriteria> New data for the InterceptionCriteria field, if the scope of the C
surveillance action is to be changed
<newMonitoringCenter> New data for the MonitoringCenter field, if the forwarding targets are C
to be changed
Deactivation
Parameter Description M/C/O
<lIID> LIID of the action M
<endDateTime> Time of proposed deactivation, in GeneralizedTime format. Non- C
specification of this parameter indicates immediate deactivation
InterceptionCriteria
Parameter Description M/C/O
<interceptVoice> 1 specifies whether the voice communication service should be M
monitored
<interceptData> 1 indicates whether the internet access service is to be monitored M
<interceptIdlemodeHandover> indicates whether handovers of a mobile telephony terminal are to be C
monitored even in idle mode
1 A false value for both parameters indicates an IRIOnly action.
MonitoringCenter
Parameter Description M/C/O
<destinationNumber> HI3 forwarding target for ISDN-based voice forwarding, format E.164 C
<ipAddress> HI2 and HI3 forwarding target for IP-based voice forwarding as well as C
data, the respective port results from Part A of the TR TKÜV
<ftpAddress> IP address of the HI2 forwarding target in the case of FTP forwarding C
<ftpUsername> FTP user name of the HI2 forwarding target C
<ftpPassword> FTP password of the HI2 forwarding target C
3.3 Description of the national XML module ‘Natparas3’ (for responses)
This Annex contains the XML description of the national module ‘Natparas3’, used to transmit additional
response data (e.g. for locating mobile telephony terminals) in the response message.
As this XML description will be subject to updates with new additional parameters, this Annex only
reflects the state of affairs at the time of publication of the relevant version of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved and will then update
the XML module. The current version of the XML description of the national parameters as well as the
provisions below for the individual parameters will be made available from time to time for download on
the website of the Federal Network Agency (www.bundesnetzagentur.de/tku) after consultation.
3.3.1 Specification of additional data in the national XML module
Natparas3
The Natparas3 module is defined for the following usage modes:
TR TKÜV, edition 8.0 (draft) Part B, page 120
Transmission of responses on determining the location of mobile terminals (locatingResult type)
and the structure of radio cells (radioStructureResult type);
here, the ETSI ResponseMessage merely serves as a transmission envelope.
Submission of supplementary response data in case of submission of subscriber data;
depending on the scope of the request, the ETSI ResponseMessage may either serve merely as
an envelope for transmission or else contain supplementary information.
Transmission of confirmations of activation or change protocols in the implementation of
surveillance actions (lawfulInterceptionResult type);
here, the ETSI ResponseMessage merely serves as a transmission envelope.
This transmission serves as an administrative-level response and replaces the HI1 messages as
described in Part A of Annex A.3 of the TR TKÜV; it can then optionally be deactivated by the
obligated company.
3.3.2 Specification of additional data in the national XML module
Natparas3
The XML module Natparas3 is inserted in the NationalResponsePayload field of the RequestMessage,
and is structured as follows:
3.3.2.1 Specifications for the header
NationalResponsePayload
Parameter Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas3 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version
version no TKÜV edition
01.26.01 7.2
<additionalInformation> Free text for additional information from the obligated undertaking with O
respect to the disclosure
<additionalDocument> Possibility of transmitting an additional document as a supplement O
<responseDetails> Here, the possible application modules are specified. M
The additionalInformation field may (similarly to Section 2.2.5) be completed with various items of
information, as described below:
<Info> <List>
<Info> <Comment>
<Info> <List>;<Comment>
<List> <ListItem>
<List> <ListItem>;<List>
<ListItem> ”<Fieldname>”=”<FieldValue>”
<Comment> COMMENT=<text>
The above identifiers in pointed brackets are designated non-terminals. Any strings are permissible for
the parameters <field name>, <field value> and <text>.
TR TKÜV, edition 8.0 (draft) Part B, page 121
Where double inverted commas or backslash characters are shown in the case of the parameters <field
name> and <field value>, these characters shall each escape via a backslash.
The <Comment> parameter additionally permits comments in free text to the network operator-specific
fields.
An example without free text:
”Criterion sought“=”12345“;”Period“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier Id”=”66221”
The same example using free text:
”Criterion sought“=”12345“;”Period“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier
Id”=”66221”;COMMENT=The cell information was already partially deleted because the data are more
than 7 days old.
The free text field "otherInformation" of ETSI-XSD is to be used for missing parameters according to
Section 2.2.5.
responseDetails
Parameter Description M/C/O
<locatingResult> for results for location determinations; if multiple SIM cards are C
assigned to the identifier, this parameter must be occupied per SIM
card and transmitted as a standalone <locatingResult> in the
<response details>
<radioStructureResult> for responses to requests for the structure of radio cells, with the C
specific data requested defined in the ETSI XSD
<lawfulInterceptionResult> for responses to activation/change/deactivation of a surveillance C
action, after the surveillance order itself has been transmitted
<rejectedTargets> Rejected targets should be stated here. If several targets have been C
rejected, the element <RejectedTargetNumber> is to be used
accordingly
3.3.2.2 Specifications for rejectedTargets in the national XSD addendum
rejectedTargets
Parameter Description M/C/O
C
<rejectedTargetInfo> For numbering of rejected targets and communication of the reason. M
3.3.2.3 Specifications for the locatingResult in the national XSD addendum
For applications of type locating, one locatingResult per SIM card is defined. If several SIM cards have
been assigned to the identifier specified in the locating request, then the locatingResult parameter with
the respective response parameters is defined in the headers for each individual SIM card.
locatingResult
Parameter Description M/C/O
<mSISDN> Phone number of the mobile telephony terminal to be located, in C
E.164 format pursuant to § 2.2.3.4
<iMSI> IMSI of the located SIM in 3GPP TS 09.02 format, format pursuant to C
Section 2.2.3.4
<iMEI> IMEI of the located mobile telephony terminal in 3GPP TS 09.02 C
format, format pursuant to Section 2.2.3.4
<loginStatus> Reference to the state of the mobile terminal (attached/registered or C
detached/unregistered)
<detachReason> Reason of cancellation as free text, e.g. “Switch off by user” C
<vLR> VLR identifier in E.164 format, C
Format as defined in Section 2.2.3.4
<mME> Mobility Management Entity C
Use analogous to VLR identifier
<lastRadioContact> Time of last radio contact in GeneralizedTime format, format as C
defined in Section 2.2.3.1
<transmitterDetails> Reference to the network technology (GSM or UMTS) C
see definition in the ETSI XSD (TransmitterDetails
parameter)
TR TKÜV, edition 8.0 (draft) Part B, page 122
<userLocationInformation> in 3GPP TS 09.02 format, C
Format as defined in Section 2.2.3.4
<extendedLocation> For transmission of the geographical coordinates of the aerial location C
see definition in the ETSI XSD (ExtendedLocation parameter) as
defined in Section 2.2.3.2
<postalLocation> Postal address of the location of the antenna, where postal addresses C
are used in addition to geographical coordinates
see definition in the ETSI XSD (postalLocation parameter)
<subscribedTelephonyService In order to submit queries that do not relate to a location, but to a C
s> person, such as for IP address disclosure.
The indication ‘conditional’ refers to the scope of the legal basis for the request.
3.3.2.4 Specifications for the radioStructureResult in the national XSD
addendum
radioStructureResult
Parameter Description M/C/O
<radiationPattern> graphical representation of the theoretical coverage area (base64- M
encoded TIFF document )
<userLocationInformation> Contains cell information like cell ID, LAC, ECI etc. O
<azimuth> Main beam direction O
3.3.2.5 Specifications for the lawfulInterceptionResult in the national XSD
addendum
lawfulInterceptionResult
Parameter Description M/C/O
<lIID> Reference number M
<begin> Activation time of the surveillance action C
Date and time in GeneralizedTime format as described in Section
2.2.3.1
<end> Deactivation time of the surveillance action C
Date and time in GeneralizedTime format as described in Section
2.2.3.1
<modification> Modification time of the surveillance action C
Date and time in GeneralizedTime format as described in Section
2.2.3.1
3.3.2.6 Specifications for the subscriberDataResult in the national XSD
addendum
The disclosure of subscriber data relates to the special subscriberDataRequest as described in Section
3.2.2.4 and always takes place within the ETSI XSD. To produce the reference to the request, the header
as defined in Section 3.3.2.1 must also be transmitted.
For the actual disclosure of a subscriberDataRequest with respect to telephony, the TelephonySubscriber
parameter of the ETSI XSD is used, which contains an option to specify several contracts (e.g. contracts
for different mobile telephony numbers) in a single response. Disclosure of the billingMethod,
bankAccount, and billingAddress or contractPeriod features is also done within the ETSI XSD.
The NationalResponsePayload field is not suitable for the transmission of supplementary data for
individual contracts or mobile telephony numbers since it can only be used once per response.
Accordingly, to report contract-specific supplementary data, the nationalTelephonySubscriptionInfo field in
the TelephonySubscriber parameter of the ETSI XSD needs to be supplemented as follows:
TR TKÜV, edition 8.0 (draft) Part B, page 123
nationalTelephonySubscriptionInfo
Parameter Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas3 module M
The format of the version number is made up as follows:
ETSI version.TR edition No,
where:
ETSI version: 8 characters,
TR edition: 4 characters
No: 2 characters
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version
version no TKÜV edition
01.26.01 7.2
<pIN> PIN of the target identifier C
<other> Free text for reporting on other requests as defined in the <other> C
parameter of the subscriberDataRequest
The excerpt from the ETSI XSD given below shows the structure of the TelephonySubscriber parameter
with various options for disclosure of subscriber data.
TelephonySubscriber ::= SEQUENCE
{
subscriberID [1] TelephonySubscriberId OPTIONAL,
-- unique identifier for this subscriber, e.g. account number
genericSubscriberInfo [2] GenericSubscriberInfo OPTIONAL,
-- generic personal information about this subscriber
[...]
subscribedTelephonyServices [4] SEQUENCE OF SubscribedTelephonyServices
OPTIONAL,
-- a subscriber (or account) may have more than one service listed against them
...,
nationalTelephonySubscriberInfo [5] NationalTelephonySubscriberInfo OPTIONAL
-- To be defined on a national basis
-- Only to be used in case the present document cannot fulfil the national
requirements
}
SubscribedTelephonyServices ::= SEQUENCE
{
[...]
timeSpan [3] TimeSpan OPTIONAL,
-- Start and end data, if applicable, of the subscription
registeredNumbers [4] SEQUENCE OF PartyNumber OPTIONAL,
-- The set of telephone numbers registered for this service
[...]
iMSI [9] IMSI OPTIONAL,
pUKCode [13] UTF8String OPTIONAL,
pUK2Code [14] UTF8String OPTIONAL,
iMEI [15] SEQUENCE OF IMEI OPTIONAL,
nationalTelephonySubscriptionInfo [16] NationalTelephonySubscriptionInfo
OPTIONAL,
-- To be defined on a national basis
-- Only to be used in case the present document cannot fulfil the national
requirements
paymentDetails [17] PaymentDetails OPTIONAL
}
Excerpt from the ETSI XSD TS 102 657
TR TKÜV, edition 8.0 (draft) Part B, page 124
3.3.2.7 Labelling data sets by origin
In the parameter NationalRecordPayload, a selection must be made for each record, whether the data
according to §§ 9 and 12 TTDSG or §176 Telecommunications Act are provided. Equally, the obligation
under § 177(3) sentence 2 Telecommunications Act is fulfilled as a result.
NationalRecordPayload
Parameter Description M/C/O
<countryCode> Value 'DE' M
<headerID> See also Section. 3.2.2.1 M
<typeOfData> Identification of the data origin (operational or stocked traffic data) M
typeOfData
Parameter Description M/C/O
<betrieblicheVerkehrsdaten> Traffic data available for operational reasons. C
<bevorrateteVerkehrsdaten> Traffic data stored on the basis of a legal obligation (cf. ‘Act C
introducing a storage obligation and a maximum retention period for
traffic data’).
RejectedTargetInfo
Parameter Description M/C/O
<rejectedTargetNumber> For numbering of rejected targets M
<rejectedTargetErrorMessage Text field for communicating the reason for rejection in a few words O
>
4 Transmission of accounting information and submitting claims for
compensation pursuant to § 23(1) of the German Judicial
Remuneration and Compensation Act
4.1 Basic principles
This section describes the technical details of the optional secure electronic transmission of accounting
information and making claims for compensation in preparation of the actual compensation pursuant to §
23(1) of the German Judicial Remuneration and Compensation Act.
4.2 Methods of electronic transmission
The method uses the ETSI specification TS 102 657 as well as the provisions stipulated in this part of the
TR TKÜV.
Transmission enables the obligated undertakings to send the accounting information for a particular
period, as defined in § 23(1) of the German Judicial Remuneration and Compensation Act, to the relevant
authorised agencies for settlement. The accounting information comprises the processed
RequestNumbers (e.g. of a traffic data disclosure or identifier activation) and the cost and discount tariffs
applied by the obligated undertaking.
The standardised transmission of these billing data enables the authorised bodies to automatically cross-
check with the data available to them. The subsequent steps (confirmation, discussion of discrepancies,
etc.) are not part of this interface due to the large variety involved.
The accounting data is transmitted with the national XML module Natparas2, which has to be inserted in
the field NationalRequestParameters of the RequestMessage.
4.3 Description of the national XML module ‘Natparas2’ (for accounting
data)
This section contains the description of the XML elements used to transmit accounting information from
the obligated undertakings to the authorised agencies in a request message. Here, the ETSI
RequestMessage merely serves as an envelope for transmission. A response message for this
application is not envisaged.
The provisions of Section 2.2 apply accordingly to transmission via HTTP and error handling.
TR TKÜV, edition 8.0 (draft) Part B, page 125
As this XML description will be subject to updates with new additional parameters, this Annex only
reflects the state of affairs at the time of publication of the relevant version of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved and will then update
the XML module accordingly. The current version of the XML description of the national parameters as
well as the provisions below for the individual parameters will be made available from time to time for
download on the website of the Federal Network Agency (www.bundesnetzagentur.de/tku) after
consultation.
Determining the supplementary data
Compensation
Parameter Description M/C/O
<compensationName> Free text for unambiguous description of accounting information (e.g. M
for a specific month with consecutive number for retransmission after
correction)
<compensationItem> see 4.3.1.1 M
Stipulations regarding the CompensationItem parameter
CompensationItem
Parameter Description M/C/O
<requestNumber> The RequestID for which compensation is to be claimed (e.g. a traffic M
data disclosure or for activation of a surveillance action)
<groupID> This designates RequestIDs that are settled as a group in accordance M
with the provisions of § 23(1) of the German Judicial Remuneration
and Compensation Act 1
<jVEG2017> Selection field in the national module for the tariff number, M
e.g. ‘German Judicial Remuneration and Compensation Act number
102’
<rebate> Designation of whether the tariff includes a 20 % rebate due to a
central contact point
Possible values:
- Rebate included: true
- Rebate not included: false
<quantity> Quantity or multiplier of the tariff 2 M
<price> Final tariff for the relevant RequestID, including any rebates and M
multiplier
<comment> Free text for additional comments O
1 For example, if eight IP addresses are requested in the same procedure (No 201 pursuant to Annex 3 of § 23(1) of
the German Judicial Remuneration and Compensation Act), the eight RequestIDs corresponding to the individual
requests shall be listed, using the same groupID. The tariff as defined in § 23(1) of the German Judicial
Remuneration and Compensation Act shall be specified for a single RequestID only; for the other RequestIDs, an
amount of ‘0’ shall be specified.
2 This will normally be ‘1’. In volume-based invoices (e.g. for compensation of management costs pursuant to point
104), the required multiplier shall be specified as an integer value.
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 126
Annex A.1 Explanatory notes on the procedure
Annex A.1 contains further explanations and illustrations of the procedure.
Example records for the different use cases as well as the current versions of the national XML modules
Natparas2 and Natparas3 are available on the website of the Federal Network Agency at
www.bundesnetzagentur.de/tku.
Annex A.1.1 Fundamental flow of communication
The figures below explain the basic uses of the interface; they complement the descriptions in
ETSI TS 102 657.
Division into system, sender and recipient:
a) successful transmission of a request
berechtigte Stelle Authorised agency
Verpflichteter obligated party
SINA-VPN über Internet SINA VPN via internet
Sender sender
Req über HTTP req via HTTP
Empfänger recipient
System Verpfl. obligated party system
XML-Schema Prüfung erfolgreich XML schema check successful
Automatische Checks automatic checks
Manuelle Checks nach ReqAck manual checks by ReqAck
ReqAck über HTTP ReqAck via HTTP
System bSt system bSt
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 127
b) successful transmission of a response
berechtigte Stelle Authorised agency
Verpflichteter obligated party
SINA-VPN über Internet SINA VPN via internet
Sender sender
Req über HTTP req via HTTP
Empfänger recipient
System Verpfl. obligated party system
XML-Schema Prüfung erfolgreich XML schema check successful
Automatische Checks automatic checks
Manuelle Checks nach ReqAck manual checks by ReqAck
ReqAck über HTTP ReqAck via HTTP
System bSt system bSt
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 128
c) Transmission of a faulty message (error 5.1.5.3)
The figure shows an example of a faulty request message. This error can occur with any type of
message (Req, ReqAck, etc.).
berechtigte Stelle Authorised agency
Verpflichteter obligated party
SINA-VPN über Internet SINA VPN via internet
Sender sender
Req über HTTP req via HTTP
Empfänger recipient
System Verpfl. obligated party system
XML-Schema Prüfung erfolgreich XML schema check successful
Automatische Checks automatic checks
Manuelle Checks nach ReqAck manual checks by ReqAck
ReqAck über HTTP ReqAck via HTTP
System bSt system bSt
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 129
d) successful transmission of a request and multi-part response as defined in Section 5.2.3
of the ETSI TS 102 657
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 130
berechtigte Stelle Authorised agency
Verpflichteter obligated party
SINA-VPN über Internet SINA VPN via internet
Sender sender
Req über HTTP req via HTTP
Empfänger recipient
System Verpfl. obligated party system
XML-Schema Prüfung erfolgreich XML schema check successful
Automatische Checks automatic checks
Manuelle Checks nach ReqAck manual checks by ReqAck
ReqAck über HTTP ReqAck via HTTP
System bSt system bSt
Annex A.1.2 Stipulations regarding participation in the IP VPN using a cryptobox
General
To protect the IP-based transmission point, dedicated cryptoboxes based on the IPSec protocol family
are used to connect the subnetworks of the authorised agencies and obligated parties into a Virtual
Private Network (VPN). To administer the cryptographic keys used for authentication, a Public Key
Infrastructure (PKI) is set up, for which the Federal Network Agency operates as the central certification
and registration authority. In addition, the Federal Network Agency administers the possible security
relationships in an Access Control List (ACL) made available via a directory service.
The cryptoboxes are positioned as dedicated systems in front of the subnetworks of authorised agencies
and obligated parties which they are intended to protect. These systems ensure authentication, integrity,
and encryption.
More extensive mechanisms to protect the transmission point, such as measures against denial of
service attacks on authorised agencies, are addressed only to a limited extent by cryptoboxes and should
be independently resolved by the operator of the relevant subnetworks.
The respective crypto-asset systems on the side of the authorised entity are components of the technical
facilities of the authorised body and, on the side of the obliged entity, components of the obliged entity’s
technical facilities; therefore, their operation (e.g. operation of a syslog server) and maintenance and
troubleshooting are the responsibility of the operator of the relevant subnetwork.
The requirements for cryptoboxes should be updated in future to reflect the current state of the art in
order to ensure continued protection. The relevant extensions (e.g. use of different key lengths) or
necessary short-term changes in the existing implementations in case of security issues arising later
should be implemented by the operator of the relevant cryptobox within a period laid down for each case
individually – in the context of extensions or updates made available by the manufacturer of the cryptobox
– according to the requirements set by the Federal Network Agency.
Network architecture
The cryptoboxes of the authorised agencies and the obligated parties constitute a meshed network,
where directed security relationships (point-to-point connections) are created between the
telecommunication systems of the obligated parties and the subnetworks of the authorised agencies.
Links between obliged entities are not permitted.
The required certificate keys for authentication of cryptoboxes are created by the Federal Network
Agency and, after registration, stored on the smart card of each cryptobox as supplied by the operator of
the relevant subnetwork. The keys used to encrypt the transmitted data are created by the cryptoboxes
themselves for each active VPN.
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 131
After the cryptoboxes are put into operation, they autonomously set up a secure connection to the
directory service at the Federal Network Agency in order to retrieve the current ACL. Further update
processes for the ACL either take place automatically or are controlled by the Federal Network Agency.
The log data created by the cryptoboxes (e.g. a successful ACL update, failure) are sent to the log server
of the obligated party or the authorised agency in the standard syslog format (UDP port 514) for further
processing.
Design of internet access or transfer point
To ensure unambiguous addressing of VPN endpoints and of sending and receiving systems on the
connection used to transmit the surveillance copy or the IRI as well as the data as referred to in Part B,
public IP addresses are used. If existing intranet structures are used, separate tunnelling must usually be
used to meet the protection requirements. However, various different network configurations are possible
in principle.
The above requirements should be taken into account when describing the design of the internet access
or transmission point in connection with the submission of the concept.
Use scenarios and procedures
In normal situations, cryptoboxes are a fixed component of the subnetworks and are identified
unambiguously in the ACL, inter alia, by their IP configuration. After registration and key creation, the
directory service is updated.
A list of data needed to administer the ACL, together with a description of the total process (policy), is
made available to all participants in the procedure.
The concept should mention all the relevant details (e.g. the proposed IP address for the transmission) to
enable the ACL to be maintained appropriately.
Other provisions and guidelines for participation in an IP VPN
In addition to the above provisions for participation in an IP VPN, the following normative individual
provisions and guidelines apply:
Rules for the Registration and Certification Authority TKÜV-CA of the Federal Network Agency,
Department IS16 (Policy)
Annex X.3 reflects the status of these rules at the time of publication of this edition of the TR
TKÜV.
Guideline document ‘Integration of IP cryptoboxes into the network infrastructure of obligated
parties and authorised agencies’
Application for participation in the IP VPN for obligated parties and authorised agencies
(Registration and technical description of the infrastructure of the subnetwork with IP addresses
and a selection of options)
These documents are available for download from the website of the Federal Network Agency, in the
section on telecommunications, under the keyword ‘Technical Regulation of Telecommunications’ /
‘Technical Implementation of Surveillance Actions’.
Table of suitable IP cryptoboxes
The systems fulfilling the basic technical system and interoperability requirements are listed in the
following table.
The updated table is published on the download site of the Federal Network Agency
(www.bundesnetzagentur.de/tku).
No. Manufacturer Product name Contact person
1 secunet Security Networks AG SINA Box Division Public Authorities
Ammonstraße 74 Email:
[email protected]
01067 Dresden Tel.: 0201/5454-0
www.secunet.com
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 132
Annex B Email-ESB transmission procedure
This Annex describes the national requirements for the Email-ESB transmission method.
1. Basic description of the procedure
The use of the Email-ESB transmission procedure is governed by Sections 1 to 3 of this part of the TR
TKÜV.
Before using the Email-ESB transmission procedure, once the authorised agency has been notified of the
presence of a surveillance order or other request, the requesting authorised agency and obligated party
must first exchange their public keys for use in the encryption procedure. It is not envisaged that the keys
will be held centrally for this procedure, e.g. via a key server. The obligated party must ensure that the
key he transmits comes from the requesting authorised agency, e.g. by means of a phone verification of
the fingerprint.
As well as the surveillance order or other request, the authorised agencies may transmit notes on the
requested traffic data (e.g. direct line search, real time forwarding) and the request periods (times of
disclosure, redelivery of late records after expiry of the ordered period) to facilitate processing. The
processing is based on the relevant comments on the transmission procedure ETSI-ESB.
When the ETSI-ESB transmission process is used, only software solutions that enable an encryption
method according to the specified OpenPGP procedure in hybrid application in RFC4880 . The OpenPGP
Standard supports the most common cryptoboxes and algorithms. For application, an asymmetric RSA
encryption with a key length of at least 4096 bits and a symmetric AES encryption with a key length of at
least 256 bits should be used. The recording lines of the authorised agencies must support these
processes.
Other encryption procedures using proprietary PGP or other end-to-end encryption methods are not
permitted. Where confidential documents have to be transmitted by the authorised agency (e.g. a court
order deemed a classified document), it is the authorised agency’s duty to select a dedicated encryption
of this document (e.g. using Chiasmus encryption software) and transmit it by the Email-ESB after
agreement with the undertaking concerned. The encryption process by the OpenPGP Standard is not
affected by this.
If the Email-ESB transmission process is not integrated into the query system, the connection between
the query system and Email-ESB must have transport protection in accordance with Section 4.1 of the
requirements catalogue pursuant to § 180 Telecommunications Act. Data transport between the facilities
by data carrier (e.g. USB stick) is not permitted. Moreover, the requirement for automatic logging
pursuant to § 35 TKÜV must also be ensured.
The following applies to obliged entities to protect against access from the internet:
the hardware and software component used for the Email-ESB transmission procedure must not
be used for any other purposes;
the Email-ESB transmission procedure must be disengaged from the internet after use; and
a firewall must be installed between the Email-ESB transmission procedure and the internet
connection.
In addition, the plain data arising in the Email-ESB transmission procedure must be deleted from RAM
after transmission. Outsourcing to a hard drive or, for example, into a file for "Sent items" or similar must
also be prevented (Section 3.2.2 in Part B).
According to the second sentence of § 177(3) Telecommunications Act, traffic data stored under § 176
Telecommunications Act are to be identified at the time of transmission to the authorised entity. For this
purpose, each individual traffic record must be marked with the syntax “prepared traffic data”. Operational
traffic data to be transmitted shall be marked with the syntax “operational traffic data”.
Upon transmission of the surveillance order or in a separate email, authorised agencies can specify the
disclosure of delayed traffic data (late records) which will only become available after a waiting period and
after the queried period has elapsed. The waiting period to be agreed with the Federal Network Agency
has to be long enough for late records to be regularly recorded completely. Disclosure of these late
records takes place after this waiting period and includes, where appropriate, all the traffic data stored at
this point for the entire period. This specification may be withdrawn by the authorised agencies in a fresh
email.
TR TKÜV, edition 8.0 (draft) Part B, Annex A, page 133
Format of the order
The order shall be converted into the multipage TIFF format (CCITT Group 4 Fax) for transmission. The
maximum file size is 5 MB. If a follow-up order does not contain all the required data (e.g. legal basis,
identifier, period), they must be transmitted in a single file together with the original order.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.1, page 134
Part X Informative Annex
TR TKÜV, edition 8.0 (draft) Part X, Annex X.1, page 135
Part X contains the proposed changes to the TR TKÜV which should serve as a basis for discussion of
the next edition, as well as additional information on the various Annexes to this publication.
Annex X.1 Proposed changes to the TR TKÜV
This Annex is non-mandatory as defined in § 170(6) of the Telecommunications Act. It only notifies
possible changes in the future, the necessity of which will be determined only after the completion of this
issue or after completion of international standards in progress or with the launch of corresponding
services or technologies. These changes will be agreed upon in the preparation of the next edition of TR
TKÜV.
In the context of furnishing proof pursuant to § 170(1) point 4 of the Telecommunications Act, the Federal
Network Agency will approve any implementations produced on the basis of this informative Annex as
technically correct.
The proposed changes have been inserted into the relevant copied text segment and marked as such by
means of bold italics and underlining.
Annex X.1.1 Forwarding of packet-switched voice communication services (e.g.
VoLTE)
Against the background of the imminent possibility of ISDN-based decoupling and the current decoupling
between access network and IMS in mobile communications, the following roadmap for forwarding
packet-switched voice communication services (e.g. VoLTE) was agreed, to be implemented depending
on available 3GPP specifications. The current regulations described below (stage 1) shall also apply to
corresponding services provided by mobile virtual network operators (MVNO) that provide their services
(e.g. VoLTE) independently of the access network. In this case, the IMS operator (usually the MVNO)
shall forward the VoIP portion and the EPS Service Gateway operator (usually the operator of the mobile
telecommunications access network used) shall forward the LocationInformation. The information is
correlated as follows.
Step Description Time limitation
1 Actual state
The two sets of information shall be forwarded concurrently in accordance
with 3GPP TS 33.108 and ETSI TS 102 232-5:
ETSI TS 102 232-5 for the VoIP portion according to Annex H
3GPP TS 33.108 as IRI-only for the LocationInformation according to
Annex D
the correlation can be done via LIID and timeStamp, the CIN is not
correlated between both outputs
The form of the dual forwarding shall be tolerated under the following
circumstances:
1. the timeStamp information must be correct
2. the correlation must be clearly possible for all services and service
features (e.g. Multi-SIM) by means of LIID, timeStamp and, where
applicable, IMSI. This may need to be explained in the plan.
3. The derivation of the location information must be reported with the
timestamp at which it becomes known to the network; the forwarding
must take place immediately after this event
4. It must be possible for the LocationInformation to also be provided
solely to terminals in stand-by mode when ordered, and thus for the
requirement under § 7(7), No 7, second clause of the TKÜV to be met
2 Use of 3GPP TS 33.128 modules only
The use of ETSI TS 102 232-5 shall be replaced by the use of the
corresponding 3GPP TS 33.128 modules designed for the respective
services.
The necessity described in stage 1 of the dual forwarding according to
3GPP TS 33.128 from the access network as well as the IMS with the
correlation via LIID and timeStamp will continue to apply here and will be
linked to the same conditions.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.1, page 136
Annex X.1.2 Security requirements
Under § 14(1) TKÜV, the obligated party must, among other things, use state-of-the-art technology to
prevent unauthorised use of the measures it must take to technically implement orders, in particular the
technical equipment for controlling the surveillance functions and the transmission point under § 8 TKÜV,
including the intermediate transmission paths. Pursuant to § 36(1) TKÜV, technical features to this end
may be set out in the TR TKÜV.
In a next issue, the Federal Network Agency plans to establish appropriate provisions covering the
monitoring functionality in the TKA-V, the monitoring functions, the transfer point and the transmission
lines between them.
In addition to basic security standards and BSI technical guidelines, the Federal Network Agency will also
consider the various ETSI specifications (e.g. ETSI TS 103 308 and 103 487) in these provisions. Once
the relevant security requirements have been fully drawn up, the corresponding specifications shall be
included in the TR TKÜV as references.
On the basis of these provisions, a questionnaire will be developed. This will need to be completed as
part of the required documents for the evidence notice and in it the obligated party shall describe the
anticipated risks related to the cited systems, equipment and transmission paths and the specific
protective measures taken, as with the procedure under § 166 Telecommunications Act.
In line with the risk assessment to be carried out, specific requirements are desired for certain risks, e.g.
for:
installations, facilities or transmission routes not located on their own premises or located abroad
systems, equipment and transmission paths for which sufficient IT security measures are
currently not possible and so need supplementing with increased physical security measures.
To solve this issue, a special work group is scheduled to be convened.
Annex X.1.3 Future requirements for mobile communications, in particular for
5G
Future network technologies can offer new challenges in meeting regulatory requirements for
telecommunications surveillance, which need to be identified and for which solutions need to be created.
This informative Annex is intended to describe new technologies and set out the problems or challenges
that may occur in line with current knowledge in order to raise awareness of these issues among
manufacturers, network operators and authorised agencies as early as in the development stage, and to
develop possible solutions for the future TKÜ via the standardisation route.
The aim is also to make it possible to revert to standardised solutions for new network technologies by
describing the technical implementations in this guideline. Otherwise, specific national solutions would
need to be devised, and these could lead to significantly higher costs due to the individual nature of their
implementation.
Currently, the technical requirements are being developed for the new mobile telecommunications
standard, 5G. At the same time, the LI requirements are also in the process of being standardised.
Fundamentally, the surveillance functionalities must also comply with statutory requirements in future
networks, although lower quality or more complex analysis must be anticipated due to stronger
encryption.
Some aspects of the development already known are discussed below and commented on certain
challenges of artificial monitoring functionality:
- Identity recognition
Where possible, IDs in 5G should be routed using pseudonyms that cannot be traced back to the user
(keyword ‘privacy’). In this case, for LI all LI-relevant interfaces will in future have to be designed such
TR TKÜV, edition 8.0 (draft) Part X, Annex X.1, page 137
that the pseudonymised identities can be reassigned to a user. In roaming situations too, operators will
have to take account of the required mechanisms at the interfaces in terms of transmission and
recognition mechanisms.
- Network slicing
5G network slicing will allow network operators to divide individual physical networks into several virtual
networks in which the network slices can be retrieved as necessary. In future, therefore, networks will be
able to be implemented across countries. As a result, issues may arise in terms of data security/integrity
when executing a judicial order. For example, target lists may be managed abroad, or entire network sub-
services may be rented by foreign operators.
When designing services abroad, network operators shall be responsible for implementing the security
requirements and forwarding in accordance with German law.
- NFV - Network Functions Virtualisation
With the introduction of Network Functions Virtualisation under 5G, operators are given the opportunity to
implement their networks in a virtual environment and thus become less reliant on hardware. It should be
ensured that the use of Network Functions Virtualisation does not restrict the proper functioning of LI.
Note on location data:
In the case of other or future networks (e.g. 5G), it has to be ensured that the location information so far
provided and now available on the entire network will be reported even if standardisation has not included
transporting this information to the core network or the recording points for event data.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.2, page 138
Annex X.2 Assignment of identifiers for authorised agencies to ensure
uniqueness of reference numbers
Basic principles
Pursuant to § 7(2) sentence 1 TKÜV, every obligated company should designate every surveillance copy
transmitted by means of the reference number of the respective surveillance action as prescribed by the
authorised agency, if this copy is transmitted to the authorised agency via telecommunications networks
with transmission capabilities.
Pursuant to the TR TKÜV and the underlying ETSI and 3GPP specifications, the reference number
should be composed of a maximum of 25 characters.
The permitted character subset consists of all upper-case and lower-case letters ‘a’…‘z’, ‘A’…‘Z’ (without
umlauts), all digits and the characters ‘-’, ‘_’ and ‘.’. However, when using ISDN stubs for transmission of
the copy of the content, only the digits ‘0’ to ‘9’ are permitted.
Depending on the implementation of the ETSI interface and the associated change in administrative area,
preallocation of the reference number by authorised agencies is now possible in most cases.
Possible problem cases
On the other hand, many network elements depend on different actions not being administered with
identical reference numbers. In practice, situations where the same reference number has been assigned
by different authorised agencies may lead to ambiguities and therefore potential technical errors in the
surveillance technology when matching and transmitting surveillance copies. As a consequence, there
could in some cases be a partial or complete failure to forward copies of the content to authorised
agencies.
Ensuring uniqueness of reference numbers
To ensure uniqueness and thereby an error-free operation of transmission devices, an additional
parameter is needed as part of the reference number. This identifying parameter ensures differentiation of
the authorised agencies, who in turn assign the remaining positions of the reference number
independently to uniquely identify the surveillance action.
To ensure the above, the Federal Network Agency assigns a once-only, unique three-character AA ID to
each authorised agency.
In the future surveillance actions, this AA ID should be placed in the first three positions of the reference
number, provided the obligated undertaking required to implement the order has already introduced the
ETSI implementation. The authorised agency then informs the obligated party of the entire reference
number including the AA ID.
Accordingly, the entire reference number will be composed as follows:
1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
AA ID 22 positions per authorised agency to assign unique reference numbers
Permitted characters, in principle: "a’…’z’, ’A’…’Z’ (ohne Umlaute), ’-’, ’_’, ’.’, und
"0’…’9’. Permitted characters for ISDN forwarding: "0"..."9"
The allocated AA ID will also be used for the interface for technical implementation of legal measures for
information requests on traffic data (see Part B of this TR TKÜV).
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 139
Annex X.3 Provisions for the registration and certification authority TKÜV-CA of
the Federal Network Agency, Department IS16 (Policy)
The Federal Network Agency defines the regulations for the registration and certification authority TKÜV-
CA and for participation in the Virtual Private Network (TKÜV-VPN). In doing so, it must take into account
the respective state of the art (§ 14 TKÜV).
If, in the course of further development of the state of the art, stricter requirements are to be placed on the
precautions to be taken or if the need arises to change precautions already taken, the VPN subscribers
shall make the necessary adjustments in accordance with the specifications of the Federal Network
Agency within a period to be specified by it in each individual case.
The currently valid policy is available for download at: //www.bundesnetzagentur.de/tku
1 General
1.1 Introduction
This policy contains the provisions on the Registration and Certification Authority of the Federal Network
Agency, Department IS16 (TKÜV-CA) for participation in the Virtual Private Network ‘TKÜV-VPN’ and the
details to be provided by subnetwork operators for the administration of the Public Key Infrastructure
(PKI) as well as a description of the overall process.
These provisions are mandatory for both the authorised agencies participating in the procedure and the
obligated parties under § 170 and/or § 174 Telecommunications Act as subnetwork operators of the VPN.
1.2 Identity of the Registration and Certification Authority TKÜV-CA
Address: Federal Network Agency
Department IS 16
Canisiusstraße 21
D-55122 Mainz
Email:
[email protected]
Note on email transmission: When sending confidential information (e.g. application for
VPN participation) by email, PGP encryption software should be used.
1.3 General information services provided by the TKÜV-CA
Additional details and requirements of the TKÜV-CA are made available on the website of the Federal
Network Authority www.bundesnetzagentur.de/tku.
1.4 Validity of this document
The current SINA policy, “TKÜV-CA (Policy)” is available in version 2.1.1 with date 16 June 2021 and is
valid for the operation of the TKÜV-VPN until revocation or publication of a new issue. Details on the
validity of this document will be published via the general information services of the TKÜV-CA on the
above internet address.
2 Services provided by the TKÜV-CA
2.1 Creation of the certificates, management of the Certification
Authority
The TKÜV-CA creates and manages the certificates for participation in the TKÜV-VPN and for secure
transmission between obligated parties and authorised agencies. To this end, it registers the relevant
participants, creates for each participant the cryptographic key required for the authentication of his
systems, and certifies this key using its own CA key. The certificates thus created are stored on smart
cards, which are provided by the respective participants to the Federal Network Agency as operator of the
TKÜV-CA.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 140
The TKÜV-CA also creates and maintains the Access Control List (ACL) based on the details supplied by
the participants, making this list available for use by the cryptoboxes via an LDAP directory service. In
order to administer any present local routers, the required associated IP addresses of the ACL are made
available on request to the subnetwork operators.
To verify the security relationships or the used cryptoboxes, the TKÜV-CA operates a test device which is
kept on standby in case of failure. The system does not allow the Federal Network Agency to test the
security relationships between the obligated parties and authorised agencies.
2.2 Security of the CA system
All technical devices of the TKÜV-CA which are required to operate the TKÜV-VPN are located in special
access-controlled areas. Dedicated computers are used for the services of the TKÜV-CA; communication
between the cryptoboxes operated within the VPN and the directory service and associated central
management is itself secured by means of a cryptographic procedure.
The creation of certificates and maintenance of the ACL takes place in accordance with the “four eyes
principle”.
The operation of the devices of the TKÜV-CA is provided with support from the manufacturer of the
systems. These contractual provisions do not relate to the systems used by the authorised agencies and
the obligated parties.
3 Requirements for participants
Participants in the TKÜV-VPN as defined in this Policy are the authorised agencies and the obligated
parties, with their respective subnetworks.
Participants shall appoint one CA officer for each TKÜV-CA and, where appropriate, one representative,
who will be the liaison for the relevant subnetworks and, in particular, will be responsible for security.
In urgent situations, the CA officers will receive the required information from the CA administrator via
phone, email or normal post. It should be ensured that these messages are retrieved quickly.
The following requirements apply to CA officers and their representatives:
The smart cards described by the TKÜV-CA should be handled with normal caution to prevent
abuse by unauthorised persons and may only be passed on to persons entrusted with the
operation or administration of the relevant cryptoboxes.
Upon request, e.g. in case of subsequently known security defects, the smart cards for deletion of
the content data must be returned to the TKÜV-CA.
If there are grounds to disable a certificate (e.g. company shutdown, loss of the smart card,
abuse), this should be reported to the TKÜV-CA immediately so that the required measures (e.g.
disabling in the directory service, revocation of the certificate) can be taken.
Otherwise, the requirements of the TKÜV shall apply, particularly § 15 TKÜV (confidentiality).
4 Rules for registration
To facilitate registration, a set of instructions, a registration form and the IP configuration of the
cryptoboxes will be made available at the internet address of the TKÜV-CA ( VPN participation
application form).
4.1 Registration of the authorised agencies
Since the relevant authorised agencies can be identified uniquely, there will be no verification of personal
identity. Registration or issuance of a smart card is requested from the TKÜV-CA by email and in writing,
together with all the required details, by a CA officer appointed by the authorised agency.
In the event of a new registration, change or removal of the person responsible for CA or the
representative, the TKÜV-CA must be immediately informed (“application SINA-VPN” on the website of
the Federal Network Agency at bnetza.de/TKU); these changes do not require replacement of the smart
card.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 141
4.2 Registration of the obligated parties
Obligated parties are each registered through verification of their personal identity by means of an identity
card or passport.
The appointed CA officers or representatives appointed by those responsible within the undertaking
should preferably be persons entrusted with the organisational management of the technical facilities
used to implement the surveillance actions, e.g. the persons appointed under § 19 TKÜV or others
charged with the tasks of an administrator.
The CA officer requests the registration or sending of a smart card to TKÜV-CA by email or in writing (
SINA-VPN application) with all data to be provided to the persons to be registered.
Registration is done at TKÜV-CA.
New registration becomes necessary when a registered person of the obligated party is replaced. The
removal of a registered person or a change in the legal status of the obligated party should immediately
be notified to the TKÜV-CA ( VPN participation application); these changes do not require replacement
of the smart card.
5 Rules for certification
The TKÜV-CA issues certificates only for the entire TKÜV-VPN process.
A set of instructions and forms for certification will be made available at the internet address of the TKÜV-
CA.
Certificates are produced with a maximum validity of 4 years; the user certificate is linked to a single
smart card.
5.1 Data to be provided
For the purposes of certification ( SINA participation request), participants submit their basic details;
these are used to create the X.509 certificates and to create or update the ACL in the directory service.
The subsequent detailed decisions are made autonomously by the TKÜV-CA. The submitted details are
stored securely.
The naming scheme is prescribed by the TKÜV-CA. Other naming conventions do not have to be
observed due to the closed VPN.
A. Data for the X.509 certificates
(determined by TKÜV-CA)
The X.509v3 certificates used in this procedure create the link between the identities of participants
in the TKÜV PKI, in the form of an X.500 Distinguished Name (DN) and a public key which is certified
by the digital signature of the TKÜV-CA. The DN is included in the certificate as the subject and
combined with the public key. The relevant format is given in the table below.
Table ‘Format of the X.500 Distinguished Name (DN)’
Feld Meaning Value
C Land (Country) DE
SP State of Province Name (Bundesland) . 1)
L Locality Name (Ort) . 1)
O Organization Name (Organisation) regtp_sina
OU Organizational Unit Name (Abteilung) further subdivision if necessary (in addition
to CN)
CN Common Name (Name) name of the authorised agency or
obligated party (e.g. ‘LKA_Stuttgart_1’)
email email address of the identity to facilitate administration of names (is
derived automatically from the data in the
form: CN@[OU].O.C)
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 142
1) If a value ‘.’ is entered, the field remains unused.
The Distinguished Name corresponds to the user name in the cryptobox, which can be viewed on
the display of the cryptobox.
Example: C: DE, O: regtp_sina, CN: LKA_Stuttgart_1, LKA_Stuttgart_1@regtp_sina.de
Table ‘Format of the X.509v3 certificate’
Feld Meaning Value
version Version of the X.509 certificate 3
serial number unique number for each certificate consecutive number
signature signing algorithm used
issuer Distinguished Name of the TKÜV-CA see above
validity period of validity
subject Name Distinguished Name of the authorised agency or
obligated party
subject public key of the owner (subject name)
PublicKeyInfo
unique Identifiers unused
Extensions
rfc822Name mapping of the DN to an email address used for IPSec; is
created
automatically
B. Data for creation/extension of the ACL
(set by TKÜV-CA following general provision by participant)
The Access Control List (ACL) contains all valid security relationships of the relevant participants,
and is managed exclusively by the TKÜV-CA.
After commissioning or restart of the cryptobox with the smart card issued by the TKÜV-CA, the
cryptobox automatically sets up a connection to the directory service and loads the current ACL. The
ACL provided is always signed by the TKÜV-CA; the cryptoboxes will not accept unsigned ACLs.
After this, the system is ready for operation.
The data required for creating or supplementing the ACL concern the issued certificate and the
unique IP addresses used to address the application (IP endpoint) behind the cryptobox (IP WAN
and IP local), to be supplied by the participants.
For assigning the IP addresses, the subnetwork operators will be given a guideline with an example
configuration ( VPN participation request, chart).
Subnetwork operators are responsible for the accuracy of their details; the Federal Network Agency
may merely conduct a simple plausibility check.
Table ‘Necessary public IP addresses for unique addressing’
Field Meaning Value
IP-Router-WAN internal IP address of the (default) router required
exposed to the internet
IP-Crypto-WAN IP address/subnetwork mask of the cryptobox required
exposed to the internet
IP-Crypto-Local IP address/subnetwork mask of the cryptobox required
exposed to the internal network
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 143
IP-Router-Local IP address of the internal router used to connect optional (depends
more subnetworks to the box on network
structure)
IP application IP address(es) of the devices supplied to required 1)
implement the legal measures
IP-Logserver IP address of a dedicated log server receiving required 1)
operational and audit logs
1) Private IP addresses can be used for the connection; these must then be connected to the
public IP address of the IP cryptobox (IP-crypto local) by means of address translation (NAT). The
NAT, in turn, should of course be assigned a unique IP address exposed to the cryptobox.
5.2 Instructions
Persistence of connection of the cryptoboxes to the internet
The exact connection of the cryptobox to the internet (IP configuration) as the subscriber-side
portion of the security relation to the management and LDAP server of the TKÜV-CA, as well as
to the dedicated IP log server, are stored persistently on the smart card with the Auto-Init option,
so that at the start of the cryptobox, the ACL can be downloaded and any errors reported. In
case of changes, a new smart card needs to be issued by means of the application procedure
( VPN participation application).
In case of changes to the application proper (IP usage application) which do not affect the IP
configuration, a new smart card need not be issued.
Acceptance of designated hosts only (applications) behind the cryptobox
In addition to the security interactions between the cryptobox, the management, the
LDAP server of the TKÜV-CA and the dedicated IP log server, only uniquely designated hosts
(applications) are defined as security relations in the ACL; acceptance of entire subnetworks is
permissible. However, the TKÜV-CA reserves the right to limit the number of individual security
relationships and/or the size of the subnetwork at its own discretion. The security relationships
between the hosts of the obligated party and those of the authorised agencies are always
mutual.
Use of routers, package filters, firewalls, etc.
When using routers or network elements with package filtering or firewall functionality on the
internal side between the cryptobox and the host within the subnetworks, it should be ensured
that the administration of such elements - where required - does not cause any delays or
obstructions to the implementation of surveillance orders. If such network elements are relevant
for the IP configuration, they should be mentioned.
Providing partners’ IP addresses
In order to administer any network elements for routing, the TKÜV-CA supplies lists of the
required IP addresses on an FTP server operated by the TKÜV-CA and secured by means of a
cryptobox. The operators of subnetworks will be granted access rights upon request; retrieval
and processing of this list are the responsibility of the operators of the subnetworks, and the
content of the lists should be handled confidentially.
5.3 Test of security relationships or cryptoboxes used
After the subnetwork is commissioned, a test will be conducted to ensure correct operation, using the test
device operated by the TKÜV-CA for authorised agencies and obligated parties. This test serves to verify
the basic functionality of the IP configuration and the security relationships defined for management and
testing systems; it is done at the obligated party’s premises prior to acceptance of the technical
surveillance device. The system does not allow the Federal Network Agency to test the security
relationships between the obligated parties and authorised agencies.
5.4 Fact sheet for unique addressing of subnetworks
In case of participation in the VPN or use of cryptoboxes in the subnetworks of the obligated parties and
the authorised agencies, it should be explained how the relevant subnetwork will be uniquely addressed.
In addition, the IP addresses needed for the procedure should be notified to the TKÜV-CA. To support
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 144
participants in their planning, a fact sheet has been developed which can be obtained from the relevant
information services. No guarantee can be given as regards the completeness of this fact sheet due to
the large number of technical solutions that are possible.
5.5 Example layout
IP log server
Network Log
admin. server
In-house
network
Internet
WAN
local cryptobox
firewall router
router
IP application IP router WAN
IP crypto WAN
local IP router IP crypto local
Diagram 1 ‘Example of a subnetwork with unique IP addresses’
Another example can be found in the VPN participation application.
6 Disabling a smart card
Disabling of a smart card takes place by means of a corresponding entry on a blacklist which is
transmitted to all participating cryptoboxes and loaded by them upon restart. The entry in the blacklist
ensures that the cryptobox equipped with the associated smart card will be excluded from participation in
the VPN. Identical backup cards will also be affected. A card is normally disabled after consulting the
relevant VPN participant. However, cards may also be disabled with immediate effect if there is sufficient
reason for doing so.
The blocking of a smart card can be necessary, for example, if
the issued smart card was lost or compromised,
misuse has occurred or the conditions of the TKÜV-CA have been violated,
there are circumstances requiring a temporary shutdown of the cryptobox.
The VPN participants are obliged to immediately notify the TKÜV-CA of a possible blocking reason.
Depending on the reason for blocking, a blocked smart card can also be removed from the blacklist
again, so that it can be used in normal operation.
7 Revocation of certificates
Certificates may be revoked only directly at the TKÜV-CA by an entry in the directory. The VPN
participants are obliged to inform the TKÜV-CA of a possible reason for withdrawal without delay.
Revocation of a certificate may be necessary, for example, when
the issued smart card was lost or compromised,
data in the certificate are invalid (change of IP configuration, company shutdown),
misuse has occurred or the conditions of the TKÜV-CA have been violated.
A certificate is always revoked when a smart card is deleted.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 145
A certificate is generally revoked after consulting the relevant VPN participant. However, on a given
occasion, the revocation can also be made directly by the TKÜV-CA without consultation. A withdrawal of
the revocation is not possible. If a company resumes operations, a new smart card needs to be issued.
8 Distribution and handling of smart cards
For the configuration and authentication data, smart cards are used onto which details of the user and
cryptobox are stored.
The required quantity of empty cards of the relevant type should be enclosed by the relevant VPN
participant together with the VPN participation request. It is normally recommended to have an identical
replacement card created for each IP cryptobox. Smart cards are distributed by the TKÜV-CA in person
or via post to the designated group of persons (registered persons) of the relevant VPN participant.
Smart cards are protected by a PIN/PUK combination as standard. The PIN is hard-coded by the TKÜV-
CA to a value where the cryptobox boots into its operational state after power-up without prompting for
the PIN. The PIN can be overwritten by the keyboard of the cryptobox; however, for a PIN other than the
registered PIN, the manual input of the PIN on the cryptobox is necessary for each boot of the system
(off/on).
Therefore, the PIN should not be modified!
9 Card content
The values set out in the following table are stored on the smart card at dispatch by the TKÜV-CA. The
following are defined as shown:
Column M (as in manipulation-secure): Data with an 'X' in the column are stored on the smart
card and protected from manipulation.
Keyword IP addresses: The “black side” or “black network” is the side of the cryptobox which is
exposed to the internet, hence insecure, and is therefore encrypted. ‘Red side’ or ‘red network’
means the unencrypted area in the secure network.
Keyword M Value / keyword
CA public key X
CA certificate X Certificate and public key of the certification authority
Key pair of the user X Certificate, public and private key of the user
Validity of the X Encoded into the user‘s certificate; 4 years
certificates
Parameter sets for key Cryptographic parameters necessary for the calculation of temporary
exchange keys between participants
Security relationships One security relationship each for the management system and the
LDAP directory (required for initial downloading of the ACL after power-
up of the cryptobox) and security relationships for the test devices of the
Federal Network Agency. These security relationships are generally
stored persistently; this means that these relationships cannot be
overwritten by entries of the ACL. Part of the security relationship are
the cryptographic functions to be used (one-way function / encryption
algorithm)
PIN / PUK Security mechanism
IP address of the Interface name (ethX), IP address/subnetwork mask
cryptobox (black side)
IP address of the WAN IP address
router (black side)
IP address of the Interface name (ethY), IP address/subnetwork mask
cryptobox (red side)
Releases IP addresses of the releases
IP address of the syslog IP address of the dedicated syslog server
server(s)
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 146
IP address of the NTP The TKÜV-CA operates its own NTP server, whose IP address is
server(s) encoded; a client-side NTP server may also be used
Time limit Time interval for querying the NTP server
IP address of the hot- Only if used: Interface name (ethZ), IP address/subnetwork mask
standby interface
The menu system of the card reader integrated into the cryptobox allows a number of settings to be read
and partly modified (PIN, time); further explanations can be found in the manual for the cryptobox.
Examples:
Keyword Value / keyword
IP configuration, "black side" Interface name (ethX)
IP address/subnetwork mask
IP configuration, ‘red page’ Interface name (ethY)
IP address/subnetwork mask
LDAP server IP address
Syslog-Server IP address
NTP server IP address
Identities username = Distinguished Name
Versions ACL version
Number of policies
Show/Set Time Display and editing of date and time
10 Management of cryptoboxes/selection of options
10.1 Architecture of management and test devices at the Federal
Network Agency
The architecture of the overall management at the site of the TKÜV-CA for the cryptoboxes used in the
subnetworks is divided into two subsystems:
a management station to administer the cryptoboxes, set up the security relationships and create
the smart cards, and
a server for the directory service (LDAP) and a general database.
Both subsystems are connected to the internet via a cryptobox. The entire management is duplicated for
reasons of redundancy.
For each subsystem, security relationships with all cryptoboxes in the subnetworks of the authorised
agencies or obligated parties (but not the hosts secured by them) should be hard-coded on the smart
card. The management system should be able to reach the cryptoboxes for ACL updates and the
cryptoboxes should be able to reach the server to load updated ACLs.
All security relationships are set up by the TKÜV-CA. Security relationships with the subsystems of the
management system must be hard-coded on the smart cards; the security relationships of the obligated
parties’ hosts with the authorised agencies’ hosts are entered in the ACL of the directory service and then
loaded into the cryptoboxes by the TKÜV-CA automatically or manually.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 147
obligated party Authorised
agency
Internet
technical equipment evaluation
for transmission of
analysis
devices
‘Management access II’ ‘Management access I’ ‘Test access’
secondary
LDAP and primary
cryptobox
LDAP and test location
PKI
Database management reference facility
Structure of the PKI and the test device/reference system at the Federal
Network Authority
Diagram 2 ‘Architecture of management and test devices at the Federal Network Agency’
The test device (reference system) of the Federal Network Agency is used for acceptance pursuant to §
170 and/or 174 Telecommunications Act and for functional testing of the authorised agencies’ and
obligated parties’ cryptoboxes after commissioning. The system does not allow the Federal Network
Agency to conduct functional tests of the connections between obligated parties and authorised agencies
as defined in the ACL. However, participants do have such a possibility pursuant to § 23 TKÜV.
11 Selection of options/values
The management system allows various options for configuration of the cryptoboxes and security
relationships which have to be decided before issuance of the smart cards. These options are shown
below.
11.1 Log server
As each subnetwork operator is individually responsible for planning, use, maintenance and
troubleshooting of the cryptoboxes, they should each operate their own log server. The Federal Network
Agency does not provide log servers for the participants; it also does not obtain access to the participant-
side log servers.
The cryptoboxes used have no local mass storage devices such as hard disks or floppy drives. Therefore,
event reports cannot be stored locally. However, as these are needed for surveillance of the cryptoboxes
and network, log servers should be set up. The IP address of the log server and the connection between
the individual cryptobox and the associated log server are stored persistently on the smart card. The UDP
protocol with port 514 is used throughout.
Several SYSLOG servers may be set up for each cryptobox and the log data will then be transmitted to all
log servers.
11.2 Heartbeat
In addition to the log server, a time interval may be given after which the cryptobox sends a message to
the log server(s) to signal its operation, even when there is no further activity to be recorded. This
information is used to transmit certain system states such as interface statistics, uptime, etc. If no value is
entered, heartbeats will not be produced. However, normal activities will always be recorded, independent
of this setting. The heartbeat setting applies to all registered log servers.
TR TKÜV, edition 8.0 (draft) Part X, Annex X.3, page 148
As part of the application procedure ( VPN participation application, options sheet), subnetwork
operators may indicate how this function should be used.
11.3 NTP server
The NTP server provides the time service within the PKI. The time (and date) retrieved from this server
enables the cryptobox to determine whether a given certificate is still valid. If a box does not yet have
access to an NTP server, as this connection first needs to be set up, the local time as given by the on-
board system clock is used for comparison. After a successful connection to an NTP server, the
cryptobox clock is also synchronised to the server's time.
The Federal Network Agency provides an NTP server exclusively for cryptoboxes via its management
system; the required security relationships are stored persistently on the smart card. The reference time
is UTC, as derived from the official time of the Federal Republic of Germany. Participants may optionally
enter their own NTP servers.
It is possible to enter multiple NTP servers per cryptobox. In this case, they are queried in the order
stored on the smart card.
Querying an NTP will create a syslog entry.
11.4 Supplying IP addresses of partner subnetworks
In order to administer network elements for routing and/or filtering where required, the TKÜV-CA supplies
a list of the required IP addresses on its own FTP server, secured by means of a cryptobox. The
operators of subnetworks will be granted access rights upon request; retrieval of this list is the
responsibility of the operators of the subnetworks. The list is only updated as needed.
11.5 Hot standby (HSB)
In hot standby mode, two cryptoboxes are installed to operate as a cluster. One of the systems is active
(master or Sys1), whereas the second system (slave or Sys2) takes over in the event of the failure of the
first system. This mode of operation requires specially prepared smart cards.
11.6 Software version cryptobox
At present, only SINA Boxes from Secunet are used as cryptoboxes. Only version 3.7.4.3 or newer is
permitted as operating software for the SINA Box.
11.7 Smart cards
Only Starcos smartcards version 3.5 with the BSI patch ECGDSA are currently approved.
12 Other applicable documents
Other applicable documents, in their respective current versions, are:
Telecommunications Act (TKG)
Telecommunications Surveillance Ordinance (TKÜV)
Technical Guideline for the implementation of legal measures for the surveillance of
telecommunications and the disclosure of information (TR TKÜV)
VPN participation request
TR TKÜV, edition 8.0 (draft) Part X, Annex X.4, page 149
Annex X.4 Table of applicable ETSI/3GPP standards and specifications as well
as the ASN.1 modules
On the basis of § 11 sentence 5 TKÜV, the Federal Network Agency publishes information on the
applicable versions of the ETSI and 3GPP standards and specifications in force pursuant to the TR TKÜV
on its website in the section on telecommunications, under the keywords ‘Technical Regulation of
Telecommunications’ / ‘Technical Implementation of Surveillance Actions’.
An essential part of this are the applicable ASN.1 modules.
Any syntax errors present in the ASN.1 modules should be corrected and care taken to use the correct
Object Identifier (OID) or version number. In addition, versions of the modules that are not backwards
compatible with the other versions must not be applied.
The following table contains this information when this issue of the TR TKÜV is published.
Applicable ASN.1 modules Version of the Requirements or instructions for application
(more recent versions than those given standard or
can normally be applied) specification
ETSI ES 201 671, TS 101 671 (Annex C)
This includes the versions of modules which have an OID as well as older versions which have previously been
implemented in the networks with their concepts endorsed.
HI2Operations Version 10 This version contains an error from edition 3.2.1 of the
specification, which makes it incompatible.
Accordingly, this version may only be used up to
edition 3.1.1.
HI2Operations Version 11 This version contains an error which makes it
incompatible. This version may not therefore be used.
Edition 3.6.1. of the specification removes the error
from the then Version 12.
3GPP TS 33.108 (Annex D)
This includes the versions of modules which have an OID as well as older versions which have previously been
implemented in the networks with their concepts endorsed.
3GPP TS 33.128 (Annex D)
TS33128Payloads, R16, version 2 Version 16.3.0
ETSI TS 102 232-01 (Annexes F.3 and G)
LI-PS-PDU, Version 4 Version 1.4.1
ETSI TS 102 232-02 (Annex F.3)
EmailPDU, Version 3 Version 2.1.1
ETSI TS 102 232-03 (Annex G)
IPAccessPDU, Version 4 Version 1.6.1
ETSI TS 102 232-04 (Annex G)
L2AccessPDU, Version 3 Version 1.3.1
ETSI TS 101 909-20-2 (Annex G)
PCESP, Version-4(4) Version 1.1.2
TS101909202, interceptVersion (0)
ETSI TS 102 232-05 (Annex H.1)
IPMultimediaPDU, Version 1 Version 2.1.1
ETSI TS 102 232-06 (Annex H.2)
PstnIsdnPDU, Version 1 Version 2.1.1
ETSI TS 101 909-20-1 (Annex H.3)
TS101909201, interceptVersion (0) Version 2.1.1
TSI TS 103 707 (Annex I)
XML XSD definition according to Annex Version 1.1.1
B
ETSI TS 102 657 (Part B)
TR TKÜV, edition 8.0 (draft) Part X, Annex X.4, page 150
The uses are published on the Federal
Network Agency’s website at
http://www.bundesnetzagentur.de/tku
TR TKÜV, edition 8.0 (draft) Part X, Annex X.5, page 151
Annex X.5 Standard concept for the preparation of verification documents, test
records and test reports for verification testing
For the preparation of the documents pursuant to § 19 (2) and § 34 (1) TKÜV and for the review of the
organisational precautions pursuant to § 17(4) and § 35 sentence 7 TKÜV, the Federal Network Agency
provides the documents described below:
Standard concepts
Pursuant to § 19(2) TKÜV, the Federal Network Agency may specify requirements regarding the
documents (concept) to be submitted by the obligated party. This is done by providing service-specific
standard concepts which generally refer to the topics listed in § 19(2) TKÜV. This should make it easier
for obligated parties to submit the necessary documents for examination. In the standard concepts, for
example, the organisational precautions (e.g. overall responsible person, business hours, contacts,
contact persons) or the description of technical matters (e.g. explanation of services and features as
support for the evaluation, description of the telecommunications system, the surveillance equipment or
the information systems) are dealt with.
A standard concept for each of the different services is published on the website
www.bundesnetzagentur.de/TKU
The obligated installation operator shall use the standard concept for the design of the verification
document (concept) to be submitted.
Test protocols and test reports
The Federal Network Agency shall use test protocols or test reports for the examination of technical and
organisational arrangements pursuant to § 170(1), first sentence, point 4 Telecommunications Act and for
inspection pursuant to § 17(4) and § 35 sentence 7 TKÜV. As preparation of the obligated companies for
the audit to be carried out and as basic preparation for the requirements resulting from the TKÜV and TR
TKÜV, the documents are provided by the Federal Network Agency upon request or in advance of the
audit.
TR TKÜV, edition 8.0 (draft) Part X, continuation, page 152
Updates
The procedure for future updates to the TR TKÜV is governed by the provisions of § 36 TKÜV, pursuant
to which the Federal Network Agency lays down the relevant details, with the participation of associations
of obligated parties, authorised agencies, and manufacturers of surveillance systems and recording and
analysis devices.
Fundamental changes to this Guideline will be denoted by means of a new edition number before the
decimal point.
Adjustments and additions to parts of the TR TKÜV which were already described in a previous edition
will be denoted by a new version number after the decimal point.
In both cases, new versions of the TR TKÜV will be notified in the Federal Gazette and the Official
Journal of the Federal Network Agency.
Edition list
Edition Date Reason for change
1.0 December 1995 First version of the TR TKÜV
2.0 April 1997 Updated as announced in Dec. 95
2.1 March 1998 1. Requirements for voice mail systems and similar storage systems / inclusion
of an additional variant for transmission of event data
2. Time basis for time data in the data sets
3. Editorial corrections
2.2 December 2000 Corrections to edition 2.1
1. Update of Annex 1
2. Annex 3
Designation of unused digits by either hex ‘F’ or ‘odd/even’ indicator and hex
‘0’ according to TABLE 4-10/Q.931
3. Adjustment of Annex 6
3.1 Deletion of transmission method ‘Eurofile’ and ‘subaddress’ for event data
3.2 Forwarding to active fax devices at authorised agencies (support for
procedures according to ITU-T T.30) and use of the BC ‘audio’ and HLC
‘Facsimile’)
3.0 November 2001 Inclusion of the national requirements for implementation of ETSI standard
ES 201 671 V2.1.1 in Germany as Annex 7
3.1 May 2002 Editorial adjustments to the Technical Guideline to the TKÜV, change of
abbreviation to TR TKÜ
4.0 April 2003 1. Deletion of technical requirements in Section 5.2.3 for packet-switched, non-
IP-based networks
2. Flexible application of the FTAM and FTP transmission protocols, associated
requirements for file names in Annex 1
3. Inclusion of requirements for secure transmission of monitored
telecommunications over IP networks using IPSec, as Annex 4 to Annex 7
4. Requirements for packetisation of event data in case of implementation
pursuant to Annex 7
5. Inclusion of the national requirements for implementation of 3GPP
Specification TS 33.108 in Germany as Annex 8
6. Inclusion of the national requirements for monitoring of email as Annex 9
4.1 November 2004 1. Notice of notification on the title page
2. Deletion of the reference to coordination with international committees in
Annexes 7 and 8.
3. New Version 4 of the ASN.1 module with the national parameters (Annex 7,
Annex 3)
TR TKÜV, edition 8.0 (draft) Part X, continuation, page 153
4. Determination of the port number for TCP in Annex 7, Point F.3.1.3
5. In Table 1/A.5, the value for the maximum file length was increased to 25
6. In Annex 1, a reference to the possibility of transmission of the IRI according
to TS 102 232 was included
7. In Annex 5, stipulations were laid down for the major parameters when using
FTP.
8. In Annex 7, Annex 2, a reference to the possibility of transmission of the HI1
notifications was included
9. Inclusion of the national parameters as an integral component of the HI2
module in Annex 7, Annex 2
10. Specification of the treatment of log files in Annex 7, Annex 4
11. Annex 9, inclusion of the requirements pursuant to ETSI standard TS 102
233
12. Annex 10, inclusion of the requirements for IP-based forwarding pursuant to
ETSI standard TS 102 232
5.0 December 2006 1. Restructuring of the TR TKÜ
2. New provisions according to (previous) § 11, sentence 6 TKÜV (identifiers
for surveillance)
3. Detailed provisions for internet gateways on the basis of ETSI specifications
4. Adjustments with respect to Unified Messaging Systems and email
5. New provision for forwarding of SMS messages according to the national
variant (Annex B)
6. Other editorial corrections
5.1 February 2008 1. Requirements for VoIP and other multimedia services based on the SIP,
RTP or H.323 and H.248 protocols or the IP Cablecom architecture and for
emulated PSTN/ISDN services
2. Adjustments with respect to email through inclusion of all protocols in the
ETSI specification TS 102 232-2
3. Clarification for internet gateways, with regard to the services distributed
through them, such as IP TV and video on demand.
4. Adjustments with respect to the requirements in case of difficulties in
transmission of the surveillance copy to the receiving device of the
authorised agency
5. Inclusion of the CGI field as a mandatory supplemental field for coordinates
according to Annex B
5. Other editorial corrections
6.0 December 2009 1. Restructuring / renaming
2. Extension by an optional transmission point for provision of information on
traffic data according to ETSI specification TS 102 657
3. Optional electronic transmission of orders
4. Other editorial corrections
5. Copy of the new policy, Version 1.4 for the TKÜV-CA
6. Process description to ensure uniqueness of reference numbers for
surveillance actions
6.1 January 2012 1. Adjustments of the standard values, Section 3.2
2. Addenda on possible identifiers for surveillance of internet gateways, Section
4.1
3. Inclusion of a process description as per § 23(1) point 3 TKÜV
4. Clarification on FTP transmission procedures, Annex A.1.2.2
5. New version of the national ASN.1 module ‘Natparas’, Annex A.3.2
TR TKÜV, edition 8.0 (draft) Part X, continuation, page 154
6. Value of Calling Party Subaddress for international exchange surveillance,
Annex B.3
7. Relaxation of requirements concerning the use of the COLP check, Annexes
B.1, C.1, and D.1
8. Specification of ULICv1 for packet-switched in mobile telephony, Annex C.1
and Annex D.1
9. Adjustments for email, Annex F
10. Clarification of allocation of different SIP messages to IRI events and use of
IP source/destination addresses, Annexes H.3.2, H.3.3 and H.3.4
11. Addenda in the table of applicable ASN.1 modules, Annex X.4
12. Unified requirement for the use of timestamps
6.2 August 2012 1. Rewording and consolidation of the provisions of the previous Parts B and C
into the new Part B to reflect the refinement of the new interfaces already
introduced with edition 6.0
2. Adjustment to Annex X.4
6.3 6 April 2016 1. Editorial revision of the entire document
2. Annex A: Addition of Point 3.3 ("data losses")
3. Annex A: Supplementary clarification of WLAN (point 4.1)
4. Annex B: Note on the end of use of forwarding pursuant to Annex B
5. Annex C: Note on the end of use of forwarding pursuant to Annex C
6. Annex C: Restriction of validity to ISDN/PSTN (no mobile telephony now
included)
7. Annex D: Addition to location information
8. Annex D: Explanations of Packet Direction, IP addresses and ports (table)
9. Annex F.3.1.1: Explanations of Network Element Identifier, Payload Direction
(tables)
10. Annex G.1.1: Explanations of Network Element Identifier, Payload Direction
(tables)
11. Annex H: Explanation of Mid-Session Interception (H.1.2), obligation for
essentially complete forwarding of telecommunications (H.1.4)
12. Annex H.3.1: Annex G.1.1: Explanations of Network Element Identifier,
Payload Direction, Keep-Alives and IP addresses (tables)
13. Annex X.3: Adjustment to "Policy"
14. Part B: Adjustment in line with the current legal basis
15. Part B: Further development of the underlying ETSI specification
16. Part B: selective subscriber data queries
17. Part B: Standardisation of network operator responses for BDA and VDA
18. Part B: Flexible use of free text fields
19. Part B: Extension of the national modules regarding requirement for text
form and introduction of a version scheme
7.0 14.06.2017 1. Editorial revision of the entire document
2. Part A, Annex A: Supplementary clarification of WLAN (point 4.1)
3. Part A, Annex D.1 (Table C.1.1): Specification of port number
4. Part A, Annex F.3.1.1 (Table 5.2.4): Additional reference to ‘Communication
identifier’
5. Part A, Annex F.3.1.1 (Table 5.2.6): new specification for ‘Payload
timestamp’
6. Part A, Annex F.3.1.1 (Table 5.2.11): new specification for ‘Interception Point
identifier’
TR TKÜV, edition 8.0 (draft) Part X, continuation, page 155
7. Part A, Annex G.1.1 (Table 5.2.4): Additional reference to ‘Communication
identifier’
8. Part A, Annex G.1.1 (Table 5.2.6): new specification for ‘Payload timestamp’
9. Part A, Annex G.1.1 (Table 5.2.11): new specification for ‘Interception Point
identifier’
10. Part A, Annex H.1.2: Supplementary information on activating a surveillance
action with existing telecommunications link
11. Part A, Annex H.3.1 (Table 5.2.4): Additional reference to ‘Communication
identifier’
12. Part A, Annex H.3.1 (Table 5.2.6): new specification for ‘Payload timestamp’
13. Part A, Annex H.3.1 (Table): Reference to encoding information
14. Part A, Annex H.3.1 (Table 5.2.11): new specification for ‘Interception Point
identifier’
15. Part A, Annex H.3.2 (Table 5.4): Supplementary references to ‘Events and
IRI record types’
16. Part B: Adjustments to ‘1. Basic principles’
17. Part B: New specifications concerning transmission procedures
18. Part B: Specifications for guaranteeing data security and data quality
19. Part B, Annex A: Clarification of various usage procedures, traffic data in real
time, cancel message, radio cell requests, urgent surveillance orders.
20. Part B, Annex A: Inclusion of version scheme, late record, direct line search,
identification of data sets
21. Part B, Annex B: Specifications on new ‘Email-ESB’ transmission procedure
22. Part X, Annex X.3: Adjustment to "Policy"
7.1 11.06.2018 1. Editorial revision of the entire document
2. Deletion of Annex B (Part A) due to repeal of X.25/X.31
3. Notes on IP addresses and encodings, no acceptance of control options,
request for encryption (requirements from the new TKÜV; various Annexes
in Part A)
4. Note on telecommunications surveillance activation (various Annexes in Part
A)
5. Use of the relevant standards for telecommunications forwarding; exceptions
for IMEI surveillance Annex D (Part A); also note in Annex X.1.1
6. Adjustments to Part B, Annex 1: Use of newer versions / use of legal data
Basics (Chapter 1.2), Late Records (Chapter 1.3.1.1), Real-time disclosure
(Chapter 1.3.2), Time to availability (Chapter 1.3.3.2; 3.3), premature
deactivation of a warrant (chapter 1.3.1.4), rejected targets (chapter 1.3.1.4),
radio cell structure excluded. mobile radio connections (Chapter 3.2.2.5)
9. Note on future security requirements and requirements for 5G (Annexes
X.1.2 and X.1.3)
10. Note on test log and plan template (Annex X.5)
7.2 23.11.2020 1. Editorial revision of the notes on MTU size (Part A, Chapter 3.3.2), on
identifiers for the implementation of monitoring measures of the internet
access path (Part A, Chapter 4.1) and on the transmission of FTP files (Part
A, Annex F.1)
2. Part A, Annex I: Inclusion of specifications for messaging services
3. Part B: Adjusted specifications for warrant request (Chapters 1.3.x, 3.2.2.2)
4. Part B: Extension of information on the location of mobile terminals to
include all types of location and the prevention of danger to life, limb, health
or freedom of a person (Chapters 1.3.5, 3.2.2.5).
5. Part B: Extended labelling for traffic data request (1.3.5, 3.2.2.3)
TR TKÜV, edition 8.0 (draft) Part X, continuation, page 156
6. Part X, Annex X.3: Update ‘Policy’
7. Part X, Annex X.5: Editorial revision
8.0 tt.mm.yyyy Formal changes to the remuneration to the individual obligations under §§
170 et seq. Telecommunications Act, as a result of the entry into force of the
amended Telecommunications Act and the correspondingly adapted TKÜV
on 01.12.2021.
Maret Ots
Saatja: Karl Stern <
[email protected]>
Saatmisaeg: teisipäev, 23. november 2021 11:54
Adressaat: Mart Laas; Maret Ots
Teema: teatised
Manused: 2021649D.docx; 2021669PL.docx
Järeltegevuse lipp: Järeltegevus
Tähtpäev: kolmapäev, 24. november 2021 16:00
Olekulipp: Lipuga märgitud
Tere
Saadan kaks teatist:
1) Saksamaa 649 „Tehnilised suunised telekommunikatsiooni järelevalve ja teabe avalikustamise õiguslike
meetmete rakendamiseks [TR TKÜV], versioon 8.0“. Ooteaeg lõpeb 10.01;
2) Poola 669 „Digitaliseerimise ministri määrus raadiolitsentsita kasutatavate raadioringhäälingu või
raadiovastuvõtuseadmete kohta“. Ooteaeg lõpeb 17.01.
Karl
1