Chapter - XIX

MOBILE TRAIN RADIO COMMUNICATION -LTE-R

19.0 This chapter covers basic technical information of Long Term Evolution
(LTE), Evolved Packet Core (EPC) and Mobile Train Radio
Communication System LTE-R. This document is based on Specifications
of LTE and LTE-R (FRMCS) developed by 3rd Generation Partnership
Project (3GPP) and International Union of Railways (UIC).

19.1 With GSM, ERA and UIC added extra functionality and called it GSM for
Rail, GSM-R. So far the indication is that UIC will try a different approach
with LTE and try to get as much functionality into the regular LTE
standard, thereby not needing to add extra specific functionality for
railways. There are some indications that LTE will end up with more
functionality that is valuable to the railway industry than GSM did in its
time. The Mobile Train Radio Communication System with LTE technology
is in the development stage.

19.2 The International Union of Railways, UIC a global organization for Railway
has set up Future Rail Mobile Communications System (FRMCS) project
to prepare the necessary steps towards the introduction of a successor of
GSM-R. The Future Railway Mobile Communication System - FRMCS has
been prepared by UIC in order to have a Mobile Train Communication
System based on LTE.

19.3 Limitations of GSM-R:-

19.3.1 As the communication demands increased and the capabilities of

electronic devices evolved, it has become necessary to support data
communication as much as voice communication. GSM-R does not
provide packet-switched transmission. Therefore, data communication
must be delivered by Circuit-Switched Data (CSD), which cannot assign
the network resources based on the actual demand. This means that data
is transmitted over virtual circuits, just like voice frames. Being bursty in
nature, data sources send varying amounts of data at irregular intervals.
Such a bursty transmission does not fit well into a fixed circuit provided by
GSM-R. As a result, circuits are often underutilized and network resources
are wasted.

19.3.2 GSM-R is becoming an obsolete technology. The predicted obsolescence

of GSM-R is by 2030.
.4 LTE: Long Term Evolution:-

19.4.1 Long Term Evolution (LTE) is the latest family of mobile communication
standards (4G) developed by 3rd Generation Partnership Project (3GPP).
The main requirements for the new access network are high spectral
efficiency, high peak data rates, Short round trip time as well as flexibility
in frequency and bandwidth.

19.5 Components of Long Term Evolution (LTE):-

Fig.-1: Basic EPS Architecture with E-UTRAN Access (Source: 3GPP.org)

19.5.1 The key components of the LTE network sub-system are mentioned
below:

19.5.1.1 E-UTRAN: eNodeB (Equivalent of BSS in GSM-R)

(Evolved Universal Terrestrial Radio Access Network)

The Evolved NodeB (eNodeB) is the base station for LTE radio. eNodeB
is the RAN (Radio Access Network) node in the network architecture that
is responsible for radio transmission to and reception from UEs( User
Equipment) in one or more cells. The eNodeB is connected to EPC nodes
by means of an S1 interface. The eNodeB is also connected to its
neighbor eNodeBs by means of the X2 interface.
 Fig. 2: LTE Architecture (Source: 3GPP.org)

19.5.1.2 Serving Gateway (S-GW):

The gateways (Serving GW and Packet Data Network GW) deal with the
user plane. They transport the IP data traffic between the User Equipment
(UE) and the external networks.

The Serving GW is the point of interconnect between the radio-side and

the EPC. As its name indicates, this gateway serves the UE by routing the
incoming and outgoing IP packets.

It is the anchor point for the intra-LTE mobility (i.e. in case of handover
between eNodeBs) and between LTE and other 3GPP accesses. It is
logically connected to the other gateway, the PDN GW.

19.5.1.3 Packet Data Network Gateway (PDN-GW):

The PDN GW is the point of interconnect between the EPC and the
external IP networks. The PDN GW routes packets to and from the PDNs.
The PDN GW also performs various functions such as IP address / IP
prefix allocation or policy control and charging. 3GPP specifies these
gateways independently but in practice they may be combined in a single
"box" by network vendors.

19.5.1.4 Mobility Management Entity (MME):

The MME deals with the control plane. It handles the signalling related to
mobility and security for E-UTRAN access. The MME is responsible for
the tracking and the paging of UE in idle-mode. It is the termination point
of the Non-Access Stratum (NAS).
19.5.1.5 Home Subscriber Server (HSS):
The HSS (for Home Subscriber Server) is a database that contains user-
related and subscriber-related information. It also provides support
functions in mobility management, call and session setup, user
authentication and access authorization.

