GR Lte Nov 2016 PDF

वर्गीय आवर्श्यकताएँ
सं ख् या:टीईसी/जीआर/डबल्यू ए स/एलटीए -001/01.नवर्म्बर

2016
GENERIC REQUIREMENTS
No.: TEC/GR/ WS/LTA-001/01. Nov. 2016
लॉन्ग टमर एवर्ल्यू श न-एडवर्ांस् ड(एलटीई-ए) - एवर्ं एवर्ोल्वर्ड पै के ट

कोर (ईपीसी) िरलीस 11
Long Term Evolution -Advanced (LTE-A) And
Evolved Packet Core (EPC) Release 11
© टीईसी, 2016
© TEC, 2016
द ू र सं च ार अभिभियांि त्रिकी के द
खु श ीदलाल भिवर्न, जनपथ, नई िदल्ली–110001, भिारत
TELECOMMUNICATION ENGINEERING CENTRE

KHURSHID LAL BHAWAN, JANPATH, NEW DELHI – 110001, INDIA
c.gov.in
Release 01: November, 16
2
Price: 800/-FOREWORD
Telecommunication Engineering Centre (TEC) functions under

Department of Telecommunications (DOT), Government of India.
Its activities include:
 Issue of Generic Requirements (GR), Interface Requirements
(IR), Service Requirements (SR) and Standards for Telecom Products
and Services
 Field evaluation of products and Systems
 National Fundamental Plans
 Support to DOT on technology issues
 Testing & Certification of Telecom products
For the purpose of testing, four Regional Telecom Engineering Centers
(RTECs) have been established which are located at New Delhi,
Bangalore, Mumbai, and Kolkata.
ABSTRACT
This document contains the Generic Requirement (GR) of Long Term

Evolution-Advanced including radio network evolution and System
Architecture Evolution (SAE) evolution of the packet core network (Evolved
Packet Core, EPC) defined by 3GPP under Release-11 of 36 series for
deployment in the Indian mobile network.
The document covers the technical and General Requirements, features &
functionality of the various nodes involved viz. e-NodeB, MME, Packet/
Serving Gateway, Policy Control and Charging Rules Function (PCRF),
relevant part of HSS/IMS for support of EPC nodes, OMAP, SON, backhaul
interface requirements on respective nodes, Support required on network
nodes for required support of Application services, dimensioning, general
requirements etc.
This document doesn’t cover the technical and general specifications for
Home eNodeB, MBMS, Backhaul/Backbone transport network and
application servers.
This GR is applicable for FDD and TDD.
CONTENTS
Claus Particulars Page No.

e
History Sheet i
References ii
Chapter -1
1 Introduction 1
.
2 Description 2
.
3 LTE – Radio Access Network (RAN) 10

.
4 Mobility Management Entity 33

.
5 PDN and Serving -Gateway 38

.
6 Policy And Charging Function (PCRF) 41

.
7 Home Subscriber Server (HSS) 44

.
8 System requirements 48
.
9 Operations Administration Maintenance and 49

. Provisioning (OAM&P)
1 IMS/Voice over LTE 54

0
.
1 Charging 56
1
.
1 Wifi and LTE Interworking 57

2
.
1 Virtualization 58
3
.
4
1 General Requirements 59
4
.
1 Quality Requirements 66
5
.
1 EMI/EMC Requirements 69
6
.
\
Chapter -2
1 Information for the procurer of product 72
7
.
Abbreviations 74
HISTORY SHEET
Sl. GR No. Title Remar
No. ks
1 GR/WS/LTA- Long Term Evolution -Advanced Issue 01

001/01 NOV (LTE-A) And Evolved Packet Core November
2016 (EPC) Release 11 2016
NO. TEC/GR/LTA-001/01. NOV 16 6

REFERENCES
S.N Document No. Title/Document Name

o.
1) 3GPP TR 21.905 “Vocabulary for 3GPP Specifications”
2) 3GPP TS 22.278 " Service requirements for the Evolved Packet
System (EPS)".
3) 3GPP TS 36.306 " Evolved Universal Terrestrial Radio Access (E-
UTRA); User Equipment (UE) radio access
capabilities ".
UTRA); User Equipment (UE) radio transmission
and reception ".
UTRA); Base Station (BS) radio transmission and
reception ".
UTRA); Medium Access Control (MAC) protocol
specification".
UTRA); Radio Link Control (RLC) protocol
specification ".
UTRA); Packet Data Convergence Protocol (PDCP)
specification ".
UTRA); Radio Resource Control (RRC); Protocol
specification".
1 3GPP TS 36.201 " Evolved Universal Terrestrial Radio Access (E-
0) UTRA); LTE physical layer; General description ".
1) UTRA); Physical channels and modulation ".
2) UTRA); Multiplexing and channel coding ".
3) UTRA); Physical layer procedures ".
4) UTRA); Physical layer; Measurements ".
5) UTRA) and Evolved Universal Terrestrial Radio
Access Network (E-UTRAN); Overall description;
Stage 2".
6) UTRA); Requirements for support of radio

resource management ".
1 3GPP TS 36.411 " S1 Layer 1".
7)
1 3GPP TS 36.413
8) " S1Application protocol (S1AP) ".
1 3GPP TS 36.420 “X2 General aspects and principles”

9)
2 3GPP TS 36.423 “X2 Application protocol (X2AP)”

0)
2 3GPP TS 23.401 “General Packet Radio Service (GPRS)

1) enhancements for Evolved Universal Terrestrial
Radio Access Network (E-UTRAN) access”
2 3GPP TS 23.402 Architecture enhancements for non-3GPP
2) accesses
2 3GPP TS 22.115 Service aspects; Charging and billing
3)
2 3GPP TS 23.122 Non-Access-Stratum (NAS) functions related to

4) Mobile Station (MS) in idle mode
2 3GPP TS 23.203 " Policy and charging control architecture "
5)
2 3GPP TS 32.240 “Telecommunication management; Charging

6) management; Charging architecture and
principles”
2 3GPP TS 32.511 “Telecommunication management; Automatic
7) Neighbour Relation (ANR) management;
Concepts and requirements”
2 3GPP TS 32.521 Telecommunication management; Self-Organizing
8) Networks (SON) Policy Network Resource Model
(NRM) Integration Reference Point (IRP);
Requirements
2 3GPP TS 32.522 “Telecommunication management; Self-
9) Organizing Networks (SON) Policy Network
Resource Model (NRM) Integration Reference
Point (IRP); Information Service (IS)"
0) Organizing
Networks (SON); Policy Network Resource Model
(NRM)
Integration Reference Point (IRP); Common
Object
Request Broker Architecture (CORBA) Solution
Set (SS)
”
Organizing
Networks (SON) Policy Network Resource Model
(NRM)
Integration Reference Point (IRP); eXtensible
Markup
Language (XML) file format definition” .
2) Organizing Networks (SON); Policy Network
Resource Model (NRM) Integration Reference
Point (IRP); Solution Set (SS) definitions
3 3GPP TS 33.106 “Lawful interception requirements.
3)
3 3GPP TS 33.107 “3G security; Lawful interception architecture and

4) functions”
3 3GPP TS 33.108 “3G security; Handover interface for Lawful
5) Interception (LI)”
3 3GPP TS 33.210 “3G security; Network Domain Security (NDS); IP
6) network layer security”
3 3GPP TS 33.401 “3GPP System Architecture Evolution (SAE);
7) Security architecture”
3 3GPP TS 33.402 “3GPP System Architecture Evolution (SAE);
8) Security aspects of non-3GPP accesses”
3 3GPP TS 24.301 “Non-Access-Stratum (NAS) protocol for Evolved
9) Packet System (EPS); Stage 3”
4 3GPP TS 32.421 “Telecommunication management; Subscriber
0) and equipment trace; Trace concepts and
requirements”
1) and equipment trace; Trace control and
configuration management”
2) and equipment trace; Trace data definition and
management”
4 3GPP TS 23.002
3)
“Network architecture”
4 3GPP TS 23.216 “Single Radio Voice Call Continuity (SRVCC);

4)
Stage 2” .
4 3GPP TS 29.168 “Cell Broadcast Centre interfaces with the

5) Evolved Packet Core; Stage 3” .
4 3GPP TS 29.212 “Policy and charging control over Gx reference
6) point” .

4 3GPP TS 29.214 “Policy and charging control over Rx reference
7) point” .
4 3GPP TS 29.272 “Evolved Packet System (EPS); Mobility
8) Management Entity (MME) and Serving GPRS
Support Node (SGSN) related interfaces based on
Diameter protocol”.
4 3GPP TS 29.274
9)
“3GPP Evolved Packet System (EPS); Evolved
General
Packet Radio Service (GPRS) Tunnelling Protocol
for
Control plane (GTPv2-C); Stage 3”.
5 3GPP TS 36.171
0) “Evolved Universal Terrestrial Radio Access (E-
UTRA);
Requirements for Support of Assisted Global
Navigation
Satellite System (A-GNSS) “.
5 3GPP TS 23.271 “Functional stage2 description of Location
1) Services (LCS)” .
5 3GPP TR 23.891 “Evaluation of LCS Control Plane Solutions for
2) EPS”.
5 3GPP TS 36.355 “Evolved Universal Terrestrial Radio Access (E-
3) UTRA); LTE Positioning Protocol (LPP)”.
5 3GPP TS 22.071 “LCS Service description; stage 1”.
4)
5 3GPP TS 36.305 “Evolved Universal Terrestrial Radio Access

5) Network (E-UTRAN); Stage 2 functional
specification of User Equipment (UE) positioning
in E-UTRAN”.
5 3GPP TS 36.455 “Evolved Universal Terrestrial Radio Access (E-
6) UTRA); LTE Positioning Protocol A (LPPa)”.
5 ISO-9001:2008 “Quality Management System – Requirement”.
7)
5 IS-41D & E “Cellular Radio Telecommunications Intersystem

8) Operations”
5 CISPR 22 (2003) “Limits and methods of measurement of radio
9)
disturbance characteristics of Information
Technology Equipment”.
6 EN55022 “Limits and Methods of Measurement of Radio
0)
Interference Characteristics of Information

Technology Equipment”.
6 IEC 60479-1 (1984) “Effects of current on human beings: Part 1”
1)
6 IEC 60215 (1987) “Safety requirements of radio transmitting

2)
equipments (for Radio equipments only)”
6 IEC-60950 (2001) “Information technology equipment – Safety”
3)
6 TEC/FLA/SMP/001
4)
6 TEC/GR/BAT-01
5)
6 GR/WS/LIS-003
6)
6 GR/WS/UTR-001/02
7)
6 GR/IMS-01
8)

CHAPTER-1
1.0 Introduction
This document contains the Generic Requirement (GR) of Long Term

Evolution -
Advanced including radio network evolution and System Architecture
Evolution (SAE) evolution of the packet core network (Evolved Packet
Core, EPC) defined by 3GPP under Release-11 of 36 series for deployment
in the Indian mobile network.
The document covers the technical and General Requirements, features &
functionality of the various nodes involved viz. e-NodeB, MME, Packet/
Serving Gateway, Policy Control and Charging Rules Function (PCRF),
relevant part of HSS/IMS for support of EPC nodes, OMAP, SON, backhaul
interface requirements on respective nodes, Support required on network
nodes for required support of Application services, dimensioning, general
requirements etc.
This document doesn’t cover the technical and general specifications for
Home eNodeB, MBMS, Backhaul/Backbone transport network and
application servers.
This GR is applicable for FDD and TDD.
1.1. Definitions
Long Term Evolution (LTE): Long Term Evolution (LTE) is the

standardisation work by the Third Generation Partnership Project (3GPP)
which defines a new high-speed radio access method for mobile
communications systems.
LTE is the enhancement of the 3GPP family of cellular systems that
include GSM, GPRS and EDGE as well as WCDMA and now HSPA (High
Speed Packet Access), which offers a smooth evolutionary path to higher
speeds and lower latency. Besides providing the efficient use of operators’
finite spectrum assets, LTE offers richer mobile service environment.
Realisation of full potential offered by advanced new radio interface of LTE
requires an evolution from present hybrid packet/circuit switched
networks to all-IP (Internet Protocol) environment. From the Network
operator’s perspective, LTE facilitates reduced delivery costs for rich,
blended applications combining voice, video and data services and
simplified inter-working with other fixed and wireless networks.
The LTE–SAE architecture reduces the number of nodes, supports flexible
network configurations and provides a high level of service availability.
LTE– SAE will also inter-operate with GSM, WCDMA/ HSPA and CDMA.

Evolved Packet Core (CBC): The EPC is the latest evolution of the 3GPP
core network architecture for providing converged voice and data on a 4G
Long-Term Evolution (LTE) network. EPC was first introduced by 3GPP in
Release 8 of the standard.
It was decided to have a "flat architecture". The idea is to handle the
payload (the data traffic) efficiently from performance and costs
perspective. Few network nodes are involved in the handling of the traffic
and protocol conversion is avoided.
It was also decided to separate the user data (also known as the user
plane) and the signalling (also known as the control plane) to make the
scaling independent.
3GPP specified support of multiple access technologies in EPC and also

the handover between these accesses. The idea was to bring convergence
using a unique core network providing various IP-based services over
multiple access technologies.
Existing 3GPP radio access networks are supported. 3GPP specifications
define how the interworking is achieved between an E-UTRAN (LTE and
LTE-Advanced), GERAN (radio access network of GSM/GPRS) and UTRAN
(radio access network of UMTS-based technologies WCDMA and HSPA).
The EPS also allows non-3GPP technologies to interconnect the UE and the
EPC. Non-3GPP means that these accesses were not specified in the 3GPP.
These technologies include e.g. WiMAX, cdma2000®, WLAN or fixed
networks.
2. Description
Key Features to be modified as: Some of the key features of LTE as
mentioned in 3GPP include the following: (However requirements against
this GR shall be limited to scope defined in clause 1.1)
 High spectral efficiency
- OFDM in Downlink, Robust against multi-path interference & High
affinity to advanced techniques such as Frequency domain channel-
dependent scheduling & MIMO
- DFTS-OFDM (“Single-Carrier FDMA”) in Uplink, Low PAPR, User
orthogonality in frequency domain
- Multi-antenna application
 Very low latency
- Short setup time & Short transfer delay; Short HO latency and
interruption time;
Short TTI, RRC procedure, Simple RRC states
 Support of variable bandwidth 1.4, 3, 5, 10, 15 and 20 MHz
 Simple protocol architecture
- Shared channel based
- PS mode only with VoIP capability
 Simple Architecture

- eNodeB as the only E-UTRAN node
- Smaller number of RAN interfaces, eNodeB « MME/SAE-Gateway (S1),
eNodeB « eNodeB (X2)
 Compatibility and inter-working with earlier 3GPP Releases
 Inter-working with other systems, e.g. cdma2000
 FDD and TDD within a single radio access technology
 Efficient Multicast/Broadcast
- Single frequency network by OFDM
 Support of Self-Organising Network (SON) operation
 Enhanced Home NodeB / eNodeB
 Public Warning System
 Multi-Media Telephony Service enhancements
 Service Specific Access Control in EPS
 Support for IMS Emergency Calls over GPRS and EPS
 LCS for LTE and EPS
2.1 Applications: Some of the services and applications which can be

offered via LTE network are following, however these scope of
applications deliverables are not defined in this GR:
 Guaranteed Bit rate (GBR) requiring like

- Conversational Voice
- Conversational Video (Live Streaming)
- Real Time Gaming
- Non-Conversational Video (Buffered Streaming)
 Non- Guaranteed Rate (non-GBR) requiring services like
- IMS Signalling
- Video (Buffered Streaming) TCP-based (e.g., www, e-mail,
chat, ftp, p2p file sharing, progressive video, etc.)
- Voice, Video (Live Streaming) Interactive Gaming
- Video (Buffered Streaming) TCP-based (e.g., www, e-mail,
chat, ftp, etc.)

2.2 Network Architecture
The Architecture of a GSM/WCDMA/LTE network is shown in Figure

1.1.
Application Services
IP Networks IMS Core
SRVCC
Rx
SGi Gxa PCRF
SWx SWm
HSS 3GPP AAA
STa Gx
HLR S6d S6a S6b
Gxa/
GMLC
S13 OCS Radius
EIR SMLC
CoA
Gr SLg/SLs Gz Gy
Sv S2b (GTP)
ePDG
MSC PDN GW
S4
SGs S5/S8 (GTP) S2a
Gs S11 Serv GW GTP
SGSN S3
rel8
MME S2a STa/ SWn
PMIP Radius
Gb S10
Iu-C S12 S1-U

2.2.1 The key components ofS1-Cthe LTE network sub-system as highlighted in
LTE CDMA WiFi Non-3GPP
red colour
2G 3G
in above diagram, are part of the scope of thisNon-Trusted
GR as
eHRPD
mentioned below:
 eNodeB
 MME (Mobility Management Entity)
 S-GW (Serving Gateway)
 PDN-GW (Packet Data Network Gateway)
 HSS (Home Subscriber Subsystem)
 PCRF (Policy Control and Charging Rules Function)
 GSMA VoLTE (Voice over LTE) /SRVCC (Single Radio Voice Call
Continuity)
2.2.2 Interfaces for LTE network:
2.2.2.1 S1-MME (S1-C): Reference point for the control plane protocol
between E-UTRAN and MME. 3GPP TS 36.413
2.2.2.2 S1-U: Reference point between E-UTRAN and Serving GW for the per
bearer user plane tunneling and inter eNodeB path switching during
handover. 3GPP TS36.414
2.2.2.3 S3: It enables user and bearer information exchange for inter 3GPP
access network mobility in idle and/or active state.
2.2.2.4 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.
2.2.2.5 S5: It provides user plane tunneling 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 non-collocated PDN GW for the required PDN
connectivity.
2.2.2.6 S6a: It enables transfer of subscription and authentication data for
authenticating/authorizing user access to the evolved system (AAA
interface) between MME and HSS.
2.2.2.7 S6d: It enables transfer of subscription and authentication data for
authenticating/authorizing user access between Rel-8 SGSN and
HSS.
2.2.2.8 Gx: It provides transfer of (QoS) policy and charging rules from PCRF
to Policy and Charging Enforcement Function (PCEF) in the PDN GW.
2.2.2.9 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.
2.2.2.10 S10: Reference point between MMEs for MME relocation and MME to
MME information transfer.
2.2.2.11 S11: Reference point between MME and Serving GW.
2.2.2.12 S12: Reference point between UTRAN and Serving GW for user
plane tunneling 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.
2.2.2.13 S13: It enables UE identity check procedure between MME and EIR.
2.2.2.14 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.
2.2.2.15 Rx: The Rx reference point resides between the AF and the PCRF in
the TS 23.203
2.2.2.16 X2: This is the interface between eNB. The interface is used for data
forwarding and control messages during an inter-eNB handover.
3GPP TS36.422/36.423
2.2.2.17 Gb: Interface between the base station subsystem and the SGSN
the transmission protocol could be Frame Relay or IP.
2.2.2.18 Gr: Interface between the SGSN and the HLR. Messages going
through this interface uses the MAP3 protocol.
2.2.2.19 Gs : Interface between the SGSN and the MSC (VLR). Uses the
BSSAP+ protocol. This interface allows paging and station
availability when it performs data transfer. When the station is
attached to the GPRS network, the SGSN keeps track of which
routing area (RA) the station is attached to. An RA is a part of a
larger location area (LA). When a station is paged this information is
used to conserve network resources. When the station performs a
PDP context, the SGSN has the exact BTS the station is using.
2.2.2.20 Gy: The on-line charging interface between the PDN GW and the
online charging system (OCS). Uses the diameter protocol (DCCA
application).
2.2.2.21 Gz: The off-line (CDR-based) charging interface between the S-Gw
/PDN GW and the CG. Uses GTP'
2.2.2.22 SLg: This defines the EPC LCS Protocol (ELP) used between the
GMLC and the MME in the Evolved Packet Core (EPC).
2.2.2.23 SGs: The support CS fall back in EPS a new interface SGs is added in
LTE architecture. SGs interface is the reference point between the
MME and MSC server. SGs interface is used for the mobility
management and paging procedures between EPS and CS domain,
and is based on the Gs interface procedures. The SGs reference
point is also used for the delivery of both mobile originating and
mobile terminating SMS.
2.2.2.24 SWn: Interface between Untrusted Non-3GPP IP Access and ePDG
and is used for carrying signalling and DATA.
2.2.2.25 SWm: Interface between the 3GPP AAA and ePDG and is used for
authentication and authorisation of a user at tunnel setup between
UE and ePDG.
2.2.2.26 SWx: Interface between HSS and 3GPP AAA and is used for
subscriber profile management as well for non 3GPP access related
location management.
2.2.2.27 S2b: This interface provides user plane tunneling and tunnel
management between ePDG and PDN GW over GTP interface.
2.2.2.28 Gxa: GXa interface is required to support QoS rule and event
handling for PCC in a trusted non 3GPP network. Although as an
alternative to this radius protocol can be used for policy control for
trusted non 3GPP network
2.2.3 eNodeB (eNB): eNB is the RAN node in the network architecture
that is responsible for radio transmission to and
reception from UEs in one or more cells. The eNB is connected
to EPC nodes by means of an S1 interface. The eNB is also
connected to its neighbour eNBs by means of the X2 interface.
Below follows a high level description of the functionality provided
by eNB.

