Performance simulation study of a WiMAX based telecom ... · PDF filePerformance simulation study of a WiMAX based telecom architecture for train control systems ... is GSM-R, designed

Performance simulation study of a WiMAX based telecom architecture for train control systems

Marina Aguado, Eduardo Jacob, Puri Saiz, Marion Berbineau M. Higuero, I. Estefania, O. Onandi INRETS- LEOST University of the Basque Country Villeneuve D´Ascq (France) Alameda de Urquijo S/N Bilbao (Spain) Abstract: A great amount of the research being carried out in the transportation industry, and motivated by public administrations, is focused on safety and sustainability issues. European Union has encouraged the interoperability between the different European railway signalling systems with the design and standardization of the ERTMS (European Rail Traffic Management System). The communication technology that supports ERTMS is GSM-R, designed to support high mobility scenarios (up to 500km/h). Nevertheless, this technology presents the same data communication characteristics as 2nd generation mobile GSM. In heavy load situations, such as complex yards or busy junctions, communication flows have presented bottlenecks for new high priority connections. At the same time, off railway environment, there are many standardization groups, IEEE and IETF, focused on mobilizing Internet by standardizing new access technologies and protocols. Some of the research working groups are related to technologies such as 802.11p, 802.16e [1] or 802.20. In this paper we present the performance results obtained when deploying an ETCS application on a 802.16e-WiMAX based telecom architecture. The same QoS KPI [2] demanded to GSM-R in EIRENE specification have been evaluated.

Introduction

The possibility of using technologies with high data rate, low latency and high speed support, has allowed what it is termed ITS (Intelligent Transportation Systems) New Generation. Its main aim is safe operations. Nevertheless, this high mobility scenario, such as the railway scenario, still demands a great amount of research work. In previous research works [3], it has been identified how, traditionally, progress in mobile telecommunications technologies have allowed railway telecommunications technology to go a step forward and, in the same way, the railway control systems. We have also concluded that B3G technology represents a new revolution in railway communication systems, more specifically because these technologies have been designed to support high speed, low latency, high transmission data rate, quality of service (QoS), and security protocols that result in the capacity to support broadband applications in real time. Applications such as remote control of the train, real time access to information available from all the train sensors, thus monitoring safety aspects and train health, video surveillance, including identification and detection in real time of behaviors that may affect passengers security, can be supported in a network architecture based on these technologies. All this set of services and applications will enable a safer railway operation, which at the same time will allow an increase in line capacity by supporting moving block techniques. Our research work aims to provide a contribution to the railway transportation safety and security by presenting a network architecture (network topology and protocols) based on the new wireless broadband digital communication technologies. This proposal can be considered as an attractive alternative for emerging countries. The methodology used to validate the architecture proposed as a candidate to support ETCS traffic consists of analyzing its behavior when compared to the EuroRadio quality of service requirements demanded to GSM-R communication. In order to do that, a discrete event network simulation system has been used [4]. A real railway network has been characterized in the simulation tool and then signalling traffic data as well as other

value added services with low latency and broadband demanding data traffic have been properly modeled. Balise reader behavior has also been properly characterized in the tool. This paper is structured as follows; firstly the European Rail Traffic Management Control System (ERTMS) architecture (block diagram and components description) is introduced. In second place, the ETCS application routines modeled over a network discrete event simulator are detailed. Then the simulation platform is validated comparing the communication message interchange with real ERTMS traffic. Next section consists of detailing the proposed communication architecture description (network topology and protocols). And finally, the results obtained when deploying this application on a WiMAX based deployment, will be compared to the QoS parameters demanded to the GSM-R communication system within the EIRENE specification.

The ERTMS System & EIRENE Requirements

