DEFINING THE CBTC OVER LTE INTERFACE: RIDING THE WAVE

Rodrigo Alvarez
MEng CEng MIET
Titan ICT Consultants

SUMMARY
This paper examines the requirements that a radio data transmission network needs to meet to serve as the
train-to-shore radio bearer for a Communications-Based Train Control (CBTC) system. Those requirements
are first considered through a data traffic modelled, and then mapped against the capabilities of a Long
Term Evolution (LTE) radio network, in order to identify the necessary configuration parameters and the
network architecture.
The examination of the resulting parameters and architecture characteristics lead the author to conclude that
public mobile telephony LTE networks may not be suitable to support CBTC systems, although private LTE
networks can be configured to fulfil that mission.

connecting to Wi-Fi Access Points (AP) and being

1 INTRODUCTION
able to operate in a tethering mode, acting as a
The last couple of years have seen a quiet Wi-Fi AP itself.
revolution starting to unfold in the
At the same time, the “Internet of Things” is
Communications-Based Train Control (CBTC)
exponentially increasing the number of devices
arena. A groundswell of change is clearly building
that are connecting via Wi-Fi networks to other
up, and the moment is ripe for the greatest
devices. The unlicensed radio frequency spectrum
technology swap in this space in over a decade.
bands where Wi-Fi operates are getting busier and
But what will be involved in that change?
busier with each passing day.
Since 2003, free-space propagation data radio
Recognising these challenges, the industry is
transmission has been the norm in most CBTC
taking the necessary steps to replace W-Fi-based
projects around the world, as the possibility of
radio systems in CBTC applications. In all cases
using continuous radio communications allowed
thus far, the selected technology seems to be
CBTC systems to overcome some of the issues
Long Term Evolution – as defined by the 3GPP
presented by track-bound induction loop and
family of standards [1]. A number of trials are
waveguide technologies.
underway, and commercial applications should not
At the time, the most cost-effective off-the-shelf be more than a few years away, at most.
radio technology that could provide sufficient
Given that radio communications lies at the core of
bandwidth for the CBTC application was,
CBTC system architecture, this change begs a
undoubtedly, the IEEE 802.11 standard family –
number of key questions. What changes, if any,
commercially known as “Wi-Fi”. In a very short
need to be made to existing CBTC applications in
period of time, all CBTC suppliers in the world
order to use LTE as a data radio bearer? And how
developed systems that made use of Wi-Fi-based
does an LTE network need to be configured and
radio solutions. Currently, dozens of Wi-Fi-based
optimised in order to support a CBTC application?
CBTC solutions are in full commercial operation in
Corollaries of great significance stem from these
four continents, and a large number of CBTC
highly technical questions, such as whether CBTC
deployment projects are currently in different
could be implemented over a public mobile
stages of development all over the world.
telephony LTE network, or how much spectrum
Things, however, have changed since 2003. CBTC bandwidth needs to be reserved for CBTC
is expanding outside its original environment of systems.
underground, inner-city, relatively short dedicated
This White Paper will delve into the technical
mass transit lines. Newer projects are deploying
interface between CBTC applications and LTE
CBTC over longer sections, on lines that go into
radio networks. It will explore the requirements
the suburbs, becoming overground as they do so,
imposed by CBTC applications on their current
and some times even encountering mixed traffic
radio bearers, and we will try to map those
situations. This leaves CBTC systems more
requirements against the data bearer services that
exposed to external radio interference than they
LTE networks can provide. We will explore the
had ever been in the past.
implications of optimising LTE networks to meet
On the radio front, things have been changing those requirements, and what other applications
even more. Wi-Fi technology has become so could still make good use of an LTE network at
successful that it is now at the core of data different priority levels.
consumption growth in the mobile telephony
market, with smartphones being capable of

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

2 DATA TRAFFIC MODEL AND RADIO communications subsystem, thus building a data
INTERFACE REQUIREMENTS traffic model for a typical CBTC application that will
allow us to identify the requirements that a CBTC
Firstly, we will address the way in which CBTC
application imposes over its radio subsystem.
uses radio resources, in order to identify the
requirements that the CBTC application imposes 2.1 CBTC System Architecture
over any radio bearer used for train-to-shore data This section will describe the architecture of a
transmission. In order to do this, we will have a generic CBTC system, maintaining a vendor
closer look at the architecture of a CBTC system, agnostic terminology based on the IEEE 1474.1
both on the wayside and on board. We will then standard [2]. Figure 1 below shows the different
examine a series of operational scenarios to map components of an IEEE 1474 CBTC system.
how the different components of a CBTC system
interact with each other using the radio