2.2.3.1 Cell control and MME support - eNB owns and controls the radio
resources of its own cells. Cell resources are requested by and
granted to MMEs in an ordered fashion.
2.2.3.2 Mobility control - The eNB is responsible for controlling the mobility
for terminals in active state. This is done by ordering the UE to
perform measurement and then performing handover when
necessary.
2.2.3.3 Control and User Plane security - The ciphering of user plane data
over the radio interface is terminated in the eNB. Also the ciphering
and integrity protection of RRC signaling is terminated in the eNB.
2.2.3.4 Shared Channel handling - Since eNB owns the cell resources, eNB
also handles the shared and random access channels used for
signaling and initial access.
2.2.3.5 Segmentation/Concatenation -
2.2.3.6 Radio Link Control (RLC) Service Data Units (SDUs) received from
the Packet Data Convergence Protocol (PDCP) layer consist of whole
IP packets that may be larger than the transport block size provided
by the physical layer. Thus, the RLC layer must support
segmentation and concatenation to adapt the payload to the
transport block size.
2.2.3.7 HARQ - A Medium Access Control (MAC) Hybrid Automatic Repeat

reQuest (HARQ) layer with fast feedback provides a means for
quickly correcting most errors from the radio channel. To achieve
low delay and efficient use of radio resources, the HARQ operates
with a native error rate which is sufficient only for services with
moderate error rate requirements such as for instance VoIP. Lower
error rates are achieved by letting an outer Automatic Repeat
reQuest (ARQ) layer in the eNB handle the HARQ errors.
2.2.3.8 Scheduling - A scheduler with support for the QoS (Quality of

Service)/ QCI (QoS Class Identifier) model shall provide for efficient
scheduling of User Plane and Control Plane data.
2.2.3.9 Multiplexing and Mapping - The eNB performs mapping of logical

channels onto transport channels.
2.2.3.10 Physical layer functionality - The eNB handles the physical layer
such as scrambling, Tx diversity, beamforming processing, and
OFDM modulation. The eNB also handles layer one functions like link
adaptation and power control.

2.2.3.11 Measurements and reporting - eNB provides functions for
configuring and making measurements on the radio environment
and eNB-internal variables and conditions. The collected data is
used internally for RRM (Radio Resource Management) but can be
reported for the purpose of multi-cell RRM.
2.2.4 Mobility Management Entity (MME) - The EPS architecture defines an

MME node, which contains Core Network control functionality.
Although the functionality is not entirely the same, the MME
conceptually constitutes a control plane SGSN node. The Control
Plane terminal protocols terminate at the MME which also manages
the mobility contexts of the UEs. The same MME remains in control
of a UE as long as the UE move within an MME pool area. Below
follow high level descriptions of the functions performed by the
MME.
2.2.4.1 UE attach/detach handling -This allows UE to register and de-

register to the network.
2.2.4.2 Security (AAA) - The MME implements functions for Authentication,

Authorization and Accounting (AAA) to verify users’ identities, grant
access to the network and track users’ activities, respectively. In
addition, the MME performs ciphering and integrity protection of
NAS message signaling.
2.2.4.3 EPS Bearer Handling - The MME manages the setting up,
modification and tearing down of EPS Bearers. It is assumed that a
UE in E-UTRAN will always have one default EPS Bearer established
at the time of attachment to the network.
2.2.4.4 Mobility Anchor – IP Point of Presence - The MME acts as a mobility

anchor point which hides UE mobility from the fixed network. When
a UE attaches to the network it is assigned an IP address from an P-
GW. While the control of a UE may be transferred to another MME as
a consequence of a HO, the UE’s IP Point of Presence (PoP) will
remain at the P-GW. Thus, the mobility of UEs is transparent to the
fixed network.
2.2.4.5 Mobility Management for Idle Mode UEs - The MME manages
mobility of idle mode UEs. Idle mode UEs are tracked with the
granularity of Tracking Areas.
2.2.5 P/S Gateway: The EPS architecture defines the Serving and PDN GW
(P/S Gateway) node. The EPS architecture does not specify if the
nodes should be co-located or separated. The P/S-GW functionality
is very similar to the existing GGSN node. The main additions are

adding support packet buffering during E-UTRAN paging and
additional support Non-3GPP inter-working (e.g. CDMA2000, WLAN).
The P-GW provides an interface to the outside world (e.g. the
Internet). The P/S-GW can mainly be seen as a user plane node
however they also perform some QoS related signaling (it
terminates the interface for policy control). Below follow high level
descriptions of the functions performed by the P/S-GW.
The P/S-GW is involved in the following control plane functions:
2.2.5.1 EPS Bearer Handling - The P/S-GW triggers the setup of EPS Bearers
upon request from the policy control functions.
2.2.5.2 Mobility Anchor – IP Point of Presence - The P-GW acts as a mobility

anchor point which hides UE mobility from the fixed network. When
a UE attaches to the network it is assigned an IP address from an P-
GW which then also assumes the role of mobility anchor to the UE.
While the control of a UE may be transferred to another MME or S-
GW as a consequence of a HO, the UE’s IP Point of Presence (PoP)
will remain at the P-GW. Thus, the mobility of UEs is transparent to
the fixed network. Further, the P/S-GW handles the following user
plane functions:
2.2.5.2.1QoS Policy Control and Enforcement - To simplify bearer requests

from an application point of view, increase operator’s control over
its network resources and limit the potential for abuse by users, EPS
QoS is network controlled. The policy control and enforcement
functions associate users’ traffic flows with appropriate QoS classes
and executes rate policing to prohibit users or flows from exceeding
the QoS limits specified in users’ subscription agreements. Downlink
(DL) traffic is policed in the P/S-GW whereas Uplink (UL) traffic is
policed in the eNB.
2.2.5.2.2Charging - The charging function is responsible for charging the user

for its traffic according to the rate that applies for a particular
service, subscription etc.
2.2.5.2.3Lawful Intercept - Lawful interception facility shall be provided as

defined in 3GPP TS 33.106, 33.107, 33.108 and TEC GR No.
GR/WS/LIS-03 for LIS. This function shall enable to intercept
communication electronically by law enforcement agencies (LEAs)
as per Licensing and regulatory requirements.
2.2.5.2.4Policy Control and Charging Rules Function (PCRF) - Policy control

and Charging Rules functionality encompasses two main functions:

2.2.5.2.4.1 Flow Based Charging, including charging control and online credit
control
2.2.5.2.4.2 Policy control (e.g. gating control, QoS control, QoS signalling,
etc.).
2.2.6 HSS: The Home Subscriber Server (HSS) manages user’s subscription
information and the logical procedures related to a variety of packet
accesses and business domains. HSS provides the user management
logic related to LTE, WLAN and broadband accesses in the context of
IMS, SAE/EPC or other packet oriented business solutions in a network.
2.2.7 Frequency bands for LTE: LTE can be used in both paired (FDD) and
unpaired (TDD) spectrum. Among the various bands specified in 3GPP
TS 36.104, the bands of operation of LTE shall be as defined by DoT,
however at least 3GPP FDD bands 1, 3, 5, 7, 8,28 and 3GPP TDD bands
38,40 and 41 shall be supported with 5, 10, 15 and 20 MHz bandwidths
for FDD (wherever applicable) and 5, 10, 15 and 20 MHz for TDD
(wherever applicable) shall be supported. Channel bandwidth for
additional options of 5 & 15 MHz for TDD may be reviewed and shall be
as per tender requirement. However, the actual operation shall be
regulated by the spectrum allocated. This document covers both FDD
and TDD requirements on the RAN.
3 LTE – Radio Access Network (RAN): The E-UTRAN requirements are

based on 3GPP Release 11.0.0 specifications.
3.1 RAN Architecture - 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.

MME / S-GW MME / S-GW
S1
S1
S1
S1
X2 E-UTRAN
eNB eNB
X2
X2
eNB
eNB is the RAN node in the network architecture, is responsible for

radio transmission to and reception from UEs in one or more cells. eNB
shall support the functions as per 3GPP including the following:
3.1.1 Cell control and MME support: eNB owns and controls the radio
resources of its own cells. Cell resources as requested by and
granted to MMEs shall be in an ordered fashion.
3.1.2 Mobility control
3.1.3 The eNB shall be able to control the mobility for terminals in active state.
3.1.4 Control and User Plane security
3.1.5 eNB shall support the ciphering of user plane data over the radio interface
and integrity protection of RRC signaling.
3.1.6 Shared Channel handling: eNB shall be able to handle the shared and
random access channels used for signaling and initial access.
3.1.7 Segmentation/Concatenation: RLC layer shall support segmentation
and concatenation to adapt the payload to the transport block size.
3.1.8 eNB shall support HARQ functionality.
3.1.9 Scheduling
3.1.10 Multiplexing and Mapping: The eNB shall be support mapping of logical
channels onto transport channels.
3.1.11 Physical layer functionality: eNB shall support scrambling, Tx diversity,
beam-forming processing, and OFDM modulation. The eNB shall also
support link adaptation and power control.
3.1.12 Measurements and reporting
3.1.13 eNB shall support RRM (Radio Resource Management) functionality.
eNodeB Architecture Requirements
3.1.14 The eNodeB architecture shall be based on a distributed architecture,
comprised of a E-UTRAN baseband unit (BBU) and Remote radio head
(RRH).
3.1.15 The eNodeB shall support Common Public Radio Interface (CPRI)
(version 4 or higher) or OBSAI (Open Base Station Architecture
Initiative) version (4.2 or higher) for interfacing the BBU with the RRH
Module.
3.1.16 The eNodeB shall support indoor and outdoor configurations of RRH.
3.1.17 The eNodeB shall support from one to six sectors per site
3.1.18 The eNodeB Macro cell shall be capable of being software configured to
operate as a microcell
3.1.19 The eNodeB shall support optical or Electrical Gigabit Ethernet physical
connection for backhaul and O&M. Specific physical connection
requirement (Optical or Electrical) and numbers shall be indicated in
tender requirement.
3.1.20 The eNodeB shall provide a mechanism for troubleshooting and
monitoring subscriber sessions and interfaces.
3.1.21 The eNodeB shall support remote fault detection, self-testing, remote
fault mitigation, and remote fault recovery.
3.1.22 The network element shall support remote Software/firmware updates
via the OSS.
3.1.23 The system specification for an eNodeB shall be as mentioned in table below (as
per 3GPP TS 36.104):
1. Channel bandwidth (as per Clause FDD:5/10/15/20 MHz
1.3.10) TDD:5/10/15/20 MHz
2. Transmission bandwidth configuration FDD:25/50/75/100

NRB in E-UTRA channel bandwidths (In TDD: 25/50/75/100
accordance of Clause 1.3.10)
Transmitter
3. Base station output power (mean 20 to 30W per

power level per carrier measured at Antenna Port
the antenna connector).
To be measured at antenna port on
top of eNodeB (however actual
requirements may be reviewed in
tender requirement for lower power
requirements). The maximum power
radiation shall be regulated by latest
DoT guidelines/ instructions/ licensing
conditions. It shall be possible to
reduce output power through software
commands with suitable step size.

4. RE Power control dynamic range As per 3GPP TS
36.104 #6.3.1
5. Frequency error ± 0.05 ppm
6. Error Vector Magnitude As per 3GPP TS

36.104 #6.5.2
7. Time alignment between transmitter 65 ns (for each
branches carrier frequency)
TAE (Time alignment
Error) requirements
for Carrier
aggregation
scenarios as per
3GPP TS 36.104,
#6.5.3
130 ns for intra-
band contiguous CA
260 ns for intra-
band non-
contiguous CA
260 ns for inter-
band CA
8. DL RS power within 2.1 dB of the
DL RS power
indicated on the DL-
SCH
9. Adjacent Channel Leakage power As per 3GPP TS
Ratio (ACLR) 36.104 #6.6.2.1
10. Transmitter spurious emissions (9 kHz As per 3GPP TS
to 12.75 GHz) 36.104 #6.6.4
11. Transmitter inter-modulation As per 3GPP TS
36.104 #6.7.1
Receiver:
1. Reference sensitivity level As per 3GPP

(subject to band of
operation)
2. Dynamic range (capability of the As per 36.104
receiver to receive a wanted signal in $7.3.1
the presence of an interfering signal
inside the received channel
bandwidth)
3. Adjacent Channel Selectivity (ACS) As per 36.104
and narrow-band blocking $7.5.1
4. Receiver spurious emissions As per 36.104
$7.7.1
5. Receiver inter-modulation As per 36.104
$7.8.1

3.2 Base Band Unit (BBU) Requirements:
3.2.2 BBU shall be able to work in frequency bands as per clause 3.1.23 by
software change only.
3.2.3 BBU should be able to use spectrum flexibly and work with bandwidth
options of mentioned in Clause 3.1.23.
3.2.4 Baseband unit should be Hardware ready to support higher order
sector configurations for various LTE channel bandwidth: 6x1
configuration, 6x2 configuration
3.2.5 Baseband unit should be hardware ready to support 8x8 MIMO in
Downlink and 4X4 MIMO in Uplink for TDD
3.2.6 Baseband unit should be hardware ready to support 4x4 MIMO in
Downlink and 4x4 MIMO in Uplink for FDD
3.2.7 Baseband Unit shall support FDD and TDD simultaneously on the same
common hardware platform running a common software
3.2.8 Modules if any, in BBU should be field replaceable.
3.2.9 Baseband Capacity upgrades should be scalable.
3.2.10 Baseband unit shall have electrical or optical gigabit Ethernet for
backhaul
3.2.11 All hardware shall fully comply with the relevant 3GPP TS 36.104 LTE
specification
3.2.12 All hardware shall fully comply with the relevant 3GPP TS 36.104 LTE
specification
3.3 eNodeB Functional Requirements - The eNodeB shall comply to

Release 11.0.0 of the following set of 3GPP specifications:
Basic Requirements -
3.3.1 The eNodeB shall support 3GPP Release 11 Physical Layer 1
specifications
3.3.2 The eNodeB shall support 3GPP Release 11 Radio Layer 2 and 3
specifications
3.3.3 eNodeB owns and controls the radio resources of its own cells. Cell
resources as requested by and granted to MMEs shall be in an
ordered fashion.
3.3.4 Mobility control: The eNodeB shall be able to control the mobility for
terminals in active state.
3.3.5 The eNodeB shall support the ciphering of user plane data over the
radio interface and integrity protection of RRC signaling.
3.3.6 The eNodeB shall be able to handle the shared and random access
channels used for signaling and initial access.
3.3.7 Segmentation/Concatenation: RLC layer shall support segmentation
and concatenation to adapt the payload to the transport block size.
3.3.8 The eNodeB shall support HARQ functionality
3.3.9 The eNodeB shall support Contention based Random Access (RA)
procedure
3.3.10 The eNodeB shall support DL Power Allocation for data channels.
3.3.11 The eNodeB shall support Downlink power allocation parameters,
such PDSCH-to-RS ratios, as defined in 3GPP TS 36.213
3.3.12 The eNodeB shall support DL Power Control for data channels.
3.3.13 The eNodeB shall support DL Power setting for signalling and control
channels.
3.3.14 The eNodeB shall support Normal and Extended cyclic prefix.
3.3.15 The eNodeB shall support Cell reselection procedures
3.3.16 The eNodeB shall support System Information Broadcast (SIB), SIB1-
SIB8, SIB10-SIB16
3.3.17 The eNodeB shall support Uplink demodulation reference signal
3.3.18 The eNodeB shall support CSI-RS (Channel State Information-
Reference Signal)
3.3.19 The eNodeB shall support Event-triggered measurement reporting
3.3.20 The eNodeB shall support Signalling Radio Bearer (SRB), including
SRB0, SRB1, and SRB2.
3.3.21 Radio Bearer (RB) combinations dynamic mapping to Physical
Resource Block (PRB).
3.3.22 The eNodeB shall support RRC signaling procedures specified in
3GPP TS 36.331.
3.3.23 The eNodeB shall support RLC behaviour as specified in 3GPP TS
36.322.
3.3.24 The eNodeB shall support PDCP behaviour as specified in 3GPP TS
36.323.
3.3.25 The eNodeB shall support UL & DL Link Adaptation.