In 1994, the European Union launches the European Railway Traffic Management System - ERTMS, as the standard for signaling and traffic management systems in order to provide interoperability along the entire European railway network; solving, this way, the technical and operational diversity within the European railway systems. ERTMS consists of two blocks: ETCS (standardized automatic train protection system as well as a track-to-train communication protocol) and GSM-R (standardized Radio Digital communication system used to exchange data and voice between trackside and onboard). GSM-R is the bearer for ETCS traffic and its architecture is based on the GSM phase2+ norm and some specific functions known as ASCI (Advanced Speech Calls Items) features such as functional addressing, voice group calls... Within ERTMS legal framework and European specifications, the UIC project EIRENE [5,6] identifies the GSM-R necessary requirements to cope with the ETCS traffic needs, with special emphasis in the QoS parameters demanded. This specification defines the functional and systems requirements specifications necessary to ensure that core railway functionality is provided. EIRENE defines the requirements for an EIRENE network and the performance levels which are to be achieved. The aim is to provide interoperability between networks and a consistent level of service. These QoS KPI parameters are detailed in Table 1.

QoS Parameter Value

Connection establishment delay of mobile originated calls (CED)

< 8.5s (95%) ≤10s (100%)

Maximum end-to-end transfer delay (30 byte data block) (TED) Average end-to-end transfer delay

≤ 0.5s (99%) ≤ 400 to 500ms

Network registration delay (NRD)

≤ 30s (95%), ≤ 35s (99%), ≤ 40s (100%)

Handover effective time (between BSs)

> 300ms

Transmission Data Rate

>= 2.4 Kbps.

Table 1: QoS KPI requirements for EIRENE networks.

Modelling ETCS: Data traffic characterization and routines

ETCS main features consists in supervising continuously train movements, informing and supervising the driver, allowing spot, semi-continuous or continuous track to train communication. The ETCS level 2 provides full ATP supervision and continuous track-to-train transmission via GSM-R. Fixed Eurobalizes are used as reference points and the MA (Movement Authority) from RBC (Radio Block Center) to train are sent via GSM-R. In order to validate our approach, ETCS data traffic may be borne satisfactorily over an other different communication architecture than the GSM-R architecture, it has been necessary to properly characterize and model this ETCS data traffic. The message exchange described in the ETCS standard specification [7] together with the message trace from a commercial ETCS level 2 implementation have allowed us to identify the deterministic rules that govern the message exchange between the RBCs and the train. The following routines have been identified: a. Connection established: This routine takes place every time a new train initiates its mission and during the train handover procedure between RBCs..

Message 155: Initiation of a Communication Session Message 32: Configuration Determination Message 159: Session Established. The train confirms that the session is correctly established and initiates the communication with the RBC just after receiving a 32 message.

b. Validated train data: This routine takes places every time the train connects to a new RBC and after the train passes through the first balise group.

Message 129: Validated Train Data Message 8: Acknowledgement of Validated Train Data Message 146: Acknowledgement

c. Position Report (PR): Each time a train passes through a balise group a message is launched from the train to the RBC reporting balise group identification and consequently train position.

d. Movement authority (MA): The RBC sends the movement authority to the train and then this message is acknowledged by the train.

Message 136: Position Report

Message 3: Movement Authority Message 146: Acknowledgement

e. Movement authority request (MAR):

This routine is initiated in the train. In our simulation we launch it periodically. The frequency introduced is that one so that the total number of messages matches with the one provided in the trace file.

Message 132: Movement Authority Request

f. General message (GM): This routine is initiated in the RBC every 15 seconds sending a 26 message. The train then answers back with an ACK message.

Message 26: General Message Message 146: Acknowledgement

g. Disconnection:

Rule: This routine takes place whenever the train ends its connection to an RBC: end of mission or RBC handover procedure.

Message 156: Termination of a Communication Session Message 39: ACK of Termination of a Communication Session

The RBC handover routine process has also been identified and implemented. The previously detailed routines generate most of the signalling data traffic exchanged between the RBC and the train. There is also some extra signalling data traffic related to operational exceptions (not within the scope of normal operation) that has not been considered in this first transmission analysis study. Once these main ETCS routines have been validated by ERTMS system providers, our next step has been to model this application within the network simulation tool. Opnet Modeler Simulation, and more specifically its ACE Whiteboard tool, has been used for

