**6. Future work**

488 Wireless Communications and Networks – Recent Advances

Integration with the train-to-earth wireless communication architecture via heavy

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

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

Fig. 7. Remote Application Management Service (Remote-AMS) and how it interoperates

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

with the Broadband Communication Manager (BCM).

terrestrial Remote-AMS communication requests.

**APP**

**APP**

**Others**

integration with the train-to-earth wireless communication technology.

Manage queries about the status information of the on board applications.

communications scheme.

**5.2.2 Architecture** 

management entity.

As future lines of work, the major efforts in train-to-earth wireless communication are focused on the improvement of the capabilities of the communication channel. Concerning with these improvements the followings are two of the hot topic to deal with:

1. **Communication network virtualization.** Where the technology and the terrestrial platform which takes part in the digital contents interchange are selected transparently to the front-end back-end applications depending on which technology suits better the communication features (information volume, nature and priority, communications cost; coverage, and so on).

Nowadays, the wireless technologies available for this kind of communication between the railway and the terrestrial platform are: WiMax, WiFi, GPRS, UMTS, TETRA or GSM-R. Nevertheless, the proposed solutions have to be compatible with any other future communication technology.

2. **Hybrid self-managed and shared communication channel.** The challenge is to design a shared communications channel to be used for all applications, regardless of current or future functionality of those applications. With this new communications scenario, applications will only provide the information to be transmitted, and the destination of communication (being hidden protocols and the complexities of the communication). The channel itself will decide when is the right time to send the information and what is the best technology.

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.
