Applying a TETRA technology in a CBTC system to

Applying a TETRA technology in a CBTC system to transfer voice and critical data 1. Vieira, Paulo – Train Control Systems Expert (MRS Logística S.A.) 2. Fonseca, Sérgio - Senior Signaling Systems Engineer (Alstom Brasil) 3. Arroyo, David - Senior Telecommunications Engineer (Secure Networks Oy - EADS)

Summary: MRS Logistica S/A, a large Brazilian heavy haul railroad that connects the three largest Brazilian cities - São Paulo, Rio de Janeiro and Belo Horizonte - has started to deploy in 2007 a recently acquired CBTC (Communications Based Train Control) system, replacing existing signaling and control systems that were based on a CTC (Centralized Traffic Control) architecture. One of the most critical issues of any CBTC system is how the communication system, where the signaling data relies on, will be designed and how it will actually behave. This issue becomes even more critical when voice and non-vital data will have to share the same resources as it’s been designed in the MRS´s CBTC system. This paper presents how the Tetra technology has been applied in the MRS´s CBTC system, providing digital voice and data services, by optimizing the use of PDCH (Packet Data Channel), TCH (Traffic Channel) and MCCH (Main Control Channel) resources to carry voice, vital signaling, and other non-vital data to/from trains and other systems along the railroad line, to the control center. The whole solution includes issues as radio coverage study, and its validation on field, data and voice traffic study, interfaces from Tetra system to all external systems. Finally it's included a debriefing about factory / field tests and system deployment. Index Terms: Communication System, CBTC, TETRA technology, Heavy Haul operation. 1. INTRODUCTION MRS Logística is a concessionary that controls, operates and monitors the Brazilian Southeastern Federal Railroad Network, formerly owned by the government, as a branch of the National Railroad Network. The company has been in operation in cargo railway transportation since 1996. It interconnects the states of Rio de Janeiro, Minas Gerais and São Paulo. The company has 1,674 km of railways that make the transportation process easier in a region that concentrates approximately 65% of Brazil's gross domestic product and is home to the largest industries in the country. Through MRS' railways you can also reach the ports of Sepetiba and Santos (the most important in Latin America). Figure 1 below shows the location of the MRS Logística network.

Figure 1: Simplified Map of the MRS railroad lines

1.3

The MRS´s CBTC system

The MRS's CBTC system, known as SIACO (Integrated Operations Control and Automation System) is equivalent to ETCS (European Train Control System) Level 2, even though it’s not fully compliant to ETCS. Figure 2 below depicts the system and its components.

Figure 2: Architectural diagram of the SIACO System

• Integrated Operational Control Center (CCOI, in Portuguese). Responsible for the integration of the information coming from all systems involved with the railroad traffic control operation and the corporate systems. • Signaling and Control System (SSC, in Portuguese). Responsible for the signaling system of the railroad. It is composed of a Safety Logic Subsystem (SLS) component in the Center side, and Object Controllers (OC) in the field. In the final system configuration, all the signal aspects of the existing CTC system installed along the line will be removed as the new signaling system interacts with the onboard component of the locomotives. • Onboard Control System (SCB, in Portuguese). Responsible to provide a human machine interface (HMI) - essentially a conventional computer device (OBC – Onboard Computer) that allows Train Conductors to interact with the system. The SCB shall also guarantee the safe movement of trains through a vital component the ATC (Automatic Train Control) - that enforces train movements according to the SSC authorizations. The SCB also provides non-vital features that implement operational procedures and monitors train operations, increasing the

