SIGNAL + DRAHT (92) 9/2000 61© by Tetzlaff Verlag, Hamburg

GSM-R

Rudolf Schrenk

This article describes quality-of-service (QoS) tests at railway cu-stomer trial sites. The QoS testsconsider the GSM-R networkwhich has been agreed to by theUIC to be the track-to-train com-munication platform for the cur-rent and future railway applica-tions. The performance of the va-rious applications themselves willnot be the focus hereafter.Based on the experience gainedduring several test campaigns onrailway operator’s trial tracks inGermany, France, Switzerlandand Sweden, some recommenda-tions are given concerning thetest and evaluation strategy ofQoS criteria. Used test tools andtypical QoS values, measured atcustomer trial sites which areequipped with Siemens GSM-Rinfrastructure, are presented. Thetests‘ results demonstrate that ina well-planned radio environ-ment all known railway QoS re-quirements will be fullfilled bythe installed GSM-R equipment.

1 Introduction

In 1993 the European railways organizedunder the UIC (Union International desChemins de fer) agreed to introduce a

GSM-based communication system forvoice and data transmission. This GSM-Rnetwork with its own frequency spectrumof 4 MHz (20 carriers) will be the uniquedigital radio platform for the great varietyof current and future railway applications( R A P s ) , like ETCS, E RT M S, F F B, D i a-g n o s -tics, Logistics, Emercency Mgmt, Passen-ger Information System, Ticketing, etc..Since this decision, most of the Europeanrailway companies have built up trial siteswith GSM-R prototypes to test and vali-date the railway specific functions and re-quirements, as defined,for example, in the“UIC EIRENE (European IntegratedRailway Radio Enhanced Network) FRS& SRS”or the “FFFIS for EURORADIO(ETCS/ERTMS)”. The ETSI-Standard is,of course, the binding baseline for theGSM-R system.The GSM-R functionality is mainly testedat reference test beds (RTB) of the GSM-R network suppliers. Quality-of-service,however, can be approved and validatedbetter under the real operational and ra-dio environment conditions along the rail-track of a customer trial site (CTS).

2 Customer Trial Sites

From a QoS testing point of view, a custo-mer trial site consists of the railtrack envi-ronment,the GSM-R network and a set ofspecific measurement equipment.

2.1 Rail Environment

A customer trial site railtrack has a typicallength of anywhere from 30 km up to 120km. It can be in a flat terrain topography(e.g. BANVERKET CTS Stockholm-Nynäshamn) or it can be embedded in a

valley with surrounding hills (e.g. SBBCTS Olten – Sempach). It can enclose noor a lot of tunnels (e.g. ARCOR CTSStuttgart – Mannheim) – covered usuallyby “repeaters”.The test trains can run with a speed of 60km/h to 330 km/h (for example the TGVengine of SNCF at the MORANE CTSParis-Monchi). A train’s journey on a cu-stomer trial site railroad, which is called atest “run”, can be with or without stopsbetween the departure and the arrival sta-tion.The number of base station transceivers(BTS) along the track, their antenna‘sheight and gain, the transmitter powerand the receiver sensitivity determine thecoverage which can be expected. Normal-ly the BTS are situated a few meters awayfrom the track and have a typical densityof 0.1... 0.3 BTS / km.The railway operators use special 8W mo-bile terminals for train drivers / track-side elements (CabRadio) and 2 W gene -ral purpose mobiles (Handheld). Usuallythey have disabled the GSM function“MS/BS Power Control”.The interference situation,that directly ef-fects the radio connection quality or bit-error-rate (BER), is essentially deter-mined by the radio network planning ta-king into account the topography aroundthe railtrack. Figure 1 shows an exampleof a trial site railtrack.During a test run apredetermined number of subscribers, ter-minals and SIM-cards are in operation.

The traffic profile depends on the applica-tion intention of the railway operator. Itcan comprise voice and/or data calls,transmission rates of 2.4/ 4.8/ 9.6 kbpstransparent or non-transparent, point-to-point (PTP) or voice group (ASCI) callservices, permanent or short connections,single or multiple (parallel) calls.

2.2 Network Configuration

Figure 2 shows a typical GSM-R networkconfiguration as used for quality-of-ser-vice tests at different customer trial site.