3.3.26 Uplink-Downlink frame configuration for TDD defined in 3GPP TS
36.211 as configuration-1 (Ul-2: DL-2) & Configuration-2 (UL-1: DL-3)
shall be supported
3.3.27 The eNodeB shall support QPSK, 16QAM,64QAM and 256 QAM
modulation on the Downlink
3.3.28 The eNodeB shall support QPSK, 16QAM and 64 QAM modulation on
the Uplink
3.3.29 The eNodeB shall support PDSCH resource allocation types 0 and 2
3.3.30 The eNodeB shall support Short Buffer Status Report (BSR) and Long
BSR
3.3.31 The eNodeB shall support Random Access Preamble burst format 0
and 4
3.3.32 The eNodeB shall support Cell-specific reference signal
3.3.33 The eNodeB shall be support mapping of logical channels onto
transport channels.
3.3.34 The eNodeB shall support scrambling, Tx diversity, and OFDM
modulation.
3.3.35 Support for Discontinuous Reception (DRX) to enable reasonable UE
battery consumption
3.3.36 The eNodeB shall be capable of connecting to multiple MMEs within
the same MME pool.
3.3.37 The eNodeB shall support multiple S-GWs.
3.3.38 The system shall support at least Sixteen (16) external alarms as
inputs for external devices.
The baseband processing shall be implemented in software and
shall be programmable and upgradeable to support Release 12/13
features or enhancements in Release 11 specifications by software
upgrade.
MIMO Capabilities:
3..3.39 The Radio Unit shall possess at least four antennas and
correspondingly four transmit as well as receive signal processing
chains
3.3.40 The eNodeB shall support 2x2 SU-MIMO with spatial multiplexing in
the downlink.
3.3.41 The eNodeB shall support 4x2 SU-MIMO in downlink. This means the
eNodeB shall transmit four different cell specific reference signal (4
CRS Transmission).
3.3.42 The eNodeB shall support 4x4 SU-MIMO with spatial multiplexing in
the downlink
3.3.43 The eNodeB shall support Single User (SU) MIMO in uplink
3.3.44 The eNodeB shall support Multi User (MU) MIMO in uplink
3.3.45 The eNodeB shall support transmission modes TM1 to TM4, TM7,
TM8 and TM9 as defined by 3GPP
3.3.46 The eNodeB shall also support Inter-mode switching between
various Transmission modes (Spatial Multiplexing to Transmit
Diversity, Beamforming to MIMO) based on UE’s channel conditions
LTE QoS Requirements:
3.3.47 The eNodeB shall support all nine Quality of Service Class Identifiers
(QCIs) as per TS 23.203, Section 6.1.7
3.3.48 The eNodeB shall support the maximum permissible data radio
bearers (DRBs) (eight)
3.3.49 The eNodeB shall support dynamic addition and deletion of
dedicated bearers

3.3.50 The eNodeB shall support both UE initiated as well as Network
Initiated dedicated bearer creation
3.3.51 The eNodeB shall support both UE initiated as well as Network
Initiated dedicated bearer Modification
3.3.52 The eNodeB shall support Proportional fair eNB scheduler, round
robin and Max C/I weighted proportional scheduling as operator
configurable
3.3.53 The eNodeB shall support delay based scheduler in which scheduler
takes into account the age of the packet and makes sure that VoIP
packets are scheduled within the PDB (Packet Delay Budget). This
results in an efficient scheduling of both voice and data services
3.3.54 The system shall support the option to specify a minimum rate for
best effort traffic in order to help mitigate the fairness problem and
also help in giving a consistent cell edge throughput when using
proportional fair schedulers
3.3.55 The eNodeB scheduler shall support prioritization of traffic in
downlink as per the QCI priority value
3.3.56 The eNodeB Scheduler shall take into account ARP (Allocation and
Retention Priority) parameters of priority level, the pre-emption
capability and the pre-emption vulnerability during bearer
establishment/modification
3.3.57 The eNodeB shall support Extended QCI which enables the operator
to define and configure new Quality of Service Class Identifier (QCIs)
in addition to the existing standardized QCIs (0-9). This will further
enable the operator to more flexibly differentiate between bearers
or service flows from a Quality of Service (QoS) perspective
3.3.58 The inactivity timer for RRC and NAS (that makes the connection to
be released) should be configurable by the operator for each QCI
(standard and extended)
3.3.59 The eNodeB shall support device awareness feature. It should allow
to create terminal blacklist for faulty cases of devices for a certain
feature. The feature will not be activated to the devices included in
the blacklist. However, the feature will be activated for all the rest
of devices.
3.3.60 The eNodeB shall support mapping of QCIs to DSCP bits and
marking the Egress IP Packets for different QCIs as per the
configured mapping. This is important for end-to-end QoS in uplink.
3.3.61 The eNodeB shall support the pre-scheduling of resources to UEs
(access grants) even if not required, which can be activated if
certain load thresholds are reached.
3.3.62 The eNodeB shall have capability to give absolute priority in the
uplink scheduler to Scheduling Requests (SRs) received from UEs on
the Physical Uplink Control Channel (PUCCH)
3.3.63 The eNodeB shall have capability to prioritize paging messages in
overload situations based on a priority provided by the MME.
3.3.64 The eNodeB shall have the capability to support the S1-AP
procedures (Overload Start and Overload Stop) that can be used to
aid an MME in handling overload situations.
Mobility Requirements:
3.3.65 Mobility control: The eNodeB shall be able to control the mobility for
terminals in active state
3.3.66 The eNodeB shall support Cell reselection procedures. Cell Re-
selection based on:
• Broadcast priority indication
• Broadcast cell-specific reselection parameters
• Broadcast cell-specific blacklists
• Access class baring parameters
3.3.67 The eNodeB shall support Inter PLMN reselection
3.3.68 The eNodeB shall support “connection re-establishment” procedure
3.3.69 The system shall support multi-target RRC connection re-
establishment where reconnection is enabled in multiple eNodeB.
The RRC connection re-establishment should be supported in all
cells with neighbor relation to the cell where the UE detected radio
link failure
3.3.70 The system shall support following types of Inter eNB handover:
• Intra frequency
• Inter frequency: same band
• Inter frequency: different band
• Over X2
• Over S1
• Intra MME and SGW
• Inter MME
• Inter MME and SGW
• Inter SGW
3.3.71 Intra-RAT, intra frequency HO via S1 based on UL & DL radio criteria
3.3.72 Intra-RAT, intra frequency HO via X2 based on DL radio criteria and
with data forwarding
3.3.73 The system shall support data forwarding at Intra-LTE handover,
both over X2 and S1 interfaces. The solution should reduce the risk
for TCP fall back into slow start at handover as no data packets are
lost
3.3.74 The system shall support S-GW relocation at X2 handover
3.3.75 The system shall support subscriber triggered mobility where
specific action per subscriber category is possible
3.3.76 For intra-frequency handover procedures, the system shall support
handover to “best cell” based on RSRP, RSRQ and thresholds
3.3.77 The eNodeB shall support Load control mechanisms that provides
overload protection for cells with a highly loaded air interface, by
throttling incoming handovers and initial accesses in the cell
3.3.78 The eNodeB shall be able to prioritize the paging messages in
overload situations based on a priority provided by the MME.
3.3.79 The eNodeB shall support interworking between FDD and TDD,
including session continuity, handover, load balancing
3.3.80 The system shall support TCP optimization by delay-based active
queue management (AQM) functionality. The feature shall improve
user perceived performance regarding throughput and delay by
dropping TCP/IP packets in a "TCP friendly" manner
3.3.81 The eNodeB should support blind handover for IRAT using pre-
configured neighbors
3.3.82 The eNodeB shall support PS Handover to WCDMA:
• Based on Coverage
• Based on LTE Load
3.3.83 The eNodeB shall support UTRAN/ GERAN session continuity based
on release with redirect
3.3.84 The eNodeB shall support configuration of different Inter-RAT
handover parameters per QCI
3.3.85 Inter-RAT Mobility/session continuity in RRC Idle state (LTE to
GSM/WCDMA when in Idle state)
3.3.86 The eNodeB shall support inter-frequency Load Balancing to
manage uneven distribution of traffic load between different carrier
frequencies
3.3.87 The eNodeB shall support coverage triggered WCDMA IRAT
Handover. Event B2 measurement may be used to find suitable
target cell
3.3.88 The eNodeB shall support IRAT handover for UE with multiple EPS
bearers by using handover parameters per QCI
3.3.89 The eNodeB shall support Inter-Radio Access Technology (RAT)
Offload to WCDMA
3.3.90 The eNodeB shall support throughput based mobility to WiFi.
eNodeB should control mobility between Wi-Fi and LTE based on
end-user throughput. The user is steered to the network, Wi-Fi, or
LTE that currently offers the best throughput. The throughput
evaluation should be performed in real-time for the individual user.
“Voice Support in LTE” Requirements:
3.3.91 The eNodeB shall support Voice over IP services

3.3.92 The eNodeB shall support creation of dedicated bearers with the
following QCIs for carrying different type of traffic associated with
the VoLTE Service: QCI-5 for IMS Signaling, QCI-1 for Voice Traffic,
QCI-2 for Video Traffic
3.3.93 The eNodeB shall support creation of a separate PDN/APN for IMS-
VoLTE services with the following types of bearers: Default bearer
with QCI-5, Dedicated GBR bearer with QCI-1 for Voice, Dedicated
GBR bearer with QCI-2 for Video
3.3.94 The eNodeB shall support prioritization of traffic on VoLTE bearers
(QCI 5, 1 and 2) in the Downlink
3.3.95 The eNodeB shall support RLC UM (Unacknowledged Mode) for
services that tolerate a higher packet loss rate but require lower
latency, e.g. VoLTE
3.3.96 The eNodeB shall support Robust Header Compression (RoHC)
3.3.97 The eNodeB shall support Delay-Based Scheduling to ensure that
the delay bounds associated with real-time services (e.g., voice or
video) are satisfied. This scheduling feature marks each packet with
low priority upon arrival, increasing its priority as it approaches its
delay bound. In most scenarios, this allows multiple packets to be
bundled together and delivered together to or from the UE, thereby
making more efficient use of radio resources
3.3.98 The eNodeB shall support TTI Bundling
3.3.99 The eNodeB shall support frequency hopping in Uplink in order to
improve coverage for VoLTE calls
3.3.100 The eNodeB shall have capability to do Access Class Barring(ACB)
skip for VoLTE and Video calls
3.3.101 The eNodeB shall support the possibility to be able to define
different inactivity timer settings on a QCI basis. This shall reduce
VoLTE call drop rates during alerting phase due to idle mode
transition to WCDMA or GSM
3.3.102 The eNodeB shall support CS Fallback to UTRAN and GERAN as
primary CS service for traditional voice traffic if IP Multimedia
Subsystem (IMS) Voice over IP (VoIP) services are not available
3.3.103 The eNodeB shall provide CS Fallback with System Information to
GERAN and UTRAN. The interruption time at release with redirect is
shortened as the UE does not have to read system information
before accessing the cell
3.3.104 The eNodeB shall support Single Radio Voice Call Continuity (SRVCC)
handover to UTRAN/ GERAN. Voice calls (VoLTE) that have been
established over LTE shall be able to continue if the user moves
away from LTE coverage to areas with only WCDMA/GSM coverage
while still on a call

3.3.105 The eNodeB shall be capable of emergency calls prioritization by
using dedicated resources in admission control during initial access,
E-RAB establishment and incoming handover
3.3.106 The eNodeB shall be able to handle Emergency Calls during CS
fallback. The eNodeB should offer, the operator the possibility to
apply separate priorities for CS fallback for emergency calls as
compared to CS fallback for ordinary voice calls. This allows the
operator to direct emergency calls to the network that has the best
positioning performance and thus comply to the FCC phase 2
requirements on positioning accuracy for such calls
3.3.107 The eNodeB shall allow UEs to establish an EPS session without a
SIM or without service for the purpose of placing IMS-based
emergency calls
Carrier Aggregation Requirements:
3.3.108 The eNodeB shall support LTE-FDD Carrier Aggregation (CA) with
upto 3 Cell Carriers
3.3.109 The eNodeB shall support Inter-Band CA between various
standardized FDD bands
3.3.110 The eNodeB shall support Intra-Band contiguous and non-
contiguous CA
3.3.111 The eNodeB shall support CA between FDD and TDD
3.3.112 The eNodeB shall support Carrier Aggregation band combinations
which are specific to India and already standardized in 3GPP Release
13
3.3.113 The eNodeB shall support Uplink Carrier Aggregation (Upto 2CC)
3.3.114 The eNodeB shall support Dynamic selection of Secondary
frequency when having multiple cell carriers for CA
3.3.115 The eNodeB shall take into account CA users during Load Balancing
to avoid losing CA capabilities and to avoid congestion because of
CA activation
3.3.116 It should be possible to aggregate carriers where different
Transmission Modes (TM) are used in the aggregated cells
3.3.117 The eNodeB shall support up to UE category 12 as defined in 3GPP
3.3.118 The Baseband Unit should be hardware ready to support upto 5
CellCarrier (CC) CA, upto 100 MHz bandwidth and >1 Gbps of peak
throughputs
3.3.119 The system shall support Downlink Carrier Aggregation between
separate eNBs
Interference Mitigation Requirements:

3.3.120 The eNodeB shall support Interference Rejection Combining in its
PHY layer receiver for improved performance in interference limited
scenarios
3.3.121 The eNodeB shall support frequency selective scheduling (FSS) in
Downlink
3.3.122 The eNodeB shall support Interference aware and channel aware
frequency selective scheduling on PUSCH using Sounding Reference
Signals (SRS)
3.3.123 The eNodeB shall support coordinated scheduling in uplink between
all cells of the same logical eNode B (cells within common baseband
pool) whereby interference between neighbour cells located within
the common baseband pool is minimized via scheduling of
resources in a dynamic and coordinated way.
3.3.124 The eNodeB shall support coordinated scheduling in downlink
between all cells of the same logical eNode B (cells within common
baseband pool) whereby interference between neighbor cells
located within the common baseband pool is minimized via
scheduling of resources in a dynamic and coordinated way.
eMBMS Requirements:
3.3.125 The MCE shall be supported logically within the eNodeB and should
support all associated interfaces: M2, M3 and M1
3.3.126 The eNodeB shall support Multicast Channel (MCH) and associated
Physical Multicast Channel (PMCH)
3.3.127 The eNodeB shall support extended cyclic prefix
3.3.128 The eNodeB shall support Multimedia Broadcast/Multicast Service
over Multimedia Broadcast Single Frequency Network (MBSFN)
3.3.129 The eNodeB shall support SIB13. MBSFN control channel information
and MBSFN Area specification are specified by SIB13
3.3.130 The eNodeB shall support up to 3 MBSFN Areas in the same location
3.3.131 The eNodeB shall support SIB16 which contains information related
to GPS time and Coordinated Universal Time (UTC). The UE may use
the time information for numerous purposes, e.g. to synchronize the
UE clock (to determine MBMS session start/ stop)
3.3.132 eMBMS should be supported in case of multiple carriers also, which
means operator can choose to broadcast service on one of the
carriers or both carriers simultaneously. The eNodeB shall support
SIB15 which is broadcasted by RAN and it enables all cells to
provide MBMS SAIs for the current frequency and also for
neighboring frequencies where MBMS is provided

3.3.133 The eNodeB shall be able to support unicast traffic and eMBMS
services simultaneously. Unicast traffic should not be affected by
eMBMS traffic and vice versa.
3.3.134 The seamless mobility for eMBMS shall be supported in both
RRC_IDLE state as well as RRC_CONNECTED state
Location Services Requirements:
3.3.135 The system shall support Cell ID Based Location Support where the
cell ID for a specific UE is transferred to MME upon request
3.3.136 The eNodeB shall support location determination based on
Enhanced Cell ID (ECID). The UE position shall be estimated using
the geographical coordinates of its serving eNB and additional UE
and radio resource measurements (e.g. Reference Signal Received
power and quality for serving cell, strongest neighboring cells) to
improve the location estimate
3.3.137 The eNodeB shall support the A-GPS positioning system through the
3GPP LPP Protocol
3.3.138 The eNodeB shall support the OTDOA as specified in 3GPP
3.3.139 The eNodeB shall support Positioning Reference Signal (PRS) to
improve the accuracy and performance of the OTDOA methods for
location determination by UE
Other Release 8/9/10/11 Features Requirements:
3.3.140 The eNodeB shall support ETWS and CMAS features as specified in
Release 8 and Release 9
3.3.141 The eNodeB shall support pooling of processing resources across co-
located BBU’s within centralized RAN configuration allowing
expansion of capacity of cells
3.3.142 The eNodeB shall support Centralized RAN solution over at least 48
LTE cells enabling coordination features between any group of cells
located within the configuration
3.3.143 The eNodeB shall support Enhanced PDCCH (ePDCCH), a Rel-11
capability that enable support of UE specific control signaling.
ePDCCH can therefore be used to increase amount of downlink
PDCCH capacity since the ePDCCH resource can be scheduled to the
UEs in addition to traditional PDCCH resources.
3.3.144 The eNodeB shall support clustered Uplink SC-FDMA where end user
uplink throughput (for supporting UEs) improves by allowing uplink
transmissions from one and the same UE to be clustered. This
allows the uplink allocations for the UE in question do not have to

be contiguous, as is generally the case because of the standard SC-
FDMA nature of the uplink
3.3.145 The eNodeB shall support dynamic PUCCH in which allocation and
de-allocation of PUCCH resources is dynamic depending on signaling
load
3.3.146 The eNodeB shall support functionality to increase performance by
dynamically reducing interference caused by reference signals in
neighboring cells during low and medium load
3.3.147 Small cell deployment on the same carrier as the Macro (i.e. co-
channel) shall be supported
3.3.148 The eNodeB shall support idle/connected mode load balancing
between macro cell and small cells
3.3.149 The eNodeB shall Support UL intra-site COMP (common baseband)
3.3.150 The eNodeB shall Support DL intra-site COMP (common baseband)
OAM & SON Requirements:
3.3.151 The eNodeB shall be “Plug-and-Play” and should support “Zero

Touch” commissioning
3.3.152 The eNodeB SON shall support Automatic PCI planning
3.3.153 The eNodeB shall support PCI collision detection and resolution
3.3.154 The eNodeB SON shall support Automatic Root Sequence Index (RSI)
allocation for PRACH planning
3.3.155 The eNodeB shall support Automatic Neighbour Relations (ANR)
based on UE Measurement Report
3.3.156 The eNodeB shall support automated configuration of best neighbor
relations for Intra-RAT load management
3.3.157 It shall be possible to black list and exclude neighbors that have a
low handover success rate, from the neighbor list
3.3.158 The eNodeB shall support Mobility Robustness Optimization (MRO)
related to Too-early, Too-late or Handovers to Wrong Cell
3.3.159 The eNodeB shall support Mobility Load Balancing (MLB)
3.3.160 The system shall support soft lock of cells making it possible to take
cells out of traffic with minimal impact on ongoing traffic
3.3.161 The eNodeB shall support Coverage and Capacity optimization
features thus ensuring optimum tradeoff between coverage,
capacity and quality as well as handling load imbalance
3.3.162 The eNodeB shall support Remote Electrical Tilt (RET) optimization
for AISGv2.0 compatible Antenna Line Devices. RET Configuration
enables the eNodeB ability to send configuration data to installed
RET units through their Iuant interface
3.3.163 The eNodeB shall support Self-Healing procedures

