technical advisory note (tan) on implementation of lte on

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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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


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

of

60


Indian Railways


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


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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)


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

of

60


Indian Railways


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,


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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


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);


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)


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

of

60


Indian Railways


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

of

60


Indian Railways


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

of

60


Indian Railways


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

technical advisory note (tan) on implementation of lte on

Documents