6 Performance requirements for rail-bound mass transit

22.2893GPPMobile communication system for railwaysRelease 17TS

6.1 Environmental conditions

Rail-bound mass transit communication is required mostly in tunnels and urban areas. Tunnels are specific and require separate consideration in signal propagation, e.g for waveguide like non-line-of-sight communication, changing cross-section or blocking/shadowing by other trains. Here, the use of leaky feeder cables can be essential depending on the deployment scenario. Within urban areas the interference through other users and the multi-path propagation in conjunction with a high velocity have to be considered. In both environments a high train density has to be considered, especially in stations and shunting yards or depots.

6.2 Low latency and high reliability

6.2.1 Overview

Low latency and high reliability, high communication service availability, and dependability of communication are important service and performance requirements for mass transit train control (MTTC) such as communication based train control (CBTC). They are necessary to provide high grades of automation such as necessary for e.g. driverless trains. Furthermore, trains will simultaneously exchange control information and status information with the responsible traffic management system on the ground.

Trains are operated at speeds up to 160 km/h. The communication for rail-bound mass transit has to be provided under these conditions.

Especially train control communication is of extreme importance to ensure passengers safety. The relative braking distance of a rail vehicle is an important indicator of the safety requirements.

6.2.2 Scenarios and KPIs for rail-bound mass transit

6.2.2.1 Overview

There are three main drivers behind the growing importance of communication services in rail-bound mass transit: (1) train automation (2) operational data, and (3) passenger information.

Caused by increased safety awareness, onboard video surveillance/CCTV and emergency calls play an increasing role in order to setup communication with passengers during emergencies, e.g., when trains have to stop inside tunnels. CCTV is required for high grades of automation by regulation.

Communication for rail-bound mass transit can be associated with different communication patterns as described in TS 22.104 [7] Clauses 4.3 and 4.4 and as used in communication for cyber-physical control applications in vertical domains.

Periodic deterministic communication is periodic with stringent requirements on timeliness and availability of the communication service. A transmission occurs every transfer interval.

Aperiodic deterministic communication is without a pre-set sending time, but still with stringent requirements on timeliness and availability of the communication service.

Non-deterministic communication subsumes all other traffic types than periodic/aperiodic deterministic communication. This includes periodic/aperiodic non-real-time traffic.

Mixed traffic cannot be assigned to one of the other communication patterns exclusively.

6.2.2.2 Scenarios and KPIs for rail-bound mass transit

Coexistence of automated train control with other train applications: A train is operated in an automated manner, and the communication of the train controller with the rail side co-exists with traffic generated by other applications.

The following communication scenarios of rail-bound mass transit shall be considered in order to support the coexistance of automated train control with other train applications:

Use case 1: Periodic communication for train control.

Use case 2: Communication serving CCTV cameras streaming within the train and to the rail-side.

Use case 3: Emergency call from the train to a remote control centre via the mass-transit communication system.

The following communication scenario shall be considered in order to support train coupling in rail-bound mass transit:

Use case 4: Wireless communication link between two coaches; the link carries traffic from many applications.

The following communication scenario shall be considered in order to support rail-bound mass transit:

Use case 5: CCTV offload in train stations.

A characteristic parameter can be used to characterise the dynamic behaviour and performance of the functionality of the communication service of the 5G network (key performance indicator).

A communication service is considered unavailable in case an expected message is not received within a specified time, which, at minimum, is the sum of maximum end-to-end latency and survival time. The end point in "end-to-end latency" is assumed to be the communication service interface between the application and the 5G system (cf. TS 22.104 [7] Annex C).

Mean time between failures (MTBF) is one of the typical indicators for communication service reliability. This parameter states the mean value of how long the communication service is available before it becomes unavailable. For instance, a mean time between failures of one month indicates that a communication service runs error-free for one month on average before an error makes the communication service unavailable. Usually, an exponential distribution is assumed. This means, there will be several failures where the time between two subsequent errors is below the mean value (1 month in the example).

Availability and reliability together indicate frequency and duration of acceptable unavailabilies of a communication service.

An influence quantity is not essential for the characterisation of the dynamic behaviour of an item but it affects the performance of the characteristic parameter of an item.

Further information on characteristic parameters and influence quantities used in Table 6.2.2.3-1 can be found in TS 22.104 [7] Annex C.

The 5G system shall support the communication service performance requirements (KPIs) reported in Table 6.2.2.3-1.

Table 6.2.2.3-1: Characteristic parameters (KPIs) of communication service performance requirements for rail-bound mass transit

Characteristic parameters

Influence parameters

Use case

Communi­cation service availabi­lity: target value

(note 1)

Commu-nication service reliability: mean time between failures

End-to-end latency: maximum (note 2)

Service bit rate: user experienced data rate

Commu­nication pattern

Message size

Transfer interval: target value

Survival time

UE

speed

# of UEs

Service area (note 3)

1: Control of automated train (note 4)

99,999 %

below 1 year but >>1 month

<100 ms

≥200 kbit/s

periodic deter­ministic

≤200 byte

100 ms

~500 ms

≤160 km/h

<25

50 km x 200 m

2: CCTV com­muni­cation ser­vice for surveillance cameras (note 4)

>99,99 %

~1 week

<500 ms

≥2 Mbit/s

aperiodic deter­ministic

~500 ms

≤160 km/h

<25

50 km x 200 m

3: Emergency voice call (note 4)

>99,99 %

~1 day

<200 ms

≥200 kbit/s

aperiodic deter­ministic

~2 s

≤160 km/h

<25

50 km x 200 m

4: Train coupling

>99,9999 %

~1 year

<100 ms

1 Gbit/s

mixed traffic

~500 ms

(note 5)

2

3 m x 1 m

5: CCTV offload in train stations

≥1 Gbit/s

non-deter­ministic

~0 km/h

≥1

train station

NOTE 1: One or more retransmissions of network layer packets may take place in order to satisfy the communication service availability requirement.

NOTE 2: Unless otherwise specified, all communication includes 1 wireless link (UE to network node or network node to UE) rather than two wireless links (UE to UE).

NOTE 3: Length x width.

NOTE 4: 2 UEs per train car, column “# of UEs" is per train, there are multiple trains in the given service area.

NOTE 5: UE speed is irrelevant since this communication takes place between two train segments.

Annex A (informative):
Change history

Change history

Date

Meeting

TDoc

CR

Rev

Cat

Subject/Comment

New version

2018-12

SA#82

SP-181001

Presentation for one-step approval to SA

1.0.0

2018-12

SA#82

SP-181001

Raised to v.16.0.0 following SA#82’s one-step approval

16.0.0

2019-03

SA#83

SP-190084

0002

1

D

Editorial corrections to TS 22.289

16.1.0

2019-03

SA#83

SP-190081

0001

2

F

Moving rail-bound mass transit requirements – shift into FRMCS

16.1.0

2019-12

SA#86

SP-191030

0006

2

B

Call setup time for interworking with LMR

17.0.0

2019-12

SA#86

SP-191030

0007

2

B

Off network communication for interworking with LMR

17.0.0