3.3.164 The eNodeB shall have capability to supervise all cells. It should
able to detect sleeping cells and supports self-healing by
automatically trying to recover the suspected sleeping cells
3.3.165 The eNodeB shall support Energy Saving feature
3.3.166 The eNodeB shall support micro sleep in the Downlink enabling
discontinuous transmission to save energy during low traffic. The TX
in the eNodeB shall be able to mute transmission during empty
OFDM symbols
3.3.167 The eNodeB shall be able to automatically reconfigure the antenna
system from MIMO to SIMO mode and back based on traffic load in
the eNodeB order to lower the power consumption
3.3.168 The eNodeB shall have capability to dynamically and automatically
turn on and off the capacity cells based on current traffic load. This
will reduce power consumption and reduce inter-cell interference
3.3.169 The system shall support advanced monitoring of the antenna
system in order to be able to indicate problems related to the
antenna system, e.g. mismatched antenna pair Rx diagrams,
swapped or disconnected feeders and loss in RF path
3.3.170 The system shall support means to monitor the CPRI link quality
3.3.171 The eNodeB shall support Minimization of Drive Test feature as per
3GPP Release 11
MORAN Requirements:
3.3.172 The system shall support eNodeB sharing between 2 operators

using a dedicated LTE carrier per operator with its own PLMN-Id
3.3.173 It shall be possible to provide MORAN using a single BBU element
shared between the operators
3.3.174 All AAS/RRH products of the vendors shall be capable to be used in
2-Way sharing scenario allowing to configure at least 2 LTE carriers,
1 per operator, within the IBW of the AAS/RRH products. Carriers of
the 2 operators can have different bandwidth
3.3.175 The eNB shall support independent QoS parameter settings for each
operator
3.3.176 The eNodeB should be able to do resource partitioning of capacity
to obtain minimum level of resource on a per operator basis
3.4 eNodeB Interface Requirements:
3.4.1 X2 Interface - The interface allowing interconnecting eNBs with each

other is referred to as the X2 interface. The X2 interface shall
support the exchange of signalling information between two eNBs,
in addition the interface shall support the forwarding of PDUs to the
respective tunnel endpoints. From a logical standpoint, the X2 is a
point-to-point interface between two eNBs within the E-UTRAN. A
point to- point logical interface shall be feasible even in the absence
of a physical direct connection between the two eNBs.
3.4.2 Functions of the X2 interface - The list of functions on the X2
interface shall include the following:
3.4.2.1 Intra LTE-Access-System Mobility Support for UE in LTE_ACTIVE:
3.4.2.2 Context transfer from source eNB to target eNB;
3.4.2.3 Control of user plane tunnels between source eNB and target eNB;
3.4.2.4 Handover cancellation.
3.4.2.5 Load Management
3.4.2.6 Inter-cell Interference Coordination
3.4.2.7 Uplink Interference Load Management;
3.4.2.8 General X2 management and error handling functions:
3.4.2.9 Error indication.
3.4.2.10 X2 Interface Requirements
a. The X2 interface shall support 3GPP Release 11 specifications.
b. The X2 interface shall support Ethernet
c. The interface shall support either IPv4 or IPv6.
3.4.3 S1 Interface - The S1 interface is specified at the boundary between
the EPC and the E-UTRAN. Figure-2 depicts the logical division of the
S1 interface. From the S1 perspective, the E-UTRAN access point is
an eNB, and the EPC access point is either the control plane MME
logical node or the user plane S-GW logical node. Two types of S1
interfaces are thus defined at the boundary depending on the EPC
access point: S1-MME towards an MME and S1-U towards an S- GW.
The E-UTRAN may thus have several S1access points towards the
EPC. As a minimum, each S1 access point (in E-UTRAN or EPC) shall
independently fulfil the requirements of the relevant S1
specifications (36.41x series).
S1 is a logical interface.
There may be multiple S1-MME logical interfaces towards the EPC
from any one eNB. The selection of the S1-MME interface is then
determined by the NAS Node Selection Function.
There may be multiple S1-U logical interfaces towards the EPC from
any one eNB. The selection of the S1-U interface is done within the
EPC and signalled to the eNB by the MME
3.4.4 Functions of S1 Interface
3.4.4.1 S1 UE context management function
3.4.4.2 E-RAB management functions
3.4.4.3 S1 link management function
3.4.4.4 GTP-U tunnels management function
3.4.4.5 S1 Signalling link management function
3.4.4.6 Mobility functions for UEs in LTE_Active
3.4.4.7 Intra-LTE handover
3.4.4.8 Inter-3GPP RAT handover
3.4.4.9 Mobility to CDMA2000 System
3.4.4.10 Paging function
3.4.4.11 Roaming and area restriction support functions
3.4.4.12 S1 interface management function
3.4.4.13 Coordination functions
3.4.4.14 Security function
3.4.4.15 Service and network access function
a. Core network signalling data transfer function
b. UE tracing
c. Location reporting function
d. RAN Information Management function
e. MME Selection with MME Load re-balancing & Overload Indication
Management.
3.4.4.16 S1 Interface Requirements – eNodeB to SGW Interface
a. The S1 interface shall support 3GPP Release 11 specifications.
b. The S1-U interface shall be Ethernet
c. The interface shall support either IPv4 or IPv6 or as per tender
requirements.
3.5 eNodeB other requirements:
3.5.1 O&M Interface: The eNodeB shall include an O&M interface

debugging and troubleshooting and for providing fault, configuration
and performance data to an O&M server. The OA&M interface shall
be Ethernet.
3.5.2 RRH shall be able to work up to a distance of 40 Km.
3.5.3 The system shall provide multiple level of recovery from software
and hardware faults such that the impact on system operation shall
be in accordance of the severity of the faults
3.5.4 The system hardware or software shall not pose any problem due to
change in date and time
3.5.5 eNodeB shall support nominal voltage -48v (-44.4 to -56 V) DC
supply voltage shall support nominal voltage be as per TEC GR for
SMPS (TEC/FLA/SMP-001)
3.5.6 Baseband unit in the eNB shall be able to support at least 1 Gbps
data throughput in the downlink.
3.5.7 Baseband unit in the eNB shall be able to support at least 500 Mbps
data throughput in the uplink

3.6 Remote Radio Head (RRH) Requirements:
3.6.1 RRH shall support flexible installation methods either in a shelter,

pole-mounted, outdoor at the base of the tower, or on the tower
masts/platforms in close proximity to the antennas.
3.6.2 The equipment shall be manufactured in accordance with the
international quality standards ISO-9001 for which the manufacturer
shall be duly accredited.
3.6.3 RRH should have at least 4Tx/4Rx path, each Tx with as specified
in clause 2.1.23
3.6.4 RRH should be on small volume and light weight. Dimensions should
be provided.
3.6.5 Bandwidth supported by RRH should be up to 20 MHz
3.6.6 RRH shall have optical CPRI version 4 (or higher version) or OBSAI
version 4.2 (or higher version).
3.6.7 Max power consumptions of RRH with 4x4MIMO shall not exceed
350W
3.6.8 RRH should support DC power supply of -48V (-44.4V to -56V)
3.6.9 All LTE capable Remote Radio Unit products shall be convection
cooled i.e. no fans.
3.7 Antenna:
3.7.1 Keeping in view different coverage areas, following antenna types

should be provided as per requirements: -
a. 18 dBi, 65 deg Beam width for DU, U & SU Areas.
b. 17 dBi, 90 deg Beam width for Rural Areas.
c. 21 dBi, 33 deg Beam width for Highways.
3.8 RAN Dimensioning:
3.8.1 eNB shall allow subscribers capacity to be pooled between all

sectors. Baseband subscriber capacity shall be pooled over all
sectors.
3.8.2 Baseband unit in the eNB shall be able to support at least 32
simultaneously scheduled subscribers. A scheduled subscriber has
data to be sent in the uplink or downlink and is queued in the
scheduler.
3.8.3 Baseband unit in the eNB shall be able to support at least
4000simultaneous RRC connected subscribers
3.8.4 Baseband unit in the eNB shall be able to support Omni and multi-
sector configurations

3.8.5 eNB shall provide VLAN separation for O&M and X2/S1 traffic. Two
separate VLANs on a common physical interface
3.8.6 The link budgets are shown below:
S.No. Parameter Value Unit Remark

1. Frequency Band As per MHz
Clause
1.3.10 or
tender
requireme
nt
2. Duplex Method TDD/FDD

3. Available BW (in 5, 10, 15, MHz
accordance of Clause 20
1.3.10)
4. Clutter Area
4 (i). Dense Urban Km2
4 (ii). Urban Km2
4 (iii). Sub Urban Km2
4 (iv). Rural Km2
5. Total Subs Year wise Data
6(i). Subs Distribution
6(ii). Dense Urban
6(iii). Urban
7(iv). Sub Urban
8(v). Rural
9. Traffic Profile 3 GB/mont
Data Consumed/Sub h;
Mbyte/B
H
10. Cell edge bit rate 128 kbps
requirements UL
11. DL Coverage bit rate At least 1 Mbps
(one)
12. DL/UL ratio As per UL: %
DL
configurati
on
13. Penetration Losses
13(i). Dense Urban 22 dB
13(ii). Urban 18 dB
13(iii). Sub Urban 16 dB
13(iv). Rural 10 dB
14. Standard Deviation
14(i). Dense Urban 10 dB
14(ii). Urban 8 dB
14(iii). Sub Urban 8 dB
14(iv). Rural 7 dB
15. Area Coverage Probability
15(i). Dense Urban 95 %
15(ii). Urban 95 %
15(iii). Sub Urban 95 %
15(iv). Rural 90 %
16. Antenna Gain(eNodeB) 18 dBi
All four clutters
CPE gain 6 dB
17. Antenna Height
18(i). Dense Urban 25 m
18(ii). Urban 25 m
18(iii). Sub Urban 30 m
18(iv). Rural 35 m
19. Antenna Configuration Like DL 2x2
MIMO
20. Propagation Model Okumura
Hata
21. Channel Model EPA5
22. Transmit Power
22(i). UE 23 dBm
22(ii). eNodeB Output dBm
Power as
per Clause
2.1.23
23. UE Power Class Class 3

24. UE Category 2….5
3.8.7 For coverage target RSRP shall be as -110dB. However, it may be

reviewed in tender requirement.
3.8.8 The eNodeB shall support both the open-loop power control and the
closed-loop power control of the UE
3.8.9 The eNodeB shall store one-to-one mapping between data radio
bearers and S1 bearers to create the binding between a data radio
bearer and an S1 bearer in both the uplink and downlink to enable
Quality of Service (QoS) enforcement
3.8.10 The eNodeB shall have a QoS aware scheduler in Medium Access
Control (MAC) Layer supporting all the 9 QoS Class Identifiers
(QCIs).
3.8.11 The eNodeB scheduler shall take into account QCI, Allocation and
Retention Priority (ARP) and Guaranteed Bit Rate (GBR) / Aggregate
Maximum Bit Rate (AMBR) while taking scheduling decisions.
3.8.12 Operation & Maintenance
3.8.12.1 eNB shall support integrated Trace tools to monitor all supported
interfaces for trouble shooting.
3.8.12.2 eNB shall support initiating Tracing function on UE basis when
requested by the MME.
3.8.12.3 eNB shall support initiating Tracing function on cell basis when
requested by the MME
3.8.12.4 eNB shall support performance management in XML format that can
be post processed
3.8.12.5 The eNodeB control software shall interact with various hardware /
software entities of the eNodeB and provide the health
status/Alarms of the entire system on the OSS.
3.8.12.6 The eNodeB control software shall be responsible for logging of call
processing events and sending the log file on the network to a
designated syslog server
3.8.12.7 The system shall maintain a system log and core dump logs
3.8.12.8 The eNodeB should support both local and remote configuration for
any software upgrade.
3.8.12.9 The eNodeB shall be capable of providing the system configuration
data to the Management Information Base (MIB) of the system
3.8.12.10 The eNodeB shall support the visual indicators for status and
fault.
3.8.12.11 The eNodeB shall have reboot and shut-down capability
3.8.12.12 eNodeB shall support built-in power-on diagnostics and system
monitoring capabilities to detect hardware failures

3.8.12.13 The eNodeB should support Local Maintenance Ports for any
debugging and troubleshooting.
3.8.12.14 The system shall display the count for the total number of UEs
connected to the eNodeB
3.8.12.15 The eNodeB shall support Graphical User Interface (GUI)
3.8.12.16 The eNodeB shall have the ability to detect and report any
hardware fault within the equipment
3.8.12.17 The eNodeB shall have the ability to detect and report Power
failure condition of Radio Unit
3.9 Link Layer:
3.9.1 The eNB shall support the operator configurable use of VLANs
compliant to IEEE802.1Q on any Ethernet interfaces.
3.9.2 The eNB shall be able to flexibly map traffic onto one or more
VLANs.
3.10 Transport IPv4 and IPv6:
3.10.1 The eNB hardware and software shall support IPv4 packet formats
on all Ethernet transport interfaces in compliance with IETF RFC791.
3.10.2 The eNB hardware shall support IPv6 packet formats on all Ethernet
transport interfaces in compliance with IETF RFC2460 + RFC5095.
3.10.3 Requirement of IPv4 or IPv6 shall be configurable at the time of
installation.
3.11 QoS in The Transport Layer:
3.11.1 The eNB shall comply with the IETF DiffServe architecture as defined
in IETF rfc2475 and shall support the DSCP interpretation of the TOS
field in the IPv4 header as defined in IETF rfc2474.
3.11.2 The eNB shall support the use of the Ethernet Priority Code Point
(PCP) field as defined in IEEE802.1Q-2005 section 9.
3.11.3 The transport QoS is managed at layer 3 with the DSCP field of IP
packets and at layer 2 with the “Pbit” bits in the Ethernet frames.
3.11.4 The DSCP for S1-U and X2-U are configurable by operator.
3.11.5 The vendor shall provide DSCP values that are supported in the
eNodeB
3.11.6 Layer 2 QoS marking shall be supported when the backbone
network supporting the eUTRAN is a layer 2 switched network
3.11.7 DSCP-Pbit mapping shall be configurable. Default DSCP-Pbit to be
provided.

3.11.8 The eNodeB shall support a minimum of 8 queues dedicated to each
physical egress interface. The vendor shall detail the number of
queues supported.
3.12 eNodeB Synchronization
3.12.1 The solution shall support end-to-end synchronization solutions to
maintain call quality and traffic throughput. The following
synchronization shall be supported.
3.12.2 eNodeB for TDD systems shall support a frequency accuracy of
50parts per billion or better and a phase accuracy of 3microseconds
or better
3.12.3 eNodeB shall support GPS synchronization options.
3.12.4 The GPS receiver should contain more than 1 output port.
3.12.5 eNodeB shall support at least 48 hr hold over mode in case of
frequency synchronization loss and at least 6 hr hold over mode in
case of Phase synchronization loss
3.12.6 The eNodeB shall support synchronization support for synchronous
Ethernet according to ITU-T G.8262/Y.1362
3.12.7 The eNodeB shall also support time and frequency synchronization
through IEEE 1588v2
3.12.8 The base station shall support IEEE 1588v2 Grand Master
functionality, Cost and time to service can be reduced if Grand
Master can be distributed close to cell sites
3.13 Security IPsec in Transport:
3.13.1 System support IPsec and IKEv2 for the backhaul transport in the
eNodeB, according to the 3GPP specification
3.13.2 IPSEC is implemented in order to protect S1 and X2.
3.13.3 The eNB shall support the use of indirect X2 connections (no direct
connectivity between eNB, all X2 traffic shares the 'core traffic'
IPSEC tunnel to the security gateway and the X2 separated out by
the core network and turned around to the security gateway
terminating the IPsec tunnel containing the 'core traffic' to the peer
eNB).
3.14 Ancillaries:
3.14.1 AISG Antenna Line Devices must be configurable on site via a direct
eNode-B connection. All aspects of 3GPP/AISGv2.0 functionalities
must be accessible and configurable.
3.14.2 AISG Antenna Line Devices must be fully configurable remotely via
the O&M platform.

3.14.3 All aspects of 3GPP/AISGv2.0 functionalities must be accessible and
configurable
4 Mobility Management Entity:
4.1 Software Features

4.1.1 MME should support EPS Mobility Management for LTE Access.
4.1.2 The EMM and ECM states should be independent of each other and
should comply to 3GPP standard 23.401
4.1.3 The following mobility management procedures for LTE access shall
be supported:
4.1.3.1 Service Request
a. Attach
b. Detach
4.1.3.2 UE-initiated Detach
4.1.3.3 HSS-Initiated Detach
4.1.3.4 MME-initiated Detach
4.1.3.5 S1 Release
4.1.3.6 HSS Notification (as part of location update message from MME to
HSS)
4.1.3.7 Paging
4.1.3.8 Tracking Area Update (TAU)
a. Periodic TAU
b. Intra-MME TAU
c. Inter-MME TAU
4.1.3.9 Handover
a. X2-based handover
b. S1-Based Handover
4.1.3.10 MME should support EPS session management including the
following as a minimum:
a. PDN connectivity (default bearer activation)
b. PDN disconnection (default bearer deactivation)
c. Dedicated bearer activation
d. Dedicated bearer deactivation
e. Bearer modification
4.1.3.11 MME should support intersystem session continuity of session
between LTE to WCDMA /GSM and Vice versa on S3/S4 interface
along with handover support between LTE and CDMA (eHRPD
networks)
4.1.3.12 LTE UE authentication should be supported. Authentication and
Security procedures should be based on encryption algorithms
EEA0/EEA1 and integrity algorithm EIA1.

