Questo articolo è stato pubblicato in occasione della
“Wireless Design Conference 2002” London 15-17 Maggio 2002
Trains as Mobile devices: the TrainCom project
The TRAINCOM (1) is a research project partially funded by the European Community under the "Information Society Technology" Programme 1998-2002, it involves 14 participants of 7 countries with an effort of 650 pms, it will end in December 2003. The project aims to fully specify and develop a communication system for telematic applications in the railway field, integrating the on-board network, 2G-3G radio links and Internet technologies. A train, as a cluster of devices connected by a network, is "a mobile user" that is performing some services like passenger information, train identification and fleet management. The train is connected to the ground section with a set of wireless connection and is capable to switch between them "on the fly" regarding the requirement of bandwidth requested by the "service".
Scarica l’articolo in formato pdf
The TrainCom project uses the results of a previous one, the ROSIN project (2), where one of the goal was to obtain the data transmission from train to ground by Wireless System. The communication architecture of Figure 1 will be used mainly in long range, cross-border trains for passenger information, monitoring, maintenance and fleet management. Considering the existing network structures and services of the railway operators, a key point is the interoperability of the system and the communication protocols of the applications.
Train coupling / decoupling is widely used and has to be supported by dynamic addressing schemes in the communication infrastructure, others important issues, because there are multiple communication routes to a coupled train, are the rules for the communication path.
Basically, are requested two different modes of access to trains or vehicles: (a) direct access to a specific set of vehicles regardless where it is, (b) access to a specific train, regardless which set of vehicles builds the train.
A common radio communication system is needed for ubiquitous access to border crossing traffic. The TrainCom communication infrastructure is intended to be "open" and not restricted to a specific implementation of radio link (e.g. GSM,WLAN) or train on-board network (e.g. TCN, FIP).
TrainCom will develop a reliable train-ground communication system, offering ubiquitous remote access to on-board equipment and integrating available and new technologies:
The picture of Figure 1 shows the main components of the system and their connection: the RoGate on-board and RoGs, RoNS and RoClient in the Ground Segment.
The RoGate is the device that implements the interface between ground (the Internet world) and the on-board network. It is connected to the ground section with a set of wireless connection and is capable to switch between them "on the fly" regarding the needs of bandwidth requested by the "service". The values of Figure 2 are the Service profile defined in IMT-2000.
The choice of the communication system between ground and train at wireless level affects heavily :
From the ground side of the network, the RoGate is the access point of the train and represents the "train" in the network. The RoGate could implement the interfaces to the Jini discovery and lookup service. It includes specialised knowledge of the kind of leases that are handled out by the Jini lookup service and it will be able to renew those leases directly in managing the stubs for these services.
Main purpose of the Ground Segment system composed by Ground Segment (RoGs), Name Server (RoNS) and Clients is to develop models, functions and basic modules for future innovative train-ground communication processes and viceversa and to verify the functionality and demonstrate the potentiality of the technologies developed in the TrainCom project.
The design of this system presents several strong requirements:
RoGs application will have to demonstrate the potential advantages offered by TrainCom infrastructure. Therefore, it’s necessary to define some basic features like structures, user interfaces, structure accesses-management and so on.
From a functional point of view we can considered the RoGS system as composed by:
All data are implemented using XML language, a proposed architecture, from a ground-level point of view is represented in the Figure 3.
Figure 3 - RoGS architecture
The services considered by the project are mainly the Passenger Information System, Fleet Management, Maintenance Operation and Locomotives and vehicles interoperability. In setting up a service like the TrainCom one we can also define how this service could be deployed. The TrainCom network could acts as mobile virtual network operator (MVNO) providing services to the Train Operator Company. TrainCom could rents capacity (MVNO) from the mobile network operator (MNO) as an independent player (e.g. Sense Communications in Norway and Sweden) and integrate the TrainCom services in the network.
In the future it is likely that there will be more than one network technology to provide the customer with mobile data services.
Figure 4 - Wireless Coverage Areas
In term of services, the requirements are defined by the International Mobile Telephone Standard 2000 (IMT-2000) and listed in Figure 2.
The service's requirements in terms of bandwidth are related to the size of the information needed per session, see Figure 5 .
The "Medium Multimedia" data rate (Figure 2) is available to moving terminals in urban and suburban areas; the maximum data rate of 2 Mb/s is available only to slow-moving terminals relatively close to base stations, terminals in rural areas are provided with lower data rates (up to 144 kb/s). Under these restrictions, UMTS will not be able to deliver the high rates necessary for certain applications.
Figure 6 - UMTS requirements
The base of TCP/IP communication is the assignment of unambiguous IP addresses to each device. To build such unambiguous addresses, it is necessary to identify basic compound device structures (e.g. all devices on the vehicle bus) in a set of vehicles. This configuration is static and all devices inside know the identification of the set of vehicles (e.g. UIC-Identifier) assigned by the railway operator. Each device on the vehicle bus has a unique MAC address.
The internet has a hierarchical structure. Such a hierarchy is also found in trains with vehicle bus and train bus and via the radio link up to the operators intranet.
To assign the appropriate addresses, there exist two mechanisms: Dynamic Host Configuration Protocol (DHCP) and Dynamic Domain Name System (DDNS). These services reflect the railway requirements with quickly changing configurations: trains are only few hours in operation and may couple and decouple.
For the static configuration in a set of vehicles, DHCP and DDNS may play the role of a preconfigured central address server. The services should be located on the train bus / vehicle bus gateway. The addresses on the train bus are dynamic, because they change with a change of the train configuration. DHCP and DDNS should be located on the radio link gateway (RoGate). Some considerations for the address assignment are needed, if trains have more than one radio gateway. It is necessary, that only one radio gateway will assign addresses. But all radio gateways may be used for communication.
A train gets its address from a DHCP server on the ground station (RoGS). Then the train registers its address on the ground DDNS. Using these mechanisms, a device in a train is addressable with the address hierarchy operator.train-name.operation-id.device-id.
For security reasons, it’s important to say that the access to the train must be allowed only by the RoGS, any access request need to be authenticate and authorised.
To increase the robustness of the addressing system, a lease based mechanism with a specific time to live should be used. If a train does not renew its lease in time, all occupied resources are released and are available again, the lease mechanism is a foundation of Jini technology.
As stated previously, the RoGate represents the "train" in the network. Usually, the train need to be logged-in and out in the network. If we analyse the figures about the quantity of trains involved daily, the maintenance of this process is very resources consuming. Rather than requiring explicit installation and removal from the network, this kind of network environment calls for components that are able to join and leave the network in a far more ad hoc fashion. A suitable way to solve the problem and perform the task is using Jini technology. We are moving to a world where the Internet is used as an infrastructure for embedded computing (6).We begin to access the Internet with mobile and hand-held devices; and as we use the Internet for activities such as environmental monitoring and automated remote diagnostics, the network environment will be made up of components with these characteristics:
In particular, the heterogeneity and transient nature of the participants on the edge require different approaches than previous networks, which had relatively homogeneous participants and a somewhat stable infrastructure.
The use of Jini technology simplifies the development of distributed systems because Jini forces distributed systems developers to deal with the network in early stages of development. Jini is not just a programming library to implement distributed systems, but a new paradigm for distributed system development. Using Jini, distributed systems developers can automate the, usually tedious, configuration process of such systems. Jini enables the search for particular services based on complex attributes. Jini provides self -healing communities of services as it uses the concept of leases, further details can be found in (3) and (4).
The author offers his thanks to all the TrainCom partners, in special way to the Team of Workpackage 3 - Architecture of the TrainCom Communication system.