Wireless Technologies in the Railway: Train-to-Earth Wireless Communications

Since the origins of the railway in the XIX century most of the innovation and deployment efforts have been focused on aspects related to traffic management, driving support and monitoring of the train state (Shafiullah et al., 2007). The aim has been to ensure the safety of people and trains and to meet schedules, in other words, to ensure the railway service under secure conditions. To achieve this it has been necessary to establish a communication channel between the mobile elements (trains, infrastructure repair machinery, towing or emergency vehicle, and so on) and the earth fixed elements (command posts and stations, signals, tracks, etc.) (Berrios, 2007).


Introduction
Since the origins of the railway in the XIX century most of the innovation and deployment efforts have been focused on aspects related to traffic management, driving support and monitoring of the train state (Shafiullah et al., 2007). The aim has been to ensure the safety of people and trains and to meet schedules, in other words, to ensure the railway service under secure conditions. To achieve this it has been necessary to establish a communication channel between the mobile elements (trains, infrastructure repair machinery, towing or emergency vehicle, and so on) and the earth fixed elements (command posts and stations, signals, tracks, etc.) (Berrios, 2007).
Nowadays, safety is a priority too, but new requirements have arisen, mainly concerning the quality improvement of the transport service provided to the passengers (Aguado et al., 2005). Moreover, the current European railway regulation by establishing that railway services be managed by railway operators independent of railway infrastructure managers 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 et al., 2007) that is explored in this chapter.
The use of wireless technologies and Internet is growing in the railway industry which allows the deployment of new services that need to exchange information between the trains and terrestrial control centres (Shafiullah et al., 2007). In this sense, there are suitable solutions for other environments which allow to manage the bandwidth in terms of data rates. Therefore, these solutions are not designed for railway needs, and do not cover all the requirements that the railway industry has (California Software Labs, 2008;Marrero et al., 2008).
This chapter describes a specific wireless communications architecture developed taking into account railway communications needs and the restrictions that have to be considered in terms of broadband network features. It is based on standard communication technologies and protocols to establish a bidirectional communication channel between trains and railway control centres. and UMTS) and broadband solutions such as WiFi (IEEE 802.11, 2007) or WiMax (IEEE 802.16.2, 2004). The wireless local area networks WiFi enable the exchange of information, at much higher speeds and bandwidths than with other technologies. The cost of deployment of such networks is very low, but these are limited in terms of coverage or distance they cover. To address this limitation, the WiMax technology has emerged extending the reach of WiFi, and is a very suitable technology to establish radio links, given its potential and high-capacity at a very competitive cost when compared with other alternatives (Aguado et al, 2008).
All technologies discussed so far aim to establish a wireless communication channel between fixed elements and mobile elements of the railway field, but what happens with the services offered by means of this communication channel?, how can they have access to the channel?, how can they share it?. To address these questions, a categorization of railway services is necessary. Traditional applications or services of the railway can be classified into two major groups: (1) services related with signalling and traffic control; and (2) services oriented to train state monitoring.
The first group of services is based on the exchange of information between infrastructure elements (tracks, signals, level crossings, and so on) and control centres, all of them fixed elements. Additionally, it uses voice communication between train drivers and operators in the control centres. Therefore, for this type of service, traditional communication systems based on analogical technology remain significant.
The second group of services requires the exchange of information in the form of "data" between the trains and the control centres. In this case, the new services use any of the wireless technologies mentioned so far, but on an exclusive basis, which means that each application deployed on the train must be equipped with its own wireless communications hardware. This leads to have an excessive number of communications devices, often underused. In addition, there are still many applications that require a physical connection "through a wire" between the train devices and a computer for information retrieval and updating tasks.
On the other hand, a new set of services around the end user (passenger, or companies who need to transport some goods) is emerging. These services are oriented to providing a transport service of higher quality that not only is safe, but provides additional benefits such as: detailed information about the location of trains and schedules, contextual advertising services, video on demand, and so on. All these services are characterized by their need of a wireless communication channel with high bandwidth and extensive coverage (Garstenauer & Pocuca, 2011). As a result, the following needs are identified: (1) to standardize the way to exchange train state information between the trains and the control centres; and (2) to define a wireless communications architecture suitable for the new 'end user'-oriented services (Aguado et al., 2005).
In this chapter, a specific communications architecture based on standard technologies and protocols; that is designed to manage train-to-earth connectivity at application layer, will be presented in order to fulfil such needs.