4.1.3.13 MME should support Bearer, Context and APN handling. This will
include, as a minimum:
a. Restrict the number of simultaneous EPS bearer a subscriber may
have open based on 3GPP 29.274
b. Use of selection mode to determine APN selection depending on the
received subscription information based on 3GPP TS 29.272
c. Resolution of the APN name via DNS. A round robin mechanism shall
be supported to select the P-GW address out of the delivered
address list sent by the DNS.
d. In case a bearer request towards the PDN Gateway is not answered,
retransmission shall be performed. After a configurable number of
retransmissions, a new create context request shall be sent to the
next available PDN Gateway according to the used algorithm (round
robin or priority). The MME shall reject a bearer response message
by the PDN Gateway, in case another PDN Gateway has already
answered the bearer request procedure.
e. In the attach procedure, a default EPS bearer should be established
by the MME. In addition to this, the MME should support multiple
bearers.
f. MME node should support IPv6 on control/transport plane.
g. MME should support user plane Dual-Stack IPv4/v6, allowing for
Dual-Stack LTE-GSM/WCDMA session continuity.
h. MME functionality shall be collocated with SGSN in the same node.
The collocated SGSN-MME should support 2G/3G/LTE access.
i. The MME node should support MME Pool for LTE access which
provides flexible and resource-efficient architecture with built-in
network redundancy as per 3GPP TS 23.401 and TS 36.413.
j. The collocated SGSN-MME node with dual access (2G-3G, 2G-LTE,
3G-LTE) and triple access (2G-3G-LTE) functionality should be
supported in Pool.
k. The MME node should support at least 16 MME nodes in a pool.
l. The MME node should have Multi PLMN support. The MME node
should be able to support at least 5 PLMN.
m. The MME node should support Lawful Intercept as per 3GPP TS
33.107. The signaling information passing through the MME will be
captured as IRI information. In LTE no payload will pass through
SGSN-MME, payload transfer takes place between PDN-GW and e-
NodeB or PDN-GW and node-B.
n. The MME node should be able to support access restriction between
LTE, WCDMA or GSM network. MME should be able to do restriction
based on IMSI number series.
o. MME node should support UE Tracer functionality as per 3GPP TS
32.421, TS 32.422 and 32.423.
4.1.3.14 It shall be possible to trace MME node interfaces based on IMSI
series. Following interface should be supported
a. S1-MME (SCTP)
b. S6a (SCTP)
c. S10 (GTP-C)
d. SGs
e. Sv
f. S11
g. S13
h. SLg
i. S3
j. Gn/Gp
4.1.3.15 MME should support PDN and Serving Gateway selection based
upon below mentioned session management and mobility
management procedures (3GPP standards TS 23.401 and 29.303)
4.1.3.16 The MME shall support control plane positioning using SLg and SLs
interfaces as defined in 3GPP R9.
4.1.3.17 The Gateway selection should be based / supported on three areas:
a. PDN Gateway Selection - based on Access Point Name (APN)
b. Serving Gateway Selection - based on Tracking Area (TA)
c. Combined PDN and Serving Gateway Selection - based on APN and
TA
4.1.3.18 The MME shall support circuit switched fall back on GSM/WCDMA to
provide voice service to LTE subscribers without the need for IMS.
4.1.3.19 The UE Tracer functionality shall be supported for subscriber trace
when troubleshooting in operator networks, as well as for network
analyses and optimizations. MME & eNodeB shall be able to
generate periodic log files.
4.1.3.20 The MME shall be able to forward access and other network or UE
information about the subscriber to the GGSN, SGW and PGW and in
turn to the service layer in order to allow differentiation of services
and charging schemes.
4.1.3.21 The MME shall be able to sent the UE time zone information over
S11 interface to the GGSN, SGW and PGW.
4.1.3.22 The MME shall support IPv6 transport plane for interfaces like S3,
S4, S16, S6d, LI, and OAM/Gom
4.1.3.23 Session and traffic continuity shall be provided in MME pool move
operation so that an active LTE user experiences a very short
suspension of service.
4.1.3.24 The MME shall be able to override subscribed QoS in HLR, to allow
policy controller to take full and dynamic control of QoS adapted to
each individual user and service.

4.1.3.25 The MME shall support HSS initiated APN re-direct functionality on
the basis of subscribed Default APN and Subscribed APN received on
HSS
4.1.3.26 The MME shall be able to setup S12 interface based direct tunnel
between the RNC & S-GW.
4.1.3.27 The MME shall support restoration procedure for lost connection
over Gn to avoid problems with Machine-to-Machine (M2M) devices
that do not automatically reattach or re-activate sessions
4.1.3.28 The MME shall be able to SMS over LTE over SGs without need for
IMS.
4.1.3.29 The MME shall be support Automatic Neighbor Relationship.
4.1.3.30 In MME pool, for achieving better Session resilience it should be
possible to do the continuous user data replication mechanisms
between MMEs in pool
a. Each MME in the pool can have two roles, one is the serving-MME,
and the other is the replication MME (R-MME).
4.2 Hardware Requirements:

4.2.1 MME HW proposed should provide all IP interfaces
4.2.2 The MME hardware board proposed should be able to handle
signaling traffic.
4.2.3 The SGSN-MME board proposed should be able to handle signaling
and payload traffic.
4.2.4 The MME solution shall support distributed deployments with load
sharing across multiple geographical sites.
4.2.5 Simultaneous use of IPv6 and IPv4 on control plane shall be
supported in the HW. No HW change out is required when migrating
to IPv6
4.2.6 MME should support one or more of the following input power:
a. -48V (-44V to -53 V)
4.2.7 MME should support fault-tolerance/ 1+1 redundancy on key
components like power supply, fan tray etc and by 1+1 or n+1
redundancy on on traffic and signalling cards.
4.3 QoS Support:

4.3.1 MME should comply to Release 8 3GPP Standard for supporting EPS
Bearers using QCI and for mobility between LTE and WCDMA/GSM
accesses using Gn SGSN with Pre-Rel-8 QoS parameters
4.3.2 The MME node should comply to 3GPP Rel-12 standards and later as
per 3GPP TS 23.401, 24.301, 29.272, 29.274, 36.413.
4.3.3 The MME should support granular QoS parameters and attributes
defined in 3GPP 23.107 Rel 11 and later such as Traffic Handling
Priority (THP) and Allocation and Retention Policy (ARP), UE AMBR,
APN-AMBR, Maximum Bit Rate (MBR), Guaranteed Bit Rate (GBR),
and Allocation and Retention Priority (ARP)
4.3.4 The MME should support all standardized QCI classes 1-9, also for
GBRs & non-GBRs.
4.3.5 MME should support session resilience for payload as well as
subscriber context prevention
4.3.6 MME should support overload protection in a way that active
subscribers are prioritized over non-active subscribers to enable
payload users (revenue contributors) to continue sending and
receiving payload packets with a minimum of service interruption
4.4 Operation & Maintenance:

4.4.1 The MME shall support integrated Trace tools to monitor all
supported interfaces for trouble shooting. MME should be capable of
initiating Tracing function by IMSI series
4.4.2 MME should log all the events related to session and mobility
management.
4.4.3 MME should support initiating Tracing function on UE/IMSI basis
when requested by the OSS
4.4.4 MME should support initiating Tracing function on Cell basis when
requested by the OSS
4.4.5 The MME, at a minimum, shall capture the following events in a log:
4.4.5.1 Attach
4.4.5.2 Activation of EPS bearer context, both primary and secondary
4.4.5.3 Deactivation of EPS bearer context
4.4.5.4 Attach for LTE Access
4.4.5.5 Detach for LTE Access
4.4.5.6 UE Handover
4.4.5.7 Tracking Area Update (TAU)
4.4.5.8 Service Request for LTE access
4.5 Dimensioning:
MME shall be scalable at least up to 5 Million EMM registered
subscribers and shall be able to support at least up to 15K eNodeBs.
However actual requirements shall be reviewed in tender
requirements.
4.5.1 LTE Users = % * Total HLR Subscribers using LTE Network
4.5.2 LTE Attached Users (SAU) = % * LTE users that will simultaneously
attached in BH.
4.5.3 LTE Active User (EPS Bearer) = % * LTE Attached Users in BH.
4.5.4 LTE Context per EPS Bearer= Number * LTE Active User in BH.
4.5.5 Throughput per EPS bearer = Number (bps)
4.5.6 Average Packet Size = Number (Bytes)
5 PDN and Serving -Gateway:
5.1 Software Requirements
5.1.1 The P-GW should be able to support at least 3000 APN
configuration.
5.1.2 S-GW shall support S11 interface towards MME for control plane
signaling, and managing the EPS bearers. S11 interface should
comply to 3GPP TS 23.401, 29.274.
5.1.3 Support hand over from a source eNodeB to a target eNodeB using
the X2 reference point (based on TS 23.401, 23.402, 29.274). The
functionality should also include support for end-user Intra LTE
mobility using both S1 and X2 as defined in TS 36.413. Intra LTE
mobility and EPS session management is provided by the MME and
the Serving GW.
5.1.4 P-GW should be able to handle EPS Bearer and Session
Management like creation, modification, and termination of
connections and handles the connections over the EPS Network
between a User Equipment (UE) and the Packet Data Network
(PDN), comply to 3G PP TS 23.401
5.1.5 The S-GW and P-GW should support Multiple PDN connectivity per
UE. The UE attaching to any of the Packet Gateway shall be able to
connect to multiple PDNs either on the same PDN-GW or on
separate PDN-GWs. Should comply to 3G PP TS 23.401
5.1.6 Gateway Split, Home Network (GTP) should be supported as per
3GPP TS 23.401, 29.274 so that operators can split their gateways
to achieve network efficiencies in terms of transport costs and
organization.
5.1.7 S-GW should support Idle Mode paging as per 3GPP TS 23.401,
29.274.
5.1.8 P-GW and S-GW should have Dual-stack Subscriber Support which
provides supports for UEs that can use an IPv6 bearer for telephony
and multimedia services, and one IPv4 bearer for general Internet
service access.
5.1.9 P-GW and S-GW should support Anti-Spoofing.
5.1.10 Charging should be supported as per 3GPP TS 23.401, 32.251,
32.298,32.297
5.1.11 The P-GW and S-GW shall support Diameter based Rf/Gz interface
for offline charging as per 3GPP TS 23.401, 32.251, 32.298.
5.1.12 The P-GW and S-GW shall support Diameter based Gy for online
charging.
5.1.13 The P-GW and S-GW CDR format shall be as per Abstract Syntax
Notation One (ASN.1).

5.1.14 S-GW and P-GW CDR Transfer to Billing System will be done using
Gz interface using GTP, Based on 3GPP TS 32.295.
5.1.15 S-GW and P-GW should support storage of CDR with a minimum
storage capacity of at least 300 GB
5.1.16 P- Gw should support standard Gx interface (based on standard
Diameter based Protocol) towards the PCRF and should be capable
of acting as a PCEF. Gx interface proposed should support Policy and
charging control architecture (Release 9) 3GPP TS 23.203 and Policy
and Charging Control over Gx reference point (Release 8) 3GPP TS
29.212.
5.1.17 Proposed P-GW and S-GW should act as a PCEF and be able to fetch
Dynamic policies from PCRF over Gx interface.
5.1.18 P-GW should be able to initiate Create Bearer Request or delete
bearer request towards the S-GW and MME after receiving the
request from PCRF or PGW-initiated or MME-initiated respectively
5.1.19 The P-GW and S-GW shall support Lawful Interception as per 3GPP
TS 33.107 on control (signaling) and data plane (payload).
5.1.20 The P-GW and S-GW shall support Inter-working for trusted and non-
trusted non-3GPP access using GTP based interfaces.
5.1.21 The P-GW and S-GW shall Event Based Monitoring where all events
will be streamed out of the node and available for external
processing.
5.1.22 The P-GW and S-GW shall allow PCRF to trigger a QoS modification
in the GGSN based on Packet Inspection on service level.
5.1.23 The P-GW (in case of GTP) and S-GW (in case of PMIP) shall be able
to report the usage per service to a PCRF to support for instance fair
usage policies differentiated over different services. This shall be
implemented according to 3GPP R9.
5.1.24 The P-GW and S-GW shall support Guaranteed Bit Rate (GBR)
bearers and evolved Allocation Retention Policy (ARP).
5.1.25 The P-GW and S-GW shall allow the UE to simultaneously connect to
multiple PDNs either through the same PDN-GW or through separate
PDN-GWs.
5.1.26 The P-GW and S-GW shall support session continuity between LTE
and WCDMA/GSM access networks, i.e. the end user traffic can be
moved between the different access technologies while maintaining
the user session
5.1.27 The P-GW and S-GW shall support O&M output to XML-file that could
be fetched from an external performance monitoring system. This
will ensure that the counter values are persistent and kept also in
the event of a failure of the node.

5.2.1 The MME and GW solution should support distributed deployments
with load sharing across multiple geographical sites.
5.2.2 P/S-GW HW should support IPv4 and the HW will be prepared for
IPv6. No HW change out is required when migrating to IPv6.
5.2.2.1 Network Interface Requirement for P and S gateway
a. The P/S-GW should support 10G Base-R/W.
b. The P/S-GW should support 10/100/1000Base-T interfaces and
1000Base-LX/SX interfaces.
c. The P/S-GW shall enable the use of VLANs compliant to IEEE802.1Q
on all Ethernet interfaces.
d. The P/S-GW shall support IEEE 802.3ah OAM mechanism in Ethernet
interfaces.
5.2.3 P/S-GW should be at least NEBS level 3 compliant.
5.2.4 Vendor should provide environmental requirement for P/S-GW such
as:
5.2.4.1 Overall mounting dimensions
5.2.4.2 Power requirements
5.2.4.3 Reliability
5.2.5 The P/S-GW should provide various level of resiliency mechanisms
mentioned below:
5.2.5.1 Failure: Any internal or external event causing a hardware or
software component to cease working normally.
5.2.5.2 Redundancy: The ability to keep functioning normally in the event of
a component failure, by having standby components ready to take
over the operation of the failed component.
5.2.5.3 Resilience: The ability to keep functioning normally with a minimal
or no loss of service in the event of a component failure. In the CPG,
this is achieved by replicating the data to the shared memory.
5.2.5.4 Standby: A component ready to take over operation in case of
failure in an active component.
5.2.5.5 Subscriber data: Session and mobility information for user
equipment
5.2.5.6 Packet Gateway shall be able to support overload protection and
shall be able to provide session limit based on per user or per APN
level
5.3 QoS/ Latency:
5.3.1 The S-GW and P-GW should support Quality of Service based
standard Release 8 and 3G PP TS 23.401 Rel 11
5.3.2 QoS enforcement should be based on the QCI filters/PCC rules
(including APN-AMBR) supplied by the PCRF dynamically over Gx
interface or pre-configured static QoS rules. As a minimum with
static QoS, following should be supported: -
5.3.3 QoS Enforcement based on QCI filters/PCC rules
5.3.4 QoS Policing and Metering using ACLs
5.4.1 The P/S-GW should provide a flexible, cost-effective and secure

management system
5.4.2 P/S-GW should have logging support, configuration management,
fault management, performance management and security
management capabilities
5.4.3 P/S-GW should offer a Performance Management solution that
collects and reports the data relevant to the application.
5.5 Dimensioning:
5.5.1 LTE Active User (PDP) = % * LTE Attached Users in BH.

5.5.2 LTE Context per PDP = Number * LTE Active User in BH.
5.5.3 Throughput per PDP = Number (bps)
5.5.4 Average Packet Size = Number (Bytes)
6 Policy And Charging Function (PCRF):

6.1.1 The PCRF shall support the Gx interface towards the Policy and
Charging Enforcement Function (PCEF) compliant to Rel 12 of 3GPP
23.203, 29.212 and 29.213 and back ward compatible to old release
6.1.2 PCRF on the basis of usage reports received from PCEF should apply
the following policies, at a minimum:
6.1.2.1 Existing IP session level. PCRF stores usage counters at session
level and reset them every time the user disconnects.
6.1.2.2 Configured period of time (a month or a configured number of days
or hours).
6.1.2.3 Based on a billing cycle. PCRF stores usage counters during a billing
cycle and reset them on the specified billing date.
6.1.3 PCRF shall be capable of Dynamic Policy control including change of
values & attributes in respect of functionalities such as Binding,
Gating Control, Event Reporting, QoS control and IP-CAN Bearer
establishment.
6.1.4 PCRF should be able to initiate Network-initiated dedicated bearers
on the basis of the Application used (Rx interface)

6.1.5 PCRF should support Time of day Policy Activation by sending
Revalidation -Time. PCRF shall be able to provide a new value for
the revalidation timeout by including Revalidation-Time in CCA or
RAR
6.1.6 PCRF should notify the user by sending SMS or email at occurrence
of certain events like monthly quota or charge expiry
6.1.7 PCRF should be able to converge usage-accumulators across
multiple-accesses i.e for fixed access via Radius accounting and for
Wireless access over Gx & Gy interface.
6.1.8 PCRF should support IMS based VoIP services running over both
GPRS access, HSPA access, & LTE access
6.1.9 PCRF should support Multi-vendor RADIUS CoA
6.1.10 PCRF shall support multiple SMS notifications in multiple languages
(with different texts) to multiple parties at usage thresholds. For
regional / local language support SMPP/ HTTP interface towards
external application server for translation and Unicode/ 7-bit
encoding schemes as per 3GPP may be provided.
6.1.11 PCRF should support 3GPP R9 Gx compliant usage reporting based
on Monitoring-keys AVP’s (Service Based)
6.1.12 PCRF should support overlapping IP-Addresses over Gx interface
allowing for policy control with PCEF nodes that provide support to
MVNO operators
6.1.13 PCRF should send a SMS/e-mail notification any time that data user-
session is terminated notifying user about the actual traffic usage
and remaining quota left until expiration date.
6.1.14 PCRF should be able to do Bandwidth Control based on time of the
day, special day, day of the week.
6.1.15 PCRF should be able to define policies based on subscriber dynamic
parameters like RAT Type and Roaming Status.
6.1.16 PCRF should be able to give right service to right subscriber eg.
Gold subscriber should be able to get higher QoS as compared to
Bronze
6.1.17 PCRF should be able to do service authorization based on
subscription. For eg. Gold subscriber should be given all services,
bronze denied few.
6.1.18 PCRF should have multiple auto provisioning profile. Subscribers
which are not provisioned in PCRF should be provisioned using this.
This profile can be selected based on RAT Type, PLMN or
combination.
6.1.19 Multiple subscribers should be able to share common quota in PCRF
along with their individual limit. For e.g., 5 members of family have
combined limit of 2Gb and individual of 500 Mb. After that there
should be an option to deny service or QoS should be degraded
6.1.20 Single Account: Subscriber having 2G, 3G, LTE and Wire line
subscription should be able to have a common account enabling
threshold and quota rules to be applied.
6.1.21 Offered PCRF should have Support of Emergency Calls for IMSI and
non IMSI-based subscribers via IMS service using an emergency APN
6.1.22 PCRF should support keep track of user location at all VoLTE session
stages. Hence, full support of 3GPP Network Location Information
should be available
6.1.23 PCRF should support Multimedia Priority services on Gx and Rx

interface
6.1.24 Reliability
6.1.24.1 The PCRF system shall have geo-redundancy and high availability at
least 99.999%
6.1.24.2 Always-on
6.1.24.3 Automatic software recovery
6.1.24.4 Data replication
6.1.24.5 Overload control and overload protection
6.1.24.6 Software updates and upgrades during operation
6.1.24.7 Upgrade and update of Operating System during operation
6.1.24.8 Online backup
6.1.24.9 Hot-swap hardware replacement
6.1.24.10 HW should support IPv4 and the HW should be prepared for IPv6.
No HW change out is required when migrating to IPV6.
6.1.25 PCRF shall support S9 interface.
PCRF should be available as VNF to be deployed in Virtual
Environment.
6.2 QoS/Latency:
6.2.1 PCRF should support QoS Control for Default and Dedicated Bearer.
QOS Control should be possible on below mentioned levels:
6.2.1.1 QoS control at service data flow level
6.2.1.2 QoS control at IP CAN bearer level
6.2.1.3 QoS Conflict Handling
6.3 Dimensioning:
6.3.1 Total LTE Subscribers = % * Total HLR Subscribers using LTE Network
6.3.2 User end notifications to be considered
6.3.3 Usage Limit per Subscribers need to be mentioned for applying
policies based upon aggregated usage per user per time duration
(say month or day or week)
6.3.4 Average PDP Duration considered to be as 60 minutes
6.3.5 For applying Dynamic policy control Rx should be considered
7 Home Subscriber Server (HSS):