this purpose. When creating this ERTMS application, it is necessary to define the tiers that would participate in the exchange message and that, later on, will be identified as nodes within the simulation scenario. The messages exchanged between the different tiers have been properly modeled (size and HEX format) as well as the existent dependency between them and the logical sequence that these messages follow. The message processing time in each tier has been obtained from the real trace log.

Figure 1: Detail on the ETCS modelling proccess. This ETCS data traffic, normally borne by the GSM-R deployment, will be deployed on a WiMAX based architecture in our study.

ETCS model validation

The modelled application has been validated following two approaches. In the first approach, the modelled application when running on the simulation platform generates a message log (Table 2). This log has been compared to the real commercial data trace (Table 3). As it can be observed, in the following tables, the message sequence is the same one. When compared the full log, some small differences can be appreciated since the MA messages in the created application are sent periodically and in the real one they depend also on the CCO dispatcher and external variables.

Time Position Source Destination Message Type Id Bytes

-------------- -------------- -------------- ---------------- ------------------------------- ----- -------

122.635806 1.530025 Wimax_train RBC 0 Acknowledgement 146 22

126.235200 1.650005 Wimax_train RBC 0 Position Report 136 32



136.735200 2.000005 RBC 0 Wimax_train General Message 24 18





151.735200 2.500005 RBC 0 Wimax_train General Message 24 18





Table 2: Simulation message log.

Table 3: Real message log from commercial ERTMS.

The second approach to validate the application is to compare the total data load generated within a 40 minutes run with the train at 120 km/h speed (Table 4).

ETCS real data trace

(40 min)

ETCS simulation data

(40 min) Time (sec) 2.400 2.400 Nº Message sent 1.017 981 Nº Bytes aplication 31.479 29.958 Message/min 25,42 24,52 Bytes/message 30,952 30,538 Bytes/sec 13,11 12,48

Table 4: ETCS real data trace vs ETCS simulation data.

The data load is very similar. The number of messages sent is slightly different due to MA messages forced periodicity as previously identified and, in second place, due to the RBC handover procedure. In actual systems, this handover procedure takes longer due to the existing RBC communication over the backbone. This has not been considered in the simulation environment. So, in the real RBC handover routine several position messages will be duplicated. The real application when deployed on the GSM-R architecture generates 1.1 Mb total traffic load. The load generated in the simulation platform is lower. The main reason is that the headers involved in the protocol stack represents lower data load. This architecture offers then a higher performance. The next Figure 2 shows in the first graph, the traffic sent by the train and generated by the ERTMS application. The second graph represents the load already encapsulated over TCP/IP and, in the third graph, the traffic sent on WiMAX, when CRC and ARQ have been implemented.

Time Position Speed Source RBC Id Type Bytes 5:10: PM 866 TRAIN 2 146 Acknowledgement 22 5:10: PM 837 70719,5 120 TRAIN 2 136 Position Report 32 5:10: PM 902 70886,2 120 TRAIN 2 136 Position Report 32 5:11: PM 838 71052,8 120 TRAIN 2 136 Position Report 32 5:11: PM 682 RBC 2 24 General Message 18 5:11: PM 867 TRAIN 2 146 Acknowledgement 22 5:11: PM 838 71219,5 120 TRAIN 2 136 Position Report 32 5:11: PM 886 71386,2 120 TRAIN 2 136 Position Report 32 5:11: PM 838 71552,9 120 TRAIN 2 136 Position Report 32 5:11: PM 682 RBC 2 24 General Message 18 5:11: PM 868 TRAIN 2 146 Acknowledgement 22 5:11: PM 199 71652,9 120 TRAIN 2 136 Position Report 32 5:11: PM 949 71719,5 120 TRAIN 2 136 Position Report 32 5:11: PM 839 71886,1 120 TRAIN 2 136 Position Report 32