The AuthorD i p l . I n g.(FH) Rudolf Schrenk Born in 1949. Graduated in Electrical En-gineering from the Munich University ofApplied Sciences. From1975 till 1985 wor-ked on military radar tracking systems forS i e m e n s, M u n i c h . Since 1985 has been wor-king for Siemens mobile communication inbase station development. Since 1999 res-ponsible for GSM-R issues within the sy-stems engineering division.

A d d r e s s :Hofmannstraße 51, D-81379 MünchenE - M a i l :r u d o l f. s c h r e n k @ i c n . s i e m e n s. d e

GSM-R: Quality of Serv i c eTests at Customer Trial Sites

Figure 1: Example ofa trial site railtrack

62 SIGNAL + DRAHT (92) 9/2000© by Tetzlaff Verlag, Hamburg

GSM-R

The GSM-R infrastructure consists of anumber of “on-air” cells (BTS) along therailtrack,their controller (BSC),an opera-tion & maintenance center (OMC), atranscoding & rate adaption unit (TRAU)and a mobile switching center (MSC),which realizes the circuit switch to theoperator’s fixed network (e.g. ISDN), andthe rail specific radio block center (RBC).The RBC contains the fixed terminals(phones/ modems/ PCs) needed for theQoS test. Often the entities OMC, BSC,TRAU and MSC are co-located withinthe RBC.At the trackside there is an engine thatusually pulls a test coach.

2.3 Measurement Equipment

The test coach carries at least one 8 WCabRadio (Kapsch) with a GPS receiverand a trace-PC (TPC), one 2 W Handheld(Sagem) and a couple of antennas on theroof with a coax-panel in the test cabin.Both mobile types (MS) are able to hand-le the GSM bearer services BS24/25/26 aswell as the new voice broadcast /groupcall services VBS/ VGCS (ASCI functio-nality). For multiple parallel calls additio-nal mobiles (8 W-MS and/or 2 W-MS), aswell as MS from other suppliers can be, ofcourse, taken along.The air interface between the MS and theBTS (Um) can only be observed by built-in tracers of the MS suppliers. For exam-ple, the Kapsch-TPC traces the messagesand user data received from and transmit-ted to the Um-interface and inserts locati-on data from a GPS-receiver into the tra-ce on a unique time base.The signalling on the standard GSM inter-faces between BTS and BSC (Abis), bet-ween BSC and MSC (A) and betweenMSC and the ISDN network (I) can beobserved by so-called “GSM protocol tra-cers”.In order to have a unique and accu-

rate time base for the messages that aretransported through the GSM-R system itis important that all the involved interfa-ces are plugged to the same tracer. Thereare protocol tracers of different supplierson the market, but the K1205 from TEK-TRONIX has proved efficient in manyQoS tests.The OMC is used to set certain test para-meters (data base) and to collect state sta-tus infos and performance measurementcounters during the runs. At the RBC thereceived contents of data calls (short com-mands or long files) are saved on the massstorage units of the TPC. QoS tests can beorganized efficiently if the OMC, theK1205 and the fixed test terminals are co-located within the RBC. Otherwise, addi-tional staff and coordination effort areneeded to obtain comprehensive test re-sults. It is advisable to have a GSM-R -in-dependent communication channel (pu-blic GSM,analogue radio) during the testruns for test coordination purposes.

3 Testing

A QoS test campaign lasts 3 to 5 days with4 to 8 runs per day, depending on the testfocus and the customer trial sitec h a r a c t e r i stics. For an optimal test executi-on,7 skilled testers are needed in a typicalcustomer trial site configuration: two atthe mobile terminals, two at the fixed ter-minals, one at the K1205,one at the OMCand one test coordinator (TC).The TC sitsin the RBC or goes with the train, depen-ding on the test activities.

3.1 Test Strategy

The TC negotiates the QoS test campaignwith the operator, plans the test proce-dures and distributes individual “testschedules” to each tester before the runs.

The sheets contain time, equipment, pho-ne numbers to be dialled and trace file na-mes for each action.During the runs, the testers have to proto-col relevant events and subjective percep-tions of the speech quality on these sheets.For a reliable statistical QoS evaluation atleast 600 calls of different types and 200handovers should be generated during thewhole test campaign.Before the runs the correctness of theSW-versions / data base (DB) settings hasto be checked and the measurementequipment has to be installed and calibra-ted, if needed. All system and test toolclocks have to be synchronized, as well asthe testers‘ watches. Specific DB para-meters have to be set (e.g. MEAS_REPORT=ON) and relevant performan-ce measurement scanners have to be crea-ted at the OMC.