Managing train-to-earth wireless communications
This section describes a general purpose wireless communications architecture to address the needs for high bandwidth and wide coverage. This solution is based on the www.intechopen.com Wireless Communications and Networks -Recent Advances 472 management of a wireless communications channel at the application layer. The architecture proposed is currently being deployed in some railway companies from Spain (Euskotren and ETS from Basque Country, and Renfe from Spain), will be presented . It is an innovative general purpose wireless communication channel which allows the train to communicate with the railway control centres in such a way that the applications or services are unaware of communication issues such as: establishment and closure of the communication, management of the state of connectivity, prioritization of information and so on.
This new wireless communication architecture has to respond to the demand for communication and transmission of information from any application, so it will have to take into account the nature of the information to be sent. The information exchanged between two applications (one on earth and the other on a train) may have different urgency degrees depending on their purpose or treatment with respect to the exchanged information. In fact, there is information that needs to be transmitted at the time that it is generated, for example in case of positioning information or alarms in some critical train operation elements. On the other hand, there may be less urgent information whose transmission can be postponed, such as train CCTV images, or audio files used by the background music. In addition, the urgent or priority information is usually smaller than the non-priority information.

Towards a train-to-earth wireless communications architecture
In this section the core components of the mentioned wireless communications architecture are described. This architecture allows a full-duplex transmission of information between applications and devices deployed in the trains, and applications that are in the railway control centres. The description of the architecture will be made at two levels: conceptual and physical level. The first level defines the basic concepts of the architecture, and the second one illustrates the technologies used to implement the architecture in two real scenarios.

Conceptual level
From a conceptual point of view, two issues are especially important: the elements that manage architecture's behaviour and the ways in which the different applications (terrestrial and on-board) 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 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.
Due to the information transmission needs and for a correct and optimized used of the communication architecture, two types of communications are distinguishes: "slight" and "heavy" communications. These two types take into account characteristics of both information and communication technologies, such us: the volume and the priority of the information, the existence of coverage, and the cost of the communication.
 Slight communications: This type of communication is for the transmission of small volumes of information (few kB.) and with high priority. In general, information that has low latency (milliseconds or a pair of seconds) and needs to be transmitted exactly when it is generated or acquired (for instance, the GNSS location of a train, or a driving order to the train driver). For example, in the first case, if the information about positions is not sent immediately after its generation (real-time transmission), it loses all relevance.  Heavy communications: This type of communication is tied to the transmission of large volumes of information (in the order of MB) and with low priority. The importance of this information is not affected by the passage of time, so it doesn't need to be transmitted at the exact time it is generated (no real-time transmission).

Physical level
In this section the technological aspects of the wireless architecture are described. They refer to the protocols and the communication technologies used for the development of the trainto-earth architecture (showed in Fig. 1). 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. The major aim has been the ease of integration of any application or system into the new communication architecture. Concerning with this objective, 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 (TCM) and the On-board Communication Managers (OCM) is based on REST (Representational State Transfer) technology. This communication technology uses the HTTP (HyperText Transfer Protocol) protocol and XML formatted messages. This solution is similar to traditional XML Web Services but with the benefit of a low overload and computational resources consumption.
Although the information interchanged between the TCM and the OCM is not encrypted, using the HTTP protocol allows the easy migration to HTTPS (HyperText Transfer Protocol Secure) that offers encryption and secure identification. It can be seen that every communication has to go through two core elements that can result in the loose of channel availability in case of failure. This problem is tackled by means of the use of web services because this solution deploys support web services in a way similar to traditional web architectures. It can be said that the selected technologies and architectures are well known and broadly used in different application areas or contexts, but they are novel in the railway 'train-to-earth' communication field.
In order to establish a wireless communications channel between the trains and the railway control centres, mobile and radio technologies have been selected (Yaipairoj et al., 2005). In this case, slight and heavy communications use different technologies due to different transmission characteristics.
Due to de necessity of delivery of information in real-time, mobile technologies such as GPRS/UMTS/HSPA (Gatti, 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/UMTS/HSPA) depends on whether the service is provided or not, (by a telecommunications service provider), and the coverage in a specific area. ). To increase coverage availability, the hardware installed in each train has two phone cards belonging to different telephone providers. This allows switching from one to the other depending on coverage availability. Therefore, the idea is to have a predetermined operator, and only switch to the second when the former is unable to send.
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 deployment 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 et al., 2004). As the application layer protocols are standard, other radio technologies such as TETRA or WiMAX (Aguado et al, 2008) can easily substitute the ones 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