19.5.1.6 Policy and Charging Rules Function (PCRF):

The Policy and Charging Rules Function (PCRF), is a combination of the
Charging Rules Function (CRF) and the Policy Decision Function (PDF),
and ensures the service policy and sends Quality of Service (QoS)
information for each session begun and accounting rule information.
These policies are enforced in the eNodeB.

19.5.1.7 Policy and Charging Enforcement Function (PCEF):

The Policy and Charging Enforcement Function (PCEF) performs policy
enforcement and service data flow detection, allowing data flow through
the implemented P-GW. It is also responsible for the QoS on IP packets in
the P-GW. The PCEF enforces rules that allow data packets to pass
through the gateway.

19.5.1.8 IP Multimedia Core Network Subsystem (IMS):

IMS is an all-IP system designed to assist mobile operators deliver next
generation interactive and interoperable services, cost-effectively, over an
architecture providing the flexibility of the Internet. These services include
voice, pictures, text and video, or any combination of these with existing
services. IMS has become the core component within 3G, cable TV and
next generation fixed telecoms networks which deliver Internet Protocol
multimedia to mobile users.

Fig.3: Non-roaming architecture of 3GPP Accesses (Source: 3GPP.org)

19.6 Features of Long Term Evolution (LTE):-

19.6.1 LTE is fully packet-switched IP-based mobile communication standard

from 3GPP. Both real time services and datacom services will be carried
out by IP protocol. LTE network assigns the network resources to users
and applications depending on the actual transmission demand.

19.6.2 LTE introduces a simplified core network called Evolved Packet Core
(EPC) with fewer elements than in the legacy standards.

19.6.3 The new access solution, LTE, is based on OFDMA (Orthogonal

Frequency Division Multiple Access) and in combination with higher order
modulation (up to 64QAM), large bandwidths (up to 20 MHz) and spatial
multiplexing in the downlink (up to 4x4) high data rates can be achieved.

For the downlink, OFDMA (Orthogonal Frequency Division Multiple

Access) is used and for the uplink SC-FDMA (Single Carrier - Frequency
Division Multiple Access) is used which is also known as DFT (Discrete
Fourier Transform) spread OFDMA.

The new radio interface offers much higher spectral efficiency than any
other legacy mobile communication standard. Modulation and coding
schemes are dynamically chosen in LTE based on the radio conditions
and the traffic demand. The link adaptation mechanism allows the network
to balance between throughput and reliability of the radio transmission.

Fig.-4: OFDMA and SC-FDMA (Source: 3GPP.org)

19.6.4 Frequency:
LTE is developed for a number of frequency bands – E-UTRA operating
bands- currently ranging from 700 MHz up to 2.7GHz. The available
bandwidths are also flexible starting with 1.4 MHz up to 20 MHz. LTE
supports both the time division duplex technology (TDD) as well as
frequency division duplex (FDD).
19.6.5 Spectral Flexibility:

19.6.5.1 E-UTRA shall operate in spectrum allocations of different sizes, including

1.25 MHz, 1.6 MHz, 2.5 MHz, 5 MHz, 10 MHz, 15 MHz and 20 MHz in
both the uplink and downlink. Operation in paired and unpaired spectrum
shall be supported.

19.6.5.2 The system shall be able to support content delivery over an aggregation
of resources including Radio Band Resources (as well as power, adaptive
scheduling, etc) in the same and different bands, in both uplink and
downlink and in both adjacent and non-adjacent channel arrangements. A
“Radio Band Resource” is defined as all spectrum available to an
operator.

19.6.6 Peak data rate (Spectral Efficiency):

19.6.6.1 Instantaneous downlink peak data rate of 100 Mb/s within a 20 MHz
downlink spectrum allocation (5 bps/Hz)

19.6.6.2 Instantaneous uplink peak data rate of 50 Mb/s (2.5 bps/Hz) within a
20MHz uplink spectrum allocation)

19.6.6.3 The highest theoretical peak data rate on the transport channel is 75 Mbps
in the uplink, and in the downlink, using spatial multiplexing, the rate can
be as high as 300 Mbps.

19.6.7 Transmission Latency:

19.6.7.1 Control-plane latency : 100 ms

19.6.7.2 User-plane latency : 5 ms

19.6.8 Control-plane capacity :

At least 200 users per cell should be supported in the active state for
spectrum allocations up to 5 MHz.

19.6.9 Mobility:

19.6.9.1 E-UTRAN should be optimized for low mobile speed from 0 to 15 km/h.

19.6.9.2 Higher mobile speed between 15 and 120 km/h should be supported with
high performance.