Figure 1 CBTC System Architecture

The pink-shaded squares correspond to the The ATO subsystem provides speed regulation,
Automatic Train Protection (ATP) and Automatic programmed stopping, door control and other train
Train Operation (ATO) functions. operator functions. These functions are
implemented by the ZC and the OBC, as in the
The ATP subsystem provides safety by
ATP subsystem.
maintaining train separation, enforcing maximum
speed restrictions and safely interlocking trackside The blue-shaded square corresponds to the
equipment. Train separation is maintained by the Automatic Train Supervision (ATS) system. ATS
Zone Controller (ZC), which knows the location of monitors trains, adjusts individual train
all the trains within a given section of track, and performance to maintain schedules and adjusts
which maintains communication with the service patterns to minimise the effect of traffic
computer-based Interlocking (IXL) regarding the perturbations. It also implements route setting,
status of different trackside Object Controllers both manual and automatic. All changes to train
(OC). behaviour instructed by the ATS subsystem are
actually implemented by the ZC-OBC pair, and
The ZC sends instructions regarding train
changes to trackside systems are implemented by
movement to each individual train. Those
the IXL-OC combination.
instructions are received and acted upon by the
Onboard Controller (OBC).

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

Finally, the green-shaded areas in the centre of 4. Handover between Radio Cells
the diagram stand for the Data Communications
5. Handover between Zone Controllers
Network (DCN). The DCN includes a Fixed
Transmission Network (FTN) that acts as the glue
2.3.1 Network Registration
between all the trackside elements – including the
trackside components of the radio network. It also During the start-up process of onboard CBTC
includes a radio element that implements train-to- equipment, while a train is potentially still in a
shore data transmission. stabling siding or in a depot workshop, the
Currently, the radio network mentioned above is Onboard Data Radio (ODR) will power up together
often implemented through a series of IEEE with the rest of the on board equipment.
802.11 (Wi-Fi) Access Points. In the near future, Upon powering up, the ODR will attempt to register
however, the architecture that is starting to replace onto the radio network. A network registration
802.11-based radio networks will be composed of message exchange sequence will take place
an Onboard Data Radio (ODR), an LTE Radio between the ODR and the wayside DCN
Access Network (RAN) – with a series of individual infrastructure.
radio base stations called eNodeBs – and an
Evolved Packet Core (EPC). In the case of an IEEE 802.11 network, this traffic
exchange will merely involve the nearest Wi-Fi
2.2 CBTC On Board Architecture Access Points (AP), therefore needing a
configuration update of all the CBTC ODRs
A lot of the details of the architecture of on board
operating in the network whenever a new AP unit
CBTC components will not only be dependent on
the specific CBTC solution being implemented, but is introduced.
will change from train set to train set – since the In the case of an LTE network, this registration
OBC will need to interface the trains braking process will take place on the Control Plane
system, for instance, and that interface will be between the ODR, the LTE radio base station
slightly difference from train to train. Particulars (eNodeB) in which the ODR is camping at the
about balise or beacon readers, tachometers, time, and the Mobility Management Entity (MME),
radar detectors to deal with slips and slides, etc… the Serving Gateway (SGW) and the Home
may all be different. Subscriber Server (HSS) that form part of the
Evolved Packet Core (EPC). See Figure 3 below
However, the radio communications interface
for a brief schematic of LTE network architecture.
presents certain trends that seem to be almost
universal in the sector.
MME HSS

PCRF