3.2 Test Procedures

Radio Environment It is suggested that the first 2 to 4 runs beused to check the coverage and interfe-rence situation, the functioning of thetools and the availability of the systemcomponents in particular. It does not ma-ke sense to measure QoS. if the prerequi-sites concerning the radio conditions andsystem stability are not fullfilled.- there/back run: single permanent voice

call using a 8W-Kapsch,- there/back run: single permanent voice

call using a 2W-Sagem,- supervise availability & stability (state

status) of the system resources duringthe runs.

Data CallsDepending on the RAP the data servicecan, in principle, be: at a rate of 2.4,4.8 or9.6 kbps. transparent (T) or non-transpa-rent (NT), in uplink (UL) or downlink(DL) direction- single permanent data call using 8 W-

MS (repeated short commands T),- single permanent data call using 8 W-

MS (long file transfer NT),- single permanent data call using 2 W-

MS (long file transfer NT),- multiple short data calls (MOC/MTC)

with Kapsch (UL & DL transmission),- multiple short data calls (MOC/MTC)

with Sagem (UL & DL transmission),- MMC data calls from train (8 W or

2 W) to trackside (8 W or 2 W),- MMC data calls from trackside (8W or

2 W) to train (8 W or 2 W),- mass (parallel) data calls using Kapsch

& Sagem,- mixed (permanent & short) data calls,- mixed voice & data calls in parallel.Voice (point-to-point) Calls- multiple short voice calls (MOC/MTC)

using 8 W-Kapsch,- multiple short voice calls (MOC/MTC)

using 2 W-Sagem,- multiple short voice calls (MMC)

Kapsch <-> Sagem (both within thetrain),

Figure 2: A typical GSM-R network configuration as used for quality-of-service tests atdifferent customer trial site

SIGNAL + DRAHT (92) 9/2000 63© by Tetzlaff Verlag, Hamburg

GSM-R

- multiple short voice calls (MMC)Kapsch <-> Sagem (one at the tracksi-de),

- mass (parallel) voice calls using Kapsch& Sagem.

Voice (group) Calls- multiple voice group calls using

Kapsch,- multiple voice group calls using Sagem,- multiple voice group calls using Kapsch

& Sagem mixed,- voice broadcast calls (VBS) in different

group area (GCA) configurations,- voice group calls (VGCS) in different

group area (GCA) configurations,- voice broadcast calls in different sub-

scriber scenario (dispatcher/talker/ li-stener),

- voice group calls in different subscriberscenario (dispatcher/talker/listener),

- voice group calls with different “callpriority” conditions.

InterworkingAt customer trial sites, where equipmentof different suppliers (e.g. Siemens- andNortel-BSS at the MORANE French andGerman trial sites) is distributed along therailtrack, a test focusing on the correct in-terworking at the supplier (BSC area)borders must be conducted:- outgoing handover behaviour of voice

& data calls using Kapsch & Sagem,- incoming handover behaviour of voice

& data calls using Kapsch & Sagem.

4 Evaluation

The evaluation of the results of QoS trialtests can be divided into the three phases“radio environment assessment”, “eventanalysis” and “performance evaluation”.The post-processing is based on the info-sources: K1205 trace files, TPC trace files,OMC state & performance counter logfi-les and tester protocols. Correlating thedifferent sources provides a complete pic-ture of what has happened within theGSM-R system during the runs.

4.1 Radio Environment Assessment

A good system performance can only beachieved in an optimal radio environ-ment.A range of factors will influence theoutcome: topography, BTS density, fre-quency planning, interference situation,terminal equipment,RF adapters, etc.. Thecorres-ponding QoS criteria are coverage and in-terference. Both can be calculated by astatistical evaluation of the RXLEV (re-

flecting coverage) and RXQUAL (reflec-ting bit-error-rate BER) values of the“MEASUREMENT_RESULT”messagestraced with the K1205 on the Abis-interfa-ces during the first 4 runs. The downlinkand the uplink have to be assessed separa-tely.For railways, the coverage is regarded assufficient when 95 % of the RXLEV va-lues are greater than –90 dBm along theentire track during the whole train run(location & time probability).The effect of higher BER on the QoS ofRAPs, which are based on bearer services,depends on the frequency, length and sa-fety protocol of the data blocks (com-

mands) and can,therefore, only be investi-gated together with the specific RAP.For voice based applications the BER is asimple approach for the interference situ-ation in general. Studies have shown thatRXQUAL values of less than or equal to3 (corresponding to a BER<1.6 %) aresubjectively perceived as “ g o o d ” s p e e c hq u a l i t y.