19.6.9.3 Mobility across the cellular network shall be maintained at speeds from
120 km/h to 350 km/h (or even up to 500 km/h depending on the
frequency band).
19.6.10 Coverage:
Throughput, spectrum efficiency and mobility targets above should be met
for 5 km cells, and with a slight degradation for 30 km cells. Cells range up
to 100 km should not be precluded.

19.6.11 Enhanced Multimedia Broadcast Multicast Service (MBMS) :

19.6.11.1 While reducing terminal complexity: same modulation, coding, multiple

access approaches and UE bandwidth than for unicast operation.

19.6.11.2 Provision of simultaneous dedicated voice and MBMS services to the

user.

19.6.11.3 Available for paired and unpaired spectrum arrangements.

19.6.12 Co-existence and Inter-working with 3GPP Technology :

19.6.12.1 Co-existence in the same geographical area and co-location with

GERAN/UTRAN on adjacent channels.

19.6.12.2 E-UTRAN terminals supporting also UTRAN and/or GERAN operation

should be able to support measurement of, and handover from and to,
both 3GPP UTRAN and 3GPP GERAN.

19.6.12.3 The interruption time during a handover of real-time services between E-

UTRAN and UTRAN (or GERAN) should be less than 300 msec.

19.6.13 Architecture and migration :

19.6.13.1 Single E-UTRAN architecture

19.6.13.2 The E-UTRAN architecture shall be packet based, although provision

should be made to support systems supporting real-time and
conversational class traffic

19.6.13.3 E-UTRAN architecture shall minimize the presence of “single points of

failure”

19.6.13.4 E-UTRAN architecture shall support an end-to-end QoS

19.6.13.5 Backhaul communication protocols should be optimized

19.6.14 Radio Resource Management requirements :

19.6.14.1 Enhanced support for end to end QoS

19.6.14.2 Efficient support for transmission of higher layers

19.6.14.3 Support of load sharing and policy management across different Radio
Access Technologies

19.6.15 Complexity :

19.6.15.1 Minimize the number of options

19.6.15.2 No redundant mandatory features

19.6.16 LTE is the latest family of mobile communication standards. Hence, it has
much lower obsolescence risk than any of the previous standards.

19.7 Mobile Train Radio Communication System (LTE-R) :-

Fig.5:- LTE-R Architecture

LTE for Railways (LTE-R) consists of User Equipments, Evolved Universal

Terrestrial Radio Access Network, Evolved Packet Core, IP Multimedia
Subsystem and Mission-Critical Push To Talk (MCPTT) application. The
LTE-R systems are compatible with modern train automation systems like
European Train Control System (ETCS) or similar and also interoperable
with other legacy mobile communication systems such as GSM and
UMTS.
19.8 Communication Requirement of Railways through LTE-R (Future
Railway Mobile Communication System):-

This section looks at various Railway requirements/features as listed by

UIC and how it can be satisfied using the LTE based architecture. Indian
Railways may include its all other specific requirements as implemented in
GSM-R.

19.8.1 Users in FRMCS:

The following users are those identified to be users within this document
and may not be necessarily conclusive within FRMCS:-
● Driver(s)
● Controller(s)
● Train staff:
o Train conductor(s)
o Catering staff
o Security staff
● Trackside staff:
o Trackside maintenance personnel
o Shunting team member(s)
● Railway staff (excl. all of above):
o Engine scheduler(s)
o RU operator(s)
o Catering scheduler(s)
o IM operator(s)
o Engineering personnel
● Station manager(s)
o Station personnel
o Depot personnel
o Etc.
● Members of the public:
o Passengers (on trains, on platforms, at stations, etc.)
o Other persons (on platforms, at level crossings, etc.)
● Systems:
o ATC on-board system
o ATO on-board system
o On-board system
o Ground system
o Trackside warning system
o Trackside system
o Sensors along trackside
o Trackside elements controlling entities (such as, for example,
for level crossings)
o Applications (such as, for example, those for monitoring lone
workers, for remote controlling of elements)
● Network operator
 ● Public emergency operator

19.8.2 Communication requirements:-

● Critical: applications that are essential for train movements and safety
or a legal obligation, such as emergency communications, shunting,
presence, trackside maintenance, ATC, etc.
● Performance: applications that help to improve the performance of the
railway operation, such as train departure, telemetry, etc.
● Business: applications that support the railway business operation in
general, such as wireless internet, etc.

These are the following sub-sections which are in line with the UIC
FRMCS document.