efficiency, safety and predictability of the railroad operation. Another component of the SCB - the Event Recorder - is responsible to acquire locomotive data in real time for telemetry purpose. • Wireless Data and Voice Communication System (STT, in Portuguese). Responsible to provide wireless data services along the entire railroad. The STT must guarantee sufficient coverage, reliability, and availability levels so that, efficient dispatching and monitoring of circulating trains can occur. The MRS’s fiber optic backbone provides the physical means of communication along the entire railroad network. Radio Base Stations (RBS) installed along the line provide the communication coverage. The STT provides voice communication as well. Even as reliance on voice communication diminishes, in some cases, the voice system will still continue to be used in contingency conditions and as a complementary communication in the railroad operation. The SIACO system is being developed by three main providers: • Alstom Brazil – providing the CCOI, SSC and SCB (OBC and ATC); • EADS (European Aerospace Defence System) – providing the STT and Radios; • Accenture-Atan – providing the REJE. 2. REQUIREMENTS FOR COMMUNICATION SYSTEM

THE

The requirements for the communication system were defined by MRS from the point of view of final users. When defining the requirements, there was a concern to not tie them to a specific solution or technology, so the providers could be able to adopt the most suitable solutions or technologies, since satisfying the user requirements. The main user requirements included coverage needs, data and voice demands. Other requirements like availability, performance, frequency plan, hardware / software requirements were also defined; however, those won’t be explored in this paper. 2.1

Coverage Needs

The MRS network crosses a complex topography area, varying from flat territory to areas with mountains and long sequence of tunnels. Since SIACO uses a fixed block architecture, MRS

realized that it would be possible to design a solution that wouldn’t require a full coverage of the network, since there was coverage enough in the points considered necessary for a fixed block architecture. In this approach, for instance, it was not exactly necessary to provide communication in the middle point of a track circuit, since the system is aware of such condition. This would allow to keep the system operational even in areas where the topology is complicated, without the need to install specific resources only to guarantee full coverage. Following this principle, MRS established the following requirements regarding coverage needs: • no need for coverage inside tunnels; • at least 95% of coverage of all network, excepting tunnels; • dark territories shall not exceed 150 meters; • dark territories shall be apart from each other at least 3,000 meters; • coverage at all notable points (Track Circuit limits, grade crossing location, derailment detector location); • coverage inside all yards. When MRS defined the requirements listed above, it took into account essentially operational needs, so, for instance, MRS accepted that trains circulating inside tunnels would not have communication as no other train would be allowed to enter the same tunnel until the train releases it – tunnels were considered a single occupation block. This premise would eliminate the need for specific communication resources inside tunnels, which are usually very expensive. However, the application would have to know how to handle this condition, “mapping” the location of tunnels and understanding that no communication would be available along those areas. The application would also have to know how to handle properly the transition from/to dark territories, taking into consideration, for instance, that trains would still be moving after leaving a tunnel, until the communication is reestablished. 2.2

Data Communication Requirements

MRS also specified some data communication requirements considering only operational needs, from the point of view of users in the train (Train Conductors) and at the Control Center (Train Dispatchers, Supervisors, Maintenance staff). In fact, MRS actually specified the information that should be sent from the Center side to the Train and vice-versa. One example is the information that

CCOI sends to the train describing all the activities it shall perform in an operation in a yard. The data transmission demand from the Center Side to the Onboard was the following: • Conditions in the vicinity of current train position (other trains, temporary speed restrictions, track interdictions) – every 5 seconds; • Operational Alarms – whenever these occur (very rarely); • Train Sheet – when the train is created and whenever it is changed; • Train Activity Plan – when the train is created and whenever it is changed; • Text Messages The data transmission demand from the Onboard to the Center Side was the following: • Train Conductor Login / Logout; • Alarms (from REJE and the SCB itself); • Train Positioning – every 5 seconds; • Event Recorder data (full download from REJE); • SCB Log download; • Real-time Remote Telemetry; • Text Messages. MRS also requested remote download capabilities for the onboard software like a new system or new database version to avoid a manual deployment that would be hard and complex to accomplish in all the locomotive and service unit fleets. MRS did not specify application requirements, like the number, frequency and contents of vital message exchanged between the signaling system (SSC) and the onboard vital system (ATC) as those would depend on the specific architecture of the solution a provider would have, however, as there were safety, operational and performance requirements, the provider would have to design an architecture with specific messages and protocols to satisfy them. 2.3