How to manage wifi based broadband communications
As it was explained previously, there are some railway applications that need a high bandwidth to interchange large amount of information without time restrictions (real time communication is not needed). This kind of communications will enable 'train-to-earth' information exchange for train side systems update/maintenance and multimedia information download/upload such as videos or pictures.
With the purpose of providing an innovative broadband communications architecture suitable for the railway, a number of WiFi networks have to be settled in places where the trains are stopped long enough to ensure the discharge of a certain amount of information. This is: stations in the header that starts or ends a tour and garages. In this way, WiFi coverage is not complete, but broadband communications are designed to update large amount of information, which, usually do not need to take place in real time.
Therefore, at this point it has to be taken into account aspects such as bandwidth, coverage or communications priorities. The existing broadband management systems, which are used in other (non mobile) environments, do not satisfy all the needs of the railway applications (California Software Labs, 2008;Marrero et al., 2008). 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 challenges, it is necessary a smart intermediate element which manages when the applications (both terrestrial and train-side) can communicate with each other. That is to say: a Broadband 'train-to-earth' Communications Manager, whose design and functional architecture is described below.

Design of the broadband communications manager
The Broadband Communications Manager (BCM) (Carballedo et al., 2010a) is a system that arbitrates and distributes shifts to communicate terrestrial applications and train-side systems (see Fig. 2); in this way, the terrestrial applications request a turn when they want to establish a communication with a train. 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 a specific train. 1. Communication establishment protocol. When the BCM decides to give a shift to communicate a terrestrial application and a train-side system, it sends an authorization to both (application and train system). To do this, the manager establishes a communication with each entity through TCP Sockets. Within these TCP Sockets a series of XML messages, that define the communication protocol, are used.
To explain in a simple way the operation of the BCM, here is the description of a typical scenario:  Firstly, a terrestrial application designed to communicate with a train system is connected to the manager through a TCP Socket.  The terrestrial application will make communication request, and will give it a certain priority. By the time the manager receives the request, it orders the request in the queue of the destination train's requests. This queue is always sorted by different criteria.  When a train arrives at a station, it connects to the WiFi network and it gets an IP address. This address is supplied to the BCM. If the train has pending communication requests, the terrestrial application is notified so that it can start the communication.


At this moment there is a direct communication between the terrestrial application and the train-side system, through the WiFi network. The responsibility for starting the communication relies on the terrestrial application because it knows the IP address of the train.  When the communication ends, the terrestrial application informs the BCM, which is ready to serve the next communication request.
It is important to emphasize that the BCM does not set any limitation or condition in the communication between the terrestrial application and the train-side system. The manager's work focuses only in defining the time at which this communication must be carried out, and warns of this fact to the entities involved in the information interchange. 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 manages the transmission shifts to prevent the monopolization of the communications channel.
2. Multithreading management. To carry out its work, the BCM must establish connections with multiple applications and train-side systems at the same time. To manage all these communications efficiently a multithreaded design has been chosen for the management of the connections. Every communication that the BCM performs with any external element (terrestrial applications and train-side systems) is carried out independently and concurrently, using a dedicated thread in each case.
Both the Train-Side Systems Handler and the Terrestrial Applications Handler (see below, Fig. 4) are separate threads that are responsible for receiving connections from external agents. Upon receiving the connection message specified in the protocol, they generate a separate communication thread with the element which has sent the message.
architecture: terrestrial applications, train-side systems and Broadband Communication Manager. Fig. 3 shows a XML message of the communication protocol. Fig. 3. An XML message with a request from terrestrial application to the BCM asking a communication with an on-board system of the train UT204.
In order to communicate terrestrial applications, train-side systems and BCM a XML messages base protocol has been defined. The choice of the TCP Socket schema and XML messages was taken due to the flexibility to add new functionality, and the simplicity of implementation (independent of platform and programming language).
Moreover, all the data handled by the BCM is stored in a relational database. These data contain information about the communication requests, trains, train-side systems, terrestrial applications, and the available communication ports between them. The BCM's design contains a data layer that abstracts the data source of the business layer, so that the changes of this data by another for a different data source does not create any problems in the proper functioning of the BCM.
4. Port to IP address translation schema. To finish, we will make a brief description of the management of the applications installed on the trains (train-side systems), which are the target of the communication from terrestrial applications. These train-side systems are implemented on a computer that will have a private IP address (within the onboard Local Area Network) and is not accessible from outside the train. Therefore, it has been defined an addressing scheme to allow access from the IP address of the terrestrial application to the IP address of the train-side system. This is achieved through PAT filtering, associating each private IP address to a port number. Thus, whenever a train acquires an IP address from a WiFi network, the port number becomes the way to access the train-side systems. PAT filtering schema also ensures the security of communications and the information transmitted.
In each train there is a communications module which is responsible for performing this filtering of port numbers to IP addresses. This module is also responsible for communicating with the BCM, and manages the opening and closing of the ports that are associated to each train-side system.