Critical Communication Applications

Performance Communication Applications
Business Communication Applications
Critical Support Applications
Performance Support Applications
Business Support Applications

Fig.-6: Grouping of FRMCS Applications (Source: uic.org)

19.8.3 Critical Communication Applications:-

19.8.3.1 On-train outgoing voice communication from the driver towards the
controller(s) of the train:
The driver shall be able to initiate a voice communication to any controller
that was, is, or will be responsible for the movement of the train.
19.8.3.2 On-train incoming voice communication from the controller towards a
driver:
An authorized controller shall be able to set up a voice communication to a
driver.

19.8.3.3 Multi-train voice communication for drivers including ground user(s):

The driver shall be able to set up a voice communication with entitled
ground user(s) and/or other drivers. A ground user shall be able to set up
a voice communication with drivers and other entitled ground user(s). The
selection could be based on the location of the train, on the track
configuration, etc. using a functional identity. The voice communication
can be bi-directional or uni-directional.

19.8.3.4 Banking voice communication:

Drivers of different locomotives within the same train shall be able to set
up voice communication. During the ongoing voice communication an
entitled controller can connect to the communication without any action of
the driver(s). The driver is able to invite an entitled controller to connect to
the communication.
Note – the different locomotives within the same train may or may not be
coupled mechanically and/or electrically.

19.8.3.5 Trackside maintenance voice communication:

A trackside worker or controller shall be able to set up a voice
communication with other authorized users. The voice communication can
be bi-directional or unidirectional.

19.8.3.6 Shunting voice communication:

A shunting user shall be able to set up an uninterrupted voice
communication with other shunting users and/or with entitled controller(s).
The voice communication could be a user-to-user or multi-user
communication. The entitled controller and other shunting users are
addressed by the system automatically (for example, based on location,
operational situation etc.).

19.8.3.7 Public emergency call:

A user is able to make a public emergency call.

19.8.3.8 Ground to ground voice communication:

A ground user shall be able to set up voice communication to another
ground user.

19.8.3.9 Automatic train control communication:

The provision of a reliable communication bearer to support the
implementation of radio based ATC systems. The ATC system shall have
a reliable communication bearer in order to ensure efficient data transfer
 between the on-board system and the ground system. (for example ETCS
L2/L3, CBTC, CTCS) , or between a train and other trains or between a
train and other trackside elements. This application provides the
communication bearer for this data,

19.8.3.10 Automatic train operation communication:

● The ATO system shall have a reliable communication bearer in order
to ensure efficient data transfer between the on-board unit and the
ground system, or between a train and other trains or between a train
and other trackside elements. This application provides the
communication bearer for this data.
● The ATO system components (on-board unit, the ground system or
other ATO entities in the trackside) may broadcast information to other
ATO system components.
● This application may include real time video between the on-board and
the ground system (for example a train mounted front camera) or
between other ATO system components.

19.8.3.11 Data communication for Possession management:

The application shall support the processes involved in taking possession
of an area of railway infrastructure for engineering purposes (for example
for track maintenance).

19.8.3.12 Trackside maintenance warning system communication:

The trackside maintenance warning system shall be able to initiate data
communication to trackside maintenance workers in the appropriate area.

19.8.3.13 Remote control of engines communication:

It shall be possible to set up data communication between an engine and
a ground based system in order to control the engine. The remote driver
can operate the engine via the ground system.

19.8.3.14 Monitoring and control of critical infrastructure:

It shall be possible to set up data communication between infrastructure
systems and a ground based or train based system in order to monitor or
control critical infrastructure such as train detection, signals and indicators,
movable infrastructure, level crossing elements, including barrier controls
vehicle sensors, lighting controls and alarms.

19.8.3.15 Railway emergency communication:

An authorized user shall be able to set up a railway emergency
communication to other users within an automatically configured area or
group, which is based upon the originator’s location or characteristics and
those users likely to be affected by the emergency

19.8.3.16 On-train safety device to ground communication:

 Based on a critical situation in the train (for example, triggered by a Driver
Safety Device (DSD)), a voice and/or data communication is automatically
set up towards a ground user (controller or ground system).

19.8.3.17 Public train emergency communication:

● This application allows any entitled user involved in train operations to
alert, via a voice and/or data communication, the drivers of the
concerned trains of a safety related incident in the vicinity of railway
infrastructure; for example, at a platform environment or a level
crossing: a person falling from a platform or slipping between train and
platform or a car being stuck on a level crossing. An entitled user in
this case could be a member of the public.
● The controller of the affected track/line(s) shall also be made aware of
the alert and shall be able to have voice communication with the alert
initiator.