S1
eNodeB
Figure 2 CBTC On Board Architecture IP
Services
Thus, Figure 2 above presents what is the most
common solution for OBC-ODR architecture on UEs
S·GW
board CBTC fitted trains. A single train set (two, eNodeB P·GW
three or more railcars) is usually fitted with two E-UTRAN EPC
OBCs, one at each end of the train – effectively
one per cabin. Each one of the OBCs is connected Figure 3 LTE Network Architecture
to an independent ODR, which is in turn connected Once registration on an LTE network has been
to two rooftop antennas. We will assume an completed, the ODR will be ready to accept a
architecture such as the one presented in Figure 2 dedicated data bearer with the Quality of Service
to model our generic CBTC radio interface. (QoS) Class Indicator (QCI) profile that will
2.3 Operational Scenarios correspond to the CBTC application – as we will
discuss in greater detail further on.
Based on the architectures presented in the
sections above, the traffic model has been divided The assumption obtained from CBTC suppliers is
into five different operational scenarios: that the network attachment process should not
unduly delay the operational readiness of the train.
1. Network Registration With this in mind, a valid assumption for our data
2. Entry into CBTC Operation model would be that radio power up and network
attachment process – from ODR turn on until the
3. Open Line CBTC Operation ODR is ready to receive instructions from the ZC –
should not take longer than 45 seconds.

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

2.3.2 Entry into CBTC Operation suppliers indicates that a large majority of them
would require an average rate around 50 kb/s, with
Once the radio is operational, the OBC will first try
peaks at a maximum rate of 100 kb/s.
to establish contact with the local Zone Controller
(ZC) in order to start exchanging information and This data throughput would, in a Wi-Fi network, be
to prepare for entry into full CBTC territory. dynamically shared between the two ODRs at
either end of the train. In an LTE network, the
The trigger of this initial connection can be
same messages are more likely to be sent by one
automatically included in the loading process of
of the two ODRs, with the second one remaining in
the OBC – if the address of the ZC is known to the
hot standby for redundancy purposes. In either
OBC – or the establishment of that connection
case, the total OBC-ZC data throughput remains
may be triggered by a balise or beacon located on
the same.
the four-foot that instructs the OBC to contact a
specific ZC. At the same time, the ZC and the ATS sub-
systems will also send messages to each OBC in
Upon being instructed by the OBC to request a
the trains within the ZC’s control area – the ATS
dedicated CBTC bearer and to establish contact
instructions will be channelled through the ZC,
with the appropriate ZC, and based on feedback
which is the only device that interacts directly with
from different CBTC suppliers, our model will
the OBC through the radio interface.
assume that the ODR will be capable of
establishing a connection with the relevant ZC The ZC will send Movement Authority (MA)
within 5 seconds of the request being triggered. messages, which state how far a given train can
go down the track based on the location and
2.3.3 Open Line CBTC Operation speed updates from all the trains in the area and
on the status of trackside Object Controllers,
Once a data link between the OBC and the ZC has
obtained from the area’s Interlocking.
been set up, the OBC will be capable of
exchanging messages with the ZC. The nature of The OBC will use information contained in the MA
these messages – again, for a typical, IEEE 1474 to apply the train’s braking system and/or to act
compliant CBTC system, bearing in mind the upon the train’s traction system.
proprietary nature of the different solutions offered
Through the ZC, the ATS system will regulate
by the supplier industry – is assumed to be as
traffic between several trains – a process called
follows.
Automatic Train Regulation (ATR) - in order to help
Typically, the OBC will send messages to the ZC railway operations to recover from previous
at regular intervals. These messages – collectively disruptions in traffic or to optimise traction power
called Position Updates (PU) – will in most cases energy consumption, by cascading train
contain three types of information: acceleration a deceleration – particularly if
regenerative braking is in use.
 Train location updates, based on the location
information obtained from the latest balise or This variety of messages can be modelled for the
beacon, updated by onboard instrumentation first CBTC solution mentioned above as 4
(tachometer, inertial navigation systems) and messages of 2 kilobits every 200 ms,
adding a 5-10% of train length (depending on corresponding to a Downlink (ZC to both OBCs)
speed, breaking performance and track profile) data transfer rate of 40 kb/s.
as moving block margins. The second supplier taken as an example would
 Train speed, measured through rotary speed generate a Downlink traffic of 1 message of 3.2
wheel sensors and Doppler radar systems (for kilobits every 312.5 ms, generating a total uplink
slip-slide compensation). throughput 10.240 kb/s per train; that is, the same
as the Uplink traffic.
 Train health status monitoring information.
