di Andrea Gatti
Questo articolo è stato pubblicato in occasione della “Wireless Design Conference 2002” London 15-17 Maggio 2002
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
INTRODUCTION
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 on-board network like TCN or FIP or possibly another on-board bus solution;
- the radio link (based on GSM, or GSM-R, when available) between train and ground
- the higher level protocols and languages of Internet (TCP-IP, HTTP, XML, JAVA, JINI and others), for message routing, formatting and delivery;
- the interface between on-board network and the Internet world;
- the ground infrastructure (Communication Servers, Name Servers, Application Servers), to support the needed communication and application services.
Communication Components
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 Table 1 are the Service profile defined in IMT-2000.
| Service | Bandwidth (kb/s) | Transmission mode |
| High interactive multimedia | 128 | Line-switched |
| High interactive | 2048 | Packed-switched |
| Medium multimedia | 384 | Packed-switched |
| Switched data | 14.4 | Line-switched |
| Simple messaging | 14.4 | Packed-switched |
| Voice | 16 | Line-switched |
The choice of the communication system between ground and train at wireless level affects heavily :
- Offered services and their characteristics;
- Quality and reliability of these services;
- Security and reliability of the connection;
- Separation of information to send at level : identifying/diagnostic/informative data;
- Bandwidth of channel communication and real operating conditions;
- The IP–addressing, Mobile IP and GSM numbering as method for train identification (related to ground-segment / service provider).
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:
- Data Structures and models must to be compatible with different users and different platforms and technologies;
- Languages and protocols must allow easy communication between several software programs and several hardware modules.
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:
- DBMS (Database Management System) that is the core of the RoGS
- Some user servers which implement the different services.
- Some user interfaces one for each user type/class that allow the access to DBMS database.
- A Radio Link unit that performs the communication between the RoGS and the RoGate installed on trains.
All data are implemented using XML language, a proposed architecture, from a ground-level point of view is represented in the Figure 2.
Deploying services
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.
| Coverage | Scale | Technology |
| Personal Area | Cubicle, Room, Vehicle | Bluethooth, IR, FM etc. |
| Home Area Public hotspot | Workshop, Building, Apartment Office | Home RF, WDSL, WLAN, UWB, etc. |
| National & International | City, Country | GSM, GPRS/EDGE, UMTS< |
| Global | World-wide | Satellite< |
- GPRS based on GSM technology will provide extensive coverage for packet based mobile data services by late 2001, but is limited in terms of bandwidth.
- UMTS will offer more spectrum and efficiency, particularly with respect to capacity. However, UMTS will initially be available only in urban areas due to the high costs of implementation and rollout time required, as over 70 networks need to be set up over the next three years in Europe.
- Public WLANs will provide users with broadband access in specific hot spots such as railway stations or airports. For example, Telenor Mobile is planning to offer its customers up to 11 mbps access to corporate intranet and internet services via WLAN.
- Bluetooth is providing a private area network (PAN) technology for peer-to-peer applications such as m-payment, data exchange and cordless synchronisation.
In term of services, the requirements are defined by the International Mobile Telephone Standard 2000 (IMT-2000) and listed in Table 1.
The service’s requirements in terms of bandwidth are related to the size of the information needed per session, see Figure 3 .
The “Medium Multimedia” data rate (Table 1) 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.
| Environment | Maximum rate kbit/sec | Mobile maximum speed km/h |
| Indoor | 2000 | 10 |
| Suburban outdoor | 384 | 120 |
| Rural outdoor | 144 | 500 |
Addressing Schemes
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.
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:
- Many will have small, inexpensive processors with limited memory and little or no persistent storage.
- They will connect to other computing elements without the direct intervention of users.
- Often, they will be connected by wireless networks.
- They will change rapidly, sometimes by being mobile, sometimes by going on and offline at widely varying rates. Over time, they will be replaced (or fail) far more rapidly than is now common.
- They will be used as a source of information, often sending that information into the centre of the network to which they are attached.
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).
Acknowledgement
The author offers his thanks to all the TrainCom partners, in special way to the Team of the Workpackage 3 – Architecture of the TrainCom Communication system.
ACRONIM
DDNS Dynamic Domain Name System
DHCP Dynamic Host Configuration Protocol
FIP Factory Information Protocol
MNO mobile network operator
MVNO mobile virtual network operator
PAN Private Area Network
Pms Person months
TCN Train Communication Network
UIC Union International des Chemin de Fer
References
- The TrainCom project website
- The ROSIN project
- Remote Monitoring of Railway Equipment Using Internet Technologies – T. Nieva, A. Fabri, A. Wegmann – Technical report No. DSC/2001/18, April 2001.
- Nieva, A. Fabri, A. Benammour. “Jini Technology Applied to Railway Systems”. Proceedings of the 2nd International Symposium on Distributed Objects and Applications – DOA’00, Antwerp, Belgium, September 2000
- IEC 61375-1 – Train Communication Network
- Virtual Organizations, Pervasive Computing, and an Infrastructure for Networking at the Edge. Sun Microsystems white paper. http://www.sun.com/jini/whitepapers/
- Traincom – Integrated Communication System for Intelligent Train Applications