19.8.3.18 Working alone:

The system shall be able to monitor the status (location, movements,
health, etc.) of a user working alone. Once the application is active, the
application can trigger voice and/or data communication applications
based on the status of the worker.

19.8.3.19 Voice Recording and access to the recorded data:

It shall be possible to enable the recording of, and access to,
communication content and the communication related data in order to
support analysis.

19.8.3.20 Data recording and access:

It shall be possible to enable the recording of, and access to,
communication content and the communication related data in order to
support analysis.

19.8.3.21 Shunting data communication:

A shunting user (e.g. the shunting leader) shall be able to set up an
uninterrupted data communication with other shunting users (e.g. the
driver) and/or with entitled controller(s)/traffic control system. The purpose
of this data communication is issuing request/commands and
confirmations related to shunting operation. The entitled controller and
other shunting users are addressed by the system automatically (for
example, based on location, operational situation etc.).

19.8.3.22 Train integrity monitoring data communication:

The train integrity monitoring system shall have a reliable communication
bearer in order to ensure safety related data be transfered between the
components monitoring train integrity. The FRMCS system shall provide
the communication bearer for this data exchange.
19.8.3.23 Public emergency warning:
A user is able to receive a public emergency warning initiated by the
Public Safety Authority.

19.8.3.24 On-train outgoing voice communication from train staff towards a ground
user:
The train staff shall be able to initiate a voice communication to any
ground user.

19.8.3.25 On-train incoming voice communication from a ground user towards train
staff
A ground user shall be able to initiate a voice communication to train staff.

19.8.3.26 Railway staff emergency communication:

An authorized user, is able to set up a railway staff emergency
communication to other users within an automatically configured area or
group. The area or group is based upon the originator’s location or
characteristics and includes those users likely to assist the originator with
the emergency.

19.8.3.27 Critical Real time video:

This application facilitates the data communication for real time
transmission of video images (“video images” may also refer to images
coming from other sources, e.g. lidar and/or radar sensors) for critical
railway operation. This includes the control of camera movements and –
zoom.

19.8.3.28 Critical Advisory Messaging services- safety related:

A user shall be able to send and/or receive critical messages, safety
related, like (predefined or any) text or pre-recorded voice messages to
instruct railway staff about the usage of the infrastructure (for example
speed restrictions, overriding of a stopping point). Messages can be
exchanged on user-to-user or on multi-user level.

19.8.3.29 Virtual Coupling data communication:

The Virtual Coupling system shall have a reliable communication bearer in
order to ensure that the safety related data is transferred between the
components making part of the Virtual Coupling system. The FRMCS
system provides the communication bearer for this data exchange.

19.8.3.30 On-train wireless backbone communications:

The enabling of a train-wide communication network requires the provision
of a reliable communication bearer to support the implementation of the
Wireless Train Backbone (WLTB). The WLTB shall have a reliable
communication in order to ensure the efficient data transfer between the
 on-train Wireless Train Backbone nodes of each rolling stock element in a
single train. The FRMCS system provides the communication bearer for
this data exchange.

19.8.3.31 Train parking protection:

An authorized user shall be able to store information about the protection
means of a parked train in a centralized application. The information can
be entered manually or be generated by a sensor.

19.8.4 Performance Communication Applications:-

19.8.4.1 Multi-train voice communication for drivers excluding ground user(s):

A driver shall be able to set up a voice communication to all drivers within
an automatically configured area that is based upon the originator’s
location.

19.8.4.2 On-train voice communication:

A member of the train staff shall be able to initiate a voice communication
with one or multiple other members of the train staff (of the same train)

19.8.4.3 Lineside telephony:

A user shall be able to set up a voice communication to an entitled
controller via lineside telephony.

19.8.4.4 On-train voice communication towards passengers (public address):

● A user shall be able to broadcast voice information to all passengers of
one or multiple trains.
● The broadcasted information could be real-time or pre-recorded.

19.8.4.5 Station public address:

● A user shall be able to broadcast vocal information to all passengers at
specific locations such as station concourses and platforms.
● The broadcast information could be real-time or pre-recorded.

19.8.4.6 Communication at stations and depots:

The station or depot user shall be able to set up a voice communication
with other user(s).

19.8.4.7 On-train telemetry communications:

It shall be possible to set up data communication between on-train
systems (on the same train or between 2 different trains) or between on-
train systems and a ground based system.

19.8.4.8 Infrastructure telemetry communications:

 It shall be possible to set up data communication between infrastructure
