TS 22.289
Mobile Communication System for Railways
V18.0.1 (PDF)
2024/03 19 p.
V17.0.0
2019/12 19 p.
V16.1.0
2019/03 19 p.
- Rapporteur:
- Mr. Merkel, Jürgen
Nokia Germany
Content for TS 22.289 Word version: 18.0.1
1 Scope
2 References
3 Definitions, symbols and abbreviations
4 Railway communication functionality
5 Performance requirements for main line
6 Performance requirements for rail-bound mass transit
$ Change history
1 Scope p. 5
The present document provides rail communication Stage 1 normative service requirements for 5G system. Rail communication includes main line and rail-bound mass transit. Communication for main line is based on the set of Mission Critical specification TS 22.280, TS 22.179, TS 22.281, TS 22.282. Several service requirements for rail-bound mass transit are based on the methodology of cyber-physical control applications TS 22.104. Requirements which are not in the scope of those specifications are provided in this Technical Specification.
2 References p. 5
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TS 22.280: "Mission Critical Services Common Requirements (MCCoRe)".
[2]
TS 22.179: "Mission Critical Push to Talk (MCPTT); Stage 1".
[3]
TS 22.281: "Mission Critical Video services ".
[4]
TS 22.282: "Mission Critical Data services ".
[5]
TR 21.905: "Vocabulary for 3GPP Specifications".
[6]
TS 22.261: "Service requirements for the 5G system"
[7]
TS 22.104: "Service requirements for cyber-physical control applications in vertical domains"
[8]
UIC EIRENE: "Functional Requirements Specification Version 8.0.0"
3 Definitions, symbols and abbreviations p. 5
3.1 Definitions p. 5
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Area traffic capacity:
total traffic throughput served per kilometer along a rail line.
CCTV:
Closed-circuit television, also known as video surveillance, is the use of video cameras for monitoring and recording people, animals and objects in different places, such as in vehicles and stations.
CCTV offload:
Transfer of video surveillance data archives from train to ground through the wireless connection between mobile communication unit in the train and ground communication units located at the depot and at the stations and/or stops.
Communication service availability:
percentage value of the amount of time the end-to-end communication service is delivered according to an agreed QoS, divided by the amount of time the system is expected to deliver the end-to-end service according to the specification in a specific area.
Communication service reliability:
ability of the communication service to perform as required for a given time interval, under given conditions.
End-to-end latency:
the time that takes to transfer a given piece of information unidirectional from a source to a destination, measured at the communication interface, from the moment it is transmitted by the source to the moment it is successfully received at the destination.
Inter-carriage link:
Wireless connection between the carriages of the train.
Reliability:
in the context of network layer packet transmissions, percentage value of the amount of sent network layer packets successfully delivered to a given system entity within the time constraint required by the targeted service, divided by the total number of sent network layer packets.
Survival time:
the time that an application consuming a communication service may continue without an anticipated message.
Transfer interval:
time difference between two consecutive transfers of application data from an application via the service interface to 3GPP system.
3.2 Abbreviations p. 6
4 Railway communication functionality p. 6
4.1 Bulk Transfer of CCTV archives from Train to Ground p. 6
4.1.1 Description p. 6
The video surveillance system in trains consists of multiple cameras which are recording and encoding the video feeds 24/7 either into the video recorders or into internal memory of the cameras themselves. The amount of video recordings is excessive, which exceeds rather fast the physical storage capacity that is available in video recorders and/or in cameras. The regulations in different countries are ruling retention time for recordings until up to 31 days or even more. However, the recordings need to be stored in the physical storages located in the vehicles for only seven days.
Next, an example estimation is provided to illustrate the offload performance with different uplink speeds, when the train is commuting from Helsinki to Kemijärvi. The parameters for the calculation are provided in Table 4.1.1-1, whereas the offload results for uplink speeds of 400 Mbps, 750 Mbps and 1000 Mbps are provided respectively in Figure 4.1.1-2, Figure 4.1.1-3 and in Figure 4.1.1-4.
| Station | Arrives | Departs | Stop time | Time between stations |
|---|---|---|---|---|
| HELSINKI | 18:52 | |||
| PASILA | 18:57 | 19:00 | 0:03 | 0:08 |
| TIKKURILA | 19:41 | 19:44 | 0:03 | 0:44 |
| RIIHIMÄKI | 20:19 | 20:22 | 0:03 | 0:38 |
| HÄMEENLINNA | 20:46 | 20:48 | 0:02 | 0:26 |
| TAMPERE | 21:38 | 22:11 | 0:33 | 1:23 |
| PARKANO | 23:03 | 23:06 | 0:03 | 0:55 |
| SEINÄJOKI | 0:08 | 0:10 | 0:02 | 1:04 |
| KOKKOLA | 1:37 | 1:39 | 0:02 | 1:29 |
| YLIVIESKA | 3:10 | 3:12 | 0:02 | 1:33 |
| OULU | 4:42 | 5:00 | 0:18 | 1:48 |
| KEMI | 6:08 | 6:12 | 0:04 | 1:12 |
| ROVANIEMI | 7:47 | 7:55 | 0:08 | 1:43 |
| MISI | 8:31 | 8:32 | 0:01 | 0:37 |
| KEMIJÄRVI | 9:00 | 9:05 | 0:05 | 0:33 |
Based on the example estimations presented in the figures 4.1.1-1 - 4.1.1-4, the required throughput speed for the offload should be at least 1 Gbps.
Hence, in order to meet the requirement regarding the retention time and to minimize the required physical storage in the train, FRMCS needs to provide the means to transfer the CCTV archives from train to ground, i.e. enable means for CCTV offload.
In a CCTV offload system, FRMCS provides means for transferring video surveillance data between a mobile communication unit in the train and ground communication units located at the depot and at the stations and/or stops alongside the predetermined route of the train. Whenever the train approaches the stations and/or stops or arrives into the depot, FRMCS facilitates the communication between the ground and mobile communication unit. The mobile communication unit in the train forwards the video surveillance data from the video recorder and/or directly from video surveillance cameras. The generic offload procedure between the ground and mobile communication units could be e.g as described in the following;
- The ground communication unit is monitoring whether a transmission signal from the mobile communication unit is available and that the signal quality is sufficient for synchronization.
- Upon successful synchronization, the ground communication unit requests offload from the mobile communication unit and the connection between the ground communication and mobile communication unit is established as soon as the sufficient signal quality is acknowledged by the FRMCS and mobile communication unit.
- The transfer of CCTV archives from train to ground is started.
- The ground communication system forwards the offloaded data further to the ground storage.
- The transfer of CCTV archives continues as long as sufficient connection between the train and ground system is available and/or aborted by the FRMCS.
4.1.2 Requirements p. 9
[R4.1.2-1]
FRMCS shall facilitate the CCTV offload from train to ground when, during the train stops the stations and/or stops, stations, and whenever the train arrives into the stops and at the depot.
[R4.1.2-2]
The FRMCS shall be able to support that CCTV archives can be transferred into the ground system in a time and resource efficient way in dedicated places such as stations, train stops or train depots.
[R4.1.2-3]
The CCTV offload shall be initiated by the ground communication unit, once the sufficient signal quality is available between the ground and mobile communication units.
[R4.1.2-4]
The transfer of CCTV archives shall not affect mission critical communication.
4.2 Bulk transfer of multimedia from ground to train p. 9
4.2.1 Description p. 9
The offering of multimedia services to the passengers is becoming default service during long travels in airplanes and more and more, also in trains. In order to minimize the excessive consumption of network capacity between train and ground, a bulk transfer of multimedia databases from ground to train during stops at the stations and depots is optimal solution. The bulk transfer of multimedia is done when the train stops at the stations, stops and depot, ideally with minimum of one gigabit transfer speed. Hence, the multimedia content can be more versatile and updated in regular basis. The actual content is also consumed in-train network operated by the FRMCS and hence it does not give burden to the link budget between train and ground. The multimedia may contain movies, TV shows, cached webpages etc.
The bulk transfer of multimedia is facilitated by the FRMCS, which provides means for transferring the multimedia databases data between ground communication units, located at the depot, stations and/or stops alongside the predetermined route of the train. Whenever the train approaches the stations and/or stops or arrives into the depot, FRMCS facilitates the communication between the ground and mobile communication unit, if bulk transfer of multimedia transfer is requested. The ground communication unit uploads the multimedia databases from ground into the mobile communication unit in the train, where the data is stored in the train multimedia data storage. The generic procedure for the bulk transfer of multimedia between the ground and mobile communication units could be e.g as described in the following;
- The ground communication unit is monitoring whether a transmission signal from the mobile communication unit is available and that the signal quality is sufficient for synchronization.
- Upon successful synchronization, the mobile communication unit requests multimedia upload from the mobile communication unit and the connection between the ground communication and mobile communication unit is established as soon as the sufficient signal quality is acknowledged by the FRMCS and mobile communication unit.
- The transfer of multimedia databases from ground to train is started.
- The mobile communication system forwards the transferred multimedia databases further into the in-train storage.
- The transfer of multimedia archives continues as long as sufficient connection between the train and ground system is available and/or aborted by the FRMCS.
4.2.2 Requirements p. 10
[R4.2.2-1]
FRMCS shall facilitate the transfer of multimedia archives from ground to train.
[R4.2.2-2]
The FRMCS shall be able to support that multimedia databases can be transferred from ground to train in a time and resource efficient way, when the train stops at the stations, train stops and at the depot.
[R4.2.2-3]
FRMCS shall facilitate communication capabilities provided by the train.
[R4.2.2-4]
The transfer of multimedia databases shall not impact mission critical communication.
4.3 Massive Inter-carriage data transfer p. 10
4.3.1 Description p. 10
The inter-carriage links between train vehicles enable sufficient capacity to enable massive data transfer throughout the train required e.g. for transfer of CCTV archives, multimedia databases and live streaming as well as for control, operational, and passenger services. Mobile communication unit in train provides connection between carriages of the train used, e.g. for the transfer of CCTV archives to a central node in the train form which the connection to the ground system will take place.
4.3.2 Requirements p. 10
[R4.3.2-1]
The FRMCS shall facilitate the onboard communication between carriages of a train, e.g. to collect CCTV content at one place on the train for transfer to the ground system.
[R4.3.2-2]
The Inter-carriage links shall support at least the same throughput speed as the mobile communication unit of FRMCS providing the link between train and ground system.
[R4.3.2-3]
The onboard communication between carriages of a train shall not impact mission critical communication.
4.4 Coexistence of automated train control with other train applications p. 10
4.4.1 Description p. 10
Train automation can be divided into control and operations. Both types consist of distributed applications that rely on dependable communication. Typically, control applications such as for automated train control are of higher priority than operational applications, and the latter are typically of higher priority than passenger services. One of the main challenges is to guarantee the premium priority of control-related communication over other types of communication, especially since the data bandwidth consumed for control is typically dwarfed by data traffic stemming from the other two application areas. Another challenge is to guarantee the super priority of operational data communication over passenger-related communication. Driverless trains are not the only source of automation in mass transit, and thus not the only source of dependable machine-type communication. For instance, mass transit train control (MTTC) including communication-based train control (CBTC) is also used for trains exhibiting lower grades of automation, if assisted by rail-to-rail-side wireless communication, which is at the core of driverless trains.
Communication services for MTTC have to coexist with other high-priority and low-priority communication services. This coexistence is done assigning priorities to the communications, see below an example of how these priorities can be allocated:
- The MTTC communication service might have the highest priority (train control).
- The CCTV communication service might have high-priority, but lower than MTTC.
- (High data rate) data communication services such as passenger internet access might be of low priority.
- Emergency calls need to be established on demand with a priority suitable to guarantee call success independent of already running communication services.
4.4.2 Requirements p. 11
[R4.4.2-1]
High priority communication services, especially their end-to-end latency and availability, shall not be affected by communication services of lower priority running in parallel.
[R4.4.2-2]
The start-up of high-priority communication services shall not be affected by already running services with different priorities.
5 Performance requirements for main line p. 11
5.1 Environmental conditions p. 11
Rail communication is subject to much diverse limitations in urban and sparsely populated areas. Depending on the landscape, the construction of tunnels, e.g. underground or mountain crossing, or the construction of new tracks, the embedding of railway lines within aisles, through uninhabited areas is required. Tunnels are specific and require separate consideration in signal propagation through the changing fill factor. Here, the use of leaky feeder cables is essential.
Crucial constraints for the provision of performance factors are summarized in a non-exhaustive list below:
- Railway corridors in general and especially in hilly terrain;
- Railway corridors through forest areas;
- Underground / tunnel environment;
- Moving trains or objects in a railway station and shunting yards;
- Free space;
5.2 Low latency and high reliability p. 11
5.2.1 Overview p. 11
In future, for example trains will simultaneously exchange control information and status information with the responsible traffic management system on the ground. This procedure is a key factor for automated operation without a driver. Nonetheless, also traditional voice communication is needed to allow train staff to communicate with the ground staff.
Trains are operated at speeds up to 500 km/h. Under these conditions voice, video and data communication are to be provided. Especially train control communication is of extreme importance to ensure passengers safety.
In normal rail operation and in the context of Grade of Automation (GoA3 and GoA4) video/radar/lidar sensors on trains and on ground will be used to:
- detect hazards on tracks, and
- ensure a safe passenger (dis-)embarkation (e.g., ensure that passengers are not stuck in doors, or between platform and train, when trains depart, and trigger emergency braking or postpone train departure if any hazardous situation is detected).
5.2.2 Scenarios and KPIs for main line p. 12
To support this various voice, video and data categories,the following rail communication scenarios under the aspect of train speed shall be considered:
- Voice Communication for operational purposes impacting train safety
- Critical Video Communication for observation purposes with indirect impact on train operation, e.g. passenger surveillance;
- Very Critical Video Communication with direct impact on train safety- related critical train control and operation, e.g. used in driverless (e.g. Grade of Automation - GoA3/GoA4) operation for automated detection of objects (no human in the loop) or video-based remote control (human in the loop);
- Standard Data Communication used for the exchange of train diagnostic information or communication relevant information;
- Critical Data Communication for present rail traffic management systems;
- Very Critical Data Communication for enhanced intelligent rail traffic management systems e.g. full automated train control systems (driverless - remote control); requires high reliable transmission and preservation of the response pattern;
- Messaging for the reliable exchange of short information e.g. train departure procedure;
| Scenario | End-to-end latency | Reliability (Note 1) |
Speed limit | User experienced data rate | Payload size (Note 2) |
Area traffic density | Service area dimension (Note 3) |
|---|---|---|---|---|---|---|---|
| Voice Communication for operational purposes | ≤100 ms | 99,9% | ≤500 km/h | 100 kbps up to 300 kbps | Small | Up to 1 Mbps/line km | 200 km along rail tracks |
| Critical Video Communication for observation purposes | ≤100 ms | 99,9% | ≤500 km/h | 10 Mbps | Medium | Up to 1 Gbps/km | 200 km along rail tracks |
| Very Critical Video Communication with direct impact on train safety | ≤100 ms | 99,9% | ≤500 km/h | 10 Mbps up to 20 Mbps | Medium | Up to 1 Gbps/km | 200 km along rail tracks |
| ≤10 ms | 99,9% | ≤40 km/h | 10 Mbps up to 30 Mbps | Medium | Up to 1 Gbps/km | 2 km along rail tracks urban or station | |
| Standard Data Communication | ≤500 ms | 99,9% | ≤500 km/h | 1 Mbps up to 10 Mbps | Small to large | Up to 100 Mbps/km | 100 km along rail tracks |
| Critical Data Communication | ≤500 ms | 99,9999% | ≤500 km/h | 10 kbps up to 500 kbps | Small to medium | Up to 10 Mbps/km | 100 km along rail tracks |
| Very Critical Data Communication | ≤100 ms | 99,9999% | ≤500 km/h | 100 kbps up to 1 Mbps | Small to Medium | Up to 10 Mbps/km | 200 km along rail tracks |
| ≤10 ms | 99,9999% | ≤40 km/h | 100 kbps up to 1 Mbps | Small to Medium | Up to 100 Mbps/km | 2 km along rail tracks | |
| Messaging | - | 99.9% | ≤500 km/h | 100 kbps | Small | Up to 1 Mbps/km | 2 km along rail tracks |
|
NOTE 1:
Reliability as defined in subclause 3.1.
NOTE 2:
Small: payload ≤ 256 octets, Medium: payload ≤512 octets; Large: payload 513 - 1500 octets.
NOTE 3:
Estimates of maximum dimensions.
|
|||||||
End-to-end latency and reliability of the communication scenarios listed in Table 5.2.2-1 shall be applied separately from the individually used priority of the communication.
To support off network communication, data categories, the following rail communication scenarios under the aspect of train speed shall be considered:
- Very Critical Data Communication for enhanced intelligent rail traffic management systems e.g. virtual coupling; requires high reliable transmission and preservation of the response pattern;
| Scenario | End-to-end latency | Reliability (Note 1) |
Speed limit | User experienced data rate | Payload size (Note 2) |
Area traffic density | Service area dimension (Note 3) |
Max required communication range (meters) (Note 4) |
|---|---|---|---|---|---|---|---|---|
| Very Critical Data Communication | ≤100 ms | 99,9999% | ≤500 km/h | 100 kbps up to 1 Mbps | Small to Medium | Up to 10 Mbps/km | 3 km along rail tracks | [1000 ~ 3000] |
| ≤300 ms | 99,9% | ≤40 km/h | 100 kbps up to 1 Mbps | Small to Medium | Up to 100 Mbps/km | 3 km along rail tracks | [1000 ~ 3000] | |
|
NOTE 1:
Reliability as defined in sub-clause 3.1.
NOTE 2:
Small: payload ≤ 256 octets, Medium: payload ≤512 octets; Large: payload 513 - 1500 octets.
NOTE 3:
Estimates of maximum dimensions.
NOTE 4:
Relevant for Off-Network MCData Service only, supporting train platooning. All trains in a platoon are driving in the same direction.
|
||||||||
5.2.3 Communication establishment p. 13
The duration of time for establishing a communication between entities, e.g. after network change or loss of communication, the braking distance between vehicles and its impact to the risk integral is crucial. Based on this, the following communication setup times of a communication shall be provided:
| Type | FRMCS | Interworking with GSM-R | Interworking with LMR |
|---|---|---|---|
| Immediate communication session establishment | ≤1 sec | ≤1 sec + call setup time as defined in table 3-1 [8] | ≤1 sec + LMR call setup time (Note 1) |
| Normal communication session establishment | ≤3 sec | ≤3 sec + call setup time as defined in table 3-1 [8] | ≤3 sec + LMR call setup time (Note 1) |
|
NOTE 1:
In the interworking, the setup times are considered with 3GPP side only. Extra times may be applied depend on interworking communication technology.
|
|||
6 Performance requirements for rail-bound mass transit p. 14
6.1 Environmental conditions p. 14
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 p. 14
6.2.1 Overview p. 14
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 p. 14
6.2.2.1 Overview |R17| p. 14
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, 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 |R17| p. 15
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 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 Annex C.
The 5G system shall support the communication service performance requirements (KPIs) reported in Table 6.2.2.3-1.
| Use case | Characteristic parameters | Influence parameters | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Communication service availability: target value (note 1) | Communication 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.
|
|||||||||||
$ Change history p. 17