Based on a value comparison between CBTC
A specific proprietary OBC solution could suppliers, a ZC-OBC bit rate per train of 100 kb/s
generate, on average and for both cab radios, 1 would cover the requirements from most suppliers.
message of 5 kilobits every 150 ms, corresponding
to a total uplink (OBCs to ZC) data transfer rate of As for latency requirements, and based on
30 kb/s. information provided by CBTC suppliers, all
supplier responses would be accommodated by a
A different CBTC supplier may propose a solution maximum end-to-end packet delay of 30 ms both
where both OBCs generate, on average, 1 in the uplink (OBC-ZC) and in the downlink (ZC-
message of 3.2 kilobits every 312.5 ms, generating OBC). This value may need to be re-examined in
a total uplink throughput 10.240 kb/s per train. the future, since it falls below the minimum delay
A comparison between the OBC-ZC data values contemplated in LTE standards. It should at
throughput requirements from different CBTC this stage be considered a work in progress.

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

2.3.4 Handover between Radio Cells 2.3.5 Handover between Zone Controllers
Inter-cell handover is one aspect where the two Many CBTC implementations do not require
radio technologies – current Wi-Fi based solutions handovers between ZCs, often because they
and future LTE networks – behave in a radically consist of completely separate lines where a single
different way, to the point where changes may be ZC controls the line end-to-end.
experienced at the CBTC application level.
In the cases where trains can move from the area
Upon completion of the registration sequence in a controlled by one ZC into the area controlled by a
Wi-Fi network, the ODR will be registered onto the second ZC, the radio infrastructure will play a role
nearest Wi-Fi Access Point. But once the train in the process.
starts to move, the ODR will very soon leave the
ZC-ZC transition may be triggered by a balise or
range of the first Wi-Fi AP. Table 1 below shows
beacon located in the four-foot, or each OBC may
the typical maximum range values available to
be have been programmed to trigger the transition
different IEEE 802.11 standards in conventional
upon reaching a certain location. In either case,
configuration:
the transition will be handled at the application
Standard Frequency Maximum Range layer, without intervention from the radio network.
802.11a 5 GHz 120 m In order to be able to communicate with both ZCs
at the same time, however, an ODR may need to
802.11b 2.4 GHz 140 m request a second dedicated data flow to the
802.11g 2.4 GHz 140 m receiving ZC (this will depend on the details of how
the CBTC application handles ZC-ZC handover). If
802.11n 2.4 / 5 GHz 250 m / 140 m this were the case, it is assumed that the allocation
802.11ac 5 GHz 250 m (amplified) of the second bearer will also comply with the
requirements listed above for OBC-ZC links,
Table 1 – 802.11 Maximum Range Values meaning twice as much data will come from a
single train as in the open line scenario.
Once an ODR moves out of the range of the AP to
which it was connected, it will need to connect to a 3 DEDICATED BEARER CONFIGURATION
new AP to maintain the OBC-ZC connection.
Once we have identified a data traffic model and a
This process may be eased through the use of Wi- set of requirements, it is the moment to explore
Fi Mobility Controllers, but very often CBTC how the future technology of choice (LTE) will be
systems rely on having one ODR registered and able to meet those requirements.
transmitting with a given AP, while the ODR at the
other end registers with the next AP down the line An LTE network will effectively treat CBTC as a
– that is, mobility is partly handled by the CBTC user application sitting on top of the LTE protocol
application itself. stack. The LTE network will handle CBTC traffic by
establishing a tunnel from the ODR, through the
An LTE network, however, will behave in a very eNodeB located on the trackside, through the
different way. Inter-cell mobility is handled by the backhaul transmission network and the user plane
Mobility Management Entity (MME) and by of the EPC and onto the ZC connected to the EPC
negotiation between the eNodeBs involved (see as an IP Service. LTE will use the GPRS
Figure 3 above). It is not necessary to use two Tunnelling Protocol (GTP) to establish data
ODRs simultaneously to maintain OBC-ZC tunnels through the LTE network [3][4].
communication – a single ODR can transition
between cells practically seamlessly. In an LTE network, user plane traffic (such as
CBTC OBC-ZC data) is carried within virtual
This difference has an immediate implication on containers called “bearers”, with each bearer
the overall availability of the system. With the having a certain QoS profile.
same amount of on board equipment, the LTE
based solution will have a higher availability than When an ODR registers onto a network, it will use
the Wi-Fi based solution, since it would be more the GTP protocol to establish initial communication
tolerant to the failure of one ODR – it doesn’t need with the LTE core through a default bearer. This
both ODRs to be transmitting at all times. default bearer is used to transmit control plane
information back and forth between the EPC and
In either case, though, inter-cell handover the ODR, establishing the identity of the ODR and
requirements will be similar from the point of view its credentials to use the network, its current
of the CBTC application. A comparison between location and requirements, and so on and forth.
the requirements provided by different CBTC This control traffic, which is in Communications
suppliers can lead to expect an average value of parlance confusingly referred to as “signalling”, is
1% packet loss during handover and a handover
time below 200 ms for a 99% of handovers.

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
 Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