Figure 2: ERTMS traffic at different layers.

Proposed WiMAX-based Network Architecture

Figure 3 represents a scheme of the proposed network communication architecture. This architecture, already published in previous research works [3], consists of a hierarchical network architecture based on ASN WiMAX architecture (802.16e), single carrier SC and OFDMA links. This access technology has been selected partly due to market maturity reasons. It has also been taken into account that in the new physical interface specification (802.16m specification) higher speeds upto 500 km/h have been considered.

Figure 3: Details on proposed architecture over simulation scenario. Network Topology

The proposed architecture includes three different hierarchical layers: the wireless backbone network, the distribution network and the access network. The wireless backbone network is set up through the connections established by node A type equipments. This type of node has three WiMAX interfaces. Two of them are dedicated to shape the backbone network through PTP (PointToPoint) links to adjacent type A nodes. The other interface provides the connection to node B equipment, through a PMP (PointToMultipoint) link. Node A is a bridge equipment that also presents an Ethernet interface to allow the connection to the RBC equipment and to the CCO servers. The distribution network is formed by the existing links between B-nodes and the higher hierarchical layer equipments, named as “A-Nodes”. B type equipments have two WiMAX interfaces: one in order to connect itself to superior hierarchic layer Node A, and another one of the WiMAX Mobile type, so as to provide access to the mobile network. The access network is the one in charge to provide service to the mobile network. The mobile network accesses the backbone network through the WiMAX mobile link between node B and the train. The hierarchical, overlapped coverage and redundant architecture has proven to present a quite correct behavior regarding random failures in the different equipments. Simulation Scenario Description When comparing GSM and the GSM-R deployment topology, GSM generally presents a 3 sectors 120º cell topology when in GSM-R the cell consists of 2 back to back sectors and the coverage geometry is linear. In the WiMAX cell topology, it has also been considered a linear coverage geometry and fully redundant. The actual limits for GSM-R inter BTS distances are between 6 and 17km although most implementations are closer to those 6km inter BTS distance. In the simulation scenario, the backbone network consists of five type A nodes. The distance between them is 20 km. One out of two will be connected to a RBC through an Ethernet link. As a general recommendation, the control area assigned to an RBC is 40 km. This value can be modified within the custom application parameters. In the distribution network, there are 20 type B nodes, named Tipo_B_x_y, being x the type A node to which the nodes are registered. The distance between two type B nodes is 5 km. It has been determined four type B nodes for each type A node. The train describes its linear trajectory at a constant 120 km/h speed. The simulation run time is 50min. Details on Simulation Model The proposed architecture has been modeled using the Opnet Beta WiMAX model (Oct 2007 release). Regarding physical layer considerations, the model employs AWGN-based BLER curves to characterize the bit error rate stage within the global WiMAX TxRx pipeline. The multipath fading correction is based on Raleigh varying channel mode. The multipath fading is only applicable to OFDMA (SC assumed equalization in receiver). It offers support to different pathloss models (ITU and IEEE); and log-normal shadow fading. Doppler Effect is also considered and it has been recently added the H-ARQ support [4]. The backbone and distribution network links are SC links with frequency band 10GHz, bandwidth 25MHz and frequency spacing 50MHz. The access network links are OFDMA links in the frequency band of 3.5GHz and bandwidth 20MHz. Regarding the characterization of the link layer, the model just considers a hard handover with no security mechanism established. The main contributions carried out by the authors on the Opnet Beta WiMAX model are related to the construction of the ASN (bridges) nodes, an initial mobility support, and more recently, an enhanced handover algorithm. Next contributions are focused on an enhanced characterization of the transmission channel.

