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

Fig. 4. Functional architecture of BCM, composed of five modules: Terrestrial Application Handler, Train-Side Systems Handler, Request Manager, Activity Log and Management Console.

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:


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

Fig. 4. Functional architecture of BCM, composed of five modules: Terrestrial Application Handler, Train-Side Systems Handler, Request Manager, Activity Log and Management

To have a global vision of the performance of the BCM, it is necessary to focus on three

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

To streamline the management of communications between terrestrial applications and the BCM, the connections are managed independently (through a dedicated thread). The main

Establish and close the connection between terrestrial applications and the BCM.

exchanged between the communication module of each train and the BCM.

Receive communication completed messages from terrestrial applications.

Send messages to a terrestrial application in order to start communication requests.

2. **Train-Side Systems Handler.** It will be responsible for managing all the messages

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

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

modules which carry out the most important functionality:

the terrestrial application to start and finish it.

Receive communication requests.

train-side systems.

functionality offered by this module would be the next one:

Console.

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. Table 1, shows the results obtained in the management of communications between four terrestrial applications (with different volume of data) and a train at the same station without the Broadband Communications Manager, while the second table shows the same scenario with the Broadband Communications Manager.



In the first table we can see that the absence of a communications manager allows communications to be made in parallel sharing the bandwidth. This greatly slows down the transfer rate, increasing the transfer time as the volume of information grows.


Table 2. Results with the Broadband Communications Manager.

The second table shows how communications are conducted from smaller to larger amounts of data transferred thanks to the algorithm developed for the communication request service. 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. At the conclusion of the tests it was determined that communications are carried out about 30% faster with the Broadband Communications Manager than without it, although there are wait times.