7.1.1 The HSS network subscription server should handle subscription
management, user authentication, mobility management, session
establishment and access authorization functions.
7.1.2 The HSS should provide support for seamless mobility between LTE
<->2G/3G and 3GPP<-> non-3GPP accesses.
7.1.3 The HSS server, if required, shall be configured adopting the new
layered architecture separating logic and data, where the HSS
server acts as a front-End logic entity managing signaling,
application and control functionalities and inter-works with back-end
database entity handling the storage of subscription profile
information.
7.1.4 The HSS should provide implementation of the IMS functionality of
the HSS network entity described in 3GPP specifications, HSS
interfaces with 3GPP AAA over SWx which in turn supports
interoperation with 3GPP2 database entities. 3GPP AAA relies on
HSS database for authentication
7.1.5 The HSS should provide support for LTE attach, detach,
authentication, location update, purge and reset procedures via S6a
interface as described in 3GPP 23.401
7.1.6 The HSS should also provide support for non-3GPP access
authentication, location management and user data handling via
SWx as described in 3GPP 23.402
7.1.7 The HSS shall provide support for non-3GPP access authorization
based on EAP-AKA. The HSS also provides support for EAP-SIM for
WLAN access.
7.1.8 The HSS should interoperate with external 3GPP AAA via SWx
interface.
7.1.9 The HSS should provide IMS subscription data access supporting the
functions related to 3GPP Sh reference point allowing data
consumers to access IMS non-transparent data information e.g. IMS
user status, IMS user location, IMS user’s assigned Initial filtering
(application trigger) criteria and other subscription related profile
information.
7.1.10 The HSS application should store and make available to multimedia
call servers all standardized subscription related data needed to
setup multimedia sessions. It should be part of the IP Multimedia

Subsystem (IMS) that builds on a packet-switched or any IP network
and introduces a new layer in the network: the session layer.
7.1.11 Mobility Management: should support user mobility through IMS
Core Network subsystem Call and/or session establishment support:
supports of the call and/or session establishment procedures in IMS
subsystem. For terminating traffic, it should provide information on
which call and/or session control entity currently hosts the user
security information.
7.1.12 The HSS should provide IMS subscription data access supporting the
functions related to 3GPP Sh reference point allowing data
consumers to access IMS non-transparent data information e.g. IMS
user status, IMS user location, IMS user’s assigned Initial filtering
(application trigger) criteria and other subscription related profile
information.
7.1.13 The HSS shall permit application servers to retrieve user profile
information upon need.
7.1.14 Authentication:
7.1.14.1 The HSS should provide support for LTE access authentication based
on USIM AKA authentication, using domain specific vector
generation procedures.
7.1.14.2 HSS should support Generic Authentication Architecture
(GAA)/General Boot Strapping Architecture (GBA).
7.1.14.3 HSS should have its own authentication vector generator as well as
allow external authentication vector generator to feed
authentication vectors to HSS
7.2 Subscriber Locator Finder
7.2.1 The requirement of multiple HSS in the network can be supported

by Subscriber Locater Function (SLF). The SLF allows the scalability
of HSS nodes in the operator network, providing a routing service to
discover which HSS node has the subscription information of a
determined user identity.
7.2.2 SLF should work in redirect as well as proxy mode when offering
data based management function
7.2.3 When HSS is deployed as part of layered architecture, SLF should
function as load balancer among various HSS.
7.2.4 SLF can also be used for adapting query between non standardised
diameter client and HSS which supports only standardised diameter
client
7.3 Subscriber Provisioning

7.3.1 HSS uses LDAPv3or SOAP for provisioning. Also LDAP is used for
search query between Front end and back end database as well in
case of layered architecture
7.3.2 Service Provisioning Support: The IMS HSS should provide access to
the service profile data for use within the IMS Network.
7.3.3 Subscriber Profile/Policy Data Repository (SPR): The IMS HSS should
support the storage of IMS user related data, and provides access to
these data. IMS Application Severs should individually be able to
provision such subscriber data (also known as transparent data) and
store it with IMS HSS, as part of the user’s IMS subscription profile.
7.4 Reliability & Redundancy:
7.4.1 The HSS server should support full redundant HW and SW

configurations, telecom grade availability 99.999% reliability.
7.4.2 The HSS server should provide an internal backup function used to
store software and database data on persistent storage.
7.4.3 HSS solution should provide flexible redundancy schemes with
local/geographical redundancy models, in real time mated-pair or
N+K redundancy (distributed configuration), with automatic
switchover in case of disaster.
7.4.4 HSS solution should also integrates overload control mechanism to
ensure and protect system availability and capacity to resume to
normal handing in a very efficient manner
7.4.5 HSS platform must support for the setup of a paired geographical
redundant component providing embedded update link mechanism
to keep synchronized the relevant data in the pair of nodes. The
main node performs online updates of dynamic data changes to the
redundant standby node, capable of taking over the functions of the
primary node in case of failure
7.5.1 The HSS server shall provide a flexible, cost-effective and secure
management system
7.5.2 HSS should have logging support, configuration management, fault
management, performance management and security management
capabilities
7.5.3 HSS server shall offer a Performance Management solution that
collects and reports the data relevant to the application. The
supported file formatting should be Extensible Mark-up Language
(XML)

7.5.4 HSS server should maintain an application log, responsible for
logging any traffic related issue and in charge of logging the
application errors as well.
7.6 HSS Features:
7.6.1 Diameter support

7.6.2 MAP Interface in HSS
7.6.3 EPC subscription management
7.6.4 Operator determined barring for EPC subscribers
7.6.5 ODB all APN
7.6.6 ODB HPLMN APN
7.6.7 ODB VPLMN APN
7.6.8 EPC mobility management
7.6.9 EPC roaming restrictions
7.6.10 EPC flexible profile management
7.6.11 SIGTRAN Support in HSS
7.6.12 IMS Mobility Management
7.6.13 IMS User Profile Management
7.6.14 IMS Session Handling Support
7.6.15 IMS Identity Management
7.6.16 Barring Handling in IMS
7.6.17 IMS Implicit Registration
7.6.18 IMS-AKA (USIM) Authentication
7.6.19 IMS User Data Access by AS
7.6.20 Subscription and Notification Support
7.6.21 Sh Support
7.6.22 IPv6 User Plane Support
7.6.23 Distributed configuration with Active/Active DB node for read
operations
7.6.24 Support of both local redundancy & geo-redundant configurations
7.6.25 LDAP access to subscriber data
7.6.26 Synchronized back-up
7.6.27 Support alarm for lost Diameter connection
7.6.28 Provisioning performance counters
7.6.29 Traceability of all requests in failure
7.6.30 Support of partitioning layer to provide customized views over the
same data for client application
7.6.31 Machine to machine provisioning through SOAP
7.6.32 Notification service for the subscribers and 3rd party data
modification
7.6.33 Diameter Load Balancing.
7.6.34 3rd Party data storage based on LDAP server
7.6.35 LDAP v3 compliant
7.6.36 Secured LDAP interface
7.6.37 LDAP referral on SDM Data Model for 3rd party application
7.6.38 LDAP transaction support
7.6.39 LDAP server high availability
7.6.40 3rd party Data resiliency (Local and geographical)
7.6.41 Flexible 3rd Party data creation policy in distributed configuration
(possibility to dedicate NRG)
7.6.42 High scalability 3rd Party Data Storage
7.6.43 On disk/in memory data storage configuration
7.6.44 3rd party Data Schema creation
7.6.45 3rd party schema up-date on the fly
7.6.46 Data Schema modeling tool (SDK tool).
7.6.47 Virtual views management for Application Client via partitioning
layer
7.6.48 3rd party access control
7.6.49 S6a interface towards MME
7.6.50 SWx interface towards AAA
7.6.51 Roaming between 2G/3G accesses and 4G access
7.6.52 Management of IMSI Signalling without using MSISDN
7.6.53 Provisioning of 2G/3G/4G subscriber in one command
7.6.54 Combined HLR/HSS/LTE support
7.6.55 LDAPv3 or SOAP for provisioning
7.6.56 Integrated AUC (HLR/HSS/LTE)
7.6.57 Manual De-registration via provisioning interface
7.6.58 Diameter reset
7.6.59 MVNO support
8 System requirements:
8.1 Interoperability
8.1.1 The LTE/EPC system shall support fall back to GSM using the
following three methods as specified in 3GPP TS 23.272:
8.1.1.1 PS handover
a. RRC Connection Release with Redirect using RIM
b. Cell Change Order (CCO) with or without NACC
c. The LTE/EPC system shall support fall back to GSM with RRC
Connection Release & Redirect using RIM as 3GPP TS 23.272.
8.1.2 The LTE/EPC system shall support fall back to WCDMA using the
following two methods as specified in 3GPP TS 23.272:
8.1.2.1 PS handover
a. RRC Connection Release with Redirect

b. The LTE/EPC system shall support fall back to GSM with RRC
Connection Release & Redirect using RIM as 3GPP TS 23.272.
8.1.3 The EPC should support inter working with CDMA network to LTE
users: -
8.1.3.1 For Voice Services:
a. CS Fullback to CDMA network (1xRTT) should be supported as per
3GPP TS 23.272 using Dual Rx terminals.
b. The CS Fullback procedure should support following procedures:
i. UE leaving E-UTRAN
ii. UE returning to E-UTRAN
c. CS Fullback procedure should support send and receive of SMS in
CDMA network (1xRTT) using Dual Rx terminals.
8.1.3.2 For Data Services:
a. The EPC-CDMA (eHRPD) interworking should be based on 3GPP TS
23.402.
b. The solution should be based on Dual Rx terminals & Partial HSGW
context procedures defined in 3GPP and CDMA standards.
c. The PDN Gateway (EPC) should support S2a interface towards
HSGW (eHRPD/CDMA) to support mobility between the networks.
d. The interworking should be based on PMIPv6 interface.
LTE network will be an overlay network over CDMA for interworking.
The CDMA networks should be able to support the above LTE
interfaces.
9 Operations Administration Maintenance and Provisioning

(OAM&P)
An LTE OAM system shall be a layered management system

modelled after the Tele-Communications Management Network
(TMN), per ITU-T Recommendation [ITU-T M.3010]. In addition to a
well layered management system, the complete end-to-end OAM&P
system shall address the following areas of management functions:
9.1 Configuration Management
The following functions of a configuration management system shall

be supported
9.1.1 Planning and Provisioning
9.1.1.1 It shall be possible to perform Planning and Provisioning related
functions remotely.
9.1.1.2 Configuration changes shall be logged, and configuration data shall
be backed up for prompt restoration of network elements.

9.1.1.3 The configuration management system shall protect the system
from Improper configuration that would disrupt normal service, and
shall maintain data consistency across network elements.
9.1.1.4 The system shall support CLI (command Line Interface) command
scripts with basic programming features for the purpose of reuse
and ease of provisioning.
9.1.1.5 Configuration change shall, as much as possible, be completed
without element reboot.
9.1.1.6 Provisioning for currently unused or unequipped slots/units shall be
allowed for the purpose of engineering planning.
9.1.1.7 Plug-and-play start-up
9.1.1.8 Self-configuring capability shall be supported
9.1.2 Status and Inventory
The configuration management system shall automatically discover

system topology and all elements within, and supports search
functions of a group or a single element. Central management
system and individual element management system shall display
consistent status and inventory information. Configuration requests
shall be explicitly confirmed upon success, or flagged with clear
failure cause.
9.1.3 Network Element Software Upgrade
9.1.3.1 Software upgrade shall be conducted in a secure manner, including

secured download of new software, and verification of the integrity
of downloaded software. Upgrades shall also not cause service
interruption, either due to download procedure itself, or due to
incompatibility between upgraded network element and its peers.
9.1.3.2 All upgrades, both successful and unsuccessful, shall be logged.
9.2 Fault Management:

9.2.1 Fault Management
9.2.1.1 Fault Management system shall have the ability to detect and
mitigate or recover from faults, and to analyze outages, goes
beyond the treatment of individual elements or the simple reporting
of individual faults. Fault management in LTE must take a
coordinated and end-to-end approach that encompasses all
elements in the EPC and RAN.
9.2.1.2 Fault management shall enable the detection, isolation, and
correction of abnormal or potentially abnormal operation. It includes
Fault Detection and Isolation, Alarm Surveillance, Overload Control,
Problem Resolution and Correction. It also includes management
support for RAS (Reliability, Availability, and Survivability) as per
3GPP TS 32.101
9.2.2 Fault Detection and Isolation:
Each node in the network shall be able to detect and isolate faults
from its own autonomous perspective without needing to be told
about the fault from some centralized entity.
9.2.3 Alarm Surveillance:
Alarms shall be raised for adverse events in the network The

information included in the alarms shall be detailed enough to
identify which system component is experiencing the failure
condition. The detail shall include
9.2.3.1 Alarm type
9.2.3.2 The probable cause
9.2.3.3 The specific problem
9.2.3.4 The perceived severity
9.2.3.5 Network Element ID
9.2.3.6 Network Element Type
The alarms shall be automatically cleared when the failure condition
is resolved. It shall not record or forward duplicate alarms for
detection of the same failure condition.
9.3 Overload control (OC):
9.3.1 Overload detection shall be supported

9.3.2 The system shall identify the source of overload, and as much as
possible throttle the loading at the source.
9.3.3 Problem Resolution to restore the system to its normal, non-faulty
state.
9.3.4 Post outage analysis of key system metrics, such as amount of
failed call attempts
9.4 Performance Management:
The following three main functions shall be provided by Performance

Management
9.4.1 Monitor

9.4.1.1 Performance Management shall enable monitoring different types of
metrics such as detailed call trace from beginning, per call
measurements etc.
9.4.1.2 Different amounts of data generated at various frequencies shall be
aggregated, and stored without negatively impacting normal
operations.
9.4.1.3 Real time display of for enabling trouble shooting shall be provided.
9.4.2 Control:
9.4.2.1 Performance management shall allow threshold definitions on key

performance metrics, and shall trigger threshold crossing alerts
when the performance falls below specified level. The collection
frequency of such key metrics shall be sufficiently high to allow for
timely response, and the system must take extra care to ensure
such high frequency does not degrade system capacity or stability.
Control mechanism shall help in realizing SON.
9.4.3 Analysis
9.4.3.1 A performance management system shall provide reporting
measurements and calculating KPIs (Key Performance Indicators)
and KQIs (Key Quality Indicators).
9.4.3.2 The collected metrics shall provide information to tune the network
parameters so the network can run more efficiently, and to help
identify and diagnose problems in the network.
9.5 Security Management:
Security Management shall protect against unauthorized access to

network control functions, as well as maintaining confidentialities,
data integrity and traceability. Security management shall ensure
network reliability and integrity. The following activities shall be
supported.
9.5.1 Selective Resource Access
9.5.2 Network Element Function enablement and control
9.5.3 Access Logs
9.5.4 Security Alarms/Event Reporting
9.5.5 Data Privacy
9.5.6 User Rights Checking
9.5.7 Security Breaches and Attempts management
9.5.8 Security Audit Trail Log
9.6 Self Optimizing Network (SON) Requirements:

9.6.1 SON – self-configuration and self-optimization of LTE based networks
shall be as per 3GPP TS 36.902. SON shall support multi-vendor
RAN deployment by providing a common language in terms of
measurement and performance data, and a common protocol for
the exchange of such information between eNBs.
9.6.2 The SON shall have the provision to address the following areas of
RAN operations:
9.6.2.1 Auto Configuration of Physical Cell ID: A PCI (physical cell ID)
uniquely identifies a cell in terms of a cell’s primary and secondary
synchronization sequences, which are used by UEs during cell
search to obtain slot and frame synchronizations. A PCI must be
unique among a cell’s neighbors, and the neighbors’ neighbors. LTE
SON shall provide ways to automate PCI assignment of cells in an
eNB, simplifying provisioning of newly deployed radio cells.
9.6.2.2 Mobility Robustness and Load Balance Optimization: Handoff
parameters are traditionally difficult and costly to optimize. Handoff
problems sometimes cannot be detected by the source eNB, such
as when a call drops soon after it is handed off to target eNB. At
other times there may be structural obstacles causing UEs to not
report pilots that should otherwise be good target candidates,
resulting in call drop as the candidate target eNB is not prepared to
receive a hand off. LTE SON shall allow eNBs to effectively share
handoff statistics, allowing better coordination within the RAN to
automatically improve handoff performance. LTE SON shall also
define mechanisms for eNBs to share loading information, allowing
an eNB to handoff UEs at the cell edge to less loaded neighbouring
eNBs, thus increasing system capacity. LTE SON shall also provide
IRAT (inter-RAT) handoff and load balancing
9.6.2.3 Random Access Channel (RACH) Optimization: The configuration of
RACH resources determines how effectively UEs can access the
RAN. Improper configuration results in access collisions which
increases call setup delays, handoff delays, data resuming delays,
call drop rates, and handoff failure rates. Since RACH resources are
exclusively reserved and cannot be used for other purposes, proper
RACH configuration also has a positive impact on system capacity.
LTE SON shall be able to optimize RACH resource allocation, RACH
transmission power control, etc, to deal with changing RAN
configurations such as topology changes and antenna tilt changes.
9.6.2.4 Automatic Neighbor Relation (ANR): LTE SON shall define procedures
for each eNB to build and maintain (e.g. further optimize) Neighbor
Relation Tables (NRTs) based on inputs such as UE measurement
reports, and eNB initial advertisements. Other information such as
handoff statistics shall also be enabled to refine NRTs to establish
preference levels among neighbor eNBs. It should be possible to
turn on/off the ANR feature per eNodeB basis. It should be possible
to prevent a neighbour ever being added (blacklisted neighbour) by
manual intervention
9.6.3 For a new eNodeB being brought up in the field, it should be
possible for the eNodeB to self-configure itself by using software
and parameters stored in a remote software repository
10 IMS/Voice over LTE:
IMS/Voice requirements are addressing IMS based Voice over LTE,

Circuit Switched Fall Back (CSFB). The IMS/MMTEL voice solution
shall support and be compliant to IMS over voice profile as
described in ‘GSMA; Voice over IMS profile IR 92. Roaming and NNI
aspects for VoLTE are part IR.65 and IR.88 which is being reworked
currently.
10.1 Circuit Switched Fall Back (CSFB)
10.1.1 IMS/MMTEL
10.1.1.1 The LTE/EPC system must support both options for providing voice
service
a. A standardized QCI value of 5 should be used for IMS SIP signaling,
with default or dedicated bearer based on PCC mechanisms.
10.1.1.2 As a minimum, there should be support for the following two
alternatives:
a. The IMS application uses a specific APN; no other application shall
use this APN. This is described in clause 1 below.
b. A single APN is used for multiple applications, including IMS.
10.1.1.3 For an IMS session request for a Conversational Voice call
(originating and terminating), a dedicated bearer for IMS based
voice shall be created utilizing interaction with dynamic PCC
10.1.1.4 One Voice UEs and network deployments shall support emergency
services in the IMS domain (in 3GPP Release 9, TS 23.167)
10.1.1.5 A parallel Circuit Switched network will continue while the IMS
network is deployed and support of Emergency calls with CS
support is required. EPS network will support SGs interface for
support of CS Emergency calls.
10.1.1.6 EPS network shall support SGs interface between MME and MSC in
GSM/WCDMA CS network
10.1.1.7 EPS network shall CS fallback to CDMA2000 1xRTT by using Dual Rx
solution as defined in 3GPP R9 23.272

