MANAGING ‘TRAIN-TO-EARTH’ HEAVY COMMUNICATIONS
A Middleware Software to Manage Broadband Wireless Communications in the
Railway Scope
Roberto Carballedo, Asier Perallos
Department of Software Engineering, University of Deusto, Av. Universidades, 24, Bilbao, Spain
Itziar Salaberría, Unai Gutierrez
Intelligent Transport Department, Deusto Technology Fundation, Bilbao, Spain
Keywords: Wireless Broadband Management, Wireless Communications Middleware, Railway Industry.
Abstract: This paper illustrates the strategy followed for the management of broadband wireless communications in a
hybrid network (mobile/radio). This management allows the optimization of both bandwidth and
transmission rate of the applications deployed in the ground control stations (terrestrial applications) and on-
board systems (train applications). It also describes the general aspects of a ‘train-to-earth’ communications
architecture, which allows an easy and standard integration of applications both new and legacy.
1 INTRODUCTION
For many years the aim in the railway industry has
been to ensure the safety of people and trains and to
meet schedules (Smith, J., Russell, S., and Looi, M.,
2003). Nowadays, safety is a priority too, but new
requirements have arisen (Aguado, M. et al., 2005).
Moreover, the current European railway regulation
makes it necessary for infrastructure fixed elements
to share information with mobile elements or trains
(handled by railway operators). This new policy
results in additional requirements on the exchange of
information between different companies. How to
fulfil these requirements is a new technological
challenge in terms of railway communications
(Shafiullah, G., Gyasi-Agyei, A. and Wolfs, P.J.,
2007) that we describe in this paper.
This paper is organized into the following
sections: the second section includes a brief
description of the ‘train-to-earth’ communications
architecture defined. The third section is the core of
this paper and describes the management of wireless
broadband communications. The fourth section
presents the results of a real deployment. To close,
the fifth section of the paper establishes the main
conclusions of this work and the following steps to
integrate our technological advances in the
manufacture of process a new train.
2 ‘TRAIN-TO-EARTH’
COMMUNICATIONS
ARCHITECTURE
In this section we describe the core components of
the Wireless Communications architecture. This
architecture allows a full-duplex transmission of
information between applications and devices
deployed in the trains, and applications that are in
the ground control stations (Salaberria, I., et al.,
2009). The description of the architecture will be
made at two levels: Conceptual and Physical level.
2.1 Conceptual Level
From a conceptual point of view, two issues are
especially important: the elements that manage
architecture’s behaviour and the ways that the
different applications transmit the information.
Our architecture hosts both terrestrial and train-
side applications, so in order to manage its
behaviour two main entities are defined: Terrestrial
131
Carballedo R., Perallos A., Salaberría I. and Gutierrez U. (2010).
MANAGING ‘TRAIN-TO-EARTH’ HEAVY COMMUNICATIONS - A Middleware Software to Manage Broadband Wireless Communications in the Railway
Scope.
In Proceedings of the International Conference on Wireless Information Networks and Systems, pages 131-136
DOI: 10.5220/0002930601310136
Copyright
c
SciTePress
Communication Manager (TCM) and On-board
Communication Manager (OCM). The former
manages terrestrial aspects of the architecture and
the latter train-side issues. Although the managers
have a different physical location, both of them have
nearly the same responsibilities:
Delivery and reception of the information,
Dynamic train addressing,
Medium access control,
Security and Encryption, and
Communication error management.
For a correct and optimized used of the
communication architecture, we have defined two
types of transmission.
Slight Communications: This communication is
for the transmission of small volumes of
information (few kB.) and with high priority.
Information that has low latency and needs to be
transmitted exactly when it is generated or
acquired (the GNSS location of a train).
Heavy Communications: This communication is
tied to the transmission of large volumes of
information (in the order of MB) and with low
priority. The management of this type of
transmission is the core of this paper.
2.2 Physical Level
In this section we describe the technological aspects
of the proposed architecture. These aspects refer to
the protocols and the communication technologies
used for the development of the new architecture.
Figure 1: Wireless communications architecture.
It is important to point out that the protocols and
technologies for the development of the new
architecture have been selected with regard to:
standardization, robustness, security, scalability and
compatibility with existing and potential
applications and systems.
In accordance to this, Web Services constitute
the transport technology for the communication
between final applications and the “local”
Communication Managers. All the information is
interchanged in XML format, in order to allow
future extensions.
On the other hand, the communication between
the Terrestrial and the On-board Communication
Managers is based on REST (Representational State
Transfer) technology. This communication
technology uses the HTTP (HyperText Transfer
Protocol) protocol and XML formatted messages.
The information interchanged between the
Terrestrial and the On-Board Communication
Managers is encrypted in order to garantee the
confidentiality of it.
It can be said that the selected technologies are
well known and broadly used in different application
areas or contexts, but they are novel in the railway
train-to-earth’ communication field.
To establish a Wireless Communications channel
between the trains and the Ground Control Centers,
mobile and radio technologies have been selected
(Yaipairoj, S., Harmantzis, F. and Gunasekaran, V.,
2005). In this case, Slight and Heavy
communications use different technologies due to
different transmission characteristics.
Movable technologies such as
GPRS/UMTS/HSPA (Gatti, A., 2002) are used for
the Slight Communications. These technologies do
not offer a great bandwidth nor a 100% coverage
and they have a cost associated to the information
transmission. Despite this, these technologies are a
good choice for the delivery of high-priority and
small sized information. The selection of the specific
technology (GPRS/UMST/HSPA) depends on
whether the service is provided or not, (by a
telecommunications service provider), and the
coverage in a specific area.
On the other hand, for the Heavy
Communications, WiFi radio technology has been
chosen. This technology allows the transmission of
large volumes of information, does not have any
costs associate to the transmission and its deplyment
cost is not very expensive. In this case, a private net
of access points is needed. This net does not need to
cover the complete train route because the Heavy
Communications are thought for the transmission of
big amounts of information at the end of train
service (for example the video recorded by the
security cameras).
Although each separate technology can’t achieve
100% coverage of the train route, the combination of
both comes very close to complete coverage (Pinto,
P., Bernardo, L. and Sobral, P., 2004). As the
application layer protocols are standard, other radio
technologies such as TETRA or WiMAX (Aguado,
M., et al., 2008) can easily substitute the ones
WINSYS 2010 - International Conference on Wireless Information Networks and Systems
132
selected now. These technologies can achieve a
100% coverage and neither one has a transmission
cost. However, there are certain limitations such as
the cost of deploying a private TETRA network, and
the cost and the stage of maturity of the WiMAX
technology.
3 HEAVY COMMUNITACIONS
MANAGEMENT
With the purpose of providing an innovative
broadband communications architecture a number of
WiFi networks have been settled in places where the
trains are stopped long enough to ensure the
discharge of a certain amount of information, this is:
some stations and garages. In this way, we can say
that the WiFi coverage is not complete, but it is
important to say that broadband communications are
designed to update large volumes of information,
which don’t need to take place in real time.
Furthermore, some additional problems have to
be solved on this environment. In one hand, it is
necessary to find a mechanism to locate the trains
because they don’t have a known IP address all the
time. A dynamic IP assignment is used for every
WiFi network so a train obtains a different IP
address every time it is connected to a network, and
a certain IP address could be assigned to different
trains in different moments. On the other hand, there
are several applications that want to transmit
information to/from the trains at the same time. This
implies the existence of a bandwidth monopolization
problem. To tackle these problems a Broadband
Communications Manager has been developed. This
manager acts as a referee or moderator between
applications and communication chanel.
The Broadband Communications Manager is a
system that arbitrates and distributes shifts to
communicate terrestrial applications and train
systems. This distribution shift is managed on the
basis of the state of the train connection to a WiFi
network (known at all times) and a system of
priorities, which are allocated according to the
terrestrial application that wants to communicate
with the train.
The function developed in the Broadband
Communications Manager is given by the problem
explained above. The manager needs to maintain a
stable fluid communication with the agents who
want to manage, so it has been established a
communication protocol that is detailed in the next
section. The basic functionality of the Broadband
Communications Manager is:
Accept connection and disconnection messages
from terrestrial applications and trains.
Accept communication requests from terrestrial
applications.
Send communication starting message to
terrestrial applications and trains, and receive
back another message when the communication
is finished.
As important as mantainig the connection between
the Broadband Communications Manager, trains
and terrestrial applications, is the fact to determine
the distribution of these shifts, ie, which
communication request must take place between a
train and a terrestrial application at any time.
Therefore, the Broadband Communications
Manager knows at every moment the status of
pending and completed communication requests,
and its role is to manage which communication
request should be conducted on each shift and let
them know to the terrestrial application and the train
affected by that communicacion request. The
determination of communication shifts is very
relevant because of the limitations imposed by the
problem of monopolization of bandwidth, described
a few paragraphs earlier. In this way, it has been
imposed some constraints such as, in each station
can only take one communication at a time, or that a
terrestrial application can only communicate with a
train at the same time. This constraints have been
used during the tests, but will they will be eliminated
in the final scenario.
It is important to emphasize that the manager
does not set any limitation or condition in the final
communication between the terrestrial application
and the train. The manager's work focuses on
defining the time at which this final communication
must be carried out, and warns of this fact the
terrestrial application and the train. It does not
define any structure or format of the information
being exchanged; it only establishes a mechanism to
know the IP address of the destination train (because
it is dynamic), and regulates or controls the
transmission shifts to prevent the monopoly of the
communications channel.
The architecture of Broadband Communications
Manager is based on XML messages exchange
between the manager itself and two types of external
entities:terrestrial applications and trains.
MANAGING 'TRAIN-TO-EARTH' HEAVY COMMUNICATIONS - A Middleware Software to Manage Broadband
Wireless Communications in the Railway Scope
133
3.1 Communication Protocol
When the Broadband Communications Manager
decides to give a shift for a terrestrial application
and a train to begin a communication, it sends an
authorization to each part so that it is carried out. To
do this, the manager establishes a communication
with the application and train’s Communications
Manager through TCP Sockets. Within these, a
series of messages in XML format that act as
communication protocol, are defined.
To explain in a simple way the operation of the
Broadband Communications Manager, here is a
representation of a typical scenario:
Firstly, a terrestrial application is connected to
the Manager through a TCP Socket.
The terrestrial application will make a request
for communication, and will give it a certain
priority. The manager, on receiving the request,
orders the queue of pending requests for the
train.
When a train arrives at a station, it connects to
the WiFi network and gets a new IP address.
This IP address is supplied by the On-Borad
Communications Manager to the Broadband
Communications Manager. If the train has
pending requests, the terrestrial application and
the train are notified so that they can start the
communication.
At this moment there is a direct communication
between the terrestrial application and the train
application.
When the communication ends, the terrestrial
application informs the Broadband Communications
Manager of that, and them a new request can be
served.
3.2 Software Architecture
The Broadband Communications Manager is
divided into 5 modules that handle processing and
deployment of all the functionality that has been
developed.
To have a global vision of the performance of the
manager, we focus on two modules which develop
the most important functionality: Connetions
Handler (terrestrial and trains), and Requests
Manager.
3.2.1 Connections Manager
The main task of the Connections Handler module
lies in implementing the communication protocol
described above. To this end, and bearing in mind
that it is necessary to manage two types of external
agents such as terrestrial applications and trains, the
Connections Handler has been developed in two
separate sub modules.
Application Connections Handler is responsible
for managing all the XML messages exchanged
between each terrestrial applications and the
Broadband Communications Manager. Basic
functionality is to receive the messages coming from
terrestrial applications and generate an appropriate
response.
Train Connections Handler is responsible for
managing all the messages exchanged between the
communication module of each train and the
Broadband Communications Manager. In this case,
the primary goal of this handler is to indicate when a
train is connected to a WiFi network and what is its
IP address. This data is very important for terrestrial
applications to communicate with train applications.
Other basic functionality is setting a connection with
the train, and sending XML messages to open and
close a communicacition ports so that a terrestrial
application can communicate with the train only
through a specific one.
There is a very important task that train
communications module manages, the disconnection
or closure of communication between trains and the
Broadband Communications Manager. Related to
this, two different scenarios can occur: in the first
one, a train that is connected to a WiFi network and
has established a communication with the
Broadband Communications Manager has no
pending requests. In this case, the manager sends an
ending request message to the train and then, the
train diconects from the WiFi network. In the second
scenario, a train is disconnected from the WiFi
network because of its movement or a connection
error. In this second case the manager checks at
every moment if the connection with the train is
alive. There is a big problem when the fails in the
middle of a transmission between the terrestrial
application and the train. To solve this, the next time
that the train connects to the Broadband
Communications Manager; it sends back a start
message of the broken communication to the
terrestrial application and a opening port message to
the train.
To carry out its work, Connections Handler must
establish connections with multiple terrestrial
applications and trains at the same time. To manage
all these communications efficiently, it has been
chosen multithreaded design for managing the
connections between Broadband Communications
Manager, terrestrial applicacions and trains. With
WINSYS 2010 - International Conference on Wireless Information Networks and Systems
134
this desing, every connection is carried out
independently and concurrently, using a dedicated
thread in each case.
Both the Train and Application Connections
Handlers are also separate threads that are
responsible for receiving connections from external
agents. When a connection XML message is
received, a separate and dedicated thread is created
to handle all the messages interchanged between the
Broadband Communicaciones Manager and any
terrestrial application or train.
As it was explained above, all the
communications are done through a TCP sockets
architecture and XML messages exchange. A
message will be defined for each requests/responses
exchanged between the three elements that form the
architecture: terrestrial applications, trains and
Broadband Communications Manager.
The choice of the TCP Socket schema and XML
messages was taken due to the simplicity of the
solution, the flexibility, and the ease of
implementation.
To finish the description of the Connections
Handler, we would like to make a brief introduction
on the management of the applications installed on
the trains, which are the target of communication
from terrestrial applications. These on-board
applications are implemented on a system that will
have a private IP address (within the Ethernet
network loaded) and is not accessible from outside
the on-board local area network. Therefore, it has
been defined an addressing scheme to allow access
from a terrestrial application to the IP address of the
on-board applications. This is achieved through PAT
filtering. Thus, whenever a train acquires an IP
address from a WiFi network, a port number
becomes the way to access the private IP addresses
of the on-board applications.
There is a Communications Module on each train
which is the responsible for performing this filtering
of port numbers to IP addresses. This module is also
responsible for communicating directly with
Broadband Communications Manager, and manages
the opening and closing of the ports that are
associated with IP address of the boarded
applications.
3.2.2 Requests Manager
Ther other important aspects that the Broadband
Communications Manager should handle is to select
the time at which these applications must carry out
the communication with the trains.
For this purpose it has been developed an
independent module called Requests Manager that
in charge of managing communication requests
between terrestrial applications and trains, and
checking when and under what circumstances they
need to be attended. Thus, it has designed an
algorithm for discerning the next request to serve.
The Broadband Communications Manager splits
communication shifts to terrestrial applications
based on requests that they have performed. These
requests are grouped by train, so the manager
handles requests addressed to each train
independently. Furthermore, requests are sorted so
that stipulates the order in which applications
communicate with the trains. The management of
requests associated with each train is based on the
following criteria: (1) priority; (2) retries; and (3)
parallelism.
The priorities associated with the requests, are
managed centrally and Broadband Communications
Manager assigns these priorities to terrestrial
applications. In addition, the manager also controls
the train applications that can communicate with
each single terrestrial application, identifying the
train communication module ports that can be
accesses by each of those terrestrial application.
To complete the communication shifts service
and management algorithm, it has prepared a final
criteria, variable in this case (Noh-sam P., Gil-
Haeng, L., 2005). This approach takes into account
two factors related with the communications that
have been carried out previously. (1) the average
duration that takes the communications of a
particular application. (2) the average duration of
trains stopping in a particular station. Thus, the
manager calculates a numeric value that represents
the fitness of serving a request, knowing that the
lower average duration of both factors will be most
appropriate.
4 TESTING AND RESULTS
The Broadband Communications Manager is
currently being tested within the infrastructure of a
railway opeator in the north of Spain.
Broadband Communications Manager is located
in a local area network designed to communicate it
with four terrestrial applications (CCTV, a remote
monitoring and document updating tool and two
fictitious applications).
In the case of the train, it has been installed a
WiFi network in a garage station. Thus, it can be
tested one of the basic scenarios of the Broadband
MANAGING 'TRAIN-TO-EARTH' HEAVY COMMUNICATIONS - A Middleware Software to Manage Broadband
Wireless Communications in the Railway Scope
135
Communications Manager: the communication
between terrestrial applications and the train when it
is in the garage. At this place a train is stopped for
hours, so it is a good place to tranmit big amounts of
information.
The performance tests have been taken into
account two key parameters: ‘train-to-earth’ data
transfer time; and waiting time between each
communication. The Table 1 shows the results
obtained without the Broadband Communications
Manager, while the second table shows the same
scenario with the Broadband Communications
Manager:
Table 1: Results without the Communications Manager.
Volume data
(MB)
Transfer time
(seconds)
Waiting time
(seconds)
< 1 1.10 0
1-10 11.30 0
11-50 58.84 0
51-100 184.62 0
In the first table we can see that the absence of a
communications manager allows communications to
be made in parallel. This slows down the transfer
rate, increasing the transfer time as the amount of
the data transferred increased.
Table 2: Results with the Communications Manager.
Volume data
(MB)
Transfer time
(seconds)
Waiting time
(seconds)
< 1 0.76 0
1-10 7.69 0.76
11-50 38.46 8.45
51-100 115.38 46.91
The second table shows how communications are
conducted in order from smallest to largest amount
of data transferred thanks to the use of the
Broadband Communications Manager. The average
time of transfer is lower than in Table 1, and the fact
that communications are conducted one-by-one
implies that there is a timeout that does not exist if
they were carried out all at same time.
New tests are planned with the train making a
journey through a series of stations. This will test the
other Broadband Communications Manager’s
application scenario: a train arriving at a station,
connecting the local WiFi network, and losing that
connection in the middle of a communication
because the movement of the train. Finally, it
remains to tests multiple trains simultaneously.
5 CONCLUSIONS
The work presented here attempts to illustrate how
we have solved the problem of bandwidth
management in wireless broadband communications.
We have defined a new system that distributes
communication shifts between different systems.
At present, both the wireless communications
architecture as the Broadband Communications
Manager is being incorporated into the
manufacturing process of a new train model, which
is a European-wide revolution.
In the coming months, our team will focus on the
optimization of the wireless broadband
communications management by increasing the
number of trains and applications involved on it, and
the definition of new services to facilitate the
development and deployment of applications on the
architecture presented.
REFERENCES
Aguado, M. et al., 2005. Railway signaling systems and
new trends in wireless data communication. In
Vehicular Technology Conf.
Aguado, M., et al., 2008. WiMAX on Rails. In Vehicular
Technology Magazine, IEEE, ISSN: 1556-6072.
Gatti, A., 2002. Trains as Mobile devices: the TrainCom
Project. Wireless Design Conference. London.
Noh-sam P., Gil-Haeng, L., 2005. A framework for
policy-based SLA management over wireless LAN. In
Proc. 2nd Int. Conf. on E-Business and
Telecommunication Networks. Reading, UK.
Pinto, P., Bernardo, L. and Sobral, P., 2004 Service
integration between wireless systems: A core-level
approach to internetworking. In: Proc. Of Int. Conf. on
E-Business and Telecommunication Networks.
Portugal.
Salaberria, I., et al, 2009. Wireless Communications
Architecture for "Train-to-Earth" Communication in
the Railway Industry. In Proc. 10th Int. Work-
Conference on Artificial Neural Networks, Spain.
Shafiullah, G., Gyasi-Agyei, A. and Wolfs, P.J., 2007.
Survey of wireless communications applications in the
railway industry. In 2nd Int. Conf. on Wireless
Broadband and Ultra-Wideband Communications.
Sydney.
Smith, J., Russell, S., and Looi, M., 2003. Security as a
safety issue in rail communications. In Proc. 8th
Australian workshop on Safety critical systems and
software. Canberra, Australia.
Yaipairoj, S., Harmantzis, F. and Gunasekaran, V., 2005.
A Pricing Model of GPRS Networks with Wi-Fi
Integration for "Heavy" Data Users. In Proc. 2nd Int.
Conf. on E-Business and Telecommunication
Networks. UK.
WINSYS 2010 - International Conference on Wireless Information Networks and Systems
136