systems and/or a ground based system (for example, to support demand
forecasting and response, equipment supervision etc.).
Note: the data communication can be permanent or intermittent.

19.8.4.9 On-train remote equipment control:

A ground based system shall be able to initiate a data communication to
relevant on train systems for control purposes,

19.8.4.10 Monitoring and control of non-critical infrastructure:

It shall be possible to set up data communication between non-critical
infrastructure systems and railway staff or a ground based or an on-board
system in order to monitor and control those infrastructure systems
remotely.

19.8.4.11 Non-critical Real time video:

This application facilitates the data communication for real time
transmission of video images for non-critical railway operation. This
includes the control of camera movements and –zoom.

19.8.4.12 Wireless on-train data communication for train staff:

Train staff shall be able to use intranet/internet services via a wireless
connection in a train.

19.8.4.13 Wireless data communication for railway staff on platforms:

It shall be possible for railway staff or railway systems to use
intranet/internet services via a wireless connection in railway areas (for
example platforms, station areas etc.).

19.8.4.14 Train driver advisory - train performance:

A user shall be able to set up data communication to provide advisory
information to the train driver in order to optimize the train journey (for
example Driver Advisory System (DAS), Traffic management (TM), Power
consumption management).

19.8.4.15 Train departure data communications:

A user shall be able to set up data communications with other involved
users to support the station departure processes.

19.8.4.16 Messaging services:

A user shall be able to send and receive non-critical messages like text,
recorded voice (for example voicemail), data, pictures, video. Messages
can be exchanged on user-to user or a user-to-multi user level.

19.8.4.17 Transfer of data:

 Transfer of recorded data for post-accident/incident analysis (for example,
CCTV, JRU, energy metering data), or any other data that requires to be
transferred between users, for example, data from train staff, time table
data.

19.8.4.18 Record and broadcast of information:

A user shall be able to record a voice or a video information that can
subsequently be transmitted to selected users based on their identity
and/or location.

19.8.4.19 Transfer of CCTV archives:

A user shall be able to bulk transfer CCTV archives between on-board
systems or between on-board system and a ground system.

19.8.4.20 Real time video call:

A user shall be able to setup a real time video call to other user(s).

19.8.4.21 Augmented reality data communication:

● A user shall be able to setup an augmented reality data communication
to the ground system. The ground system overlays information to the
video stream presented to the user.
● Once a user is connected to the ground system, the controller is able
to view the augmented reality images visible for the user.
● The controller is able to add information (or guidance) via the ground
system in the augmented reality view which is visible to the user.

19.8.5 Business Communication Applications :-

19.8.5.1 Information help point for public:

A member of the public shall be able to set up a voice communication with
the responsible ground user or train staff.

19.8.5.2 Emergency help point for public:

A member of the public shall be able to set up an emergency voice
communication that will be automatically routed to the most appropriate
ground user, train staff or driver.

19.8.5.3 Wireless internet on-train for passengers:

It shall be possible for passengers to use internet services via a wireless
connection in a train.

19.8.5.4 Wireless internet for passengers on platforms:

It shall be possible for passengers to use internet services via a wireless
connection in railway area(s) (for example platforms, station area(s) etc.).
19.8.6 Critical Support Applications:-

19.8.6.1 Assured Voice Communication

The Assured Voice Communication application shall provide a clear
indication to the users as soon as an end-to-end voice communication link
is broken or as long as the end-to-end communication link is active.

19.8.6.2 Multi user talker control:

● The system shall be able to limit the number of simultaneous talkers in
a multi-user voice communication.
● An entitled user shall be able to select and de-select user(s) being able
to talk in a multi-user voice communication.

19.8.6.3 Role management and presence:

● A user shall be able to register and deregister to one or more
functional identity/ies. A user is able to see which other functional
identities are present within a certain context (for example train, region,
communication group, Railway Emergency Communication, etc.).
Further it shall be possible for the user to identify at any time the
function / person who is talking (for example driver, train staff,
maintenance staff, platform staff, controller, etc.).
● This application will be responsible for handling the railway role
management of the users including the identity registration and
deregistration processes.

19.8.6.4 Location services:

The system shall be able to store and provide the location of the user(s) or
devices.

19.8.6.5 Authorization of communication:

The system shall be configurable, so that access to voice and data
communications can be controlled through the use of identities.

19.8.6.6 Authorization of application:

The system shall be configurable, so that access to applications can be
controlled through the use of, for example: identity; user; user-to-user;
multi-user; location, etc. The system is able to authorize access to
applications.