Functional architecture of the broadband communications manager
Functional architecture of the BCM is based on message exchange between the manager itself and two types of external entities such as terrestrial applications and train-side systems. The BCM is divided into 5 modules (Fig. 4) that handle processing and deployment of all the functionality. To have a global vision of the performance of the BCM, it is necessary to focus on three modules which carry out the most important functionality: 1. Terrestrial Applications Handler. It will be responsible for managing all the messages exchanged between each terrestrial application and the BCM. Its basic functionality is to receive the XML messages coming from terrestrial applications and generate an appropriate response. This communication is bidirectional, and it is the responsibility of the terrestrial application to start and finish it.
To streamline the management of communications between terrestrial applications and the BCM, the connections are managed independently (through a dedicated thread). The main functionality offered by this module would be the next one:  Establish and close the connection between terrestrial applications and the BCM. This module is similar to the Terrestrial Applications Handler. It receives XML messages from the communication module of each train and generates the responses. In this case, the primary goal of the module is to indicate when a train is connected to a WiFi network and its IP address. This data is very important for terrestrial applications to communicate with train-side systems.
There is a very important task that Train Communication Module manages, it is: the disconnection or closure of the connection between the train and the BCM. When a train reaches a station with WiFi connectivity, it connects to the WiFi network and establishes a communication with the BCM. After that, two scenarios can occur: in the first one, the train has no pending communication request from terrestrial applications. In this case, the manager sends a connection ending message to the train and the connection is closed. In the second scenario, a train is disconnected from the WiFi network because of its movement or a communication failure. The manager is constantly checking if the connection with the train is lost so this situation is detected as soon as it happens. There is a problem when the connection fails in the middle of a communication between a terrestrial application and a train-side system because the communication request has not finished correctly. To solve this problem, the next time the train connects to the BCM it sends back the start message of the broken communication to the terrestrial application in order to regain restart the communication. This pattern is repeated until the communication request is completed correctly, or is discarded because it exceeded the threshold of retries.
3. Request Manager. It will be responsible for managing communication requests between terrestrial applications and train-side systems, and to control when and under what circumstances the requests need to be attended.
As discussed above, the BCM 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. The communication request for each train is sorted by the following criteria: (1) priority, which represents the 'urgency' by which a request must be addressed; (2) retries, it is taken into account the number of attempts to start a communication, to avoid the monopolization of the communication channel; and (3) parallelism, the manager can handle communications from multiple applications simultaneously with several trains.
The priorities associated with the communication requests are managed centrally and the BCM assigns these priorities to each terrestrial application. In addition, the manager also controls the train-side systems that can communicate with each single terrestrial application, identifying the ports that can be accesses by each of those terrestrial applications.
To complete the communication shifts service and management algorithm, it has prepared a final criteria, variable in this case (Noh-sam & Gil-Haeng, 2005). This approach takes into account two factors that are related directly with the communications that have been carried out previously.
(1) The first factor is based on the calculation of average duration that takes the communications of a particular application.
(2) The second factor takes into account 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, since the risk of communication to be split because the train leaves the station will be less. Once calculated this criteria, it is used to discern which communication request is served, if the criteria explained a few paragraphs above is not sufficient 4. Management Console (MC) and Activity Log (AL). As for the remaining two modules, the MC contains a small management utility for monitoring the status of existing communication requests, and cancelling or changing the priority of unfinished requests. Through this interface it is possible to configure parameter and information settings of the BCM such as terrestrial applications, train-side systems, communication ports and priorities. The MC utility is based on standard design patterns like Model View Controller (MVC) so that in the future this presentation layer can be replaced by a more suitable one. The other supporting module is the AL. It stores each of the activities undertaken by the BCM.
To validate the improvement in the management of broadband communications produced by the BCM, there were a series of laboratory tests, which have subsequently been carried out in a real scenario. At first, the Broadband Communications Manager was tested in devising single communications between train and CCTV application. But to prove the performance improvement of the available bandwidth use, it has been necessary to include other terrestrial applications such as a document updating tool, and two other fictitious applications that simulate communications with the train.
The performance tests have taken into account two key parameters: 'train-to-earth' data transfer average time; and average waiting time between each communication.