Voice Communication Requirements

To define the Voice Communication requirements, MRS took as a starting point the voice demands that were in use with the existing VHF Voice analogic radio system. However, as many of the voice communication actually happen when some exceptional operation happens (like when approaching trains) and those

would be integrated with the new system using the onboard computer system to provide guidance to Train Conductors instead of voice communication, there was a great expectation to reduce dramatically the voice communication demand in those cases, which were, in fact, the majority of the cases. The railroad operation would still demand essentially four operational groups: • Train Circulation Group: it’s the group where Train Conductors talk to Train Dispatchers regarding Train Circulation issues; • Train Maintenance Group: it’s the group where Train Conductors talk to Maintenance staff about problems with the train (essentially locomotive problem issues); • Railroad Maintenance Group: it’s the group where Maintenance staff in the field talk to Maintenance staff in the Center Side about issues regarding the railroad maintenance in general; • Yard Operations Group: it’s the group where Train Conductors talk to Yard staff regarding operations inside yards. MRS requested that the system should be able to provide simultaneous conversation of all the existing groups. 3. SYSTEM APPLICATIONS (VITAL AND NON-VITAL) 3.1

Vital Application Message Exchange

The signaling related components of the Alstom architecture uses vital hardware and software at the Center Side and at the Onboard. At the Center Side, the signaling system (SSC) is composed of three processors in a two out of three voting schema communicating with the onboard system (ATC) that has two processors in a two out of two voting schema. Each SSC processor sends periodically (every 10 seconds) one vital message to each vital processor of the ATC. Each ATC processor also sends periodically (every 10 seconds) one message to each SSC processor. Figure 3 below illustrates the vital messages sent from a SSC processor (SSC Processor 1) to the ATC processors and the vital messages sent from an ACT processor (ATC Processor 1) to the SSC processors.

Figure 3: Message Exchange between Vital Components

The system uses a 32 CRC (Cyclic Redundancy Check) mechanism in all vital messages. In case the integrity of messages is not correct, the Vital Processors discard the message, without requesting a retransmission. The SSC and ATC applications have Timeout mechanisms used in different situations that allow the system to keep operational in case some messages are somehow lost or are violated. 3.2

Non-Vital Application Message Exchange

The CCOI also exchanges messages with the OBC – non vital messages that satisfy the user requirements as specified by MRS. The system implements a BAC protocol for the messages exchanged. Depending on the type of usage, the application may request a guaranteed delivery (waits for an acknowledgement) and retry mechanisms can also be applied. For instance, when an instruction to revoke an authorization for a special operation is sent from CCOI to OBC, there’s need for a guaranteed delivery. In other cases, there’s no need to guarantee the delivery, like periodical data that refreshes some information in the screen (messages lost are updated in the next refresh). 3.3

Event Recorder Data Download

The Event Recorder Download is actually divided in three different types of application:

• Alarms and Warnings: these are messages sent in real-time (no delay) from the Event Recorder when some conditions are reached when receiving data from sensors, like when an engine has a high temperature; • Full Event Recorder Download: the system also downloads all the Event Recorder data while trains are moving. As there’s no need for realtime analysis of those data, it’s been decided to “pack” the data and send it up at every fifteen minutes, which also reduced the overhead of the communication protocol. 3.4

duplex frequency pair). Spacing between adjacent carriers is 25 kHz. • Efficient features for emergency and safety networks, like: group communication, emergency calls, direct mode, priority scheme, reliable performance, fast call setup. • Advanced data communication services: TETRA provides data transfer services allowing combined use of voice and data. • Security: TETRA supports encryption of speech, data and signalling on the radio path and endtoend encryption for voice. TETRA also offers user authentication.

Logs, Alarms and Telemetry 4.2

