**3.2.1 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.

Fig. 2. The Broadband Communications Manager (BCM) arbitrating the communications between terrestrial applications and train-side systems.

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:


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.

3. **XML based protocol for data transmission.** All the communications are done through an architecture based on TCP sockets (one for the terrestrial applications and another one for the train-side systems) and XML messages exchange. A message will be defined for each requests/responses exchanged between the three elements that form the architecture: terrestrial applications, train-side systems and Broadband Communication Manager. Fig. 3 shows a XML message of the communication protocol.

476 Wireless Communications and Networks – Recent Advances

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

To explain in a simple way the operation of the BCM, here is the description of a typical

Firstly, a terrestrial application designed to communicate with a train system is

 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

When the communication ends, the terrestrial application informs the BCM, which is

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

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

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

3. **XML based protocol for data transmission.** All the communications are done through an architecture based on TCP sockets (one for the terrestrial applications and another one for the train-side systems) and XML messages exchange. A message will be defined for each requests/responses exchanged between the three elements that form the

independently and concurrently, using a dedicated thread in each case.

separate communication thread with the element which has sent the message.

series of XML messages, that define the communication protocol, are used.

connected to the manager through a TCP Socket.

ready to serve the next communication request.

scenario:

the train.

channel.

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.
