**4. 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:


Hence this broadband train-to-earth communication platform has three principal functions:


480 Wireless Communications and Networks – Recent Advances

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

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

**Data Volume (MB) Data 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 sharing the bandwidth. This greatly slows down the

**Data Volume (MB) Data 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 49.91

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

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,

applications that simulate communications with the train.

Table 1. Results without the Broadband Communications Manager.

Table 2. Results with the Broadband Communications Manager.

Manager than without it, although there are wait times.

**4. Considering the quality of service** 

transfer rate, increasing the transfer time as the volume of information grows.

the Broadband Communications Manager.

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.