maintained throughout the period when the ODR is The values proposed for uplink and downlink GBR
connected to the LTE network. and MBR, as well as the PDB, come directly from
the results of the traffic modelling described in the
Once the ODR has been authenticated on the LTE
previous sections of this paper, so they do not
network – in a manner in all similar to that followed
require any additional explanation.
by any other User Equipment (UE) registered in
the network – the QoS profile configured on the The ARP priority level proposed above tries to take
EPC to support the CBTC application will provide into account the new priority levels incorporated
the parameters for the GTP layer to set up a into 3GPP Release 12 standards for mission-
second data bearer for the ODR. critical push-to-talk voice [5]. A value of 0.8 would
place the CBTC application below emergency
This second data bearer – called a “dedicated”
push-to-talk voice communications, but above non-
bearer – will be the actual carrier for the user plane
critical conversational voice and all other
traffic of the CBTC application; i.e., this second
applications. Given the typical requirements
dedicated bearer will be the one to really carry
expected from mission-critical push-to-talk voice
CBTC traffic, encapsulating CBTC packets as user
(in the order of 10s of kb/s per UE), it is highly
payload. So it is the configuration of the CBTC
unlikely that an LTE cell will reach the levels of
dedicated bearer that is critical to understand how
congestion necessary for CBTC dedicated bearers
an LTE network could support CBTC traffic on the
to start being pre-empted.
OBC-ZC interface.
PELR has been chosen to match similar low-
The key configuration parameters associated with
latency, low-bandwidth LTE services. Given that
an LTE dedicated bearer are the following –
CBTC applications present their own mechanisms
assuming that the CBTC bearer will be set up as a
to handle message corruption, this value should be
Guaranteed Bit Rate service:
sufficient without presenting an overly taxing
 Guaranteed Bit Rate (GBR) requirement on the radio network.
 Maximum Bit Rate (MBR) 4 AVAILABILITY AND NETWORK ARCHI-
 Allocation Retention Priority (ARP) TECTURE

 Packet Delay Budget (PDB) There is one additional requirement we have not
covered so far. The reason for that is that this
 Packet Error Loss Rate (PELR) requirement does not actually stem from the CBTC
In conventional LTE networks, QoS parameters application itself or from the CBTC component
are usually grouped under specific QoS Class suppliers, but rather from the expectations that a
Identifiers (QCI). LTE specifications propose railway operator may set for the end-to-end
“typical” QCI profiles for certain generic services, operation of the CBTC system. We are talking
such as conversational voice or video, real time about availability.
gaming or buffered video streaming, but they do An indicative availability figure for the radio
not contemplate an application such as CBTC. interface that supports OBC-ZC data transmission
It is not the intention of this paper to propose a could be an availability of 99.999%, equivalent to a
single bearer configuration that may satisfy all downtime of 5 minutes and 15.6 seconds per year
future CBTC deployments. It will be the during train operations – with planned
responsibility of each specific CBTC deployment maintenance activities and downtime not
project to define the most adequate QCI profile for necessarily being counted against the total.
its CBTC application, depending on proprietary This would be an extremely demanding availability
supplier requirements and on the other requirement for any radio network. And the key to
applications that may be using the same LTE meet such a requirement is the architecture of the
network as a radio bearer. But we can venture a LTE network itself.
proposal of CBTC dedicated bearer configuration
that would meet the requirements presented in A first approach to an architecture that could meet
previous sections. This parameter configuration is such a high availability figure would entail
presented in Table 2 below: minimising single points of failure. This could be
achieved by deploying:
Parameter Value Parameter Value
 Redundant cores in separate physical
