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

 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