Deploying the ERTMS application The first step to be carried out, previous to deploy the ETCS application consists of customizing the application in accordance with railway network characteristics. For example, it is necessary to report the RBC coverage (i.e. 40Km.), the overlap between cells, the distance between Eurobalise groups, and the general and MA messages frequencies. Once the application has been fully configured it is necessary to match the tiers in the application with the nodes within the network topology. In this scenario the RBC nodes and the train are the nodes bearing the custom ETCS application profile. It is also necessary to define the transport protocol (i.e. TCP in our case) and the proper type of service (ToS) value (i.e. Reserved (7)), offering the highest priority whenever other type of data traffic is supported simultaneously. In this first scenario, the WiMAX interfaces have been configured so that the ETCS traffic employs a BE service flow.

Obtained Results

Following, some details on carried out research and results obtained. Specific statistics within the network simulator has been implemented in order to record the necessary performance indicators. Connection establishment delay (CED) This is the value of the elapsed time between the connection establishment request and the indication of successful connection establishment on the requesting side. This parameter is successfully validated if the 95th-percentile is less than 8.5s. In our simulation this parameter represents the necessary time to perform the connection established routine. In one run simulation the train has performed three connections to three different RBC while moving along the indicated trajectory. In all of them, the connection establishment delay is less than 1.4s.

Figure 4: Connection establishment delay.

Maximum end-to-end transfer delay (of 30 byte data block) (TED) TED definition is the value of the elapsed time between the request for transfer of a data frame and the indication of successfully transferred end-to-end data frame. The length of data frame shall be 30bytes. It has been created within the simulation tool a specific statistic to record this KPI. The delay introduced by WiMAX technology access is small. Figure 5 represents the downlink and uplink delay time. The maximum value does not exceed 85ms for the uplink (from the train to the node B). In Figure 6, the total end to end transfer delay is represented. The delay values from the moment the message leaves the

application layer in the sender node till it reaches the application layer in the receiver, does not exceed 0.35s. In accordance with EIRENE specifications, this parameter is successfully validated if the 95th-percentile is less than 0.5s. Figure 7 represents the probability of end to end delay in ERTMS.

Figure 5: Delay in WiMAX (DL & UL). Figure 6: Maximum Delay in ERTMS.

Average end-to-end transfer delay Figure 7 represents the average transfer delay. This average is calculated having into account the full set of message communication exchange in the simulation run. The average is between 120 and 130 ms. This parameter is successfully validated since its value is lower than the 400-500 ms demanded for GSM-R deployment. It is necessary to remark that it has not been configured a specific quality of service in the WiMAX MAC layer at this stage so the application is running over BE.

Figure 7: Prob. ETE Delay in ERTMS. Figure 8: Average ETE Delay. Handover effective time (between BSs) The mobile node or train, when following its trajectory, goes through a set of different BS (Node type B). During the simulation run, the node performs 18 handovers. The handover delay time varies between 22 and 25 ms. Figure 9 represents the handover effective time

during this 18 BS handover procedures. It can also be observed the MAC id from the actual serving base station. The highest jump corresponds to changes in node type A where the four BS node type B are attached.

Figure 9: HO Delay and serving BS id. Figure 10: SNR and Pathloss. Figure 10 represents the SNR and pathloss values. There is a clear relationship between the mobile position and the SNR value. A higher SNR value corresponds to the node getting closer to the serving BS. The handover process takes place when the SNR from the serving BS goes behind the SNR value from the neighbouring BS, taking into consideration the threshold valued configured. Transmission Data Rate

In accordance with EIRENE specifications, the transmission data rate has to be higher or equal to 2.4 Kbps.

Figure 11: Tx Data Rate with ERTMS traffic. Figure 12: Tx Data Rate with heavy FTP. This parameter is successfully validated in WiMAX access technology specifications. Figure 11 represents ERTMS data traffic. The ETCS traffic load is very low. In order to test the transmission data rate offered by the proposed architecture a heavy FTP profile has been assigned to the mobile node. This heavy ftp profile consists of the transmission

of 10 Mb. The traffic received is shown in Figure 12, reaching the 4.5 Mbps and then validating this parameter.

