technical advisory note (tan) on implementation of lte on
TRANSCRIPT
Page 1 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Technical Advisory Note (TAN)
on
Implementation of LTE on Indian Railways
Document No. STT/TAN/LTE/2021, Version 1.0
TELECOM DIRECTORATE
RESEARCH DESIGNS & STANDARDS ORGANISATION
LUCKNOW-226011
512995/2021/O/o ED/Tele-I/RDSO231
Page 2 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Contents
S. No. Items Page No.
1.0 Scope
2.0 General Requirements
3.0 Architecture of LTE for Indian Railways
Section A General Description and Functional Requirements of LTE
4.0 General Description and Architecture of LTE System
5.0 Functional Requirements of LTE – Radio Access Network
(E-UTRAN)
5.1 E-UTRAN Interface Requirements
5.2 E-UTRAN Functional Requirements
5.3 System Specification of eNodeB
5.4 eNodeB (BBU & RRH) Requirements
6.0 Functional Requirements of Evolved Packet Core (EPC)
6.1 Mobility Management Entity (MME)
6.2 Serving Gateway (S-GW)
6.3 Packet Data Network Gateway (PDN-GW)
6.4 Home Subscriber Server (HSS)
6.5 Policy and Charging Rule Function (PCRF)
7.0 Communication Requirements : Future Railway Mobile
Communication System ( FRMCS)
8.0 Mission Critical Services Requirements
9.0 LTE (Network access and eNodeB) Security Requirements
Section B Dimensioning and Implementation of LTE
10.0 System Dimensioning
10.1 Input Data for System Design
10.2 Data rate requirements of IR in LTE
10.3 Cell Edge Throughput and Cell Capacity Calculations
10.4 Design Inputs for Radio Network Planning
10.5 Link Budget
10.6 Path Loss Calculation
10.7 Cell Range and Inter eNodeB Distance
10.8 Dimensioning of Evolved Packet Core (EPC)
10.9 Network ID Planning & Numbering Scheme
10.9.1 Physical Cell Identity Planning
10.9.2 Numbering Scheme for LTE Network of Indian Railways
10.10 Tower Drawings and Dimensions
512995/2021/O/o ED/Tele-I/RDSO232
Page 3 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
11.0 User Equipment (UE) Requirements
12.0 Quality of Service (QOS) Requirements
13.0 Reliability, Availability, Maintainability and Safety (RAMS)
Requirements
14.0 Security Aspects and Requirements
15.0 Regulatory Approvals and Certifications and Environmental
Requirements
16.0 Planning, Positioning and Deployment of EPC over Indian Railway
network.
512995/2021/O/o ED/Tele-I/RDSO233
Page 4 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
1.0 SCOPE:
1.1 Long Term Evolution (LTE) for Railways, the next generation Mobile Train Radio
Communication System is planned to cater Indian Railways’ present and future
demands of voice and data. The following main applications/solutions are to be
implemented on LTE:-
i) Mission Critical Passenger Safety Services & Applications through Train
Collision Avoidance System (TCAS) on IR which is planned for up
gradation to ETCS Level 2 in future.
ii) Video Surveillance through CCTV cameras in trains along with Video
Analytics for Passenger Security and Wi-Fi facility for Passenger
information System in trains
iii) Internet of Things (IoT) based Asset reliability monitoring through LTE
1.2 In order to make uniform, cost effective, integrated and standard system over Indian
Railways, a Technical Advisory Note (TAN) on LTE for Indian Railways has been
prepared which includes the followings along with other items :-
i) Architecture of LTE system for Indian Railways
ii) Design inputs for Radio Network Planning, Cell Range and Inter site
(eNodeB) Distance
iii) Dimensioning of EPC (Evolved Packet Core)
iv) Planning, Positioning and Deployment of EPC over Indian Railway
network.
512995/2021/O/o ED/Tele-I/RDSO234
Page 5 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
2.0 General Requirements:
2.1 The LTE (i.e. both Radio and Core Network Evolution) Mobile
Communication System shall be based on 3GPP/ETSI LTE (4G)
Specifications.
2.2 The LTE shall be upgradable to further 3GPP Specification Releases and
Future Rail Mobile Communication Standard (FRMCS) being developed by
UIC.
2.3 The LTE shall be interoperable with other legacy mobile communication
systems such as GSM network of Indian Railways.
2.4 Train Collision Avoidance System (TCAS), Distributed Power Wireless
Control Systems (DPWCS)/LOCOTROL and EoTT (End of Train Telemetry)
and such other systems developed and deployed by Indian Railways are
presently being installed using UHF communication system. The LTE shall be
compatible and suitable bearer network for all above applications.
2.5 The LTE shall be compatible and suitable bearer network for Indian Railway
specific applications such as Train Protection Warning System (TPWS). It
shall also be compatible and suitable bearer network with modern Train
Automation & Protection System like European Train Control System (ETCS)
or similar for operation at desired speed.
2.6 LTE Frequency Spectrum for Indian Railways:-
The system shall be designed to work in 5 MHz (paired) in 700 MHz band
(703-748 MHz Uplink & 758-803 MHz Downlink) recommended for
allocation to Indian Railways.
2.7 LTE shall be able to support both the Time Division Duplex technology
(TDD) as well as Frequency Division Duplex (FDD). The system shall support
different carrier bandwidth (Size) starting with 1.4 MHz up to 20 MHz as per
3GPP specification.
2.8 The LTE shall be suitable for Indian Railway Train speeds from 0 - 250
Kmph.
2.9 The 230 V/ 50 Hz AC nominal Electrical Power Supply available in Indian
Railway premises with suitable stabilisation shall be provided for LTE.
2.10 The equipment shall be manufactured in accordance with the relevant
international quality standards (ISO Standards or similar) for which the
manufacturer has to be duly accredited.
512995/2021/O/o ED/Tele-I/RDSO235
Page 6 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
3.0 LTE System Architecture for Indian Railways:
3.1 LTE for Railways 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 systems shall
be interoperable with other legacy Railway mobile communication systems
such as GSM.
Fig.-1 : LTE System Architecture for Indian Railways
3.2 The following applications/solutions are to be implemented on LTE:-
i) Mission Critical Passenger Safety Services & Applications through Train
Collision Avoidance System (TCAS) on IR which is planned for up
gradation to ETCS Level 2 in future.
ii) Video Surveillance through CCTV cameras in trains along with Video
Analytics for Passenger Security and Wi-Fi facility for Passenger
information System in trains.
iii) Level Crossing Gate Video Surveillance through CCTV for train drivers
in locomotives
iv) Internet of Things (IoT) based Asset reliability monitoring through LTE.
3.3 The System shall support for V2V services based on LTE sidelink and LTE-
based V2X Services.
512995/2021/O/o ED/Tele-I/RDSO236
Page 7 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Section A
4.0 General Description and Architecture of LTE System:
4.1 3GPP Evolved Packet System (EPS) is Packet Switched Domain which
provides IP connectivity using the Evolved Universal Terrestrial Radio Access
Network (E-UTRAN).
4.2 EPS consists of EPC and E-UTRAN where User Equipment (UE) is connected
to the EPC over E-UTRAN (LTE access network). The Evolved NodeB
(eNodeB) is the base station for LTE radio. The EPC is composed of four
network elements: the Serving Gateway (Serving GW), the PDN Gateway
(PDN GW), the MME and the HSS. The EPC is connected to the external
networks, which can include the IP Multimedia Core Network Subsystem
(IMS).
SGi
S12
S3
S1-MME
PCRF
Gx
S6a
HSS
Operator's IP Services
(e.g. IMS, PSS etc.)
Rx
S10
UE
SGSN
LTE-Uu
E-UTRAN
MME
S11
S5 Serving Gateway
PDN Gateway
S1-U
S4
UTRAN
GERAN
Fig-2: LTE Architecture
4.2 The following are the logical functions (high level functions) performed within
EPS.
- Network Access Control Functions.
- Packet Routing and Transfer Functions.
- Mobility Management Functions.
- Security Functions.
- Radio Resource Management Functions.
- Network Management Functions.
4.3 The EPS supports the following:-
- Selection functions
- IP network related functions
- Functionality for Connection of eNodeBs to Multiple MMEs
- E-UTRAN Sharing Function
- IMS Emergency Session Support
- Closed Subscriber Group functions
- Location Service functions
512995/2021/O/o ED/Tele-I/RDSO237
Page 8 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
4.4 Various Interfaces of EPS (Reference points) are as below:-
i) S1-MME: Reference point for the control plane protocol between E-
UTRAN and MME.
ii) S1-U: Reference point between E-UTRAN and Serving GW for the per
bearer user plane tunnelling and inter eNodeB path switching during
handover.
iii) S3: It enables user and bearer information exchange for inter 3GPP
access network mobility in idle and/or active state.
iv) S4: It provides related control and mobility support between GPRS Core
and the 3GPP Anchor function of Serving GW. In addition, if Direct
Tunnel is not established, it provides the user plane tunnelling.
v) S5: It provides user plane tunnelling and tunnel management between
Serving GW and PDN GW. It is used for Serving GW relocation due to
UE mobility and if the Serving GW needs to connect to a noncollocated
PDN GW for the required PDN connectivity.
vi) S6a: It enables transfer of subscription and authentication data for
authenticating/authorizing user access to the evolved system (AAA
interface) between MME and HSS.
vii) Gx: It provides transfer of (QoS) policy and charging rules from PCRF
to Policy and Charging Enforcement Function (PCEF) in the PDN GW.
viii) S8: Inter-PLMN reference point providing user and control plane
between the Serving GW in the VPLMN and the PDN GW in the
HPLMN. S8 is the inter PLMN variant of S5.
ix) S9: It provides transfer of (QoS) policy and charging control information
between the Home PCRF and the Visited PCRF in order to support local
breakout function.
x) S10: Reference point between MMEs for MME relocation and MME to
MME information transfer.
xi) S11: Reference point between MME and Serving GW.
xii) S12: Reference point between UTRAN and Serving GW for user plane
tunnelling when Direct Tunnel is established. It is based on the Iu-u/Gn-
u reference point using the GTP-U protocol as defined between SGSN
and UTRAN or respectively between SGSN and GGSN. Usage of S12 is
an operator configuration option.
512995/2021/O/o ED/Tele-I/RDSO238
Page 9 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
xiii) S13: It enables UE identity check procedure between MME and EIR.
xiv) SGi: It is the reference point between the PDN GW and the packet data
network. Packet data network may be an operator external public or
private packet data network or an intra operator packet data network, e.g.
for provision of IMS services. This reference point corresponds to Gi for
3GPP accesses.
xv) Rx: The Rx reference point resides between the AF and the PCRF in the
TS 23.203.
xvi) When data forwarding is used as part of mobility procedures different
user plane routes may be used based on the network configuration (e.g.
direct or indirect data forwarding). These routes can be between eNodeB
and RNC, eNodeB and SGSN, RNC and S-GW or between S-GW and
SGSN. Explicit reference points are not defined for these routes.
xvii) Protocol assumption:
- The S1-U is based on GTP-U protocol;
- The S3 is based on GTP protocol;
- The S4 is based on GTP protocol;
- The S5 is based on GTP protocol. PMIP variant of S5 is described in
TS 23.402;
- The S8 is based on GTP protocol. PMIP variant of S8 is described in
TS 23.402.
- S3, S4, S5, S8, S10 and S11 interfaces are designed to manage EPS
bearers.
4.5 The further detailed information of interfaces with other reference points are as
available in the 3GPP/ ETSI TS 23.003.
5.0 Functional Requirements of LTE – Radio Access Network (E-UTRAN):
i) The E-UTRAN consists of eNBs, providing the E-UTRA user plane
(PDCP/RLC/MAC/PHY) and control plane (RRC) protocol
terminations towards the UE. The eNBs are interconnected with each
other by means of the X2 interface. The eNBs are also connected by
means of the S1 interface to the EPC (Evolved Packet Core), more
specifically to the MME (Mobility Management Entity) by means of
the S1-MME and to the Serving Gateway (S-GW) by means of the S1-
U.The S1 interface supports a many-to-many relation between MMEs /
Serving Gateways and eNBs.
ii) The Evolved NodeB (eNodeB) is the base station for LTE radio.
eNodeB is the RAN node in the network architecture that is
512995/2021/O/o ED/Tele-I/RDSO239
Page 10 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
responsible for radio transmission to and reception from UEs in one or
more cells.
iii) RAN Architecture is shown in schematic diagram below:
eNB
MME / S-GW MME / S-GW
eNB
eNB
S1
S1
S1
S1
X2
X2X
2
E-UTRAN
Fig.-3: RAN Architecture
5.1 E-UTRAN Interface Requirements:
5.1.1 S1 Interface:
5.1.1.1 S1 User Plane Interface:
The S1 user plane interface (S1-U) is defined between the eNB and the S-GW.
The S1-U interface provides non guaranteed delivery of user plane PDUs
between the eNB and the S-GW. The transport network layer is built on IP
transport and GTP-U is used on top of UDP/IP to carry the user plane PDUs
between the eNB and the S-GW.
5.1.1.2 S1 Control Plane Interface:
The S1 control plane interface (S1-MME) is defined between the eNB and the
MME. The control plane protocol stack of the S1 interface is shown on Figure
19.2-1. The transport network layer is built on IP transport, similarly to the
user plane but for the reliable transport of signalling messages SCTP is added
on top of IP. The application layer signalling protocol is referred to as S1-AP
(S1 Application Protocol).
5.1.1.3 The following shall be the functions of S1 interface:-
i) E-RAB Service Management function:
- Setup, Modify, Release.
512995/2021/O/o ED/Tele-I/RDSO240
Page 11 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
ii) Mobility Functions for UEs in ECM-CONNECTED:
- Intra-LTE Handover;
- Inter-3GPP-RAT Handover.
iii) S1 Paging function:
iv) NAS Signalling Transport function;
v) LPPa Signalling Transport function;
vi) S1-interface management functions:
- Error indication;
- Reset.
vii) Network Sharing Function;
viii) Roaming and Access Restriction Support function;
ix) NAS Node Selection Function;
x) Initial Context Setup Function;
xi) UE Context Modification Function;
xii) UE Context Resume Function;
xiii) MME Load balancing Function;
xiv) Location Reporting Function;
xv) PWS (which includes ETWS and CMAS) Message Transmission
Function;
xvi) Overload function;
xvi) RAN Information Management Function;
xviii) Configuration Transfer Function;
xix) S1 CDMA2000 Tunnelling function;
xx) Trace function;
5.1.2 X2 Interface:
5.1.2.1 X2 user plane interface:
The X2 user plane interface (X2-U) is defined between eNBs. The X2-U
interface provides non guaranteed delivery of user plane PDUs. The transport
network layer is built on IP transport and GTP-U is used on top of UDP/IP to
carry the user plane PDUs.
5.1.2.1 X2 control plane interface:
The X2 control plane interface (X2-CP) is defined between two neighbour
eNBs. The control plane protocol stack of the X2 interface is shown on Figure
20.2-1 below. The transport network layer is built on SCTP on top of IP. The
application layer signalling protocol is referred to as X2-AP (X2 Application
Protocol).
5.1.2.3 The X2 interface specifications shall facilitate the following:
- inter-connection of eNBs supplied by different manufacturers;
512995/2021/O/o ED/Tele-I/RDSO241
Page 12 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
- support of continuation between eNBs of the E-UTRAN services offered via
the S1 interface;
- separation of X2 interface Radio Network functionality and Transport
Network functionality to facilitate introduction of future technology.
5.1.2.2 Functions of the X2 interface:-
The following shall be the functions of X2 interface:-
i) Intra LTE-Access-System Mobility Support for ECM-CONNECTED
UE:
- Context transfer from source eNB to target eNB;
- Control of user plane transport bearers between source eNB and
target eNB;
- Handover cancellation;
- UE context release in source eNB.
ii) Load Management
iii) Inter-cell Interference Coordination
- Uplink Interference Load Management;
iv) General X2 management and error handling functions:
- Error indication;
- Reset.
v) Application level data exchange between eNBs
vi) Trace functions
5.2 E-UTRAN Functional Requirements:
5.2.1 Functions of eNodeB:
The eNodeB/ eNB shall support the functions as per 3GPP specifications
including the following:
5.2.1.1 Functions for Radio Resource Management: Radio Bearer Control, Radio
Admission Control, Connection Mobility Control, Dynamic allocation of
resources to UEs in both uplink and downlink (scheduling);
5.2.1.2 IP header compression and encryption of user data stream;
5.2.1.3 Selection of an MME at UE attachment when no routing to an MME can be
determined from the information provided by the UE;
5.2.1.4 Routing of User Plane data towards Serving Gateway;
5.2.1.5 Scheduling and transmission of paging messages (originated from the MME);
5.2.1.6 Scheduling and transmission of broadcast information (originated from the
MME or O&M);
512995/2021/O/o ED/Tele-I/RDSO242
Page 13 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
5.2.1.7 Measurement and measurement reporting configuration for mobility and
scheduling;
5.2.1.8 Scheduling and transmission of PWS (which includes ETWS and CMAS)
messages (originated from the MME);
5.2.1.9 CSG handling;
5.2.2 E-UTRAN Physical Layer Requirements:
The E-UTRAN shall support 3GPP Physical Layer (Layer 1) functional
requirements.
5.2.2.1 The E-UTRAN (eNodeB) shall support the following Layer 1 requirements:-
i) Error detection on the transport channel and indication to higher layers
ii) FEC encoding/decoding of the transport channel
iii) Hybrid ARQ soft-combining
iv) Rate matching of the coded transport channel to physical channels
v) Mapping of the coded transport channel onto physical channels
vi) Power weighting of physical channels
vii) Modulation and demodulation of physical channels
viii) Frequency and time synchronisation
ix) Radio characteristics measurements and indication to higher layers
x) Multiple Input Multiple Output (MIMO) antenna processing
xi) Transmit Diversity (TX diversity)
xii) Beamforming
xiii) RF processing.
5.2.2.2 The multiple access scheme for the LTE physical layer is based on Orthogonal
Frequency Division Multiplexing (OFDM) with a cyclic prefix (CP) in the
downlink, and on Single-Carrier Frequency Division Multiple Access
(SCFDMA) with a cyclic prefix in the uplink.
5.2.2.3 To support transmission in paired and unpaired spectrum, two duplex modes
are supported: Frequency Division Duplex (FDD), supporting full duplex and
half duplex operation, and Time Division Duplex (TDD).
5.2.2.4 The modulation schemes supported in the downlink and uplink are QPSK,
16QAM and 64QAM.
5.2.2.5 i) The physical channels defined in the downlink are:
- the Physical Downlink Shared Channel (PDSCH),
- the Physical Multicast Channel (PMCH),
- the Physical Downlink Control Channel (PDCCH),
- the Physical Broadcast Channel (PBCH),
- the Physical Control Format Indicator Channel (PCFICH)
512995/2021/O/o ED/Tele-I/RDSO243
Page 14 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
- and the Physical Hybrid ARQ Indicator Channel (PHICH).
ii) The physical channels defined in the uplink are:
- the Physical Random Access Channel (PRACH),
- the Physical Uplink Shared Channel (PUSCH),
- and the Physical Uplink Control Channel (PUCCH).
iii) In addition, signals are defined as reference signals, primary and
secondary synchronization signals.
5.2.2.6 System shall also support the following procedures:-
a. Synchronisation procedures, including cell search procedure and
timing synchronisation;
b. Power control procedure;
c. Random access procedure;
d. Physical downlink shared channel related procedures, including CQI
reporting and MIMO feedback;
e. Physical uplink shared channel related procedures, including UE
sounding and HARQ ACK/NACK detection;
f. Physical shared control channel procedures, including assignment of
shared control channels;
g. Physical multicast channel related procedures
5.2.2.9 E-UTRAN shall support physical Layer measurements which include
measurements for intra- and inter-frequency handover, inter RAT handover,
timing measurements and measurements for RRM and in support for
positioning.
5.2.3 E-UTRAN Layer 2 Requirements:
5.2.3.1 The E-UTRAN shall support 3GPP Layer 2 sublayers Medium Access Control
(MAC), Radio Link Control (RLC) and Packet Data Convergence Protocol
(PDCP) for downlink and uplink.
5.2.3.2 The main services and functions of the MAC sublayer include:
a. mapping between logical channels and transport channels;
b. Multiplexing/demultiplexing of MAC SDUs belonging to one or different
logical channels into/from transport blocks (TB) delivered to/from the
physical layer on transport channels
c. scheduling information reporting;
d. Error correction through HARQ;
e. Priority handling between logical channels of one UE;
f. Priority handling between UEs by means of dynamic scheduling;
512995/2021/O/o ED/Tele-I/RDSO244
Page 15 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
g. MBMS service identification;
h. Transport format selection;
i. Padding.
5.2.3.3 The E-UTRAN shall support Control Channels i.e. Broadcast Control Channel
(BCCH), Paging Control Channel (PCCH), Common Control Channel
(CCCH), Multicast Control Channel (MCCH) and Dedicated Control Channel
(DCCH). The Traffic Channels supported shall be Dedicated Traffic Channel
(DTCH) and Multicast Traffic Channel (MTCH).
5.2.3.5 The main services and functions of the RLC sublayer include:-
a. Transfer of upper layer PDUs;
b. Error Correction through ARQ (only for AM data transfer);
c. Concatenation, segmentation and reassembly of RLC SDUs (only for UM
and AM data transfer);
d. Re-segmentation of RLC data PDUs (only for AM data transfer);
e. Reordering of RLC data PDUs (only for UM and AM data transfer);
f. Duplicate detection (only for AM data transfer);
g. Protocol error detection (only for AM data transfer);
h. RLC SDU discard (only for UM and AM data transfer);
i. RLC re-establishment.
5.2.3.6 PDCP Sub layer: The main services and functions of the PDCP sublayer for
the user plane include:-
a. Header compression and decompression: ROHC only;
b. Transfer of user data;
c. In-sequence delivery of upper layer PDUs at PDCP re-establishment
procedure for RLC AM;
d. Duplicate detection of lower layer SDUs at PDCP re-establishment
procedure for RLC AM;
e. Retransmission of PDCP SDUs at handover for RLC AM;
f. Ciphering and deciphering;
g. Timer-based SDU discard in uplink;
5.2.4 E-UTRAN Layer 3 Requirements:
The E-UTRAN shall support 3GPP Layer 3 (RRC) functional requirements.
5.2.4.1 The main services and functions of the Radio Resource Control (RRC)
include:
i) Broadcast of System Information related to the non-access stratum
(NAS);
ii) Broadcast of System Information related to the access stratum (AS);
iii) Paging;
512995/2021/O/o ED/Tele-I/RDSO245
Page 16 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
iv) Establishment, maintenance and release of an RRC connection
between the UE and E-UTRAN including Allocation of temporary
identifiers between UE and E-UTRAN, Configuration of signalling
radio bearer(s) for RRC connection and Low priority SRB and high
priority SRB.
v) Security functions including key management;
vi) Establishment, configuration, maintenance and release of point to point
Radio Bearers;
vii) Mobility functions including: UE measurement reporting and control
of the reporting for inter-cell and inter-RAT mobility; Handover; UE
cell selection and reselection and control of cell selection and
reselection; Context transfer at handover.
viii) Notification for MBMS services;
ix) Establishment, configuration, maintenance and release of Radio
Bearers for MBMS services;
x) QoS management functions;
xi) UE measurement reporting and control of the reporting;
xii) NAS direct message transfer to/from NAS from/to UE.
5.3 System Specification of eNodeB:
5.3.1 The system specification of eNodeB shall be as per the following:-
S. No. Parameter Standard
Transmitter
As per 3GPP/ ETSI TS
36.104
i) Base station output power
ii) Adjacent Channel Leakage power Ratio
(ACLR)
iii) Transmitter spurious emissions
iv) Operating band unwanted emissions
v) Transmitter inter modulation
vi) Frequency Error
Receiver
As per 3GPP/ETSI TS
36.104
i) Reference sensitivity level
ii) Dynamic Range
iii) Adjacent Channel Selectivity (ACS)
and narrow-band blocking
iv) Receiver spurious emissions
v) Receiver inter modulation
512995/2021/O/o ED/Tele-I/RDSO246
Page 17 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
5.4 eNodeB (BBU & RRH) Requirements:
5.4.1 The eNodeB architecture shall be based on a distributed architecture,
comprised of an E-UTRAN baseband unit (BBU) and Remote radio head
(RRH).
5.4.2 The interfacing between BBU and RRH shall be with Optic Fibre Cable and
compliant to the Common Public Radio Interface (CPRI) specification or
OBSAI (Open Base Station Architecture Initiative) with latest versions or
similar specifications.
5.4.3 The BBU and RRH shall be designed to work in 5 MHz (paired) in 700 MHz
band (703-748 MHz Uplink & 758-803 MHz Downlink) allocated to Indian
Railways.
5.4.4 BBU and RRH shall be able to work with the LTE spectrum flexibly. It shall
be able to work in LTE frequency bands as specified in the 3GPP
specifications. Baseband Capacity shall be upgradable and scalable.
5.4.5 The eNodeB (BBU and RRH) shall support Omni Cell and Cell Sectorization
(Sectoring) and MIMO configuration as per site requirement.
5.4.6 The eNodeB shall support Optical (MPLS) and Electrical Gigabit Ethernet
physical connection for backhaul and O&M.
5.4.7 The eNodeB shall provide a mechanism for troubleshooting and monitoring
subscriber sessions and interfaces. The eNodeB shall support remote fault
detection, self testing, remote fault mitigation, and remote fault recovery. The
network element shall support remote Software/firmware updates.
5.4.8 The eNodeB shall support nominal voltage -48 V (-44.4 to -56 V) DC or as
specified by the purchaser.
6.0 Functional Requirements of Evolved Packet Core (EPC):
The Evolved packet Core (EPC) is the Core network of LTE system composed
of four network elements: Mobility Management Entity (MME), Home
Subscriber Server (HSS), Serving Gateway (Serving GW) and Packet Data
Network Gateway (PDN GW). The EPC is connected to the external
networks, which can include the IP Multimedia Core Network Subsystem
(IMS).
6.1 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
512995/2021/O/o ED/Tele-I/RDSO247
Page 18 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
tracking and the paging of UE in idle-mode. It is the termination point of the
Non-Access Stratum (NAS).
6.1.1 MME shall support the following functions:-
i) NAS signalling;
ii) NAS signalling security;
iii) Inter CN node signalling for mobility between 3GPP access networks
(terminating S3);
iv) UE Reachability in ECM-IDLE state (including control and execution of
paging retransmission);
v) Tracking Area list management;
vi) Mapping from UE location (e.g. TAI) to time zone, and signalling a UE
time zone change associated with mobility;
vii) PDN GW and Serving GW selection;
viii) MME selection for handovers with MME change;
ix) SGSN selection for handovers to 2G or 3G 3GPP access networks;
x) Roaming (S6a towards home HSS);
xi) Authentication;
xii) Authorization;
xiii) Bearer management functions including dedicated bearer establishment;
xiv) Lawful Interception of signalling traffic;
xv) Warning message transfer function (including selection of appropriate
eNodeB);
xvi) UE Reachability procedures.
6.1.2 The following are additional MME functions:
i) HRPD access node (terminating S101 reference point) selection and
maintenance for handovers to HRPD.
ii) Transparent transfer of HRPD signalling messages and transfer of status
information between E-UTRAN and HRPD access, as specified in the
pre-registration and handover flows.
iii) Forwarding the GRE key for uplink traffic to the target S-GW in case of
CN node relocation.
6.2 Serving Gateway (S-GW):
6.2.1 The Serving GW is the gateway which terminates the user plane interface
towards E-UTRAN (except when user data is transported using the Control
Plane CIoT EPS Optimisation). For each UE associated with the EPS, at a
given point of time, there is a single Serving GW.
512995/2021/O/o ED/Tele-I/RDSO248
Page 19 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
6.2.3 The functions of the Serving GW, for both the GTP-based and the PMIP-
based S5/S8, include:
i) the local Mobility Anchor point for inter-eNodeB handover;
ii) sending of one or more "end marker" to the source eNodeB, source
SGSN or source RNC immediately after switching the path during
inter-eNodeB and inter-RAT handover, especially to assist the
reordering function in eNodeB.
iii) Mobility anchoring for inter-3GPP mobility (terminating S4 and
relaying the traffic between 2G/3G system and PDN GW);
iv) ECM-IDLE mode downlink packet buffering and initiation of network
triggered service request procedure;
v) Lawful Interception;
vi) Packet routing and forwarding;
vii) Transport level packet marking in the uplink and the downlink, e.g.
setting the DiffServ Code Point, based on the QCI of the associated
EPS bearer;
viii) Accounting for inter-operator charging. For GTP-based S5/S8, the
Serving GW generates accounting data per UE and bearer;
ix) Interfacing OFCS according to charging principles and through
reference points specified in TS 32.240.
6.2.4 In addition to the functions mentioned above, the Serving GW includes the
following functionality:
i) A local non-3GPP anchor for the case of roaming when the non-3GPP
IP accesses connected to the VPLMN.
ii) Event reporting (change of RAT, etc.) to the PCRF.
iii) Uplink and downlink bearer binding towards 3GPP accesses as
defined in TS 23.203.
iv) Uplink bearer binding verification with packet dropping of
"misbehaving UL traffic".
v) Mobile Access Gateway (MAG) according to PMIPv6 specification,
RFC 5213, if PMIP-based S5 or S8 is used. The MAG function shall
be able to send UL packets before sending the PBU or before receiving
the PBA.
vi) Decide if packets are to be forwarded (uplink towards PDN or
downlink towards UE) or if they are locally destined to the S-GW (e.g.
Router Solicitation).
vii) DHCPv4 (relay agent) and DHCPv6 (relay agent) functions if PMIP-
based S5 or S8 is used.
viii) Handling of Router Solicitation and Router Advertisement messages
as defined in RFC 4861, if PMIP based S5 and S8 is used.
512995/2021/O/o ED/Tele-I/RDSO249
Page 20 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
ix) Handling of Neighbour Solicitation and Neighbor Advertisement
messages as defined in RFC 4861, if PMIP based S5 and S8 is used.
x) Allocation of downlink GRE key for each PDN connection within the
Serving GW, which is used by the PDN
xi) GW to encapsulate downlink traffic to the Serving GW on the PMIP-
based S5/S8 interface.
xii) If PMIP-based S8-S2a/b chaining is used:
a) the Serving GW acts as a LMA towards the MAG function of
the Trusted Non-3GPP IP Access or the ePDG;
b) the Serving GW allocates uplink GRE key for each PDN
connection within the Serving GW, which is used to
encapsulate uplink traffic on PMIPv6-based S2a/S2b interface.
c) the Serving GW includes functionality to interwork the
PMIPv6 signalling towards the PDN GW and PMIPv6
signalling towards the MAG function of the Trusted Non-3GPP
IP Access or the ePDG. In this case the Serving GW also acts
as a MAG towards the PDN GW;
d) the Serving GW includes functionality to link the user-plane of
the PMIPv6 tunnel towards the PDN GW and the user-plane of
the PMIPv6 tunnel towards the MAG function of the Trusted
Non-3GPP IP Access or the ePDG.
6.2.2 The PDN GW and the Serving GW may be implemented in one physical node
or separated physical nodes.
6.3 Packet Data Network Gateway (PDN GW):
PDN GW functionality is described in TS 23.401 for 3GPP accesses
connected to the EPC via GTP-based and PMIP-based S5/S8 interface. The
PDN GW supports functionality specified in TS 23.401 that is common to both
PMIP-based and GTP-based S5/S8 interfaces also for access to EPC via non-
3GPP accesses.
6.3.1 The PDN GW is the gateway which terminates the SGi interface towards the
PDN. If a UE is accessing multiple PDNs, there may be more than one PDN
GW for that UE, however a mix of S5/S8 connectivity and Gn/Gp connectivity
is not supported for that UE simultaneously.
6.3.2 PDN GW functions include for both the GTP-based and the PMIP-based
S5/S8:
i) Per-user based packet filtering (by e.g. deep packet inspection);
ii) Lawful Interception;
iii) UE IP address allocation;
512995/2021/O/o ED/Tele-I/RDSO250
Page 21 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
iv) Transport level packet marking in the uplink and downlink, e.g.
setting the DiffServ Code Point, based on the QCI of the associated
EPS bearer;
v) Accounting for inter-operator charging;
vi) UL and DL service level charging as defined in TS 23.203 (e.g. based
on SDFs defined by the PCRF, or based on deep packet inspection
defined by local policy);
vii) Interfacing OFCS through according to charging principles and
through reference points specified in TS 32.240.
viii) UL and DL service level gating control as defined in TS 23.203 ;
ix) UL and DL service level rate enforcement as defined in TS 23.203
(e.g. by rate policing/shaping per SDF);
x) UL and DL rate enforcement based on APN-AMBR
xi) (e.g. by rate policing/shaping per aggregate of traffic of all SDFs of the
same APN that are associated with Non- GBR QCIs);
xii) DL rate enforcement based on the accumulated MBRs of the
aggregate of SDFs with the same GBR QCI (e.g. by rate
policing/shaping);
xiii) DHCPv4 (server and client) and DHCPv6 (client and server)
functions;
xiv) The network does not support PPP bearer type in this version of the
specification. Pre-Release 8 PPP functionality of a GGSN may be
implemented in the PDN GW;
xv) packet screening.
6.3.3 Additionally the PDN GW includes the following functions for the GTP-based
S5/S8:
i) UL and DL bearer binding as defined in TS 23.203;
ii) UL bearer binding verification as defined in TS 23.203;
iii) Functionality as defined in RFC 4861;
iv) Accounting per UE and bearer.
6.3.4 The P-GW provides PDN connectivity to both GERAN/UTRAN only UEs and
E-UTRAN capable UEs using any of E-UTRAN, GERAN or UTRAN. The P-
GW provides PDN connectivity to E-UTRAN capable UEs using E-UTRAN
only over the S5/S8 interface.
PDN GW functionality is described in TS 23.401 for 3GPP accesses
connected to the EPC via GTP-based and PMIP-based S5/S8 interface.
512995/2021/O/o ED/Tele-I/RDSO251
Page 22 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
The PDN GW supports functionality specified in TS 23.401 that is common to
both PMIP-based and GTP-based S5/S8 interfaces also for access to EPC via
non-3GPP accesses.
6.3.5 Additionally, the PDN GW is the user plane anchor for mobility between
3GPP access and non-3GPP access. For this, the PDN GW includes the
following functionality:
i) A LMA according to the PMIPv6 specification, RFC 5213, if PMIP-
based S5 or S8, or if PMIP-based S2a or PMIP-based S2b is used. The
LMA function shall be able to accept UL packets from any trusted MAG
without enforcing that the source IP address must match the CoA in the
MN BCE.
ii) A DSMIPv6 Home Agent, as described in RFC 5555, if S2c is used.
iii) Allocation of uplink GRE key for each PDN connection within the
PDN GW, which is used to encapsulate uplink traffic to the PDN GW on
the PMIP-based S5/S8, or PMIP-based S2a or PMIP based S2b interface.
6.3.6 The PDN GW and the Serving GW may be implemented in one physical node
or separated physical nodes.
6.4 Home Subscriber Server (HSS):
6.4.1 The HSS (for Home Subscriber Server) is a database that contains user-related
and subscriber-related information. It is the entity containing the subscription-
related information to support the network entities actually handling
calls/sessions. It also provides support functions in mobility management, call
and session setup, user authentication and access authorization. The HSS shall
be broadly based on 3GPP specification.
6.4.2 A Home Network may contain one or several HSSs: it depends on the number
of mobile subscribers, on the capacity of the equipment and on the organisation
of the network. The HSS provides support to the call control servers in order to
complete the routing/roaming procedures by solving authentication,
authorisation, naming/addressing resolution, location dependencies, etc.
6.4.3 The HSS is responsible for holding the following user related information:
- User Identification, Numbering and addressing information;
- User Security information: Network access control information for
authentication and authorization;
- User Location information at inter-system level: the HSS supports the
user registration, and stores inter-system location information, etc.;
- User profile information.
512995/2021/O/o ED/Tele-I/RDSO252
Page 23 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
6.4.4 The HSS also generates User Security information for mutual authentication,
communication integrity check and ciphering.
6.4.5 Based on this information, the HSS also is responsible to support the call
control and session management entities of the different Domains and
Subsystems
12.4.6 The HSS may integrate heterogeneous information, and enable enhanced
features in the core network to be offered to the application & services
domain, at the same time hiding the heterogeneity.
6.4.7 The HSS shall support the following functionalities:
6.4.7.1 IP multimedia functionality to provide support to control functions of the IM
subsystem such as the CSCF. It is needed to enable subscriber usage of the IM
CN subsystem services. This IP multimedia functionality is independent of the
access network used to access the IM CN subsystem.
6.4.7.2 The subset of the HLR/AUC functionality required by the PS Domain (GPRS
and EPC).
6.4.7.3 The subset of the HLR/AUC functionality required by the CS Domain, if it is
desired to enable subscriber access to the CS Domain or to support roaming to
legacy GSM/UMTS CS Domain networks.
6.4.8. The Home Location Register (HLR):
The HLR can be considered a subset of the HSS that holds the following
functionality:
6.4.8.1 The functionality required to provide support to PS Domain entities such as
the SGSN, MME and GGSN, through the Gr, S6a, S6dand Gc interfaces and
the 3GPP AAA Server for EPS in case of non-3GPP access via SWx and for
the I-WLAN through the D'/Gr' interface. It is needed to enable subscriber
access to the PS Domain services.
6.4.8.2 The functionality required to provide support to CS Domain entities such as
the MSC/MSC server and GMSC/GMSC server, through the C and D
interfaces. It is needed to enable subscriber access to the CS Domain services
and to support roaming to legacy GSM/UMTS CS Domain networks.
6.4.9 The Authentication Centre (AuC):
The AuC can be considered a subset of the HSS that holds the following
functionality for the CS Domain and PS Domain:
512995/2021/O/o ED/Tele-I/RDSO253
Page 24 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
6.4.9.1 The AuC is associated with an HLR and stores an identity key for each mobile
subscriber registered with the associated HLR. This key is used to generate
security data for each mobile subscriber:
i) Data which are used for mutual authentication of the International
Mobile Subscriber Identity (IMSI) and the network;
ii) a key used to check the integrity of the communication over the radio
path between the mobile station and the network;
iii) a key used to cipher communication over the radio path between the
mobile station and the network.
6.4.9.2 The AuC communicates only with its associated HLR over a non-standardised
interface denoted the H-interface. The HLR requests the data needed for
authentication and ciphering from the AuC via the H-interface, stores them
and delivers them to the VLR and SGSN and MME which need them to
perform the security functions for a mobile station.
6.4.10 HSS logical functions:
HSS logical functionality shall be as per the following:-
6.4.10.1 Mobility Management:
This function supports the user mobility through CS Domain, PS Domain and
IM CN subsystem.
6.4.10.2 Call and/or session establishment support:
The HSS supports the call and/or session establishment procedures in CS
Domain, PS Domain and IM CN subsystem. For terminating traffic, it
provides information on which call and/or session control entity currently
hosts the user.
6.4.10.3 User security information generation:
6.4.10.3.1 The HSS generates user authentication, integrity and ciphering data for the CS
and PS Domains and for the IM CN subsystem. User security support
6.4.10.4.2 The HSS supports the authentication procedures to access CS Domain, PS
Domain and IM CN subsystem services by storing the generated data for
authentication, integrity and ciphering and by providing these data to the
appropriate entity in the CN (i.e. MSC/VLR, SGSN, MME, 3GPP AAA
Server or CSCF).
6.4.10.4 User identification handling:
The HSS provides the appropriate relations among all the identifiers uniquely
determining the user in the system: CS Domain, PS Domain and IM CN
512995/2021/O/o ED/Tele-I/RDSO254
Page 25 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
subsystem (e.g. IMSI and MSISDNs for CS Domain; IMSI, MSISDNs and IP
addresses for PS Domain, private identity and public identities for IM CN
subsystem).
6.4.10.5 Access authorisation:
The HSS authorises the user for mobile access when requested by the
MSC/VLR, SGSN, MME, 3GPP AAA Server or CSCF, by checking that the
user is allowed to roam to that visited network.
6.4.10.6 Service authorisation support:
The HSS provides basic authorisation for MT call/session establishment and
service invocation. Besides, the HSS updates the appropriate serving entities
(i.e., MSC/VLR, SGSN, MME, 3GPP AAA Server, CSCF) with the relevant
information related to the services to be provided to the user.
6.4.10.7 Service Provisioning Support:
6.4.10.7.1 The HSS provides access to the service profile data for use within the CS
Domain, PS Domain and/or IM CN subsystem. Application Services and
CAMEL Services Support (for GERAN and UTRAN access).
6.4.10.8 The HSS communicates with the SIP Application Server and the OSA-SCS to
support Application Services in the IM CN subsystem. It communicates with
the IM-SSF to support the CAMEL Services related to the IM CN subsystem.
The IMS CAMEL subscription data may be transferred to the IM-SSF AS
using Sh reference point in addition to the Si reference point. The HSS
communicates with the gsmSCF to support CAMEL Services in the CS
Domain and GPRS PS Domain (for GERAN and UTRAN access).
6.4.10.9 GUP Data Repository:
The HSS supports the storage of IM CN Subsystem user related data, and
provides access to these data through the Rp reference point.
6.5 Policy and Charging Rule Function (PCRF) :
6.5.1 PCRF is the policy and charging control element. In non-roaming scenario,
there is only a single PCRF in the HPLMN associated with one UE's IP-CAN
session. The PCRF terminates the Rx interface and the Gx interface. In a
roaming scenario with local breakout of traffic there may be two PCRFs
associated with one UE's IP-CAN session:
- H-PCRF that resides within the H-PLMN;
- V-PCRF that resides within the V-PLMN.
512995/2021/O/o ED/Tele-I/RDSO255
Page 26 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
6.5.1.1 Home PCRF (H-PCRF): The functions of the H-PCRF include:-
- terminates the Rx reference point for home network services;
- terminates the S9 reference point for roaming with local breakout;
- associates the sessions established over the multiple reference points (S9,
Rx), for the same UE's IP-CAN session (PCC session binding).
6.5.1.2 Visited PCRF (V-PCRF) : The functions of the V-PCRF include:-
- terminates the Gx and S9 reference points for roaming with local breakout;
- terminates Rx for roaming with local breakout and visited operator's
Application Function.
6.5.2 High Level Requirements:
6.5.2.1 It shall be possible for the PCC architecture to base decisions upon
subscription information.
6.5.2.2 It shall be possible to apply policy and charging control to any kind of 3GPP
IP-CAN and any non-3GPP accesses connected via EPC complying with TS
23.402 . Applicability of PCC to other IP-CANs is not restricted. However, it
shall be possible for the PCC architecture to base decisions upon the type of
IP-CAN used (e.g. GPRS, I-WLAN, etc.).
6.5.2.3 The policy and charging control shall be possible in the roaming and local
breakout scenarios defined in TS 23.401 and TS 23.402.
6.5.2.4 The PCC architecture shall discard packets that don't match any service data
flow filter of the active PCC rules. It shall also be possible for the operator to
define PCC rules, with wild-carded service data flow filters, to allow for the
passage and charging for packets that do not match any service data flow filter
of any other active PCC rules.
6.5.2.5 The PCC architecture shall allow the charging control to be applied on a per
service data flow basis, independent of the policy control.
6.5.2.6 The PCC architecture shall have a binding method that allows the unique
association between service data flows and their IP-CAN bearer.
6.5.2.7 A single service data flow detection shall suffice for the purpose of both
policy control and flow based charging.
6.5.2.8 A PCC rule may be predefined or dynamically provisioned at establishment
and during the lifetime of an IP-CAN session. The latter is referred to as a
dynamic PCC rule.
512995/2021/O/o ED/Tele-I/RDSO256
Page 27 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
6.5.2.9 The number of real-time PCC interactions shall be minimized although not
significantly increasing the overall system reaction time. This requires
optimized interfaces between the PCC nodes.
6.5.2.10 It shall be possible to take a PCC rule into service, and out of service, at a
specific time of day, without any PCC interaction at that point in time.
6.5.2.11 PCC shall be enabled on a per PDN basis (represented by an access point and
the configured range of IP addresses) at the PCEF. It shall be possible for the
operator to configure the PCC architecture to perform charging control, policy
control or both for a PDN access.
6.5.2.12 PCC shall support roaming users.
6.5.2.13 The PCC architecture shall allow the resolution of conflicts which would
otherwise cause a subscriber's Subscribed Guaranteed Bandwidth QoS to be
exceeded.
6.5.2.14 The PCC architecture shall support topology hiding.
6.5.2.15 It should be possible to use PCC architecture for handling IMS-based
emergency service.
6.5.2.16 It shall be possible with the PCC architecture, in real-time, to monitor the
overall amount of resources that are consumed by a user and to control usage
independently from charging mechanisms, the so-called usage monitoring
control.
6.5.3 Policy Control Functionalities:
6.5.3.1 Policy control comprises functionalities for:
i) Binding, i.e. the generation of an association between a service data flow
and the IP-CAN bearer transporting that service data flow;
ii) Gating control, i.e. the blocking or allowing of packets, belonging to a
service data flow or specified by an application identifier, to pass
through to the desired endpoint;
iii) Event reporting, i.e. the notification of and reaction to application events
to trigger new behaviour in the user plane as well as the reporting of
events related to the resources in the GW (PCEF);
iv) QoS control, i.e. the authorisation and enforcement of the maximum
QoS that is authorised for a service data flow, an Application identified
by application identifier or an IP-CAN bearer;
512995/2021/O/o ED/Tele-I/RDSO257
Page 28 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
v) Redirection, i.e. the steering of packets, belonging to an application
defined by the application identifier to the specified redirection address;
vi) IP-CAN bearer establishment for IP-CANs that support network initiated
procedures for IP-CAN bearer establishment.
6.5.3.2 In case of an aggregation of multiple service data flows (e.g. for GPRS a PDP
context), the combination of the authorised QoS information of the individual
service data flows is provided as the authorised QoS for this aggregate.
6.5.3.3 The enforcement of the authorized QoS of the IP-CAN bearer may lead to a
downgrading or upgrading of the requested bearer QoS by the GW(PCEF) as
part of a UE-initiated IP-CAN bearer establishment or modification.
Alternatively, the enforcement of the authorised QoS may, depending on
operator policy and network capabilities, lead to network initiated IP-CAN
bearer establishment or modification. If the PCRF provides authorized QoS for
both, the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS
of the individual PCC rules shall take place first.
6.5.3.4 QoS authorization information may be dynamically provisioned by the PCRF
or, it can be a pre-defined PCC rule in the PCEF. In case the PCRF provides
PCC rules dynamically, authorised QoS information for the IP-CAN bearer
(combined QoS) may be provided. For a predefined PCC rules within the
PCEF the authorized QoS information shall take affect when the PCC rule is
activated. The PCEF shall combine the different sets of authorized QoS
information, i.e. the information received from the PCRF and the information
corresponding to the predefined PCC rules. The PCRF shall know the
authorized QoS information of the predefined PCC rules and shall take this
information into account when activating them. This ensures that the combined
authorized QoS of a set of PCC rules that are activated by the PCRF is within
the limitations given by the subscription and operator policies regardless of
whether these PCC rules are dynamically provided, predefined or both.
6.5.3.5 For policy control, the AF interacts with the PCRF and the PCRF interacts
with the PCEF as instructed by the AF. For certain events related to policy
control, the AF shall be able to give instructions to the PCRF to act on its own,
i.e. based on the service information currently available.
6.5.3.6 For policy control, the AF interacts with the PCRF and the PCRF interacts
with the PCEF as instructed by the AF. For certain events related to policy
control, the AF shall be able to give instructions to the PCRF to act on its own,
i.e. based on the service information currently available. The following events
are subject to instructions from the AF:
512995/2021/O/o ED/Tele-I/RDSO258
Page 29 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
i) The authorization of the service based on incomplete service
information;
ii) The immediate authorization of the service;
iii) The gate control (i.e. whether there is a common gate handling per AF
session or an individual gate handling per AF session component
required);
iv) The forwarding of IP-CAN bearer level information or events:
- Type of IP-CAN (e.g. GPRS, etc.);
- Transmission resource status (established/released/lost);
- Access Network Charging Correlation Information;
- Credit denied.
6.5.3.7 To enable the binding functionality, the UE and the AF shall provide all
available flow description information (e.g. source and destination IP address
and port numbers and the protocol information). The UE shall use the traffic
mapping information to indicate downlink and uplink IP flows.
7.0 Communication Requirement - Future Railway Mobile Communication
System (FRMCS):-
7.1 The communication requirement of LTE shall be complying to “Future
Railway Mobile Communication System - User Requirements Specification”,
released by the International Union of Railways (UIC).
7.2 The General Communication Requirements for Voice like One-to-one calls,
Caller identity display, Restriction of display of called/calling user, Call
forwarding, Call waiting, Call hold, Call barring, and for Data like bearer
services for telemetry, messaging, train control applications, information
exchange and general data applications are available in the commercial LTE
networks based on the LTE technology releases.
7.3 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):
512995/2021/O/o ED/Tele-I/RDSO259
Page 30 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
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.
• Member 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
7.4 Communication requirements:-
• Critical: applications that is 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.
7.5 The UIC document “Future Railway Mobile Communication System - User
Requirements Specification”, shall be referred for the following sub-sections
for communication requirements:-
Clause 5: Critical Communication Applications
Clause 6: Performance Communication Applications
Clause 7: Business Communication Applications
512995/2021/O/o ED/Tele-I/RDSO260
Page 31 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Clause 8: Critical Support Applications
Clause 9: Performance Support Applications
Clause 10: Business Support Applications
8.0 Mission Critical Services Requirements:
The System shall support Mission Critical Push to Talk (MCPTT) Services,
Mission Critical Video Services and Mission Critical Data Services as per
relevant 3GPP/ ETSI Specifications.
8.1 The System shall support following minimum Mission Critical Push to Talk
(MCPTT) functionalities as mentioned below:-
i) User authentication and service authorization
ii) Configuration
iii) Affiliation and de-affiliation
iv) Group calls on-network and off-network (within one system or
multiple systems, pre-arranged or chat model, late entry, broadcast
group calls, emergency group calls, imminent peril group calls,
emergency alerts)
v) Private calls on-network and off-network (automatic or manual
commencement modes, emergency private calls)
vi) MCPTT security
vii) Encryption (media and control signalling)
viii) Simultaneous sessions for call
ix) Dynamic group management (group regrouping)
x) Identity management
xi) Floor control in on-network (within one system or across systems) and
in off-network
xii) Pre-established sessions
xiii) Resource management (unicast, multicast, modification, shared
priority)
xiv) Multicast/Unicast bearer control, MBMS (Multimedia
Broadcast/Multicast Service) bearers
xv) Location configuration, reporting and triggering
xvi) Use of UE-to-network relays
xvii) The System shall also support following MCPTT Enhancements:
- First-to-answer call setup (with and without floor control)
- Floor control for audio cut-in enabled group
- Updating the selected MC Service user profile for an MC
Service
- Ambient listening call
- MCPTT private call-back request
- Remote change of selected group
512995/2021/O/o ED/Tele-I/RDSO261
Page 32 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
8.2 Features and functionalities of Mission Critical Video Services and Mission Critical
Data Services shall be as per as per relevant 3GPP/ ETSI Specifications.
9.0 LTE Security Requirements:
The system shall support Network access security, Network domain security,
User domain security, Application domain security and Visibility and
configurability of security features as mentioned in the relevant 3GPP/ETSI
specifications.
9.1 Network access security: The system shall support the following User-to-
Network (Network access security) security features:-
9.1.1 User identity confidentiality:
9.1.1.1 user identity confidentiality: the property that the permanent user identity
(IMSI) of a user to whom a services is delivered cannot be eavesdropped on
the radio access link;
9.1.1.2 user location confidentiality: the property that the presence or the arrival of a
user in a certain area cannot be determined by eavesdropping on the radio
access link;
9.1.1.3 user untraceability: the property that an intruder cannot deduce whether
different services are delivered to the same user by eaves dropping on the radio
access link.
9.1.2 Device confidentiality:
9.1.2.1 From subscriber's privacy point of view, the MSIN, the IMEI, and the
IMEISV should be confidentiality protected.
9.1.2.2 The UE shall provide its equipment identifier IMEI or IMEISV to the network,
if the network asks for it in an integrity protected request.
9.1.2.3 The IMEI and IMEISV shall be securely stored in the terminal.
9.1.2.4 The UE shall not send IMEI or IMEISV to the network on a network request
before the NAS security has been activated.
9.1.3 Entity authentication:
9.1.3.1 The following security features related to entity authentication are provided:
9.1.3.2 user authentication: the property that the serving network corroborates the user
identity of the user;
512995/2021/O/o ED/Tele-I/RDSO262
Page 33 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
9.1.3.3 network authentication: the property that the user corroborates that he is
connected to a serving network that is authorised by the user's HE to provide
him services; this includes the guarantee that this authorisation is recent.
9.1.4 User data and signalling data confidentiality:
9.1.4.1 The following security features are provided with respect to confidentiality of
data on the network access link:
9.1.4.1.1 cipher algorithm agreement: the property that the MS and the SN can securely
negotiate the algorithm that they shall use subsequently;
9.1.4.1.2 cipher key agreement: the property that the MS and the SN agree on a cipher
key that they may use subsequently;
9.1.4.1.3 confidentiality of user data: the property that user data cannot be overheard on
the radio access interface;
9.1.4.1.4 confidentiality of signalling data: the property that signalling data cannot be
overheard on the radio access interface;
9.1.4.2 Ciphering requirements:
9.1.4.2.1 Ciphering may be provided to RRC-signalling to prevent UE tracking based
on cell level measurement reports, handover message mapping, or cell level
identity chaining. RRC signalling confidentiality is an operator option.
9.1.4.2.3 The NAS signalling may be confidentiality protected. NAS signalling
confidentiality is an operator option.
9.1.4.2.4 When authentication of the credentials on the UICC during Emergency
Calling in Limited Service Mode, can not be successfully performed, the
confidentiality protection of the RRC and NAS signaling, and user plane shall
be omitted. This shall be accomplished by the network by selecting EEA0 for
confidentiality protection of NAS, RRC and user plane.
9.1.4.2.5 User plane confidentiality protection shall be done at PDCP layer and is an
operator option.
9.1.4.3 Algorithm Identifier Values:
9.1.4.3.1 All algorithms specified in this subclause are algorithms with a 128-bit input
key except Null ciphering algorithm.
9.1.4.3.2 Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier.
Currently, the following values have been defined for NAS, RRC and UP
ciphering:
"00002" EEA0 Null ciphering algorithm
"00012" 128-EEA1 SNOW 3G based algorithm
"00102" 128-EEA2 AES based algorithm
512995/2021/O/o ED/Tele-I/RDSO263
Page 34 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
9.1.4.3.3 UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both
RRC signalling ciphering and UP ciphering.
9.1.4.3.4 UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS
signalling ciphering. UEs and MMEs may implement 128-EEA3 for NAS
signalling ciphering.
9.1.5 User data and signalling data integrity:
9.1.5.1 The following security features are provided with respect to integrity of data
on the network access link:
9.1.5.1.1 integrity algorithm agreement: the property that the MS and the SN can
securely negotiate the integrity algorithm that they shall use subsequently;
9.1.5.1.2 integrity key agreement: the property that the MS and the SN agree on an
integrity key that they may use subsequently;
9.1.5.1.3 data integrity and origin authentication of signalling data: the property that the
receiving entity (MS or SN) is able to verify that signalling data has not been
modified in an unauthorised way since it was sent by the sending entity (SN or
MS) and that the data origin of the signalling data received is indeed the one
claimed;
9.1.5.2 Integrity requirements:
9.1.5.2.1 Synchronization of the input parameters for integrity protection shall be
ensured for the protocols involved in the integrity protection.
9.1.5.2.2 Integrity protection, and replay protection, shall be provided to NAS and
RRC-signalling.
9.1.5.2.3 All NAS signaling messages except those explicitly listed in TS 24.301 as
exceptions shall be integrity-protected.
9.1.5.2.4 All RRC signaling messages except those explicitly listed in TS 36.331 as
exceptions shall be integrity-protected.
9.1.5.2.5 When authentication of the credentials on the UICC during Emergency
Calling in Limited Service Mode, as defined in the TS 23.401, can not be
successfully performed, the integrity and replay protection of the RRC and
NAS signaling shall be omitted. This shall be accomplished by the network by
selecting EIA0 for integrity protection of NAS and RRC. EIA0 shall only be
used for unauthenticated emergency calls.
9.1.5.2.6 All user data packets sent via the MME shall be integrity protected.
512995/2021/O/o ED/Tele-I/RDSO264
Page 35 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
9.1.5.3 Algorithm Identifier Values:
9.1.5.3.1 All algorithms specified in this subclause are algorithms with a 128-bit input
key.
9.1.5.3.2 Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier.
Currently, the following values have been defined:
"00002" EIA0 Null Integrity Protection algorithm
"00012" 128-EIA1 SNOW 3G
"00102" 128-EIA2 AES
9.1.5.3.3 UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling
integrity protection.
9.1.5.3.4 UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling
integrity protection.
9.1.5.3.5 UEs shall implement EIA0 for integrity protection of NAS and RRC
signalling. EIA0 is only allowed for unauthenticated emergency calls.
9.1.5.3.6 Implementation of EIA0 in MMEs and eNBs is optional, EIA0, if
implemented, shall be disabled in MMEs and eNBs in the deployments where
support of unauthenticated emergency calling is not a regulatory requirement.
9.1.6 Security visibility and configurability
9.1.6.1 Although in general the security features should be transparent to the user, for
certain events and according to the user's concern, greater user visibility of the
operation of following security feature shall be provided:
9.1.6.1.1 indication of access network encryption: the property that the user is informed
whether the confidentiality of user data is protected on the radio access link, in
particular when non-ciphered calls are set-up;
9.1.6.2 The ciphering indicator feature is specified in 3GPP TS 22.101.
9.1.6.3 Configurability is the property that the user can configure whether the use or
the provision of a service should depend on whether a security feature is in
operation. A service can only be used if all security features, which are
relevant to that service and which are required by the configurations of the
user, are in operation. The following configurability features are suggested:
9.1.6.3.1 enabling/disabling user-USIM authentication: the user should be able to
control the operation of user-USIM authentication, e.g., for some events,
services or use.
512995/2021/O/o ED/Tele-I/RDSO265
Page 36 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
9.2 Security requirements on eNodeB:
9.2.1 The security requirements given in this section apply to all types of eNodeBs.
More stringent requirements for specific types of eNodeBs may be defined in
other 3GPP specifications.
9.2.2 Requirements for eNB setup and configuration : Setting up and configuring
eNBs shall be authenticated and authorized so that attackers shall not be able
to modify the eNB settings and software configurations via local or remote
access.
i) Security associations are required between the EPS core and the eNB
and between adjacent eNBs, connected via X2. These security
association establishments shall be mutually authenticated and used for
communication between the entities. Communication between the
remote/local O&M systems and the eNB shall be mutually
authenticated.
ii) The eNB shall be able to ensure that software/data change attempts are
authorized
iii) The eNB shall use authorized data/software.
iv) Sensitive parts of the boot-up process shall be executed with the help
of the secure environment.
v) Confidentiality of software transfer towards the eNB shall be ensured.
vi) Integrity protection of software transfer towards the eNB shall be
ensured.
9.2.3 Requirements for key management inside eNB : The EPS core network
provides subscriber specific session keying material for the eNBs, which also
hold long term keys used for authentication and security association setup
purposes. Protecting all these keys is important.
i) Keys stored inside eNBs shall never leave a secure environment within
the eNB except when done in accordance with this or other 3GPP
specifications.
9.1.4 Requirements for handling User plane data for the eNB : It is eNB's task to
cipher and decipher user plane packets between the Uu reference point and the
S1/X2 reference points.
i) User plane data ciphering/deciphering shall take place inside the secure
environment where the related keys are stored.
ii) The transport of user data over S1-U and X2-U shall be integrity,
confidentially and replay-protected from unauthorized parties.
512995/2021/O/o ED/Tele-I/RDSO266
Page 37 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
9.2.4.1 Requirements for handling Control plane data for the eNB : It is eNB's task to
provide confidentiality and integrity protection for control plane packets on
the S1/X2 reference points.
i) Control plane data ciphering/deciphering shall take place inside the
secure environment where the related keys are stored.
ii) The transport of control plane data over S1-MME and X2-C shall be
applied to integrity-, confidentiality- and replay-protected from
unauthorized parties.
9.2.5 Requirements for secure environment of the eNB : The secure environment is
logically defined within the eNB and is a composition of functions for the
support of sensitive operations.
i) The secure environment shall support secure storage of sensitive data,
e.g. long term cryptographic secrets and vital configuration data.
ii) The secure environment shall support the execution of sensitive
functions, e.g. en-/decryption of user data and the basic steps within
protocols which use long term secrets (e.g. in authentication protocols).
iii) Sensitive data used within the secure environment shall not be exposed
to external entities.
iv) The secure environment shall support the execution of sensitive parts
of the boot process.
v) The secure environment's integrity shall be assured.
vi) Only authorised access shall be granted to the secure environment, i.e.
to data stored and used within, and to functions executed within.
512995/2021/O/o ED/Tele-I/RDSO267
Page 38 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Section B
10.0 System Dimensioning:
10.1 Input Data for System Design:-
Input Data for System Design
S.
No. Items
Scenario
Rural Sub
Urban
Urban
1 No. of Stations 5000 2500 500
2 Block Section Length (Average) 10 10 10
3 Train density ( No. of trains per track per km)
(approx)
0.5 0.5 0.5
4 No. of tracks in Block Section 2 3 4
5 Max No. of Trains in Block Section (All
Tracks)
10 15 20
6 Average No. of trains standing at Station PF &
Yard
4 8 16
7 Average Trains in a Cell Site at station (Station
PF + Block + Yard) (One Side of the Tower)
9 16 26
8 No. of MCPTT Users in one Train (1 Driver+1
Guard)
2 2 2
9 Average No. of MCPTT Users in Cell Site
(Block + Station PF + Yard)
18 32 52
10 No. of Active MCPTT Users in Cell Site
(Track + Station + Yard) = (25%)
5 8 13
11 No. of Trains for IoT and CCTV Services at a
time = 25 % of Total Trains in Cell Site
2 4 7
12 No. of Normal Mobile Users in a Station
(Excluding MC PTT)
25 60 100
13 No. of Active Normal Mobile Users in a Cell
Site (Excluding MC PTT (25%)
6 15 25
14 Total Stations 8000
15 No. of Normal Mobile Users in IR (except
MCPTT)
275600
16 No. of Passenger + Goods Train running daily
in IR
22675
17 No. of Passenger + Goods Train MCPTT Users
in IR
45350
Cell Edge
1 No. of Trains in Cell Edge 2 3 4
2 No. of MCPTT Users in Cell Edge 2 3 4
Note: - The above data is based on typical requirements.
512995/2021/O/o ED/Tele-I/RDSO268
Page 39 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.2 Cell Edge Throughput Calculations:-
10.2.1 Uplink Cell Edge Throughput Calculation:
S. No.
Application
Basic Unit Rural : 2 Parallel Tracks
& 2 Trains at Cell Edge
Suburban : 3 Parallel
Tracks & 3 Trains at
Cell Edge
Urban : 4 Parallel Tracks
& 4 Trains at Cell Edge
One Train
(Uplink) (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
1 ETCS Level-2 20 40 40 60 60 80 80
2
MCX – Voice (40 Kbps Single Call) (Single call per Train in
normal and 2 calls per train in
emergency situation)
40 80 160 120 240 160 320
3 MC-Video* 250 - 250 - 500 - 500
4 Geo-positioning System 10 20 20 30 30 40 40
(A) Operational Requirement (Approx.)(kbps) 140 470 210 830 280 940
(B) Without MC-Video (kbps) 220 330 440
(C) Desired Services (not mandatory)(Uplink) Rural Suburban Urban
1 Passenger information display
system (Kbps) 20 40 40 60 60 80 80
2 IoT services (Kbps)
(for Trains only) 1000 2000 2000 3000 3000 4000 4000
3 *On Board Video Surveillance
(minimum one Camera per
Train) (Kbps)
1000 1000 1000 1000 2000 1000 2000
Desired Services (Approx.)(kbps) 3040 3040 4060 5060 5080 6080
512995/2021/O/o ED/Tele-I/RDSO269
Page 40 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
* Data rate (approximately) requirement for inboard VSS shall be FHD =1 Mbps, HD = 400 Kbps and D1 (720x576) = 200 kbps for
H.265 Video compression & 25 FPS per Camera. Emergency condition at any time will be for maximum one train in Rural and 2
Trains in Suburban and Urban.
10.2.2 Downlink Cell Edge Throughput Calculation:
S. No.
Application
Basic
Unit
Rural : 2 Parallel
Tracks & 2 Trains at
Cell Edge
Suburban : 3 Parallel
Tracks & 3 Trains at Cell
Edge
Urban : 4 Parallel Tracks
& 4 Trains at Cell Edge
One Train
(Uplink) (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
Normal
Situation (kbps)
Emergency
Situation (kbps)
1 ETCS Level-2 20 40 40 60 60 80 80
2
MCX – Voice (40 Kbps
Single Call) (Single call per Train
in normal and 2 calls per train in emergency situation)
40 80 160 120 240 160 320
3 MC-Video (only in emergency) 250 - 250 - 500 - 500
4 Geo-positioning System 10 20 20 30 30 40 40
(A) Operational Requirement (Approx.)(kbps) 140 470 210 830 280 940
5
Level Crossing Gate Monitoring
CCTV Camera (2 cameras per LC
Gate)
1000
( per
Camera)
2000 4000 2000 6000 2000 8000
(B) Operational Requirement (Approx.)(kbps)
including all Services 2140 4470 2210 6830 2280 8940
512995/2021/O/o ED/Tele-I/RDSO270
Page 41 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.3 Cell Edge throughput:
Cell Edge throughput Requirement
UL Cell Edge throughput
(Emergency Situation)
220 Kbps - 440 Kbps
(As per 10.2.1 (B) Without MC Video)
DL Cell Edge throughput
(Emergency Situation)
4470 Kbps - 8940 Kbps
(As per 10.2.2 (B)
10.4 Design Inputs for Radio Network Planning:-
Parameters Value
Terrain Model Rural, Sub Urban and Urban
Path Loss Model 3GPP/ ITU-R M.2135-1 or Okumara Hata or
Similar
Cell Edge Throughput (DL) Depending on cell edge throughput calculation
Cell Edge Throughput (UL) Depending on cell edge throughput calculation
Cell Area Coverage Probability
& Minimum Coverage Level
The system shall meet the following (A) and (B)
:-
(A) : For ETCS
i) coverage probability of 95% based on a coverage
level of 38.5 dBμV/m (-98 dBm) for voice and
non-safety critical data;
ii) coverage probability of 95% based on a coverage
level of 41.5 dBμV/m (-95 dBm) on lines with
ETCS levels 2/3 for speeds lower than or equal to
220km/h.
iii) coverage probability of 95% based on a coverage
level of 44.5 dBμV/m (-92 dBm) on lines with
ETCS levels 2/3 for speeds above 280km/h;
iv) coverage probability of 95% based on a
coverage level between 41.5 dBμV/m and 44.5
dBμV/m (-95 dBm and –92 dBm) on lines with
ETCS levels 2/3 for speeds above 220km/h and
lower than or equal to 280 km/h.
(B) Cell Edge Throughput for UP link and Down
Link as per requirement
Frequency Band 700 MHz (703-748 MHz Uplink & 758-803 MHz
Downlink)
Channel Bandwidth 5 MHz
Duplex Method FDD
512995/2021/O/o ED/Tele-I/RDSO271
Page 42 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Modulation Downlink- OFDMA, Uplink- SC-FDMA
Antenna Height 35 m
UE Antenna Height 4 m for Mobile Radio & 1.5 m Outdoor UEs
eNodeB Tx-Rx Antenna Path 2 Tx- 2 Rx (2x2 MIMO)
UE Tx-Rx Antenna Path 1 Tx- 2 Rx
UE Category Class 2 or higher
eNodeB Transmit Power 43 to 46 dBm
eNodeB Cable and Connector loss 0 dBm
eNodeB Antenna Gain 16-21 dBi
eNodeB Noise Figure 5 dB
UE Transmit Power (max) 23.0 dBm
UE Antenna Gain 0.0 dBi
UE Body Loss 0.0 dB
UE Noise Figure 7 dB
UE Cable and Connector Loss 0.5 dB
Noise Spectral Density -174 dBm/ Hz
SINR Target (DL) 0 dB ≤ SINR ≤ 40 dB
SINR Target (UL) 0 dB ≤ SINR ≤ 40 dB
Cell Load (DL & UL) % 40% for Urban and Semi urban and 30% for rural
Interference Margin 2.1 dB
Penetration Loss 11 dB
10.5 Link Budget:
The link budget may be calculated as per the following:-
10.5.1 Downlink Budget (Sample):
Downlink Budget
Ref Quantity Value Units
A eNodeB Transmit Power 43 dBm
B eNodeB Cable and connector loss 0 dBm
C eNodeB Antenna Gain 19.2 dBi
D = A - B + C Equivalent Isotropic Radiated Power 62.2 dBm
E Noise Spectral Density -174 dB/ Hz
F eNodeB Transmitted Bandwidth 66.53 dBHz
G UE Noise Figure 7 dB
H SINR Target 5.5 dB
I = E + F + G
+ H
Receiver Sensitivity -94.97 dBm
J Body Loss 0 dB
K UE Antenna Gain 0 dBi
L = I + J - K Isotropic Receive Level -94.97 dBm
512995/2021/O/o ED/Tele-I/RDSO272
Page 43 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
M Interference Margin 2.1 dB
N Penetration Loss 11 dB
O Shadowing Margin 6.0 dB
P = M + N + O Link Loss and Margins 19.1 dB
Q = D - (L+P) Maximum Propagation Loss (DL) 138.07 dB
10.5.2 Uplink Budget (Sample):
Uplink Budget
Ref Quantity Value Units
A UE Transmit Power 23.0 dBm
B UE Antenna Gain 0 dBi
C UE Cable Loss 0 db
D=A+B+C Body Loss 0 dB
E Equivalent Isotropic Radiated Power 23.0 dBm
F Noise Spectral Density -174.0 dBm/ Hz
G UE Transmitted Bandwidth (2 RB) 55.6 dBHz
H eNB Noise Figure 5.0 dB
I SINR Target 8.5 dB
J=
E+F+G+H+I
eNodeB Receiver Sensitivity -104.9 dBm
K Cable and Connector Loss 0.5 dB
l eNB Antenna Gain 19.2 dBi
M= I+J+K eNB isotropic Receive Level -123.6 dBm
M Interference Margin 3.0 dB
N Penetration Loss 11.0 dB
O Shadowing Margin 6.0 dB
P+M+N+O Link Loss and Margins 20.0 dB
Q = D - (L +
P)
Maximum Propagation Loss (UL) 126.6 dB
Note: - The values may vary depending on the design input parameters.
10.6 Path Loss Calculation:-
10.6.1 The 3GPP/ITU Path loss model or Okumara Hata model or any other model
suitable for allotted frequency of LTE for Indian Railways may be adopted for
Path loss calculation.
10.6.2 The Path Loss models may be Rural, Urban and Sub Urban selection of which
may be as per site requirement.
10.6.3 The coverage simulation may be carried out for design inputs with two or
more software from different OEM’s in order to have cross verification and
better optimization.
512995/2021/O/o ED/Tele-I/RDSO273
Page 44 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.6.4 The coverage simulation software shall be proven and certified for its
application.
10.7 Cell Range and Inter eNodeB distance:
10.7.1 The approximate Cell Range and Inter eNodeB distance for desired throughput
are as below:-
Rural Suburban Urban
Cell Edge Throughput
(Kbps)
220 330 440
Cell Range (Km) 4.5 2.25 1.0
Inter eNodeB Distance
(Km)
9.0 4.50 2.0
10.7.2 The actual coverage shall be decided with Coverage Simulation software with
required design inputs and optimization through the Drive Test (optional) and
other measurements.
10.8 Dimensioning of Evolved Packet Core (EPC):
10.8.1 Evolved packet core has the following components that can be centralized and
shall be geo-redundant:
i) MME – Mobile Mobility Engine
ii) HSS – Home Subscriber Server
iii) PCRF – Policy Control and Routing Function
10.8.2 Following components of EPC shall be provided at each zone level in order to
reduce the packet delay to the RBC and vice versa:
i) Server Gateway
ii) Packet Gateway
10.8.3 EPC Core traffic profile:
EPC Traffic
Parameter
Unit Centralized Core
components Qty.
(Main Core Site)
Centralized Core
Components Qty.
(Geo-Redundant
site)
S-GW and P-
GW at each
zone
Total number
of subscribers Nos. 1,00,000 1,00,000 5555
Total
Throughput Gbps 50 Gbps 50 Gbps 5 Gbps
512995/2021/O/o ED/Tele-I/RDSO274
Page 45 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.8.4 EPC shall be support high availability and geo-redundancy with uptime of
99.999%.
10.8.5 It should be expandable to cater higher capacities as per the Railways future
network requirements.
10.8.6 EPC shall be interoperable with any LTE-RAN vendor and vice versa.
10.9 Network ID Planning & Numbering Scheme:
10.9.1 Physical Cell Identity Planning:
The Physical Cell Identity (PCI) is the identifier of a Cell within the physical
layer of LTE network. The PCI consists of downlink Primary Synchronisation
Signal (PSS) and Secondary Synchronisation Signal (SSS). The PCI is used
for measurement reporting and handover.
10.9.1.1 The PSS consists of 3 different sequence numbers 0, 1 or 2 whereas SSS
consists of 168 sequence numbers ranging from 0 to 167. The Physical Cell
IDs range from 0 to 503 and are limited to 504 which can be reused. The PCI
is calculated as below:-
PCI = 3*SSS + PSS
10.9.1.2 Physical Cell Identity planning shall be done in such way that there should not
be same ID for neighbouring cells. Physical Cell Identity shall also be planned
and allocated for redundant sectors in a Cell and provision of spare IDs shall
also be done for future use.
10.9.1.3 A typical cell ID panning for IR linear network is given below.
i) The Sectors of one Cell (suppose Cell ‘A’) and its Redundant Sectors may
be allocated one SSS ID and three different PSS IDs (0 to 2 i.e. total 3) for its
Sectors/ Redundant Sectors.
ii) The same Cell (Cell ‘A’) may be given another SSS IDs in case no. of
Sectors are more than 3.
iii) Planning for a typical Cell for example is shown in the figure below:-
512995/2021/O/o ED/Tele-I/RDSO275
Page 46 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Fig.- 4: Physical Cell Identity Planning
10.9.1.4 PCI Calculation: PCI calculation for example is given in the table below:-
Cell No. No. of Sectors Sectors SSS PSS PCI =
3*SSS + PSS
Reserved
SSS
A
2
(1 Operating , 1
Redundant)
1 0 0 0
1, 2 & 3 1/R 1 1
…
K
8 Nos.
(4 Operating, 4
Redundant)
1 14 0 42
18
1/R 1 43
2 15 0 45
2/R 1 46
3 16 0 48
3/R 1 49
4 17 0 51
4/R 1 52
L
6 Nos.
(3 Operating, 3
Redundant)
1 19 0 57
22 & 23
2 1 58
3 2 59
1/R 20 0 60
2/R 1 61
3/R 2 62
…
XXX
4 Nos.
(2 Operating, 2 Redundant)
1 167 0 501
1/R 1 502
2 2 503
2/R 0 0 0 1 & 2
Sector
3
SSS =
16
PSS =
0
Sector
1/R
SSS =
14
PSS = 0
Sector
2/R
SSS =
15
PSS =
1
Cell K
SSS = 14,
15, 16 &
17
Sector
4
SSS =
17
PSS =
0
Sector
1
SSS =
14
PSS =
1
Sector
3/R
SSS =
16
PSS =
1
Sector
2
SSS =
15
PSS =
0
Sector
4/R
SSS =
17
PSS =
1
R=
Redundant
512995/2021/O/o ED/Tele-I/RDSO276
Page 47 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.9.2 Numbering Scheme for Mobile Communication Network for Indian
Railways:-
10.9.2.1 The following numbers and identities are assigned for administration of each
mobile station in the network.
i) International Mobile Subscriber Identity (IMSI):
The structure of the IMSI will then be as shown in figure:
ii) Mobile Subscriber International Subscriber Directory Number (MS ISDN):
The structure of the MS ISDN will then be as shown in figure:
10.9.2.2 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.
10.9.2.3 The IMSI and MSISDN for Indian Railway shall be as below:-
512995/2021/O/o ED/Tele-I/RDSO277
Page 48 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
10.10 Tower Drawings and Dimensions:
10.10.1 The typical antenna height required for LTE for 700 MHz spectrum is 35 m in
case rural terrain model is adopted. The Cellular Towers available as per TEC
specifications and drawings are listed below.
512995/2021/O/o ED/Tele-I/RDSO278
Page 49 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
S. No. Parameter Standard
i) 40 Meter Narrow Base Heavy Weight
Tower
GR/TWR-02/02.MAY 2004
(RA May 2008)
ii) 60 Meter Heavy Weight M/W Tower G/TWR-03/01. JAN2000
iii) 40 Meter Narrow Base Light Weight
Tower
GR/TWR-04/01.DEC2000
iv) 30 Meter Narrow Base Heavy Weight
Tower
GR/TWR- 05/01.DEC2000
v) 30 Meter Narrow Base Heavy Weight
Tower
GR/TWR- 05/01.DEC2000
vi) 20 Meter Narrow Base Heavy Weight
Tower
GR/TWR- 06/01.DEC2000
vii) 30 Meter Narrow Base Light Tower GR/TWR-07/01.DEC2002
viii) Roof Top Tower for Cellular Mobile
Systems (30/25/20/15/10 M Tower )
GR/TWR- 09/01.FEB2004
ix) 60 Meter Narrow Base Light Weight
Tower for Cellular Systems
GR/TWR-10/01.NOV 2004
x) 40,30 & 20 meter Towers for Cellular
Systems
GR/TWR-11/01.DEC 2004
xi) 40 meter tower for cellular system (up
to170 Kmph wind speed Amendment
No.1 Dated 9.5.2006
GR/TWR-12/01. JUN 2005
10.10.2 For Tower dimensions, RDSO latest guidelines shall be followed.
11.0 User Equipment (UE) Requirements:
11.1 The MC PTT Handsets shall work and meet all required features and
functionalities of LTE network.
11.2 The MC PTT Handsets shall work in Indian Railway spectrum in 700 MHz
band and also work in other frequency bands of LTE if specified.
11.3 The maximum throughput in LTE with 5 MHz bandwidth may be calculated
as below.
DL UL
Bandwidth 5 MHz 5 MHz
MIMO 2x2 1x2
Resource Blocks 25 2
Modulation 64 QAM 16 QAM 64 QAM
Maximum Throughput 36.7 Mbps 840 Kbps 1.48 Mbps
11.4 The various UE classes in LTE are as mentioned below. Purchaser may select
the UE category as per requirement.
512995/2021/O/o ED/Tele-I/RDSO279
Page 50 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Class 1 Class 2 Class 3 Class 4 Class 5
Peak Data Rate
UL/DL (Mbps)
10/5 50/25 100/50 150/50 300/75
Modulation DL 64 QAM 64 QAM 64 QAM 64 QAM 64 QAM
Modulation UL 16 QAM 16 QAM 16 QAM 16 QAM 64 QAM
MIMO DL Optional 2x2 2x2 2x2 2x2
12.0 Quality of Service (QOS) Requirements:
12.1 QOS Parameters for Indian Railway applications/ solutions on LTE:
The one-to-one mapping of standardized QCI values to standardized
characteristics for the tentative services shall be as per below:-
QCI Resourc
e Type
Priority
Level
Packet
Delay
Budget
Packe
t
Error
Loss
Rate
Example Services Mapping of Indian
Railway applications
(Tentative)
1
2 100
ms
10-2
Conversational
Voice
Voice Mobile
Communication
2
GBR
4 150
ms
10-3
Conversational
Video (Live
Streaming)
Live Video Streaming
from Accident Site
(ART) or similar
3
3 50 ms
10-3
Real Time Gaming Not Applicable
4
5 300
ms
10-6
Non-Conversational
Video (Buffered
Streaming)
Live Video Streaming
from Accident Site
(ART)
65
0.7 75 ms
10-2
Mission Critical user
plane Push To Talk
voice (e.g., MCPTT)
Mission Critical
Services
66
2 100 ms
10-2
Non-Mission-
Critical user plane
Push To Talk voice
Voice Mobile
Communication
512995/2021/O/o ED/Tele-I/RDSO280
Page 51 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
5
1 100
ms
10-6
IMS Signalling Train Automation and
Protection Services i.e.
TCAS, ETCS and other
services
6
6 300
ms
10-6
Video (Buffered
Streaming)
TCP-based (e.g.,
www, e-mail, chat,
ftp, p2p file sharing,
progressive video,
etc.)
Video Surveillance
System (CCTV),
Passenger Information
System and Real Time
Train Information
System , IoT Services
etc
7
Non-
GBR
7 100
ms
10-3
Voice,
Video (Live
Streaming)
Interactive Gaming
Voice Mobile
Communication,
Live Video Streaming
from Accident Site
(ART) & Video
Surveillance System
(CCTV)
8
8 300
ms
10-6
Video (Buffered
Streaming)
TCP-based (e.g.,
www, e-mail, chat,
ftp, p2p file sharing,
progressive video,
etc.)
Video Surveillance
System (CCTV),
Passenger Information
System and Real Time
Train Information
System , IoT Services
etc
9
9
69
0.5 60 ms
10-6
Mission Critical delay
sensitive signalling
(e.g., MC-PTT
signalling)
Mission Critical
Services
70
5.5 10-6
Mission Critical Data
(e.g. example services
are the same as QCI
6/8/9)
Mission Critical
Services
12.2 Each EPS bearer/E-RAB (Guaranteed Bit Rate and Non Guaranteed Bit Rate)
shall be associated with and support QoS level parameters i.e. QoS Class
Identifier (QCI) and Allocation and Retention Priority (ARP).
12.3 The eNodeB can be pre-configured the QCI values that is used as a reference
to access node-specific parameters that control bearer level packet forwarding
treatment.
512995/2021/O/o ED/Tele-I/RDSO281
Page 52 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
The eNodeB can be configured to also use the ARP priority level in addition to
the QCI to control bearer level packet forwarding treatment in the eNodeB for
SDFs having high priority ARPs.
12.4 As railways will be running a number of rail applications on the same LTE
network it is important to plan and derive an e2e QoS design, taking the
Railways key applications, use cases, and call scenarios into account and
ensure;
• End to end LTE QoS design techniques
• End to End product support for QoS
12.4.1 LTE QoS Planning and Designing: MCPTT, Train control (ETCS) and
Platform information will run on the same network. From QoS design
perspective, priority should be planned to support the vital applications and
hence train control and MCPTT must be given higher priority. Some rail
applications are delay sensitive but do not demand high DL and/or UL
throughput.
12.4.2 Product Support and Configuration of QoS : There is a requirement to ensure
the relevant products in the solution can support the expected QoS. The
associated features must also be properly configured and activated.
12.4.3 Since some of the rail applications are more delay and packet loss sensitive, it
is important to consistently configure the nodes across the network which
includes IP-transport/LTE backhaul (e.g. QoS, MTU size, DSCP). The key
areas that should take in to account are as below:
PTT Application Server
LTE core (EPG)
SAPC (PCRF)
LTE backhaul
LTE RAN (eNodeB)
UE (Devices)
13.0 RAMS (Reliability, Availability, Maintainability and Safety):
13.1 System design and architecture of LTE network for Railways, not only
mandates additional technical capabilities but also requires careful planning
and designing considerations which go beyond to normal Mobile operator
network design.
13.2 Design for Mission critical applications, which requires
• Very high reliability and availability (More than four 9s)
• Well defined corridor (railways track, platform and depots) coverage
• Guaranteed latency, packet loss with strict tolerance levels
512995/2021/O/o ED/Tele-I/RDSO282
Page 53 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
• Low to medium throughput applications
• Quality of Service (E.g. Priority and Pre-emption)
• Security
13.3 Reliability, Availability, Maintainability and Safety:
LTE solution to adhere to strict RAMS (Reliability, Availability,
Maintainability and Safety). This is usually defined based on the EN 50126,
50128 and 50129 series of standards.
13.4 Preventive and Protective Solution Planning and Design:
As stated above the LTE solutions for Rail require careful requirement
analysis and solution planning/design to comply with Indian Railways RAMS
requirements. The planning and design of the technical solution must not only
take the reliability and availability into account but must also consider the
system maintainability and safety requirements throughout the system life
cycle. Some of the notable areas related to RAMS and their impact to solution
are discussed below.
13.5 More Than 4 Nines Availability:
Availability of rail systems are usually expected to be ≥ 99.99%. A system
availability target of 99.995% or 99.999% are often required by rail operators
for new mission critical radio communication systems. Further, it is expected
that any system deployed for mission critical rail applications, must avoid any
single point of failures.
13.5.1 From solution design perspective this means the end to end LTE network must
adhere to minimal unplanned outages, avoiding any single point of failures.
(E.g. 26.283 minutes in a year for 99.995.
13.5.2 For train control ETCS systems alone must adhere to 99.99% availability.
When LTE is being used as the DCN (Data Communication Network)
subsystem in the ETCS, this means the LTE network must be planned and
designed to support more than 99.99% availability.
13.6 Geo Redundancy for Key Network Functions : Rail operators usually request
physical location (geo) redundancy for the key network functions
(Redundancy at minimum two geographically separated locations).
13.6.1 This requirement is influenced by two key reasons;
To ensure system availability of key technical nodes or key functional failures.
To maintain minimum operational capacity in the rail network in an unlikely
event of a disaster. (natural or man-made, e.g. floods, earth quakes, terrorist
attacks at a primary site)
512995/2021/O/o ED/Tele-I/RDSO283
Page 54 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
13.6.2 When designing redundancy into a network, it is important to visualize the
network as an end to end interdependent system. It is crucial to evaluate and
understand the impact when one subsystem becomes unavailable or has
degraded performance. If a particular sub system in the network affects the
desired performance of the system as a whole, an appropriate redundancy
mechanism should be planned and incorporated.
13.6.4 It is expected that a LTE network running mission critical applications (e.g.
automatic train control, MCPTT) will have the following key nodes in
different physical (geo) locations to provide redundancy. (Refer figure below):
• LTE core (User Data Centre (UDC), Evolved Packet Core (EPC), Service
Aware Policy Control (SAPC) and associated routers and switches)
• OSS
• MC-PTT Application Server
• IP-Transport core aggregation nodes (as part of the IP-transport and LTE
backhaul redundancy architecture)
Fig.- 5 : Physical Geo-Redundancy of Key Functions
13.7 Redundancy in Radio Access Network: When an LTE network is used for
MCPTT and automatic train control, (ETCS) redundancy in the radio access
network and train on-board equipment are also mandatory.
13.7.1 Planning for sufficient redundancy in the e2e network, including radio access
network is important to maintain the availability and reliability targets of a rail
network. From solutions perspective, appropriate redundancy in RAN should
be planned and designed taking all of the following interdependent areas in to
account:
512995/2021/O/o ED/Tele-I/RDSO284
Page 55 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
• Track-side coverage deployment models
• eNodeB configuration models
• On-board coverage system models
• Train on-board equipment (Cab radio equipment, On-board LTE devices)
• IP-Transport and LTE backhaul solution and architecture
• LTE core network solution and architecture
• Applications
13.8 Site Hardening:
Hardening is the process of securing a system by reducing its surface of
vulnerability. Hardening is a design and a configuration issue as well as a
deployment issue.
13.8.1 When an LTE network is being used for mission critical applications, it is
important to pay special attention to site hardening. Though the LTE
equipment and the architecture may be planned to support high availability,
physical site characteristics (e.g. security vulnerabilities) might hinder the total
system availability and reliability. Hence it is important to take these
requirements into consideration in core and radio site related solutions design.
14.0 Security Aspects:
14.1 Securing authentication, authorization and communication integrity of both
MC users and O&M staff is critical. Although these requirements are normally
present also in commercial network operation, security levels are typically
higher for mission critical communications. Solutions include strong
encryption algorithms and hardening of network sites.
14.2 Network Level security:
To ensure end to end protection at network level, there shall be integrity and
confidentiality protection of the end-to-end user traffic. The end-to-end user
traffic shall be protected from an integrity and confidentiality point of view.
The end-to-end confidentiality and integrity is handled by using a Virtual
Private Network (VPN) solution. The solution uses VLANs to separate the
traffic into separate security zones for:
• User plane traffic
• Control plane traffic
• O&M traffic
14.3 Since VLAN’s only offer logical separation the use of IPsec adds
confidentiality and integrity by using the design options to make sure that:
• Connections between sites are protected by IPsec
• Connections between the EPC and other physical sites are protected by IPsec
512995/2021/O/o ED/Tele-I/RDSO285
Page 56 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
• The connections from the eNodeB to the EPC are protected with IPsec
14.4 Data Confidentiality & integrity:
The network management network integrity to ensure that data provisioned is
consistent and accurate. The solution to ensure that all business logics perform
syntactic validation to verify request format, data type as well as data value
validity against predefined value range. The solution to support Semantic
validation with regards to application/service logic and customer context. The
solution to incorporate external validation functions into the provisioning
process.
14.5 Identification Accountability & Authorization control
The network support proper authentication and authorization taking into
account security and privacy, i.e. it should be possible to present different
views on the data to the parties which require access, dependent on the
authorization. Access to the logging system and data can be restricted to
privileged accounts and user profiles (e.g. root, system administrator). There
shall be no access to Operating system or file system on the node.
14.6.1 The network element support encryption of data elements (i.e. passwords,
etc.), the network elements support traffic separation, access control lists and
logging for a historical view of “who did what” (Accounting). Authentication,
Authorization, and Accounting for Administrators. The network elements to
provide security event/KPI reporting and audit logging.
14.7 Node Hardening:
The node to be hardened from start and services shall only be possible on
request. The node to support secure boot, meaning it shall only boot on vendor
signed boot image. The node to support signed software, meaning only
software signed by vendor can be accepted by the node. This refers to
configurations files, SW releases, features etc.
14.8 O&M Security (O&M protocols, such as HTTPS, TLS, SSH, and SFTP can be
used. Further, centralized user authentication and authorization using the SLS
and LDAPS using OSS is recommended)
15.0 Regulatory Approvals and Certifications and Environmental Requirements:-
15.1 EMI/ EMC requirements for LTE base Station shall be as below as applicable:-
S.
No.
Parameter Standard
i) Conducted and Radiated Emission CISPR 22 (2008) OR
512995/2021/O/o ED/Tele-I/RDSO286
Page 57 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
CISPR 32 Class-A
ii) Immunity to Electrostatic discharge:
Contact discharge level 2 {± 4 kV}
IEC-61000-4-2
Performance Criteria-B, Clause
9
iii) Immunity to Electrostatic discharge:
Air discharge level 3 {± 8 kV}
IEC-61000-4-2
Performance Criteria-B, Clause
9
iv) Immunity to radiated RF:
(a) Radio Frequency: 80 MHz to 1
GHz, Electromagnetic field: 3V/m
(b) Radio Frequency: 800 MHz to
960 MHz, Electromagnetic field:
10V/m
(c) Radio Frequency: 1.4 GHz to 6
GHz, Electromagnetic field: 10V/m
IEC 61000-4-3 (2010);
Performance Criteria-A, Clause
9
v) Immunity to fast transients (burst):
Test Level 2:
(a) 1 kV for AC/DC power port
(b) 0. 5 kV for signal / control / data
/ telecom lines.
IEC 61000- 4- 4 {2012);
Performance Criteria-B, Clause
9
vi) Immunity to surges: AC/DC ports
a. 2 kV peak open circuit voltage for
line to ground
b. 1kV peak open circuit voltage for
line to line
IEC 61000-4-5 (2014)
Performance Criteria-B, Clause
9
vii) Immunity to surges: Telecom ports
(a) 2 kV peak open circuit voltage
for line to ground coupling.
(b) 2 kV peak open circuit voltage
for line to line coupling.
IEC 61000-4-5 (2014)
Performance Criteria-C, Clause
9
viii) Immunity to conducted disturbance
induced by Radio frequency fields:
Under the test level 2 {3 V r.m.s.} in
the frequency range 150 kHz-80
MHz for AC / DC lines and Signal
/Control/telecom lines.
IEC 61000-4-6 (2013)
Performance Criteria-A, Clause
9
ix) Immunity to voltage dips & short
interruptions (applicable to only ac
mains power input ports, if any):
Limits: -
(a) a voltage dip corresponding to a
reduction of the supply voltage of
30% for 500ms (i.e. 70% supply
IEC 61000-4-11 (2004):
a. Performance Criteria B for
Reduction of Supply 30% for
500ms or Dip to reduction of
60% for 100ms
b. Performance Criteria C for
Reduction of 60% for 200ms
512995/2021/O/o ED/Tele-I/RDSO287
Page 58 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
voltage for 500ms)
(b) a voltage dip corresponding to a
reduction of the supply voltage of
60% for 200ms; (i.e.40% supply
voltage for 200ms)
(c) a voltage interruption
corresponding to a reduction of
supply voltage of > 95% for 5s.
(d) a voltage interruption
corresponding to a reduction of
supply voltage of >95% for 10ms.
c. Performance criteria C for
Voltage Interruption>95% for 5
s
(Note: In case of Battery back-
up performance criteria A is
applicable).
d. Performance Criteria B for
Voltage Interruption >95%
duration :10ms
(Note: In case of Battery back-
up Performance Criteria A is
applicable for above
conditions.)
15.2 Safety requirements for LTE base Station may be as below as applicable:-
S.
No.
Parameter Standard
i) The equipment shall conform to IS
13252 part 1:2010- “Information
Technology Equipment – Safety-
Part 1: General Requirements”
[equivalent to IEC 60950-1 {2005}
“Information Technology Equipment
–Safety- Part 1: General
Requirements”]
Or IEC 62368-I:2014
IS 13252 part 1:2010 / IEC
60950-1 {2005} part 1;
or
IEC 62368-I:2014
15.3 Regulatory Approvals and Certifications for other Equipments/Accessories of
LTE shall be as per industry standards and Indian Railway requirements or as
specified by the purchaser.
15.4 Electromagnetic Radiation: The LTE shall meet Department of Telecom
(DoT) latest guidelines and regulations for Electromagnetic Radiation from
Antennae (LTE Base station).
15.4.1 As per DoT, “Licensee shall conduct audit and provide self certificates after
every two year as per procedure prescribed by Telecommunication
Engineering Centre (TEC)/ or any other agency authorised by Licensor from
time to time for conforming to limits/levels for Antennae (Base Station)
Emissions for general public exposure as prescribed by the Licensor from time
to time. The present limits/levels* are reproduced as below:-
512995/2021/O/o ED/Tele-I/RDSO288
Page 59 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
Frequency
Range
E-Field Strength
(Volt/Meter
(V/m))
H Field Strength
(Amp/Meter
(A/m))
Power Density
(Watts/Sq. Meter
(W/Sq.m))
400 MHz to
2000 MHz 0.434 f 1/2
0.0011 f 1/2 f / 2000
3 GHZ to
300 GHz
19.29 0.05 1
(f = frequency in MHz)” (*as per DoT letter no. 800-15/ 2010-V AS, dated
26/06/2013)
15.5 Environmental Requirements:
15.5.1 The System shall be suitable for operation in Indian climatic conditions and in
the temperature range and humidity range as specified below. Purchaser may
specify any other temperature requirement and humidity as per site
requirement.
15.5.2 The typical requirement for Temperature and Humidity and Ingress Protection
is mentioned below:-
Equipment Operating
Temperature
Operating
Humidity
Ingress
Protection
(IP)
Indoor
Installation
0ºC to 40ºC
0 to 95 %
(non condensing).
IP 54 or higher
Outdoor
Installation
-10ºC to 70ºC
0 to 95 %
(non condensing).
IP 67 or higher
15.5.3 For indoor installations, provision of Air Conditioning (AC) is mandatory.
15.5.4 In case, equipment is housed in an enclosure then the enclosure shall meet IP
requirements.
512995/2021/O/o ED/Tele-I/RDSO289
Page 60 of
60
Implementation of LTE on
Indian Railways
Document No. STT/TAN/LTE/2021,
Version 1.0
Date of Issue
dd.05.2021
16.0 Planning, Positioning and Deployment of EPC over Indian Railway network.
16.1 Initially, LTE shall be implemented on Indian Railways with 2 EPCs at two
different geographic locations (Northern and Southern). Later on, 2 more
EPCs (Western and Eastern) may be provided based on increase of traffic
capacity. The EPCs shall be redundant and virtualized.
16.2 The Northern EPC and Southern EPC shall work in redundant mode with 1:1
redundancy. The Northern/Southern EPC should be planned to work on full
capacity of designated Zonal Railways. The same capacity shall be kept as
redundant in Southern/Northern EPC.
16.3 The EPCs and designated Zonal Railways (tentative) shall be as per below:-
I) Northern EPC :
SN Zones EPC location
i) Northern Railway
New Delhi
ii) North Western Railway
iii) North Eastern Railway
iv) North Central Railway
v) East Central Railway
vi) Eastern Railway
vii) South Eastern Railway
viii) North East Frontier Railway
II) Southern EPC :
SN Zones EPC location
i) Southern Railway
Secunderabad
ii) South Central Railway
iii) South Western Railway
iv) Western Railway
v) West Central Railway
vi) Central Railway
vii) East Coast Railway
viii) South East Central Railway
---XXX---
512995/2021/O/o ED/Tele-I/RDSO290