10.1.1.8 CSFB shall be supported as per 3GPP 23.272, Release 8 for voice
and SMS.
10.1.1.9 At a minimum, the following CSFB traffic cases should be supported:
a. Mobile Originating CSFB for voice (GSM/WCDMA)
b. Mobile Terminating CSFB for voice (GSM/WCDMA)
c. Mobile Originating SMS
d. Mobile Terminating SMS
10.1.1.10 The circuit switched (CS) network shall support the following
features/functionalities: Support of SGs interface in MSC
10.1.1.11 The following support required in UE
a. MM-Tel client
b. LTE Radio
c. CS Radio
d. 3GPP IMS SIP
e. Video and voice codecs: AMR, AMR-WB (optional), H.263, H.264
(optional)
f. RTP
g. CSFB
10.1.2 IMS core and application server should support SR-VCC functionality
as specified in 3GPP TS 23.216 and allow IMS session continuity
specified in 23.237.
10.1.3 The IMS core should be able to handover to the existing 2G/3G
system using the SRVCC functionality. The SCC AS (Service
Continuity and Centralization Application Server) as per 3GPP
specified logical entity shall be able to anchor the call and control
the call transfer between access domains.
10.2 Voice over LTE Networks:

Both options as defined in 3GPP standards for providing voice
services shall be provided as mentioned below:
10.2.1 Circuit Switched Fallback (CS Fallback)
10.2.2 Voice over IMS (VoLTE)
10.2.3 CS Fallback:
10.2.3.1 CS Fallback as defined by [3GPP TS 23.272] to support voice
services for LTE by using the 2G/3G (GSM/UMTS, 1xRTT) network
shall be provided.
10.2.4 VoLTE with IMS
10.2.4.1 MMTel service as specified by 3GPP shall be provided to support a
converged telephony offering to allow the operators to offer the
multimedia telephony service over many different access types.
10.2.4.2 The GSMA VoLTE (IR.92) UNI profile specification as given below
shall be supported:
a. Telephony Service;
b. MMTel Supplementary Services
i. OIP, OIR, TIP, TIR
ii. CDIV (CFU, CFNL, CFB, CFNRc, CFNR)
iii. Call Barring Incoming / Outgoing (ICB, OCB, ICB-R, OCB-IC)
iv. HOLD
v. MWI (message Waiting Indicator)
vi. Communication Waiting
vii. Conference
c. Supplementary service management using Ut with XCAP procedures
9.2.4.3 IMS feature
a. ISIM based authentication (USIM fallback).
b. IPSec protection of signaling.
c. Both Tel-URI and SIP URI
d. GBA (recommended) or http digest authentication for Ut
e. Early dialogues
f. IMS Emergency
10.2.4.4 IMS media
a. AMR NB and WB Codec & payload format
b. RTP profile / Data transport
c. RTCP usage
d. Jitter buffer management
10.2.4.5 Bearer management;
a. Well known “IMS APN” with local PDN GW
b. The IMS APN with signaling bearer (QCI=5) established at initial
attach
c. P-CSCF Discovery
10.2.4.6 LTE radio capabilities;
a. GBR EPS bearer (QCI1) for voice
b. Non-GBR EPS bearers for SIP and XCAP
c. RoHC in PDCP
10.3 Voice over WiFi (VoWiFi):
The IMS network must support VoWi-Fi

a. Telephony Service to be supported
b. MMTel Supplementary Services
i. OIP, OIR, TIP, TIR
ii. CDIV (CFU, CFNL, CFB, CFNRc, CFNR)
iii. Call Barring Incoming / Outgoing (ICB, OCB, ICB-R, OCB-IC)
iv. HOLD
v. Communication Waiting
vi. Conference
11 Charging:
11.1 The payment /charging platform functionalities
11.1.1 Online charging / rating must be supported for LTE services. System
should allow to define the Rating logic using an user friendly GUI for
LTE services offered to end user.
11.1.2 Online charging / rating should support the cross product bundling.
E.g. certain usage of data should award the bonus on voice.
11.1.3 System should have capabilities of give online discount on data
usage.
11.1.4 All existing prepaid charging software must support LTE services.
System should able to support the 3GPP Gy, Diameter for online
charging.
11.1.5 Prepaid charging system should support 255 rating buckets to
support different LTE bundles. Each individual rating bucket should
have a start date and end date. System should allow to define
atleast 5 sub-rating bucket under main bucket account.
11.1.6 System shall allow to give bonus on Volume, Time and Money on
rating bucket.
11.1.7 Proposed real-time charging system must allow operator to provide
different kinds of bonus on refills based upon following but not
limited.
11.1.7.1 Account Balance
11.1.7.2 Age on Network
11.1.7.3 Special Date
11.1.7.4 Special Time
11.1.7.5 Current Usage
11.1.7.6 Current subscriber’s services
11.2.1 All systems part of prepaid charging solution must be in the

redundancy mode (N+N or N+1).
12 Wifi and LTE Interworking:
12.1 Trusted non-3GPP Network

12.1.1 Proposed system should support TWAG functionality using S2a ( GTP
or PMIP) architecture to integrate with PGW as mentioned in 3GPP
TS 23.402 and 24.302 Rel 12
12.1.2 S2a should support GTP-based S2a-C interface based on 3GPP TS
29.274 and S2a-U based on 29.281 Rel 11
12.1.3 Shall support session creation using Open SSID.

12.1.4 Shall support session creation using Secure SSID using SIM based
authentication using EAP-SIM.
12.1.5 The TWAG shall support MOBIKE for trusted WiFi Roaming based on
IETF RFC 4555
12.1.6 TWAG should support the UE location information retrieval from the
locally configured TWAG, AP, or converted from the AP MAC address
12.1.7 The TWAG GW should support converged hardware providing
colocation with existing PGW/SGW.
12.2 Untrusted non-3GPP Network:
12.2.1 Proposed system should support ePDG functionality using S2b(GTP)

ePDG architecture to integrate with PGW as mentioned in 3GPP TS
23.402 and 24.302 Rel 12
12.2.2 S2a should support GTP-based S2b-C interface based on 3GPP TS
29.274 and S2b-U based on 29.281 Rel 11
12.2.3 ePDG functionality should provide all required information to the
PGW for PGW to identify that session is on non 3GPP access
12.2.4 The proposed node should support Diameter based SWm interface
towards 3GPP AAA based on 3GPP TS 29.273 Rel 12
12.2.5 The proposed node should support IKEv2 for the control plane and
the ESP protocol for the user plane on SWu interface towards UE’s
based on IETF RFC 4306, IETF RFC 5996 and IETF RFC 4303
12.2.6 The solution shall support for the mobility function for untrusted Wi-
Fi based on GTP s2b based on 3G PP TS 23.401
12.2.7 The solution shall support for the multiple PDN connection for
trusted and untrusted Wi-Fi access
12.2.8 IPv4 and IPv6 support on SWu interface
12.2.9 The proposed ePDG should support UE location information retrival
based upon IP address and the port in UDP packets
12.2.10 IKEv2 with EAP-AKA authentication and authorization
12.2.11 Encapsulation and routing between IPSec and GTPv2 tunnel should
be supported
12.2.12 The ePDG should support colocation with existing PGW/SGW.
13 Virtualization:
13.1 Shall support vEPC on generic COTS hardware.

13.2 Virtual EPC solution shall include VNFs for complete portfolio
including SGSN/MMME, EPG (GGSN/SGW/PGW), PCRF, DPI.
13.3 The Virtual EPC solution shall support Cloud Integration.
13.4 The virtual EPC shall maintain the feature parity with native EPC
solution.
13.5 The virtual EPC solution shall include application level fault
tolerance on compute, storage and network.
13.6 The vEPC solution shall provide and maintain Telecom Grade KPI.
13.7 The virtual EPC solution shall be agnostic to all 3GPP access types.
13.8 vEPC shall provide location based GGSN selection to reduce delay
and transmission cost.
14 General Requirements:
14.1 General - LTE provides users a facility for high speed data &
limited voice. The system shall have facilities for automatic
roaming, locating and updating mobile subscribers.
14.1.1 The operation of the equipment shall be in the available frequency
band allotted
14.1.2 The system shall provide the best efficiency of radio spectrum and
shall be able to reuse radio frequencies.
14.1.3 Details of frequency planning i.e. frequency reuse cell pattern and
adjacent channel operation etc. wherever applicable, shall be
indicated.
14.1.4 Expansion techniques of the system shall be economical and
modular without any existing hardware changes. Expansion is
required when
14.1.4.1 Increase in no. of subscribers in the area.
14.1.4.2 Expansion of geographical coverage
14.1.5 The equipment shall be fully solid state and adopt the state of the
art proven technology. The equipment shall have the following
features:
14.1.5.1 Low power consumption
14.1.5.2 Minimum number of power supplies voltages in the equipment.
14.2 Support of Multiple Equipment Vendors:

The system shall support the possibility of using equipment and
sub-systems of different vendors like EPC, HSS, PCRF etc. as per
defined industry standards, wherever relevant.
14.3 Hardware:
14.3.1 The technology used shall be in line with modern state of the art
practice
14.3.2 The system hardware shall be modular in design and shall permit
growth in steps. The arrangement shall be such that failure/
deterioration of service shall not occur when implementing the
growth.

14.3.3 The system shall use fully digital techniques for switching, including
the subscriber stage.
14.3.4 The variety of hardware modules and components used in the
system shall be a minimum.
14.3.5 Design precautions shall be taken to minimise the possibility of
equipment damage arising from the insertion of an electronic
package into the wrong connector or the removal of any package
from any connector.
14.3.6 All components shall be rated for continuous operation of the
system under the normal operating conditions. The circuits must
also be designed so as to prevent damage to the other equipment
under any condition of operation or any conditions of fault.
14.3.7 The system hardware shall not pose any problem, due to changes in
date and time caused by events such as changeover of leap year
etc., in the normal functioning of the system.
14.4 Processors:
14.4.1 The system shall have redundancy of processors for critical

elements in core network nodes.
14.4.2 Adequate backup memory shall be provided.
14.4.3 Provision shall be made to prevent the loss/alteration of memory
contents due to power failures, improper operating procedures and
the procedure for restoring the system to its normal state, etc.
14.4.4 Dimensioning standards shall be evolved for the various types of
memories used. This shall also include standards for provisioning of
the required spare memory capacity.
14.5 Input-Output devices:
14.5.1 The communication facilities provided for exchange of information

between the elements of LTE-RAN and the maintenance and
operating personnel shall include facilities for a system test, control
and alarm indication.
14.5.2 Input / output terminals shall be capable of transmitting/ receiving
characters of a subset of the ITU-T No.5 alphabet. The
printing/display device shall print/display different graphic symbols
for the digit zero and the capital letter O. The input/output terminal
shall have the English Keyboard. Capabilities of visual display
terminals shall be as per ITU-T Recommendation Z.325.
14.5.3 Adequate number of man-machine interfaces shall be available.
14.5.4 If provision is made for monitoring from a remote terminal, it shall
be ensured that the data links conform to the ITU-T
Recommendations Q.513. Care shall be taken that the reliability of
the data links does not, in any way, affect the reliability of the LTE-
RAN. Special provision shall also be made for transmission of a
failure signal even when the system is unable to transmit an output
message.
14.5.5 A suitable alarm and display system shall be provided for a
continuous indication of the system status. The alarm system shall
also provide an alarm to indicate the failure of power supply to the
alarm circuits. Provision shall be available to extend the alarm
indications to a centralized alarm panel.
14.6 Equipment Practice:
14.6.1 All circuits shall be mounted on plug-in PCBs of standard size to

facilitate replacement. All cards of the same type and design shall
be interchangeable without necessitating special adjustments.
14.6.2 All metal parts of frames, supports, etc. shall be mechanically

rugged and constructed of corrosion resistant material or treated
with anti-corrosive finish. All equipment shall have a tropical finish.
14.6.3 Suitable test access points and displays shall be provided for
facilitating maintenance. Test access points shall be located on the
front side of the bay. All visual display devices shall be located in a
position attracting immediate attention of the operation and
maintenance personnel.
14.6.4 All fuses, keys, etc., requiring frequent replacement or operation
shall be located at a convenient height from the ground. Ladders
shall be provided, if required.
14.6.5 The equipment shall have natural cooling arrangement which shall
not involve any forced cooling, such as by using fans etc., either
inside or outside the equipment. However, in case this is
unavoidable and the fans are to be used, these shall be DC
operated and shall not impact on the MTBF of the equipment.
14.6.6 It shall be indicated whether printed board connectors are of edge-
type or plug-and-socket type. They shall not be easily damaged
during replacements and removals. The contact particulars as well
as life test performance on contact resistance for each type of
connector shall be supplied.
14.6.7 All components and material used in the equipment shall be non-
inflammable or in absence of it, self-extinguishable. They shall be
fully tropicalized.
14.6.8 The method used for connection of permanent wiring outside the
printed cards shall be indicated.
14.6.9 All cabling to be done at a site shall be completely connectorised by
using a straight-wire plug-in cable.
14.6.10 All points, where major interconnections or strapping may be
required, shall be brought out to suitable interconnection and
strapping fields.
14.6.11 Various types of cables and wires used shall be indicated. Detailed
particulars of any special wires and cables like miniaturized optical,
co-axial, screened cable; etc. shall be furnished with their actual
usage in the system.
14.6.12 The buses, if any, shall be suitably protected against electrical and
magnetic interference from neighbouring systems (like
electromechanical systems, fluorescent tubes, motors, etc).
14.6.13 The different plug-in cards shall have suitable mechanical
safeguards to prevent damage due to accidental interchange of
cards.
14.6.14 The requirement at the external interface against induced voltages
and currents due to lightning, high power system, etc. shall be
indicated.
14.6.15 The system shall provide for isolation and protection from accidental
high voltage power contact.
14.7 Marking:
14.7.1 Equipment on the bay, whether fixed or plug-in type, shall be

suitably marked. Identification of a type of card, in its connector,
shall be possible without necessitating its removal. Any plug-in
component shall be marked with sufficient information for its
complete identification.
14.7.2 Connecting cables between jacks shall be marked at their
extremities with identical designation as on fixed connecting
flanges.
14.7.3 The marking on the equipment and the cables shall be the same as
that used on the schematic drawings, cabling diagrams etc., in the
documentation supplied with the equipment.
14.7.4 All instructions, labels, or any other marking on the equipment shall
be perfectly legible and in English language.
14.7.5 Colour code used for power feeding bus-bars /cables and earth shall
be identical for a given voltage throughout the equipment.
14.7.6 Fuses shall have a suitable marking for the different ratings to
enable easy identification and replacement.
14.8 Components:

All components used shall be of rugged construction and shall be
suitably designated by a label or sign writing.
14.8.1 Components used in the LTE-RAN shall, in general, be de-rated as
regards both voltage and power ratings, to ensure a high degree of
reliability over the life of the BSS.
14.8.2 All components shall have been in use long enough in industries for
establishment of their reliability.
14.8.3 All components used shall currently be in large-scale production.
14.8.4 The failure of any component/sub-system in the LTE-RAN shall not
result in the failure of complete system.
14.9 Quality Requirements:
14.9.1 The product design / manufacture shall conform to international /

national quality standards.
14.9.2 The components used shall be available from multiple sources with
adequate qualification. Number of proprietary components used
shall be minimum. List of such components shall be indicated.
14.9.3 All the equipment shall have a tropical finish and coated to protect
against saline atmosphere.
14.9.4 Mechanical design and construction of the unit/sub-assembly shall
be robust, rigid to withstand all conditions of operation, adjustment,
replacement and the storage.
14.9.5 The equipment when packed for delivery shall be mechanically
strong and be capable of withstanding vibrations and shocks during
transportation etc.
14.9.6 Each sub-assembly shall be clearly marked to show its functions and
circuit reference so that its complete description can be located in
the instruction manual.
14.9.7 The components shall be marked with their schematic references so
that they are identifiable from the component layout diagram in the
manual.
14.10 Software:
14.10.1 The software shall be written in a High Level Language. The

software shall be modular and structured.
14.10.2 The software shall include the following characteristics:
14.10.2.1 The design of the software shall be such that the system is easy
to handle both during installation and normal operations as well as
during extensions.

14.10.2.2 The functional modularity of the software shall permit
introduction of changes wherever necessary with least impact on
other modules.
14.10.2.3 It shall be open-ended to allow addition of new features.
14.10.2.4 Adequate flexibility shall be available to easily adopt changes in
service features & facilities and technological evolution in hardware.
14.10.2.5 The design shall be such that propagation of software faults is
contained.
14.10.2.6 The software shall provide sufficient checks to monitor the
correct functioning of the system.
14.10.2.7 The system software shall not lose complete sanity under any
circumstances.
14.10.2.8 Test programs shall include fault tracing for detection and
localization of system faults.
14.10.2.9 Facilities shall be in-built to ensure automatic system
reconfiguration on detection of
a. Software fault during calls processing
b. Software fault during audit checking
14.10.2.10The software shall not pose any problem, due to changes in date
and time caused by events such as changeover of leap year etc., in
the normal functioning of the system.
14.11 Software Maintenance:
14.11.1 All software updates, for a period as specified, shall be supplied on

continuing basis. These updates shall include new features and
services and other maintenance updates.
14.11.2 Integration of software updates without posing any problem to the
running system shall be possible.
14.12 Diagnostic programs to localise hardware faults:
14.12.1 On a faulty condition, the software shall provide for isolating the
faulty sub-system and then shall automatically bring in the
diagnostic programs for diagnostic purposes.
14.12.2 It shall be possible to diagnose to single PCB level in at least 95% of
the types of PCBs.
14.13 Man Machine Communication
14.13.1 Man-Machine Language (MML)
14.13.1.1 The man-machine language shall be in English. Commands shall
be English based and responses shall be in English.
14.13.1.2 The MML shall be easy to learn and use, easy to input commands
and to interpret outputs.
14.13.1.3 The MML shall have an open-ended structure such that any new
function or requirement added will have no influence on the existing
ones. The language structure shall be such that subsets can be
created.
14.13.1.4 The character set used in the MML shall be a sub-set of the ITU-T
Alphabet No. 5 as per in ITU-T Recommendations Z.314.
14.13.1.5 The command codes shall be function oriented. There shall be
only one command per function. The codes shall be mnemonic. It
is preferred if all the command codes in a particular application
consists of the same number of characters.
14.13.1.6 The output in response to input commands shall have the same
format and use the same identifiers, codes, and labels, as the
corresponding input command.
14.13.1.7 The MML shall provide facilities for editing, cancelling, and
stopping, the completion of commands wherever possible.
14.13.1.8 The MML shall provide facilities for inputting the parameters, for
a command, in any sequence and the optional parameters need to
be inputted only when they are required.
14.13.2 Man-machine dialogue
14.13.2.1 The MML shall offer the facility for a conversational mode of
operation.
14.13.2.2 The MML shall have facility for restricting the use of certain
commands or procedures to certain staff/terminals.
14.13.2.3 Where several man-machine terminals are in use on a single
system, a mechanism shall be available to avoid clashes.
14.13.2.4 The execution of any command shall not result in malfunctioning
or/and over loading of the system. It shall also be ensured that the
operator is not locked out by the system.
14.13.2.5 The MML shall be implemented in such a way that errors in
commands or control actions shall not cause the system to stop or
unduly alter the system configuration.
14.13.2.6 Command errors detected by the system shall be indicated by
the output of error messages.
14.13.2.7 Possibility of priority messages to interrupt input or output
message of lower priority is desirable.
14.13.2.8 MML commands shall provide context sensitive help.
14.14 Checks and safeguards:
Sufficient checks and safeguards shall be built-in to the implementation of