Considering the quality of service
In previous sections there have been described a train-to-earth communication architecture that enables two kinds of communications schemes: (1) slight communications and (2) heavy communications. Slight communications aims to respond priority and real-time application communication needs that no requires broadband communications bandwidth capabilities, whereas heavy communications were designed to lower priority large information volumes transmission management with no real-time requirements.
Based on this previous work, future work aims to go a step further by combining both schemes mentioned before to enable a real-time broadband communication platform which responds to train-to-earth applications communication needs. Thus, the objective is to enable several physical network communication links between train and ground system, choosing the network link considered as the best at every moment according with the bandwidth availability. Not having final applications to get involved in the network management. So, the system should respond to several requirements:


High availability: each train should be enabled with one or more physical network communication links (3G, WiFi, etc.). Providing continuous train-to-earth connectivity in order to respond to the final applications communications demand in real-time.  The best bandwidth: the purpose of this platform is to enable real-time train-to-earth broadband communications, using the best possible bandwidth. Thus, the system will always select the physical link considered as the best in order to respond to final application communication requirements.  Quality of Service (QoS): this solution aims to make a service quality management too. Therefore it is necessary to know the bandwidth availability offered by the network link which is active at every moment, as well as the bandwidth offered by the rest of communications links (although they are not being used). At this point it is essential to establish a set of connection procedures which permit to reserve a certain bandwidth for a particular communication.
Hence this broadband train-to-earth communication platform has three principal functions: 1. Multiple physical device management, considering the dynamic selection of the best one (best bandwidth) and their abstraction into a single virtual device. 2. QoS implementation enabling the reservation and release of channels (virtual links) with a given bandwidth. 3. Message routing.
So, to carry out the train-to-earth communications management and arbitration, presented solution manages a set of criteria for prioritizing final applications communication requirements which will focus primarily on the criticality of the information transmitted and the required bandwidth, as well as their chronological arrival order.

Capabilities of the Real-time broadband communications platform
The main capabilities of this communication platform are related to (1) communication prioritization, (2) selection of the physical communication network link and (3) train-toearth information exchange management.

Communication prioritization
The objective is to prioritize train-to-earth communications based on several criteria so that the transmission of critical information have more priority over other information that need less "immediacy" when being transmitted. Therefore, this platform proposes a set of communication requests prioritization criteria in order to respond final applications communication demand (both on ground and onboard train). So, these criteria are applied to establish the order of the communication requests in train-to-earth communication prioritization queues.

Selection of the physical communication network link
The communication platform is based on different physical communication link existence so that the combination of these independent links offers a continuous train-to-earth connectivity in order to respond to the final applications communications demand in realtime. Thus, depending on the status of each of these media and their characteristics and restrictions, the platform must be designed to utilize the link that offers better performance in order to provide a high availability.
The system is designed to select at every moment the physical link that is most favorable for communications. Therefore, taking into account the availability of enabled different physical links, the system selects always as active link one that offers the best bandwidth (based on the features and coverage of the physical link).
At this point it should be emphasized that the basis is that the system always defines a single train-to-earth network link as active for communications (most favorable). So, all communications will always be generated by the channel set as active (WiFi, GSM / GPRS, Tetra, etc.) regardless of the availability of other physical channels simultaneously.

Train-to-earth Information exchange management
The main feature of the system is to manage the transmission of real-time broadband trainto-earth information. Therefore, the platform has to offer:


Real-time bidirectional communication between train and terrestrial applications allowing generating new digital services with quality of service (QoS) guarantees. Thus, different kind of information exchange between final applications (multimedia, text, bytes, etc.) has to be supported.  Train-to-earth communication management without requiring the participation of the final applications. However, transmission retries are delegated to the application logic. When an application information transmission is cut by the platform (because there is another higher priority request), and then it is re-established, it is responsibility of this application to decide if it continues transmitting from the point where it had left, or if the transmission is restarted from the beginning.  Changing the requests bandwidth allocation in cases where the data traffic on the physical environment allows platform to assign applications' communications a greater bandwidth than initially requested from them.

Design of the Real-time broadband communications platform
This platform defines two main entities (Fig. 5): Terrestrial Communications Manager (TCM) and On-board Communications Manager (OCM). The former manages terrestrial aspects of the architecture and the latter train-side issues.
TCM interact with the OCM installed on each train in order to (1) select the best network link available at each time and then (2) manage applications communication requests serving those that are considered most priority first.