All the Logs and Alarms generated from the SCB components are also sent up for operational and maintenance usage. The SCB generates ATC Logs (events from the Vital component and interfaces) and OBC Logs (events from the OBC itself and its interfaces). The system also provides a special function - RealTime Telemetry - that can be remotely turned On/Off by a Maintenance Technician at the Control Center. This function can be used, for instance, if a Maintenance Technician is notified about a suspicious behavior of a locomotive that is running in a train and wants to check the health conditions of the locomotive in real-time, monitoring some variables like temperature, pressure or any other. Once the function is set “On” for a specific locomotive and specific variables are selected, the Event Recorder starts to send periodically (at every 10 seconds) the values of the variables. According to the MRS operational needs and also in order to not congest the data traffic, it’s been established that the user can select up to five locomotives and five different variables for each locomotive to be sent. 4. THE TETRA SYSTEM 4.1

The TETRA Standard

TETRA stands for Terrestrial Trunked Radio. It is a set of open standards developed by the European Telecommunications Standards Institute (ETSI). TETRA specifies a set of open interfaces and services for new professional mobile radio systems. The TETRA standard offers the following key benefits: • Channel efficiency: four channels per carrier (a carrier comprises a single uplink/downlink

System Architecture

The EADS solution for TETRA is based on two main objectives. Firstly, the EADS TETRA System is in accordance with the TETRA standards for combined voice and data. Secondly, its design is based on a comprehensive analysis of user requirements. As a result, the EADS TETRA System meets critical user needs and makes operating in a PMR network easier. Since one of the SIACO's main goals is to reduce voice communications between trains and control & supervision operators (CCOI) in the MRS railway network, in order to increase the amount of "on the road" trains in the railway network. Therefore, STT's aim is to perform mostly data communications. Nevertheless, few voice communications are necessary and will be available in the network. Network elements and interfaces are listed and briefly described below: • DXTip: The DXTip switches speech and data between the network users, both radio users and dispatchers. It also allocates speech items in group communication and handles priorities. • TBS: TETRA Base Stations (TBS) and radio terminals provide wireless and mobile communication in the EADS TETRA System; • DWS: The Dispatcher Workstation (DWS). The DWS performs communications with subscribers, and management of subscribers, groups, dispatchers, and organizations; • TCS Server: The TETRA Connectivity Server (TCS) provides a highlevel application programming interface (API) for accessing speech and data services. • AKDC: Authentication Key Distribution Compact (AKDC)

• DM2: DM2 provides interface towards external analog systems, such as a conventional base station, and analogic voice recorders. Figure 4 below shows the architecture of the MRS’s TETRA network.

•

Packet Data Service will be used only by the Data RT.

Basic IP Packet Data Service: allows the radio subscribers to use IP features within the network and with on-board applications; OBC, ATC and REJE. These communications are performed through a Traffic Channel (TCH) used for PD feature, Packet Data Channel (PDCH). 4.4

Data Traffic Study

Data traffic study target was to find out the optimal balancing between data communication services. It means, to distribute the message load between Short data service and Packet data service, by granting:

Figure 4: MRS TETRA Network Schematic Diagram

4.3

System Configuration

The EADS TETRA System provides data message services for trains according to the following issues. Average train consist: The average train consist is composed of three Locomotives, being the first known as “Leader” and the remaining as “Remote”, each locomotive, either Leader or Remote, is equipped with two EADS Tetra Radio Terminals (RT); one of them will be used for Voice and/or SDS messages sending (Voice RT) and the second one will be used for Packet Data transmission (Data RT). Status message service & Short Data Service: These data services are usually sent through MCCH. With the TCS Server interface Application Programming Interfaces (API), through which the CCOI and SSC applications can access these data message services of the Tetra system. SSC and CCOI can send and receive Status Messages and SDS. The OBC sends and receives data messages through a computer connected to a radio unit (Peripheral Equipment Interface, PEI). Regarding the usage of the communication services by the two locomotive radio terminals, it has been designed the following configuration: • Voice and SDS services will be used only by the Voice RT;

• A safe SIACO performance; • An optimal performance of STT system; • Avoiding complex software design in the applications. Hence, radio network capacity is therefore, divided in two main parts: Main Control Channel (MCCH) dimensioning Each TBS has an MCCH that is used for signalling between MSs and the SwMI when the MS is not engaged in a call or transferring packet data. The MS cannot listen for signalling on the MCCH while it is engaged in a call or transferring packet data. Traffic Channel dimensioning; PDCH and Voice Channel (VCH) Capacity planning provides information on the number of channels or TETRA base stations needed in each cell in order to achieve a given blocking probability. Capacity planning is based on the traffic model and the radio coverage plans. The traffic capacity in a cell is calculated in Erlangs with a certain blocking probability. This, in turn, provides the number of channels needed. Since traffic channel dimensioning is based on Erlang's formula, the Average Call Duration (ACD) calculation is significatively relevant. In order to simplify the ACD calculation, since, it represents a stochastic process with non equi-probable variables, the following premises were considered: The most "resource demanding" messages are the periodicals, with a period = 10s, and an average

size of 188 bytes, both directions, in addition to another message whose period is 25s, and size is about 5kb. Since, the payload time duration of the uplink/dnlink periodic messages is different, then a payload average time has to be considered, in order to estimate the payload average time duration, the message whose period is 25s is fragmented and segment size is 188 bytes and a period of 10s. In this way, the ACD calculation considers: 4 uplink and 4 downlink periodical messages, randomly distributed within a period of 10s (Fig. X). The Payload Average Time (PAT) is calculated as follows: PAT = (M1 + M2 + … + M8 ) / 8, where Mn (1 ≤ n ≤ 8), is the payload transmission time for every message + 48 bytes IP header.

Since there is a forecasted growth of the railroad production, the amount of trains running in the network will increase compared to the current number, so, an extrapolation rate was calculated to forecast the number of trains in circulation in a 10 years projection. Through the sampling information a real picture of the current train distribution by railway section was obtained, then, by applying the extrapolation rate to the railway sections and finally to the each BS coverage area belonging to them. Critical Nodes, Shunting Yards, and Section Segments of the Railway They were defined according to operative specificities, the critical nodes and section segments of railway, where it is expected the highest amount of trains (circulating and stopped in shunting yards), under the coverage area of specific BSs. The current and extrapolated amounts of trains in critical nodes and section segments of railway, were provided by MRS, and the train distribution among the BSs which are involved either node or segment section or shunting yard, was done according to the train distribution percentage by BS. Estimated amount of trains by BS coverage area The amount of trains by BS coverage area is estimated by distributing the extrapolated amount of trains of a given section, in accordance with the radio coverage of each BS.

Figure 5: Random distribution of Up/Down link messages within 10s period

Different cases of message distribution were defined, such as; a packet data instance containing several messages, a packet data instance containing only one message, a packet data containing simultaneous uplink/downlink messages, as well as the combinations between them. Finally, a very important topic within the traffic study is the calculation of the train distribution by BS, which is based on the following information: • definition of railway sections - Railway is divided in several sections. • current amount of trains and their distribution by railway section,

5. CURRENT STAGE OF DEPLOYMENT OF THE SYSTEM

THE

As of March of 2009, the SIACO system is operating in CBTC mode in a 40 kilometers long track, located at the most congested area of the railroad network. The system runs in CBTC mode in few trains (four to six daily) and there are three Base Stations supporting the operation of those trains along this piece of the track. The project deployment is in a period of “system stabilization”, where the behavior of the system is being evaluated and performance/availability indicators are being measured as well as improvements are being developed. Real-time telemetry, Remote System Download and a few other minor Non-Vital data exchange are not yet deployed, but all the Vital, Alarms, Logs

and most of the Non-Vital messages are already being exchanged. So far the system has shown to be very stable and reliable, but still requiring a few corrections and adjustments in the software to become fully operational. It’s expected that soon the system will be released for full commercial operation.