GBR/UL 50 kb/s ARP 0.8 locations with dual homing eNodeBs, so
that traffic load is dynamically shared –
GBR/DL 100 kb/s PDB 30 ms
rather than having one of the cores in
-3
MBR/UL-DL 100 kb/s PELR 10 cold/warm/hot standby.

Table 2 – Proposed CBTC Bearer Parameters

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne
Rodrigo Alvarez Defining the CBTC Over LTE Interface: Riding the Wave
Titan ICT Consultants

 Overlapping coverage from adjacent radio requirements. Total bandwidth requirements will
cells. however vary between specific implementations,
depending on the maximum number of CBTC fitted
 Dual fed radio sites. trains to be found in a single cell, but also – and
 Duplicated power supplies. foremost – on the expectation to support additional
applications through the same LTE network. LTE’s
 Secondary backhaul paths. priority and pre-emption mechanisms make the
The specific network architecture for each site will option of sharing a single radio network amongst
depend on the topology of the CBTC system itself, several applications – such as mission critical
and may include some or all of the suggestions voice, CCTV live streaming or on board equipment
above. monitoring – a very real possibility.

5 CONCLUSION 6 REFERENCES

The previous sections have explored the [1] http://www.3gpp.org/.

requirements imposed by CBTC applications over [2] 1474.1-2004 – IEEE Standard for
the train-to-shore radio interface. Communications-Based Train Control (CBTC)
When trying to map those requirements against Performance and Functional Requirements
the capabilities of LTE networks, we have seen [3] 3GPP TS 29.281 v11.6.0 Tunnelling Protocol
that the network will need to be configured on a User Plane (GTPv1-U)
specific way in order to meet those requirements.
Even more; the availability requirements of such a [4] 3GPP TS 29.274 v12.9.0 Tunnelling Protocol
mission-critical application will impose rather Control Plane (GTPv2-C)
onerous network architectures. [5] 3GPP TS 23.203 v12.9.0 (2015-07) Policy and
The most immediate corollary to these findings is charging control architecture (Release 12)
that it may be very difficult to deliver CBTC over a
conventional, carrier-grade LTE network. Public 7 AUTHOR
land mobile operators have optimised their LTE Mr. Rodrigo Álvarez
networks to serve the requirements of what
constitutes their core business and their main Rodrigo has been involved in
source of revenue – consumer market data railway communications in
applications. the UK, Europe and Australia
for over twelve years. His
It would not be easy to reconfigure a carrier LTE experience is especially
core so that it can serve a CBTC application – centred in the integration of
changes may need to be made to such critical advanced railway signalling
elements as the radio resource scheduling systems and telecommunications technologies.
algorithms in order to meet CBTC’s very Past projects include Network Rail’s Cambrian
demanding latency and availability requirements. It ERTMS Deployment and Crossrail Programme in
would be even more complex to modify a carrier’s London, as well as GSM-R deployment in ADIF’s
network architecture along the lines indicated High Speed Network (Spain). He has also worked
above. And, most importantly, there would be very on railway research and development projects for
little economic incentives for public mobile the European Commission. Since February 2013,
telephony changes to enact these drastic changes Rodrigo has been working for the Public Transport
in their networks in order to meet the requirements Authority of Western Australia in the planning
of an application from a client base that does not phases of the Radio Systems Replacement and
constitute a significant revenue stream. Automatic Train Control Projects.
It is therefore clear that, at least for the Rodrigo’s technical background includes the
foreseeable future, CBTC applications will be design of GSM-R networks, as well as SDH and
limited to railway dedicated LTE networks that can Carrier Ethernet networks. On the signalling side,
be optimised to guarantee the operation of such a Rodrigo has a wealth of experience in ERTMS
mission-critical application. This seems, in any systems, and he is well acquainted with the
case, to be the trend that the railway sector is transmission requirements of axle counters,
following. modern Computer Based Interlocking, SISS and
As for the amount of spectrum bandwidth DOO systems. In the last three years, Rodrigo has
necessary for CBTC, the application does not had a very significant exposure to LTE, Wi-Fi and
present very onerous data throughput CBTC technologies.

AusRAIL 2015
© Copyright Titan ICT Consultants 24 – 26 November 2015, Melbourne