Network active link selection
To establish train-to-earth communications, OCM and TCM can communicate through different communications network physical links. These two entities communicate each other to select the active link considered most favorable for communications. Therefore, OCM and TCM are continuously monitoring all enabled network link status, and switch from one to other in two cases: (1) when active link connectivity is lost and (2) when OCM and TCM select another link to be the new active link. In these two cases, the active communication link change is transparent for final applications that do not detect connection interruptions if these link changes occur while they are transmitting.

Priority application communication requests management
The broadband communication platform enables train and terrestrial railway applications to communicate each other. So when an application attempts to start a new communication makes a communication request to the platform. Then the system make a decision about what priority requests can be served concurrently by the system taking into account active link bandwidth limitations and requests QoS requirements.
On the train side, the OCM must be able to prioritize communication requests made by the on board applications. So, the OCM queues train applications' requests in base of established prioritization criteria. Then taking into account communication active link bandwidth properties, the OCM notifies to TCM about the on board most priority requests that could be served concurrently by the system respecting these requests QoS requirements. TCM will ultimately decide and notify the OCM which communications can be addressed at every moment, considering the rest of the terrestrial applications' request.
Therefore, on the ground side the TCM will manage terrestrial applications' requests as OCM do in the train. Besides, TCM will have a queue for each train on the system containing that train's requests (notified by its OCM) and terrestrial requests in order to make decisions about what applications' requests can communicate at every moment.

Developing railways services over train-to-earth communications
Now we will explore the benefits of having a train-to-earth wireless communication technology like the one presented before. These benefits will be justified by mean of the new valued added railway services which will be able to be developed using this communication architecture. In this section we will show the functionality of two specific services as well as the way in which they interoperate with the train-to-earth wireless communication channel. The first one is a Backup Traffic Management Service (BTMS) which uses the slight communication infrastructure and the second one is a Remote Application Management Service (RAMS) which uses the heavy communication model and integrates with the broadband communication manager.

Backup Traffic Management Service (BTMS)
Security in railway industry is a critical issue. Intelligent Transportation Systems are becoming a very valuable way to fulfill these critical security requirements. In fact, today, rail traffic management is performed automatically using Centralized Traffic Control systems (CTC) (Ambegoda et al., 2008). These systems are based on sensors and different elements fixed on the tracks. They allow real-time traffic management: (a) location of trains, (b) states of the signals, (c) status of level crossings and (d) orientation of the needles. Most of the infrastructure management entities have a CTC that handles centralized all these issues. The applications and systems that handle these tasks are very robust and have a performance index near 100%. Problems occur when these systems fail. In those situations, traffic management has to be performed manually and through voice communications between traffic operators and railway drivers (Sciutto et al., 2007).
In this section web described a support system to assist traffic operators in emergency situations in which CTC systems fail. The main objective of this system is to reduce human error caused by the situations in which priority systems do not work properly.

Functional requirements
CTC traditional systems are centralized and rely on wired communications. When CTC system or communications fail, no one knows the location of trains, thus increasing the chances of an accident. In these situations, the railway companies put into operation its security procedures that transfer the responsibility of traffic management to traffic operators, who are people that monitor traffic in the terrestrial control centres. These people should manage the traffic manually communicating through analogical radio systems to the drivers of the trains. As people get nervous in emergency situations and that leads to mistakes, the new service aims to reduce these errors by creating a new tool to help traffic operators in emergency situations. This new tool must be based on different technologies to those used by traditional CTC systems so that failure in the former does not cause failure in the latter.
Taking into account these motivations and requirements, a Backup Traffic Management Service (henceforth BTMS) has been developed (Carballedo et al., 2010b). This service will assist traffic operators when the primary system fails. The main functions of this new system are:  Traffic situation representation for the track stretches where the main system do not provide information. The new service represents the affected line stretches situation (train locations, track section occupation states, etc.) from information received from train-side systems through real-time wireless 'train-to-earth' communications (see Fig. 6).  Traffic management environment. The objective is to provide a traffic assistance application in order to assist operators in tasks related to traffic control when the main system fails partial or totally.  Statistical analysis. About aspects related to the system performance and reliability.  Control message sending from control centre to trains. This functionality will allow traffic operators to send messages to the train drivers in order to manage and control the traffic. The BTMS provides a traffic assistance application that works independently of the main CTC system. Thus, the new service is based on an application that informs about the position of the trains on track and permits to make tasks related to traffic management and control in an easier way. Moreover, this system permits a new way of communication between the traffic operators and trains drivers: exchanging control messages.