19.8.6.7 QoS Class Negotiation:

The system shall be able to assign different QoS classes in order to fulfill
the level of communication quality required by the applications.

19.8.6.8 Safety application key management communication:

 The applications on board shall be able to authenticate the source of the
messages received as a trusted source, and shall be able to detect
corruption of the messages received.

19.8.6.9 Assured data communication:

The assured data communication application shall provide a clear
indication to the users as soon as an end-to-end data communication link
is broken or as long as the end-to-end communication link is active.

19.8.6.10 Inviting-a-user messaging:

A user can send a message to another user(s) inviting him to join the
ongoing voice communication.

19.8.6.11 Arbitration:
The system shall be able to perform arbitration between communications
competing for the attention of the user.

19.8.7 Performance Support Applications:-

None applicable.

19.8.8 Business Support Applications:-

19.8.8.1 Billing information:

An entitled user shall be able to obtain information for any type of on-
network communication from the FRMCS system in order to be able to
generate bills.

19.9 LTE-R System Architecture for Indian Railways:-

Installing an Ultra-high-speed LTE based communication corridor along IR

network would cater to the current and future data and voice needs for
Train-Ground and Train-Train communication for improved train
operations, passenger safety and passenger security services and remote
rail asset monitoring & management. The applications of LTE can be
classified under the following three broad categories:-

19.9.1 Passenger Safety & Service:

● Advanced Signalling systems like European Train Control System
(ETCS) Level 2.
● Emergency communications from train to control, train to stations and
between train to train, etc.
● Increased carrying capacity (throughput) Advanced signaling systems
allow more trains to run across a given point or segment of the track
 which effectively increase the carrying capacity (throughput) of the
same fixed civil and electrical infrastructure.

19.9.2 Live surveillance camera feeds from trains will ensure security of
passengers coupled with video analytics, this can help in prevention and
detection of crime, not only in Indian Railways network but also outside in
the peripheral areas.

19.9.3 Internal improved Railway management:

● Staff communication system.
● Remote monitoring of Railways asset to improve their availability.

Fig.-7: LTE-R System Architecture for Indian Railways

19.9.4 Indian Railway envisages following applications/facilities which will fuel

growth in data usage on deploying LTE technology:
● Mission Critical Passenger Safety Services & Applications through
ETCS Level 2 or similar Railway Signalling system on IR.
● Video Surveillance (Live Feed) through CCTV cameras in trains along
with Video Analytics for Passenger Security.
● Faster data network Communication for voice, video and other related
application.
● More network-enabled devices (IoT based Asset reliability Monitoring).
● Providing Wi-Fi facility in trains.
● Train and way side Telemetry through Mobile communications.

19.10 TRAI Frequency Band Allocation and Recommendations:-

19.10.1 TRAI has recommended allocation of 5 MHz (paired) in 700 MHz band to
Indian Railways for implementing ETCS Level-2, MC PTT + Voice, IoT
based assets monitoring services, Passenger information display system
and live feed of Surveillance of few coaches at a time. The TRAI
recommendations are as below:-

19.10.1.1 Out of 35 MHz (paired) spectrum available in 700 MHz band, 5 MHz
(paired) spectrum may be allocated to Indian Railways for implementing
ETCS Level-2, MC PTT + Voice, IoT based assets monitoring services,
Passenger information display system and live feed of Surveillance of few
coaches at a time.

19.10.1.2 To implement the video surveillance for all coaches of the train (Security
Services), Indian Railways may explore other communications means
such as-
● Dumping the video surveillance data to the system using high capacity
Wi-Fi when the train reaches a station.
● Using public telecommunication network (TSPs network) for sending
continuous video surveillance data streams to its control centre.

19.11 LTE-R Frequency Spectrum for Indian Railways:-

5 MHz (paired) in 700 MHz band (703-748 MHz Uplink & 758-803 MHz
Downlink)

This frequency band (E-UTRA Operating Band 28) is spanning from 703-
748 MHz/758-803 MHz, occupying a total of 45 MHz paired spectrum (and
a centre gap of 10 MHz). 10 MHz paired spectrum of this band had been
allocated for Defense use and 35 MHz available in this band out of which
5 MHz (paired) has been recommended to be allocated to Railways for
LTE-R.

19.12 Bandwidth Requirement for LTE-R for Indian Railways:-

The Bandwidth requirement has been stipulated as under for Operational

Requirement (A), IoT services (B) and all services i.e. Operational
Requirement + IoT Services + On Board Video Surveillance (A+B+C).

