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 |
Communication service availability: 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 |
Communication 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 deterministic |
≤200 byte |
100 ms |
~500 ms |
≤160 km/h |
<25 |
50 km x 200 m |
|
2: CCTV communication service for surveillance cameras (note 4) |
>99,99 % |
~1 week |
<500 ms |
≥2 Mbit/s |
aperiodic deterministic |
~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 deterministic |
~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-deterministic |
~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 |