Conclusions

The proposed WIMAX architecture conforms with the actual trend in the railway industry for utilization of telecommunication technologies that have been proven and validated in other markets, as well as the use of standard and open technology. This fact allows the interoperability and then reduces the dependency on a single vendor. Competitive offer of equipments from many manufacturers will allow a cost reduction in the train to ground communication systems deployment as well as a higher scalability. The main benefit obtained from the simulation studies has been to validate this standard technology for train control applications in the railway scenario and identify its clear potential for implementation. The obtained results are shown in Table 5.

Table 5: EIRENE requirements vs WiMAX based Arch values obtained.

Further steps

Further steps considered within the context of this study are related to analyze the architecture behavior with additional data traffic (such as voice services) or even traffic coming from operational complementary services such as video transmission and maintenance data transmission for surveillance systems. Another interesting study is to identify which is the best service flow within the WiMAX quality of service context that better supports ERTMS traffic.One of the identified problems for GSM-R deployments is the busy junction scenario. It will be characterized in the simulation platform how this architecture performs before such a challenge.

Acknowledgements

This project has been partially financed by the AmiGUNE [9] research framework and by the EurNEX Pole 5 on Intelligent Mobility, European Rail Research Network of Excellence, through its EurNEX MentorShip Program [10]. It is also necessary to remark INRETS contribution to characterize and model the ETCS application. AmIGUNE is a long-term collaborative Research Programme among the leading Technology Centres and Universities of the Basque Country.

References

[1] IEEE802.16e, "IEEE Standard for Local and metropolitan area networks. Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1," 2005.

[2] UNISIG, Ansaldo, ALCATEL, Alstom, Bombardier, Invensys, and Siemens, "GSM-R Interfaces Class 1 Requirements," 2005.

[3] M.Aguado, O.Onandi, E.Jacob, C.Pinedo, P.Saiz, M.Higuero "WiMAX role on CBTC systems," Proceedings of Joint Rail Conference - Pueblo, CO, March 13-16, 2007, and referenced in Vehicular Technology Magazine, IEEE, Volume 1, Issue 4, Dec. 2006 Page(s):43 - 48:

[4] Opnet Inc., "OPNET Modeler," Release 14.A [5] UIC, "UIC Project EIRENE: Functional Requirements Specification. Reference

PSA167D005 v.7.0," 2006. [6] UIC, "UIC Project EIRENE: System Requirements Specification. Reference:

PSA167D006 Version:15.0," 2006. [7] UIC and QoS Working Group, "ERTMS/GSM-R Quality of Service Specification

Reference O-2475 3.0," 2007. [8] UIC, "System Requirements Specification Chapter 7 ERTMS/ETCS language," 2001. [9] http://www.amigune.org [10] http://www.eurnex.net

Abreviations and definitions

ARQ Automatic Repeat Request ASC Advanced Speech Calls Items ASN Access Service Networks ATC Automatic Train Control ATP Automatic Train Protection AWGN Additive Gaussian White Noise B3G Beyond Third Generation BE Best Effort BS Base Station CCO Operational Control Center EIRENE European Integrated Railway radio Enhanced Network ERTMS European Rail Traffic Management System ETCS European Train Control System GSM Global System for Mobile Communication GSM-R Global System for Mobile Communication for Railway H-ARQ Hybrid Automatic Repeat Request I2T Investigación e Ingeniería Telemática IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IP Internet Protocol ITU International Telecommunication Network KPI Key Performace Indicator MAC Medium Access Control MBWA Mobile Broadband Wireless Access OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access PTP Point to Point QoS Quality of Service RBC Radio Block Center SC Single Carrier SS Subscriber Station TCP Transmission Control Protocol UIC International Union of Railways WiMAX Worldwide Interoperability for Microwave Access

Documents

Performance simulation study of a WiMAX based telecom ... · PDF filePerformance simulation study of a WiMAX based telecom architecture for train control systems ... is GSM-R, designed