Architectural and design issues
In this section, we describe the most important technical considerations about the BTMS. The main issues are those related to (1) trains positioning, (2) wireless 'train-to-earth' communications and (3) added value services. These three issues are described below.
1. Train positioning system. The BTMS permits a new way of train positioning which works independently of the main system operation. In order to achieve this target, a new hardware/software module is boarded on each train. This module combines the positioning data provided by some hardware devices (accelerometers, gyroscope, odometer, etc.) with the coordinates given by a GPS module. To generate the most accurate positioning information, this system parts from a railway lines different tabulation ways. In this case, the tabulation is related to lines lengths (in kilometres) and the traffic signals positions. Based on this information, and the data extracted from the hardware and software modules boarded on trains (including GPS), this system translates this information to kilometric points (Shang-Guan et al., 2009). Then this positioning information is sent to the control centre in real-time.
Besides, the BTMS communicates with an external positioning information system which permits the reception of train positioning information generated by the main CTC system. 2. Real-time train-to-earth wireless communications. The BTMS permits real-time train traffic management, so it is necessary to enable a real-time wireless communication channel between the BTMS installed on the control centre and the trains. For this reason, this service needs to use the previously explained train-to-earth wireless communications architecture, which enables slight communications and is based on mobile technologies (Aguado et al., 2005). 3. Additional Services. Using the mentioned train-to-earth communication architecture and the information provided by the on board positioning system positioning, two services have been developed related with the functionality of the BTMS.
The first one is a Statistical Analysis Service, which using the information stored by the positioning system on a data base, the BTMS can make statistical analysis related to the system's reliability level, GPS and GPRS coverage, and other system functionality aspects. Thus, one of the main goals of this service is to compare the received information, determining if the positioning provided by the train-side systems is according to the information generated by the primary CTC system. And the second is a Control Message Exchanged Service, which allows the procedural alarms transmission to the train-side systems. These kinds of alarms indicate anomalous situations to the train drivers: primary system failure, signal exceeds authorization to a certain point as a consequence of a failure of any electro-mechanical track component, etc.

Remote Application Management Service (Remote-AMS)
One of the main objectives of applications running inside the train is to provide information in order to facilitate the work of the train driver. Usually these applications need to use information generated in the ground centre. If this information changes, it needs to be updated remotely. In addition, there are terrestrial applications that use information generated by some on board applications. Therefore, it is necessary to be able to download that information from trains.
In order to resolve these issues, a new service that allows the remote management of on board applications (upgrade, download and deletion of information) will be proposed. This new service is composed by a terrestrial software module and an on board one that communicate each other to permit this remote management. So, this system would be integrated with the communication architecture described before based in heavy communications scheme (voluminous information with no real-time requirements).

Functionality
The main functionality of this service is to control the updating of the information used by applications running on the train terminal (for example track flat information or supporting documentation for the driver generated by the ground information systems) as well as downloading and deleting information generated by some on board applications (for example log files) remotely from the ground centre.
The solution consists of two software applications, one for the "ground" (control centre) and the other to be deployed in all train terminals. These applications are integrated with the previously described connectivity architecture via heavy communication since it involves the exchange of large volumes of information that do not require real-time communications.
Therefore, in this case, the Broadband Communication Manager (BCM) will be responsible for the arbitration of the train-to-earth heavy communication requests which are made by the software application running on the ground centre. This terrestrial application aims to communicate with those applications running inside the train to carry out all tasks related to the described service.
Thus, the terrestrial Remote-AMS application is installed on ground centre, and it will be responsible for managing the status of all applications in each terminal. On the other hand, on board Remote-AMS application will handle update, download and deletion requests made by the terrestrial Remote-AMS application. So, terrestrial and on board Remote-AMS functionality involves these issues:  Knowledge about the configuration information for each application installed on each train terminal at any time (version, creation date, last updated date, etc).  Knowledge about files and/or documents used by each application that can be updated, downloaded and/or deleted. This information will include: version, creation and last update date, update status (pending or not), etc. This management is done through a repository of information in a database.  Management of information (files) of all current and future applications installed in the train terminals. For such management the Remote-AMS service will use FTP (File Transfer Protocol) configured to work locally (inside the train). So, the technology used is well known and standardized for remote management information.  Management of the updating of configuration information of the applications installed on the train terminals.  Management of the download of the information generated by the applications running on the train terminals.  Management of the deletion of obsolete information in train terminals.