4.2 Event Analysis

The aim of the event analysis is to identifyproblems which would degrade the QoS.Events which are relevant for QoS consi-derations are regular voice & data call se-

Figure 3: Example ofan event profile of areal test run plotted ona scaled map

QOS Parameter Type Typical MP RemarksValues

Radio EnvironmentCoverage UL 96.8 % Abis RXLEV >

DL 97.5 % - 90 dBmInterference Situation UL 99.8 % Abis RXQUAL <=

DL 98.8 % 3 (1.6 %)System PerformanceSystem Availability NE, Links 100 % OMC

RessorcesCall Success Rate 99.5 % ACall Drop Rate 0.1 % AHandover Success Rate 99.5 % AProbability of Transmission Interruption 0.3 % ATime PerformanceCall Setup Time voice group call EMC 1.0 sec A

VBS/VGCS 1.9 secpoint-to-point call MOC/MTC 3.1 sec

MMC 6.2 secCall Release Times 0.6 sec AHandover Break Times Signalling 420 msec Abis

User data 300 msec TPCHandover Recreation Times Max 10 min A Low D&V

min 30 sec High D&V

Figure 4: Typically measured QoS values

64 SIGNAL + DRAHT (92) 9/2000© by Tetzlaff Verlag, Hamburg

GSM-R

tups and releases, unintended call re-leases (call drops), expected handovers,assignment and handover failures, unex-pected handovers (e.g. intra-cell / back-/ping-pong-HOVs) and unavailability ofresources.A detailed analysis of an event’s occur-rence, especially in the case of an irregula-rity, should be conducted. This should in-clude the relevant system conditions (ti-me, train position/ velocity/ acceleration/direction,cell-ID, mobile-ID, used channeltype, equipment status) and radio conditi-ons (GSM-R frequency, measured recei-ving level of serving & neighboring cells,quality, TX power levels, timing advance).Figure 3 shows an example of an eventprofile of a real test run plotted on a sca-led map.The “GSM causes”assessment is also partof the event analysis and is important aswell. For example, all handovers whichwere successful but not caused by “bettercell” are potential trouble areas and haveto be investigated and minimized.Call setup attempts which failed due to“user busy” signals have to be discardedfrom the “call success rate” calculation.

4.3 Quality-of-Service Calculation

The aim is to achieve reliable values forthe QoS parameters. They are only validfor a certain test campaign at a specifictrial site. As far as the customer trial siterepresents the radio and operational envi-ronment of the whole railway operator’sGSM-R network, these values can be ge-neralized to cover this environment. Figu-re 4 shows typically measured QoS valuesas obtained during well-coordinated testcampaigns at well-covered customer trialsites equipped with Siemens GSM-R tech-nology. The table also shows the source(measurement point MP) from which theQoS values can be derived.The system availability is the percentage(probability) of the time in which the con-figured resources (entities, links, radio &terrestrial channels) of the GSM-R systemcould be used over the time of the wholetest campaign. It only takes into conside-ration the GSM-R infrastructure compo-nents. The QoS value is derived from theaccumulated state status reports recordedon the OMC logfiles.The call success rate (CSR) is the percen-tage (probability) of call setup attemptswhich result in an established call (con-nection).In a good radio environment anda well-prepared and coordinated test cam-paign the CSR is nearly 100%.Significant-ly worse CSR, observed at some QoSruns, were associated with test coordinati-on deficits (calls to busy users, diallingwrong numbers....).The call drop rate (CDR) is the percenta-ge (probability) of connected calls whichhave been released unintensionally(drop). The strong railway requirementsof CDR<0.1% can only be achieved un-