S. Application One Train 2 Trains*

No. (downlink & (downlink &
uplink) uplink)
Normal Abnorma Normal Abnorma
Conditio l Conditio l
n Conditio n Conditio
n n
1 ETCS Level-2 100 Kbps 200 Kbps
 2 MC PTT 660 Kbps 1320 Kbps
Voice** 750 2400 750 2400
Kbps Kbps Kbps Kbps
3 Passenger Information Display 100 Kbps 200 Kbps
System
(A)Operational Requirement(1+2+3) 1.61 3.26 2.47 4.12
(Approx.) (Mbps)
(B) IoT services (Mbps) 2.0 4.0
(A+B) (Mbps) 2.61 5.26 6.47 8.12
(C) On Board Video Surveillance*** 1.5 4.5 3.0 6.0
(Approx.) (Mbps)
Total (A+B+C) (Mbps) 5.11 9.76 9.47 14.12

Table-1: Bandwidth Requirement for LTE-R for Indian Railways

Assumptions:

* Considering 2 trains between two adjacent eNodeB.

** Total no. users between two adjacent eNodeB are taken as
maximum 60. In normal situation, active users are 25% of total
users. In abnormal situation, active users are 80% of the total
users.
*** One Camera Stream (1500 Kbps) per Train in normal condition & 3
Camera Streams in abnormal situations.

MIMO All Transmission

SISO Transmit
Transmission No of 2x2 Mode
Mode/System Useable
Bandwidth Resourc Downlink Downlink Downlink Uplink Peak Uplink Peak
e Block Peak Peak Peak (Mbps) (Mbps)
(Mbps) (Mbps) (Mbps) 16 QAM 64 QAM

1.4 MHz 6 4.4 4.4 8.8 3 4.4

3 MHz 15 11.1 11.1 22.1 7.5 11.1
5 MHz 25 18.3 18.3 36.7 12.6 18.3
10 MHz 50 36.7 36.7 75 25.5 36.7
15 MHz 75 55.1 55.1 110 37.9 55.1
20 MHz 100 75 75 150 51 75

Table.-2: LTE FDD System Throughput

19.13 Uniform Numbering Scheme for Mobile Communication Network for
Indian Railways :-

A) All mobile users in the LTE-R network must be assigned a certain

addresses or identities in order to identify, authenticate and localize them.
The following numbers and identities are assigned for administration of
each mobile station in the network.
i) IMSI : International Mobile Subscriber Identity

The IMSI is a string of decimal digits, up to a maximum length of 15

digits, which identifies a unique subscription. The IMSI consists of
three fields: the mobile country code (MCC), the mobile network
code (MNC), and the mobile subscription identification number
(MSIN).

▪ Mobile country code (MCC): The MCC is the first field of the
IMSI and is three digits in length and identifies a country.
▪ Mobile network code (MNC): The MNC is the second field of
the IMSI, it is two or three digits in length and is administered
by the respective national numbering plan administrator.
▪ Mobile subscription identification number (MSIN): The MSIN
is the third field of the IMSI, it is up to 10 digits in length, and
is administered by the relevant MNC assignee to identify
individual subscriptions.

Fig.-8 : Structure and Format of IMSI (Source ITU)

ii) MS ISDN : Mobile Subscriber International Subscriber Directory

Number

Mobile Station/Subscriber International Subscriber Directory

Number (MSISDN) is a number (Mobile Phone Number) used to
identify a mobile phone number internationally.

The MSISDN composition follows the international ISDN numbering

plan with the following structure:

▪ Country Code (CC), up to three digits;

 ▪ National Destination Code (NDC), typically two or three
digits;
▪ Subscriber Number (SN), a maximum of 10 digits.

The structure of the MSISDN will then be as shown in figure:

Fig.-9 : Number Structure of MSISDN (Source 3GPP)

RDSO has approved and issued Uniform Numbering Scheme for Mobile
Communication Network (GSM-R) for Indian Railways. The same scheme
shall be applicable for LTE-R.

The IMSI and MSISDN for Indian Railway shall be as below:-

Fig.-10 : IMSI
 Fig.-11 : MSISDN

19.14 Adaptation of LTE-R on Indian Railways:-

Indian Railway is migrating from GSM-R to LTE-R for Railway Automation

System and Broadband Services. It is proposed that the future projects of
Railway Automation System and Broadband Services may be designed
with LTE. It is also required that LTE system proposed for Indian Railways
should be fit for bearer network for ETCS Level 2 for desired speed.

-x-x-x-