Manage queries about the status information of the on board applications.  Integration with the train-to-earth wireless communication architecture via heavy communications scheme.

Architecture
As mentioned before, this service is integrated with the previously described connectivity architecture via heavy communications scheme. So, when the terrestrial Remote-AMS generate tasks which involve downloading or uploading information from and to trains, it have to communicate with Broadband Communications Manager (BCM), because this is the entity who arbitrates heavy communications between ground and train applications. In this case, BCM arbitrates communications between terrestrial and on board Remote-AMS application. For proper integration with BCM, Remote-AMS (more specifically the terrestrial one) shall be compliant with the protocol of communication established by this management entity.
At this point it is important to remember that BCM does not interfere between final applications communication. The Fig. 7 shows Remote-AMS service architecture and its integration with the train-to-earth wireless communication technology. So, whenever terrestrial Remote-AMS schedules a task it has to send to the BCM a connection message. Once connected, there will be many communication requests as required. When BCM determines that a Remote-AMS request should be addressed, sends a notification to terrestrial Remote-AMS indicating to perform the service task corresponding to this request. Once the communication is completed, terrestrial Remote-AMS sends a notification to BCM which sets this request as completed and removes it from the corresponding communication prioritization queue. This same pattern is followed for all terrestrial Remote-AMS communication requests.
Apart from the improvements of the communications architecture, the design of a framework for vertical services deployment could be very interesting. This framework would offer an easy and seamless integration of new applications with the wireless communication infrastructure and with other future horizontal services. This infrastructure is based on standards and technological paradigms which are highly/ long enough proved in different environments. Furthermore, their interoperability and integration benefits are sufficiently contrasted; one example is the SOA (Service Oriented Architecture) paradigm case. It would be interesting to adopt the Software Engineering best practices and standard of interoperability used in other areas in the railway industry.
Finally, the proposed infrastructure would boost the development of new vertical services which can be classified in four categories: (1) driver assistance services, (2) services for passengers, (3) freights tracking services (based on RFID technology) and (4) services for train health monitoring. All these services have in common the need for exchange of digital content (often multimedia) between trains and ground control centres. The ubiquitous nature of connectivity that is provided by the new communications scenario will improve existing railway applications. And furthermore, will facilitate the development of new context-aware and customized services for end users. These advanced features result in fundamental improvements in the field of rail services.

Conclusion
In the railway industry, communications were born almost exclusively for the purpose of managing and regulating traffic flow, requiring by the mobile nature of this sector two modes of communication: those that occur between fixed elements of the rail infrastructure, which are based mainly in wired systems; and those which participate in the fixed and mobile elements (communications known as "train-to-earth"), which require a wireless communication channel and traditionally have materialized on the use of analogical communication systems such as traditional phone or radio.
Today, despite the maturity of the railroad industry and the advances in wireless communications technologies, the rail industry continues to base the operation of its priority services in analogical and wired communication technologies, which in fact belong to the past but still are efficient and robust.
New generation of wireless communications technologies, such as those based on conventional mobile technology (GSM, GPRS or UMTS), or broadband solutions (such as WiFi or WiMax), opens countless possibilities of use in the railway industry. As the cost of their deployment is very low, they perfectly complement traditional communication systems, and they have wide bandwidth and wide coverage that enable the deployment of new generation services in this area, some of them directly related to the end user, in order to provide a high quality transport service. On the other hand, the rise of high-speed trains is facilitating EXPANSION GSM-R as a basis for communication between signaling and regulation systems for the railway traffic.
This is precisely the topic on which this chapter is focused. It described a specific architecture of next-generation wireless communications for the rail industry to establish a train-to-earth bidirectional communication channel. This architecture is a single channel of communication between all train applications and those in the control centres. The aim of this communication channel is to standardize the way the data is transmitted between them. Thus, this channel is a resource shared by all the applications that simplifies the complex details related to communications and provides advanced services oriented to communication; services such as the selective treatment of the transmissions based on the nature and volume of the information, the location of the messages destination, the management of priorities and arbitration of communication shifts, attempts management, and so on. Moreover, we illustrate the challenges of bandwidth management in railway wireless broadband communications, and how we have faced to them. We have designed a new system that distributes communication shifts between terrestrial applications and train systems, which require the exchange of large amounts of information.