the MML so as to ensure reliable operation of the system.
14.15 eNode B DoS (Denial of Service) Attack Protection:

14.15.1 The eNode shall provide the protection against DOS attack.
The vendor shall describe how to protect against DOS attack in their
system.
14.16 Documentation:
14.16.1 All documents to be provided shall be in English language in CD-

ROM as well as in hard copy.
14.16.2 The documents shall comprise of
14.16.2.1 System description documents
14.16.2.2 System operation documents
14.16.2.3 Training documents
14.16.2.4 Diagnostic and Repair related documents
14.16.3 System description documents - The following system description
documents, wherever applicable, shall be supplied along with the
system:
14.16.3.1 Over-all system specification and description of hardware and
software.
14.16.3.2 Installation manuals and testing procedures.
14.16.3.3 Equipment layout drawings.
14.16.3.4 Spare part list.
14.16.3.5 Cabling and wiring diagram.
14.16.3.6 Detailed description of software describing the principle
interactions with hardware, structure of the program and data.
14.16.3.7 Detailed description of each individual software package
indicating its functions and its linkage with the other packages,
hardware, and data.
14.16.3.8 Planning and system engineering documents.
14.16.4 System operation documents
The following system operation documents shall be supplied.
14.16.4.1 Operating manual of the system.
14.16.4.2 Maintenance manual.
14.16.4.3 Man-machine language manual.
14.16.4.4 Operation and maintenance manual for all I/O devices and
auxiliary equipment’s.
14.16.4.5 Fault location and troubleshooting instructions including fault
dictionary.
14.16.4.6 Test procedures with auxiliary test equipment’s.
14.16.4.7 Emergency action procedures and alarm dictionary.
14.16.5 Training documents - Training manuals and documents necessary
for organising training in installation, operation & maintenance and
repair of the system shall be supplied.
15 Quality Requirements
The proposed radio network shall be most spectrum efficient.
15.1 System Radio Operating Environments
15.1.1 The system shall support multiple radio operating environments
like:
15.1.1.1 Indoor and/or outdoor operation
15.1.1.2 Outdoor operations in urban, sub-urban, rural, hilly or coastal areas
for radio coverage including following applications:
a. Contiguous coverage
b. Island coverage
c. Spot coverage
15.1.2 The relative speed between the system base stations and the
mobile stations may vary and broad categories for this relative
speed shall be as per 3GPP TS 36.101:
15.1.2.1 Stationary (0 km/h)
15.1.2.2 Pedestrian (upto 10 km/h)
15.1.2.3 Typical vehicular (upto 100 km/h)
15.1.2.4 High speed vehicular (upto 120 km/h)
15.1.3 Alarm Indications - It shall be possible to display or print out the

number of calls and occupancy for a given group of circuits/devices.
15.2 System Operation and Management:
The system shall be so designed as to enable economic flexible

handling of system administration, maintenance supervision, traffic
measurements, and routine control.
15.2.1 System supervision
15.2.1.1 Provision shall be made for continuous testing of the system to
allow both system qualities check and fault indication as a fault
arises.
15.2.1.2 The system shall provide for printouts and visual-audible alarms to
assist in efficient administration. The following minimum
printout/alarms are envisaged:
a. Audible/visual alarm on failure of any network entity.
b. Printout of congestion condition on junctions, trunks common
control devices, and processors. An audible/visual alarm shall also
be activated to give instant warning of a developing overload
situation.
c. Print-out of a record of the system configuration at any specified
time, designating equipment which are in service, in standby mode

or out of service. A visual display shall also be provided to indicate
the operating status of the processors.
d. Print-out of present status of the system or designated equipment
such as trunks free, busy or blocked, input/output device in use or
blocked, etc.
e. Printout of faults detected with identification of faulty units. The
printout shall contain the date and the time. Details of any other
printouts provided in the design for supervision and efficient
management of the system, details of the supervision panel and the
control arrangement shall be furnished.
15.2.1.3 The visual display and the devices for manual control of the
different parts of the system shall be centralized on a supervisory
panel. Details of the displays and the control arrangement shall be
provided.
15.2.1.4 In case a fault is detected requiring reloading of the program, this
shall be carried out automatically. In case of manual re-loading, it
shall be possible to stop and start at any particular point in the
program.
15.3 System and Network Management:
15.3.1 The system shall have the capability to monitor its own
performance and to detect, analyze, locate, and report faults.
15.3.2 The equipment design shall be such that any special care and
precautions on the part of the maintenance personnel are kept to an
absolute minimum.
15.3.3 Facility shall be available for introduction of centralized
maintenance control.
15.3.4 The maintenance spares supplied shall take into account the MTBF
and MTTR. At least one spare of circuit pack each type shall be
supplied.
15.4 Diagnostic capability:
15.4.1 The diagnostic capability of the system shall be such as to minimize

the human efforts required. The diagnostic programs which are
normally resident in the on line program shall be indicated. Details
of the off-line diagnostic programs shall be given. The procedure for
invoking such programs shall be described. The procedure for
consulting fault dictionary for diagnostic programs shall be made
available.
15.4.2 It shall be possible to obtain a list of equipment out of
service/locked/disabled at any given time.
15.4.3 The system shall provide facility for automatic restart under severe
fault conditions. Where automatic restart fails to restore system
sanity, facility shall be provided for manual restart of the system.
15.5 System reliability:
The downtime experienced during automatic reconfiguration of the

system where, (a) only calls in setting-up stage are lost and, (b) all
calls including established calls are lost, shall be minimized.
Frequency of occurrence of such automatic reconfigurations and the
downtimes has to be calculated and indicated. Planned outage shall
be excluded from the above availability figures.
Availability/reliability of the system based on reliability figure and
reliability model shall be furnished.
15.6 Environmental Test Conditions:
15.6.1 eNodeB B : Category A SD: QM-333

15.6.2 Outdoor eNode B, BBU &RRH : Category D SD: QM-333 and IP65
15.6.3 Antenna & Feeders : Category E as per SD: QM-333
Environment Test Quality certificates from independent test lab as
per International standards shall also be considered for above.
15.7 Qualitative Requirements (QR):
15.7.1 The supplier/manufacturer shall conform to ISO 9001:2008

certifications. A quality plan describing the quality assurance
system followed by the manufacturer shall be required to be
submitted.
15.7.2 The failure of any component/sub-system in the system shall not
result in the failure of complete system.
15.8 Quality of Service:
15.8.1.1 Flexible Service Platform

The system radio interface shall be designed in a flexible manner so
that the new services can easily be implemented. The LTE-RAN shall
support a flexible service creation and execution platform allowing
operator and user specific services to be easily created.
16 EMI/EMC Requirements:

General Electromagnetic Compatibility (EMC) Requirements: - The
equipment shall conform to the EMC requirements as per the
following standards and limits indicated therein. A test certificate
and test report shall be furnished from an accredited test agency.
Conducted and radiated emission (applicable to telecom

equipment):
Name of EMC Standard: “CISPR 22 (2008) - Limits and methods of
measurement of radio disturbance characteristics of Information
Technology Equipment".
Limits:-
To comply with Class A of CISPR 22 (2008).
The values of limits shall be as per TEC Standard No.
TEC/SD/RD/EMC-002/02.OCT 2016.
For Radiated Emission tests, limits below 1 GHz shall be as per Table
4 (a) or 5 (a) for measuring distance of 10m.
Immunity to Electrostatic discharge:

Name of EMC Standard: IEC 61000-4-2 {2008) "Testing and
measurement techniques of Electrostatic discharge immunity test".
Limits: -
Contact discharge level 2 {± 4 kV} or higher voltage;
Air discharge level 3 {± 8 kV} or higher voltage;
Immunity to radiated RF:

Name of EMC Standard: IEC 61000-4-3 (2010) "Testing and
measurement techniques-Radiated RF Electromagnetic Field
Immunity test"
Limits:-
For Telecom Equipment and Telecom Terminal Equipment with
Voice interface (s)
Under Test level 2 {Test field strength of 3 V/m} for general
purposes in frequency range 80 MHz to 1000 MHz and
Under test level 3 (10 V/m) for protection against digital radio
telephones and other RF devices in frequency ranges 800 MHz to
960 MHz and 1.4 GHz to 6.0 GHz.
For Telecom Terminal Equipment without Voice interface (s)
Under Test level 2 {Test field strength of 3 V/m} for general
purposes in frequency range 80 MHz to 1000 MHz and for protection
against digital radio telephones and other RF devices in frequency
ranges 800 MHz to 960 MHz and 1.4 GHz to 6.0 GHz.
Immunity to fast transients (burst):
Name of EMC Standard: IEC 61000- 4- 4 {2012) "Testing and
measurement techniques of electrical fast transients/burst
immunity test"
Limits:-
Test Level 2 i.e. a) 1 kV for AC/DC power lines; b) 0. 5 kV for signal /
control / data / telecom lines;
Immunity to surges:
Name of EMC Standard: IEC 61000-4-5 (2014) “Testing &
Measurement techniques for Surge immunity test"
Limits:-
For mains power input ports: (a)2 kV peak open circuit voltage for
line to ground coupling (b) 1 kV peak open circuit voltage for line to
line coupling
For telecom ports: (a) 2 kV peak open circuit voltage for line to
ground
(b)2 kV peak open circuit voltage for line to line coupling.
Immunity to conducted disturbance induced by Radio frequency
fields:
Name of EMC Standard: IEC 61000-4-6 (2013) "Testing &
measurement techniques-Immunity to conducted disturbances
induced by radio- frequency fields”
Limits:-
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.
Immunity to voltage dips & short interruptions (applicable to only ac
mains power input ports, if any):
Name of EMC Standard: IEC 61000-4-11 (2004) “Testing &
measurement techniques- voltage dips, short interruptions and
voltage variations immunity tests”
Limits:-
a voltage dip corresponding to a reduction of the supply voltage of
30% for 500ms (i.e. 70 % supply voltage for 500ms)
a voltage dip corresponding to a reduction of the supply voltage of
60% for 200ms; (i.e. 40% supply voltage for 200ms)
a voltage interruption corresponding to a reduction of supply
voltage of > 95% for 5s.
a voltage interruption corresponding to a reduction of supply
voltage of >95% for 10ms.
Note 1: Classification of the equipment:

Class B: Class B is a category of apparatus which satisfies the class
B disturbance
limits. Class B is intended primarily for use in the domestic
environment and may include:
Equipment with no fixed place of use; for example, portable
equipment powered by built in batteries;
Telecommunication terminal equipment powered by the
telecommunication networks
Personal computers and auxiliary connected equipment.
Please note that the domestic environment is an environment where

the use of broadcast radio and television receivers may be expected
within a distance of 10 m of the apparatus connected.
Class A: Class A is a category of all other equipment, which satisfies
the class A
limits but not the class B limits.
Note 2: The test agency for EMC tests shall be an accredited agency
and details of
accreditation shall be submitted.
Note 3: For checking compliance with the above EMC requirements,
the method of measurements shall be in accordance with TEC
Standard No. TEC/SD/RD/EMC-002/02.OCT 2016 and the references
mentioned therein unless otherwise specified specifically.
Alternatively, corresponding relevant Euro Norms of the above
IEC/CISPR standards are also acceptable subject to the condition
that frequency range and test level are met as per above mentioned
sub clauses (a) to (g) and TEC Standard No. TEC/SD/RD/EMC-
002/02.OCT 2016. The details of IEC/CISPR and their corresponding
Euro Norms are as follows:
IEC/CISPR Euro Norm
CISPR 11 EN 55011
CISPR 22 EN 55022
IEC 61000-4-2 EN 61000-4-2
IEC 61000-4-3 EN 61000-4-3
IEC 61000-4-4 EN 61000-4-4
IEC 61000-4-5 EN 61000-4-5
IEC 61000-4-6 EN 61000-4-6
IEC 61000-4-11 EN 61000-4-11
3 Safety Requirements :

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”]
and IS 10437 {1986} “safety requirements for radio
transmitting equipments” [equivalent to IEC 60215]

CHAPTER-2
a.i.1. Clause 2.2.7: Among the various bands specified

in 3GPP TS 36.104, the bands of operation of LTE shall be as defined by
DoT, however at least 3GPP FDD bands 1, 3, 5, 7, 8,28 and 3GPP TDD
bands 38,40 and 41 shall be supported with 5, 10, 15 and 20 MHz
bandwidths for FDD (wherever applicable) and 5, 10, 15 and 20 MHz for
TDD (wherever applicable) shall be supported. Channel bandwidth for
additional options of 5 & 15 MHz for TDD may be reviewed and shall be
as per tender requirement. However, the actual operation shall be
regulated by the spectrum allocated.
a.i.2. Clause 3.1.23 Output power: Actual requirements

may be reviewed in tender requirement for lower power requirements).
The maximum power radiation shall be regulated by latest DoT
guidelines/ instructions/ licensing conditions. The tendering authority may
also specify the step size required e to reduce output power through
software commands.
a.i.3. Clause 3.8.7 Target RSRP may be reviewed by

tendering authority at the time of procurements.

ABBREVIATIONS
Abbreviation Expanded Form

3GPP Third Generation Partnership Project
BSC Base Station Controller
BSNL Bharat Sanchar Nigam Limited
BSS Base Station Subsystem
BTS Base Transceiver Station
CB Cell Broadcast
CBC Cell Broadcast Centre
CBCH Cell Broadcast Channel
CBE Cell Broadcast Entity
CBS Cell Broadcast System
CBM Cell Broadcast Message
CI Cell Identify
DRX Discontinuous Reception
EMC Electro Magnetic Conformance
ETSI European Telecommunications Standard Institute
FTAM File Transfer And Management
FTP File Transfer Protocol
FW Fire-Wall
GIS Geographical Information Systems
GSM Global System for Mobile communications
GUI Graphical User Interface
LAC Local Area Code
LAN Local Area Network
LTE Long Term Evolution
MME Mobility Management Entity
MS Mobile Station
MSC Mobile Switching Centre
MTNL Mahanagar Telephone Nigam Limited
MTP Massage Transfer Protocol
OMC Operations & Maintenance Centre
PLMN Public Land Mobile Network
RNC Radio Network Controller
RNS Radio Network Subsystem
RSS Radio Subsystem
SAI Service Area Identity
SAC Service Area Code
SIM Subscriber Identity Module
SAT System Administrative Terminal
SMS Short Message Service
SMSCB Short Message Service Cell Broadcast
TEC Telecommunication Engineering Centre
TMN/Q.3 Telecommunications Maintenance Network
UE User Equipment
UMTS Universal Mobile Telecommunication System
WAN Wide Area Network
======== End of the document ========

GR Lte Nov 2016 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

GR Lte Nov 2016 PDF

Caricato da

Copyright:

Formati disponibili

वर्गीय आवर्श्यकताएँ

सं ख् या:टीईसी/जीआर/डबल्यू ए स/एलटीए -001/01.नवर्म्बर

लॉन्ग टमर एवर्ल्यू श न-एडवर्ांस् ड(एलटीई-ए) - एवर्ं एवर्ोल्वर्ड पै के ट

TELECOMMUNICATION ENGINEERING CENTRE

Telecommunication Engineering Centre (TEC) functions under

This document contains the Generic Requirement (GR) of Long Term

Claus Particulars Page No.

3 LTE – Radio Access Network (RAN) 10

4 Mobility Management Entity 33

5 PDN and Serving -Gateway 38

6 Policy And Charging Function (PCRF) 41

7 Home Subscriber Server (HSS) 44

9 Operations Administration Maintenance and 49

1 IMS/Voice over LTE 54

1 Wifi and LTE Interworking 57

1 GR/WS/LTA- Long Term Evolution -Advanced Issue 01

NO. TEC/GR/LTA-001/01. NOV 16 6

S.N Document No. Title/Document Name

NO. TEC/GR/LTA-001/01. NOV 16 7

1 3GPP TS 36.420 “X2 General aspects and principles”

2 3GPP TS 36.423 “X2 Application protocol (X2AP)”

2 3GPP TS 23.401 “General Packet Radio Service (GPRS)

2 3GPP TS 23.122 Non-Access-Stratum (NAS) functions related to

2 3GPP TS 32.240 “Telecommunication management; Charging

3 3GPP TS 33.107 “3G security; Lawful interception architecture and

4 3GPP TS 23.216 “Single Radio Voice Call Continuity (SRVCC);

4 3GPP TS 29.168 “Cell Broadcast Centre interfaces with the

NO. TEC/GR/LTA-001/01. NOV 16 9

5 3GPP TS 36.305 “Evolved Universal Terrestrial Radio Access

5 IS-41D & E “Cellular Radio Telecommunications Intersystem

NO. TEC/GR/LTA-001/01. NOV 16 10

6 IEC 60215 (1987) “Safety requirements of radio transmitting

NO. TEC/GR/LTA-001/01. NOV 16 11

This document contains the Generic Requirement (GR) of Long Term

Long Term Evolution (LTE): Long Term Evolution (LTE) is the

NO. TEC/GR/LTA-001/01. NOV 16 12

3GPP specified support of multiple access technologies in EPC and also

NO. TEC/GR/LTA-001/01. NOV 16 13

2.1 Applications: Some of the services and applications which can be

 Guaranteed Bit rate (GBR) requiring like

NO. TEC/GR/LTA-001/01. NOV 16 14

The Architecture of a GSM/WCDMA/LTE network is shown in Figure

Iu-C S12 S1-U

2.2.2 Interfaces for LTE network:

NO. TEC/GR/LTA-001/01. NOV 16 17

2.2.3.7 HARQ - A Medium Access Control (MAC) Hybrid Automatic Repeat

2.2.3.8 Scheduling - A scheduler with support for the QoS (Quality of

2.2.3.9 Multiplexing and Mapping - The eNB performs mapping of logical

NO. TEC/GR/LTA-001/01. NOV 16 18

2.2.4 Mobility Management Entity (MME) - The EPS architecture defines an

2.2.4.1 UE attach/detach handling -This allows UE to register and de-

2.2.4.2 Security (AAA) - The MME implements functions for Authentication,

2.2.4.4 Mobility Anchor – IP Point of Presence - The MME acts as a mobility

NO. TEC/GR/LTA-001/01. NOV 16 19

The P/S-GW is involved in the following control plane functions:

2.2.5.2 Mobility Anchor – IP Point of Presence - The P-GW acts as a mobility

2.2.5.2.1QoS Policy Control and Enforcement - To simplify bearer requests

2.2.5.2.2Charging - The charging function is responsible for charging the user

2.2.5.2.3Lawful Intercept - Lawful interception facility shall be provided as

2.2.5.2.4Policy Control and Charging Rules Function (PCRF) - Policy control

NO. TEC/GR/LTA-001/01. NOV 16 20

3 LTE – Radio Access Network (RAN): The E-UTRAN requirements are

NO. TEC/GR/LTA-001/01. NOV 16 21