ETSI TR 103 442 V1.1.1 (2016-05)
Railways Telecommunications (RT); Shared use of spectrum between Communication Based Train Control (CBTC) and ITS applications
Railways Telecommunications (RT); Shared use of spectrum between Communication Based Train Control (CBTC) and ITS applications
DTR/RT-SURITS-01
General Information
Standards Content (Sample)
TECHNICAL REPORT
Railways Telecommunications (RT);
Shared use of spectrum between
Communication Based Train Control (CBTC)
and ITS applications
2 ETSI TR 103 442 V1.1.1 (2016-05)
Reference
DTR/RT-SURITS-01
Keywords
ITS, railways
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 442 V1.1.1 (2016-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive Summary . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 CBTC description . 9
5 Market information. 9
6 CBTC Technical information . 9
6.1 CBTC Communication needs . 9
6.2 Simultaneous CBTC communications in a given geographical area . 11
6.3 Propagation parameters of CBTC radio communication . 12
6.3.1 General CBTC radio properties . 12
6.3.2 Propagation in tunnel . 12
6.3.3 Propagation Outdoors . 12
6.3.3.1 On line . 12
6.3.3.2 In depot or stabling area . 12
6.4 Mandatory characteristics to ensure CBTC safety . 12
6.5 Mandatory characteristics derived from the CBTC availability needs . 13
6.6 Summary of CBTC communication requirements . 14
6.7 CBTC typical line description . 14
6.7.1 In tunnel . 14
6.7.2 Outside . 14
7 ITS Technical information . 15
7.1 ITS description . 15
7.2 Intelligent Transport System communication architecture . 16
7.3 Networking and transport . 16
7.4 Access . 16
7.5 Security . 16
7.6 Decentralized Congestion Control . 17
7.7 CEN DSRC co-existence mitigation . 17
8 Sharing Issue . 18
8.1 Sharing scenarios . 18
8.2 Technical Sharing Solution . 18
8.2.1 Different sharing proposals . 18
8.2.2 Mitigation methods . 19
8.2.2.1 Changing the transmit parameters . 19
8.2.2.2 Harmonized access layer protocol . 19
8.2.3 Methods to detect a mitigation area . 20
8.2.3.1 Geographic database . 20
8.2.3.2 Detection of the CBTC signal . 20
8.2.3.3 CBTC warning beacon . 20
8.3 Security concern . 20
8.4 Sharing conditions . 21
8.4.1 ITS Conditions . 21
ETSI
4 ETSI TR 103 442 V1.1.1 (2016-05)
8.4.2 CBTC Conditions . 21
9 Conclusion . 21
Annexe A: Case Study of Brussels Metro . 23
A.1 General . 23
A.2 Conclusion . 25
History . 26
ETSI
5 ETSI TR 103 442 V1.1.1 (2016-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Railway Telecommunications (RT).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive Summary
The present document summarizes the CBTC and C-ITS recommendations for potential spectrum sharing of CBTC
and C-ITS applications.
The present document identifies technical solutions for sharing as follows:
• Mitigation methods.
• Methods to detect a mitigation area.
Introduction
The present document has been developed in cooperation with TC ITS in order to present to the Electronic
Communications Committee (ECC) of the European Conference of Post and Telecommunications Administrations
(CEPT) a common point of view regarding sharing possibilities between CBTC and ITS applications in the 5 875 MHz
to 5 925 MHz frequency band.
After having clearly defined CBTC applications, the present document defines first the functional needs of CBTC
regarding its communication. From that, technical needs for the communication system are derived, and the scenarios
where sharing the spectrum between CBTC application and ITS road applications could be an issue are described.
Finally the different technical means of sharing bandwidth are introduced and the next steps including a proposal for
short term regulation are defined.
ETSI
6 ETSI TR 103 442 V1.1.1 (2016-05)
1 Scope
The present document investigates the possibility of shared use of spectrum between CBTC and ITS applications in the
5 875 MHz to 5 925 MHz under the assumption that CBTC applications have priority over ITS-G5 applications.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ECC/DEC/(08)01: "ECC Decision (08)01 of 14 March 2008 on the harmonised use of the
5875-5925 MHz frequency band for ITS, and subsequent amendments".
[i.2] ETSI TR 103 111 (V1.1.1): "Electromagnetic compatibility and Radio spectrum Matters (ERM);
System Reference document (SRdoc); Spectrum requirements for Urban Rail Systems in the
5,9 GHz range".
[i.3] CENELEC EN 50159: "Railway applications - Communication, signalling and processing systems
- Safety-related communication in transmission systems".
[i.4] ETSI EN 302 665 (V1.1.1): "Intelligent Transport Systems (ITS); Communications Architecture".
[i.5] ETSI TR 101 607 (V1.1.1): "Intelligent Transport Systems (ITS); Cooperative ITS (C-ITS);
Release 1".
[i.6] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Definitions".
[i.7] ETSI TS 101 556-1 (V1.1.1): "Intelligent Transport Systems (ITS); Infrastructure to Vehicle
Communication; Electric Vehicle Charging Spot Notification Specification".
[i.8] ETSI EN 302 637-2 (V1.3.0): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service".
[i.9] ETSI EN 302 637-3 (V1.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification
Basic Service".
ETSI
7 ETSI TR 103 442 V1.1.1 (2016-05)
[i.10] ETSI TS 103 301 (V1.1.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications; Facilities layer protocols and communication requirements for
infrastructure services".
[i.11] ETSI TS 102 687 (V1.1.1): "Intelligent Transport Systems (ITS); Decentralized Congestion
Control Mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer
part".
[i.12] ETSI TR 101 612 (V1.1.1): "Intelligent Transport Systems (ITS); Cross Layer DCC Management
Entity for operation in the ITS G5A and ITS G5B medium; Report on Cross layer DCC algorithms
and performance evaluation".
[i.13] ETSI TS 103 175 (V1.1.1): "Intelligent Transport Systems (ITS); Cross Layer DCC Management
Entity for operation in the ITS G5A and ITS G5B medium".
[i.14] ETSI TS 102 792 (V1.1.1): "Intelligent Transport Systems (ITS); Mitigation techniques to avoid
interference between European CEN Dedicated Short Range Communication (CEN DSRC)
equipment and Intelligent Transport Systems (ITS) operating in the 5 GHz frequency range".
[i.15] ETSI EN 302 571: "Intelligent Transport Systems (ITS); Radiocommunications equipment
operating in the 5 855 MHz to 5 925 MHz frequency band; Harmonised Standard covering the
essential requirements of article 3.2 of Directive 2014/53/EU".
[i.16] ETSI EN 302 663: "Intelligent Transport Systems (ITS); Access layer specification for Intelligent
Transport Systems operating in the 5 GHz frequency band".
TM
[i.17] IEEE 802.11 : "IEEE Standard for Information technology--Telecommunications and
information exchange between systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[i.18] Standardisation mandate addressed to cen, cenelec and etsi in the field of information and
communication technologies to support the interoperability of co-operative systems for intelligent
transport in the european community (M/453 EN).
NOTE: Available at http://www.etsi.org/about/our-role-in-europe/public-policy/ec-mandates.
[i.19] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats".
[i.20] CEPT/ERC Recommendation 70-03: "Relating to the Use of Short Range Devices (SRD)",
Tromso 1997, Subsequent amendments 07 February 2014".
[i.21] Commission Decision 2008/671/EC of 5 August 2008 on the harmonised use of radio spectrum in
the 5875-5905 MHz frequency band for safety-related applications of Intelligent Transport
Systems (ITS).
[i.22] ECC/REC/(08)01: "Use of the band 5855-5875 MHz for Intelligent Transport Systems (ITS)".
[i.23] Commission Implementing Decision 2013/752/EU of 11 December 2013 amending Decision
2006/771 on harmonisation of the radio spectrum for use by short-range devices and repealing
Decision 2005/928/EC.
TM
[i.24] IEEE 1474.1 -2004: "IEEE Standard for Communications-Based Train Control (CBTC)
Performance and Functional Requirements".
ETSI
8 ETSI TR 103 442 V1.1.1 (2016-05)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
data communication system: global communication architecture into which radio communication links are integrated
safety: freedom from unacceptable levels of risks resulting from unintentional acts or circumstances
security: freedom from unacceptable levels of risks resulting from intentional acts or circumstances
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Access Point
ASIL Automotive Safety Integrated Level
ASIL-A Automotive Safety Integrity Level
ATC Automatic Train Control
ATO Automatic Train Operation
ATP Automatic Train Protection
ATS Automatic Train Supervision
C2C-CC Car to Car Communication consortium
CAM Cooperative Aware Message
CBTC Communication Based Train Control
CEPT European Conference of Postal and Telecommunications Administrations
C-ITS Cooperative Intelligent Transportation System
DCC Decentralised Congestion Control
DCS Data Communication System
DEC DECision
DENM DEN Message
DFS Dynamic Frequency Selection
DSRC Dedicated Short Range Communication
EC European Community
ECC Electronic Communications Committee
EDCA Enhanced Distributed Channel Access
EIRP Equivalent Isotropically Radiated Power
EM Electro Magnetic
GN Geo Networking
HW HardWare
IEEE Institution of Electrical and Electronic Engineers
IP Internet Protocol
ITS Intelligent Transportation System
ITS-G 5,9 GHz Cooperative ITS system
ITS-S Intelligent Transportation System Station
LOS Line Of Sight
MAC Medium ACcess
MIMO Multiple Input Multiple Output
NLOS Non Line Of Sight
OEM Original Equipment Manufacturer
OFDM Orthogonal Frequency Division Multiplexing
OSI Open Systems Interconnection
QPSK Quadrature Phase Shift Keying
REC RECommendation
SIL Safety Integrated Level
SNR Signal to Noise Ratio
SW SoftWare
TAC Transmit Access Control
TX Transmitter
V2I Vehicle to Infrastructure
ETSI
9 ETSI TR 103 442 V1.1.1 (2016-05)
V2V Vehicle to Vehicle
VRU Vulnerable Road User
4 CBTC description
The primary public objective of this system is to provide urban rail and regional railway operators with a means to
control and manage the train traffic on their own networks. Metro lines which are operated at a high level of
performance and short intervals between successive trains are now installing Communications-Based Train Control
(CBTC) systems.
CBTC is a wireless Automatic Train Control (ATC) system, more flexible and cost efficient than traditional ATC.
CBTC systems are deployed on urban and suburban train on dedicated tracks. Tramways and buses are not covered by
this system.
The standard IEEE 1474.1 [i.24] gives the following definition:
A CBTC system is a continuous, automatic train control system utilizing:
• high-resolution train location determination, independent of track circuits;
• continuous, high-capacity, bidirectional train-to-wayside data communications;
• train borne and wayside processors capable of implementing automatic train protection (ATP) functions, as
well as optional automatic train operation (ATO) and automatic train supervision (ATS) functions.
CBTC application requirements are defined in the standard IEEE 1474.1 [i.24].
CBTC systems allow running trains only 90 seconds apart with total safety for the passengers and the staff (or even less,
the headway depending upon time spent by the train at every station for passengers to leave and board trains, the
distance between stations and profile of the line as well as the possible acceleration, maximum speed and deceleration
of the train).
5 Market information
The automation of existing urban rail lines and the development of fully unattended metro operation (no staff on board)
are booming and represent tomorrow's challenges in this sector. Millions of passengers use urban public transport every
day (in Europe 31,6 million daily passengers in 48 cities only for metro), and the European Union's modal shift
objective means more people using public transport. CBTC markets have been presented in ETSI TR 103 111 [i.2].
6 CBTC Technical information
6.1 CBTC Communication needs
Although IEEE 1474.1 [i.24] defines the CBTC system and its requirements, the system itself as a whole is not fully
standardized which means that some parts, and in particular its communication system, are implementation dependent.
The MODURBAN project issued a functional requirement specification for CBTC systems, and a MODURBAN
architecture document (partially public), which allocates functions to a system or subsystem level but leaving some
open options and without fully specifying in details the interfaces.
As a consequence, the needs for communication and the definition of messages to be exchanged are not standardized,
even if some metro authorities promoted interoperability specifications which enable the construction of a complete
CBTC system by assembling subsystems from different manufacturers: one company can provide the wayside ATC
subsystem, while another one can provide the on-board ATC subsystem, a third one can provide the data
communication system, a fourth one can provide the ATS.
ETSI
10 ETSI TR 103 442 V1.1.1 (2016-05)
Achieving such compatibility of the subsystems require that an interoperability specification fully defines the interfaces,
which include, of course, an extensive definition of all the data exchanges through the radio channel: definition of the
protocols, list of the messages, size and detailed consist of each message in terms of functional data, performances
including rates of emission and reception for each communicating piece of equipment and each type of message.
Nevertheless these interoperability specifications, when they exist, are project dependant.
Finally, the level of performances (for example the headway between trains or the guaranteed reaction time of the
system to an unexpected safety hazard) highly influences the requirements allocated to the communication system: it
drives the amount of data to be transmitted, the frequency at which they need to be transmitted and the quality of the
transmission such as the frame error rate and the latency of the transmission.
Therefore it should be pointed out that all the data given below are based on principles and existing implementations
and are used as an example to justify the common needs for communication of CBTC, but cannot be seen as
characteristics fulfilled by all CBTC systems on the market.
CBTC communications can be classified in different groups based on their conditions for transmission, and also based
on their criticality regarding the system performance.
Some messages need to be transmitted and received regularly in order to ensure that on-board and wayside CBTC
subsystems are continuously up-to-date (typically while a train is moving and updating its location) and to ensure they
can 'monitor' each other for a safe evaluation of critical functions performed by the other interoperable subsystems.
Such messages are typically transmitted periodically and are therefore known as "periodic data". Different periods may
coexist at the same time on a same interface.
EXAMPLE: From the above-mentioned interoperable CBTC applications, some messages are transmitted at a
period of 200 ms while others are transmitted every 360 ms and some others at a period of a few
seconds.
The transmission requirement for periodical data generally gives the base for the calculation of the "mean" required
throughput for CBTC. The following periodic CBTC messages are transmitted from train to wayside:
• A 'Location Report' message sent by the on-board CBTC of each train to the wayside CBTC ('Zone
Controller'). These messages help the Zone Controller to continuously track the trains' position on a portion of
the metro line designated as its 'territory'. It should be noted that a train generally communicates with one Zone
Controller but it may also have to communicate with two Zones Controllers in order to handle smooth
transition from one territory to the next one at their common border. It may even have to anticipate
communications with 3 Zone Controllers in some specific configurations (for example when the track is
subdivided into two diverging branches).
The 'Location Report" message includes data such as the location of both ends of the train, its speed, the train
consist, etc.
If that message is received with a delay greater than 100 ms, then it is no longer useful and will be considered
as lost by the receiver: only fresh messages can ensure the safety of the application. No messages of that type
received during N seconds from a train will stop the transmission of the Movement Authority messages
authorizing that train to run (N depends on the specified headway, and can be down to 1 second for highly
efficient CBTC).
• A functional status message sent by each train to the automatic train supervision system, which is less vital
but contains more data: it includes information about the train position but also any modifications of the
rolling stock which can influence the operation, and the health status of any on-board redundant equipment, to
detect latent failures (hardware failures which have no functional impact but reduce the level of redundancy)
and fix it before a second failure occurs and many other items of functional information, and, when there is a
driver on a train, some reports on his actions.
• Messages necessary to control and ensure safe monitoring of the platform doors (where existing), also sent
cyclically when the train is at a station. Very short delays of transmission are required to ensure fast passenger
exchange at the station.
ETSI
11 ETSI TR 103 442 V1.1.1 (2016-05)
The following CBTC periodic messages are transmitted from wayside to train:
• Messages informing the trains about the status of the variable elements in the area where the train is and in the
area it will reach soon (such as a work zone, a low adhesion zone, a malfunctioning signal, etc.). Such
information is common to several concerned trains which are in the same area.
• Messages informing the train about its Movement Authority: this message identifies the zone ahead of the train
in which it can safely operate without colliding with a fixed or moving 'obstacle'. Such information is specific
to each communicating train. No messages of that type received during N seconds by a train will trigger an
Emergency break for that train, and can also have consequences on following trains.
• Messages necessary to control and ensure safe monitoring of the platform doors (where any). These messages
are also sent periodically when the train is approaching and docked at a station.
In addition, it is also sometimes necessary to send quite a high volume of data to a train to update the track database it is
using. To be transparent for train operation, these data are transmitted from the wayside as the train moves forward.
The CBTC payload contains the functional information described above, but also an important amount of data to ensure
the security and the safety of the transmitted messages such as safety codes or safety timestamps.
The resulting CBTC payload throughput is therefore between a minimum of 30 kb/s for the periodic data of a train
under the responsibility of a single wayside zone controller and without platform doors, and up to 50 kb/s for a train
under the responsibility of three zone controllers and with platform doors. With the additional non periodic data, the
throughput can be increased by 100 kb/s.
In summary the CBTC train-to-wayside throughput requirements (without redundancy) are between 30 kb/s and
150 kb/s, with typical packet length between 200 bytes and 500 bytes.
In order to allow short headways performances, a low latency of the transmission (less than 100ms) and a very low
frame error rate is required. Typically a value of maximum 1 % of frame error rate is taken into account to calculate the
performances of the complete CBTC system.
6.2 Simultaneous CBTC communications in a given
geographical area
Very often there can be two trains stopped in a station (one on each track) and two trains in each interstation (one on
each track) with a typical interstation of 600 meters length. So a density of 6 trains per linear area of 1,2 kilometres
length is a minimum to be taken into account.
In the case of a track configuration with two diverging branches, 2 additional trains should be added, so a density of 8
trains is taken into account.
In degraded mode, if congestion occurs, it could happen that 2 trains are in an interstation instead of only one.
Therefore the density of trains per linear area of 1,2 kilometres can reach 12 trains.
Depot and stabling area
In this case, the trains can be parked with only a few meters between them on the same track, and many tracks can be in
parallel.
The real density is depending on the train length, but a good order of magnitude is typically 36 trains in an area of
500 m × 20 m.
In case of fully automatic operation, all the trains in the depot continue to transmit the periodic data defined above to a
single zone controller, without dataflow for the platform doors. They therefore need to exchange 30 kb/s of periodic
data per train.
In addition it should be possible to download log files, or to upload new database to several trains.
As a result the throughput per train is doubled compared to the one of train running on mainline.
ETSI
12 ETSI TR 103 442 V1.1.1 (2016-05)
6.3 Propagation parameters of CBTC radio communication
6.3.1 General CBTC radio properties
For the 5,9 GHz band, directional antennas are easy to manufacture and are well suited to ensure radio coverage of
linear tracks.
At the time the current document was prepared, CBTC did not use a standardized access layer technology. A set of
different modulation schemes, MAC and radio bandwidths are used by current implementations.
6.3.2 Propagation in tunnel
Thanks to the attenuation brought about by the tunnel itself, the level of electromagnetic noise seen in the tunnel is
much lower than outside. Conversely, the signals transmitted inside of the tunnel are not seen outside. Only the signal
transmitted by the wayside radio installed at the entrance of the tunnel can be received outside and can be considered as
an outdoor wayside radio.
6.3.3 Propagation Outdoors
6.3.3.1 On line
Directional antennas are employed both on wayside and in the trains. They concentrate the radiofrequency signal along
the tracks and therefore increase the coverage distance and the protection against external interferences outside of the
axis of the tracks.
Wayside antenna are installed along the tracks and have a gain between 16 dBi and 24 dBi. The distance between
successive Access Points has a mean value of 500 m. Therefore the width of the area receiving significant level from
the wayside CBTC transmitter is restricted to a maximum width between 90 m and 180 m along the tracks.
With a typical antenna that has a gain of 18 dB and an aperture of 18°, the level that will be received at a distance
higher than 180 m from the track is < -90 dBm/MHz for an EIRP of 20 dBm/MHz in the frequency band 5 875 MHz to
5 925 MHz.
Train antennas are also directive, with typical gains between 9 dBi and 12 dBi. They are installed either in the train
behind the windscreen, or on the roof of the train. The area receiving significant level from the wayside CBTC
transmitter is restricted to a maximum width between 150 m and 250 m along the tracks.
6.3.3.2 In depot or stabling area
To cover depots, antennas with wider aperture are chosen in general, and the coverage is established on a well-defined
area.
6.4 Mandatory characteristics to ensure CBTC safety
For CBTC, mass transit operators have critical requirements which are classified at the highest Safety European Level
(SIL4). This level is equivalent to the highest one in aeronautics and nuclear plants, and exceeds the current
classification of the automotive industry (ASIL-A to D). This level implies enforcing formal methods for specifications,
development, and validation of HW and SW parts, then of the whole systems. CBTC systems have been deployed for
more than 15 years in several European countries under national exclusive agreements in the upper 5 GHz band.
From a safety point of view, CBTC considers its DCS part as an untrusted means of communication and uses dedicated
application protocols to ensure vital exchanges of the application data.
According to CENELEC EN 50159 [i.3] the requirement transferred to the CBTC communication system is to ensure a
sufficient level of access control (cyber security): authentication of all participants in the communication system,
integrity and confidentiality of the transmitted data have to be ensured.
ETSI
13 ETSI TR 103 442 V1.1.1 (2016-05)
In addition, the content of the messages and the protocol of data transmission itself have to ensure the safety: the way
to timestamp the transmitted information and the evaluation of the possible default of synchronization between CBTC
components is a big part of that. The reception of too many stale (or time-expired) messages is considered by the safety
applications as an abnormal and potentially dangerous situation, and can lead to a fail-safe reaction (stopping the train).
The evaluation of the position of the train also takes into account a lot of criteria, in order to avoid any unsafe decision.
Data rate, sampling rate, buffering processes, latency and packet integrity are also parameters that are taken into
account in the safety demonstration and cannot be changed.
Furthermore the communication system should not create any additional risk of intrusion into the CBTC system which
could create a possibility of a secondary level of attack such as software or configuration modification after illicitly
obtaining a password.
Finally, from a more general point of view, proper functioning of CBTC and therefore efficiency of the transport system
and the safety of passengers are based on highly reliable communication links between wayside and on-board CBTC.
External interference on the frequency band used by CBTC can cause repeated disturbances making the transport
system inoperable. This was demonstrated on the occasion of the introduction of new mobile communication services
on a Chinese public metro network when traffic was completely stopped.
6.5 Mandatory characteristics derived from the CBTC
availability needs
In any place on a metro line, CBTC train and wayside applications exchange information. In case of loss of connection,
the train will stop automatically. This situation can have a strong impact on safety of passengers, as any situation
leading to passenger evacuation could possibly generate panic movement.
To maximize the availability of connections between train and wayside applications, path diversity is required. Each
train has a minimum of two radio paths with the wayside radio infrastructure. Each radio path operates on two channels
with a different carrier frequency.
In most cities which have a metro network, some lines cross each other, or can have some tracks in parallel in some
areas (common stations, for example).
Lines are working with completely independent systems, which can come from different manufacturers. Therefore, to
keep the independence and performances in that situation, 2 pairs of channels are required.
Service availability requires redundancies and their management from the applicative level. Redundancies are relevant
for control equipment, networking units and transmitting devices as well. It is comprehensive to add redundancies at
network level, using switches, multiple links or meshed sub-networks. At transmitting level, redundancy is not enough.
A high grade of diversity is required, in order to cope with the weakness of EM propagation in various physical
environments: LOS, NLOS, with multi-path, multi-mode and spatial filtering.
It is common to combine 3 to 4 types of diversity. One type is generally kept for redundancy, e.g. a whole
communication channel. The other types are devoted to improving availability: frequency diversity, polarization
diversity, MIMO, spatial diversity (head & end of train) and macro diversity using simultaneous connections to several
successive AP's. The last one is very efficient in tunnels, when trains are masking each other at a moderate distance
from the current AP. All types of diversities being combined, a train can maintain more than 4 simultaneous links with
wayside, and the wireless coverage should be continuous.
ETSI
14 ETSI TR 103 442 V1.1.1 (2016-05)
6.6 Summary of CBTC communication requirements
Table 1 summarizes the communication needs of a typical CBTC system.
Table 1: CBTC communication requirements
Criteria Value
Payload throughput Between 30 kb/s and 150 kb/s per train on a channel ( but this data
should be sent redundantly in parallel on 2 different channels by the
two train ends)
Typical train density 12 trains for 1,2 km length of double track
36 trains in depot
Minimum number of channel needs 4
Maximum frame error rate or frame loss 1 %
when the communication is available (a
message received after too much delay is
considered lost)
Availability of the communication 99,999 % (as a consequence of a high level of redundancy)
Maximum delay (end to end transmission 100 ms
between CBTC application devices)
Data security to ensure train safety Compliant with CENELEC EN 50159 [i.3]. See also clause 6.4
6.7 CBTC typical line description
6.7.1 In tunnel
• Brussels: 68,7 km of tunnel tracks: 88,7 % of total track length (77,44 km).
• Paris: 187,9 km of tunnel tracks : 91,4 % of total track length (205,8 km).
• Madrid: 276 km of tunnels tracks : 94,2 % of total track length (293 km).
• Vienna: 30,2 km of tunnels tracks : 38 % of total track length (78,5 km).
6.7.2 Outside
Tables 2, 3, 4 and 5 show the line description for the Brussels, Paris, Madrid and Vienna networks.
Table 2: Line description for the Brussels network
Total Track length 77,44 km % 400 km big
road length
Outside: Track and road at the same level 4,019 km 5,2 % 1,009 %
Outside:Track and road at a different level 4,692 km 6,1 % 1,173 %
(open trench)
Tunnel length 68,73 km 88,7 %
Table 3: Line description for the Paris network
Total Track length 205,8 km % of total track length
Outside: Track and road at the same level 9,6 km 4,6 %
Outside:Track and road at a different level 8,3 km 4 %
(viaduct)
Tunnel length 187,9 km 91,4 %
Table 4: Line description for the Madrid network
% of total track length
Total Track length 293 km
Outside: Track and road at the same level 17 km 5,8 %
Tunnel length 276 km 94,2 %
ETSI
15 ETSI TR 103 442 V1.1.1 (2016-05)
Table 5: Line description for the Vienna network
% of total track length
Total Track length 78,5 km
Outside : Track and road at the same level 48,3 km 62 %
Tunnel length 30,2 km 38 %
7 ITS Technical information
7.1 ITS description
In response to the EU standardization request M/453 [i.18], ETSI has issued a first release of the standards to enable the
deployment of a set of Cooperative ITS applications. In particular, a set of ITS G5 access layer specifications in the
5 GHz frequency band have been published.
NOTE: The documents that form Release 1 of Cooperative ITS (C-ITS) are listed in ETSI TR 101 607 [i.5].
The applications specified in release one focused on Vehicle to Vehicle and Vehicle to Infrastructure applications, as
defined in ETSI TR 102 638 [i.6]. Among multiple applications, road safety applications are m
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...