der optimal radio conditions at the trial si-te. Significantly higher CDRs, observed atsome QoS runs, could be attributed tofaulty mobile coax adapters, coveragegaps or interworking problems.The handover success rate (HSR) is thepercentage (probability) of handover at-tempts which result in a successful swit-chover to the new (target) cell. In case offailure the call is switched back to the old(serving) cell. A lower HSR hints at unn-essessary handover attempts. This has tobe analyzed and avoided.Cellular systems like GSM have, in princi-ple, short call interruptions at the cell bor-ders (handover). These interruptions areless critical than often stressed, becausethey are normally inaudible in a speechcall and they do not result in data losses ina data call because of the safety protocollayers (e.g. HDLC) used in data commu-nications. A general railway requirementis that the interruptions not be very often,not be too long and that there should beenough “recreation” time between twohandovers for re-transmitting lost railwayapplication telegrams.The probability of transmission interrup-tion (PTI) is the accumulated handoverbreak times divided by the complete trainrun times and multiplied with the proba-bility of being in an ongoing call (trafficvalue in Erlang).A typical value at custo-mer trial sites is a PTI of about 0.3 %.The handover break time can be derivedfrom the time stamps of the HANDO-VER_COMMAND and the HANDO-VER_COMPLETE message on the Abis-trace. It includes the elapsed processing ti-me of the involved GSM-R components.The break in the transmitted user datastream can only be calculated from theTPC-trace at the receiver side. There thelost data blocks can be searched taking in-to account the used bearer service (baudrate). The break in the user data is, ofcourse, always shorter than the completehandover processing time. The measuredvalues meet the requirements of a hando-ver break if less than 1 sec.The handover recreation time is the re-m a i n -ing time between two successive hando-vers. This time is needed for RAPs with astrong real-time requirement like FFB orETCS to repeat lost commands. Depend-ing on the BTS density and the train velo-city, values from 30 sec to 10 min occuredat real trial sites. This meets the require-ment of a recreation time between twohandovers of longer than 6 sec. This QoSvalue decreases rapidly, if unexpectedhandovers occur. Therefore, the numberof handovers have, in general, to be mini-mized (equal to number of cells).Since many railway applications do notneed permanent connection but connec-tion on demand,the fast call setup and re-lease within the GSM-R network is of im-portance. Note that the times consumed inthe RAP (for establishing safety layerse.g.) are not included here.

The call setup time can be derived fromthe time stamps between the connectionrequest and the connection acknowledge-ment on the A-trace. Point to point andvoice group calls have to be distinguishedas well as MOC/MTC and MMC. Thestrong requirement of establishing a rail-way emergency call within 1 sec needsspecial operational measures, like auto-answering of the MS, disabling ciphering& authentication.The call release time can be derived fromthe time stamps between pushing the dis-connect button and releasing all resourcesfor that connection by the GSM-R system.

5 Conclusion

The QoS tests performed at trial sites ofrailway customers in various Europeancountries provide the assurance that allknown railway requirements are fullfilledwith the installed GSM-R equipment. Thestrong requirements concerning call drop& transmission interruption probabilityasume a well planned, installed and opti-mized radio environment.In order to evaluate the “end-to-end”quality-of-service it is recommended thatQoS tests be performed at CTS which in-clude the different railway applications.

ZusammenfassungGSM-R – Test der Dienstgüte aufden Versuchsstrecken

Der Beitrag beschreibt Dienstgüte(quality-of-service QoS) Tests auf Ver-suchsstrecken von Eisenbahngesell-schaften. Die QoS Tests betrachten dasGSM-R System, das von der Organisa-tion der europäischen Bahnen (UIC)als einheitliche Plattform für die ver-schiedenen derzeitigen und künftigenDienste ausgewählt wurde. Die Dienst-güte der Applikationen selbst ist nichtGegenstand des Aufsatzes.Basierend auf Erfahrungen, die in einer Reihe von Meßfahrten auf Test-strecken verschiedener Bahnbetreiberin Deutschland, Frankreich, derSchweiz und Schweden gemacht wur-den, werden Empfehlungen zur Test-strategie und zur Bewertung von Dienst-güte-Kriterien (QoS Parameter)gegeben. Verwendete Testgeräte undtypische QoS Werte – gemessen anVersuchsstrecken, die mit SiemensGSM-R Technik ausgerüstet sind –werden präsentiert. Die Ergebnissezeigen, dass bei guter Funknetzplanungalle bekannten Bahnanforderungenbezüglich der Dienstgüte mit dem in-stallierten GSM-R System erfüllt wer-den.