LA4.0 LTE RAN Technical Overview PDF

9400 LTE
RAN TLA3.0-LA4.0 Technical Overview

STUDENT GUIDE
TMO18213_V4.0-SG Edition 10
COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.
Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent
Copyright 2012 Alcatel-Lucent. All Rights Reserved.
Terms of use and legal notices

Switch
toUSEnotes
view!
TERMS OF
AND LEGAL
NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms
of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from
time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment
constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT
The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided
in this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other
authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable
permission to access and use the Content solely for your personal training and non-commercial use. This permission may be
terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must immediately cease
use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS
The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and
Alcatel-Lucents corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws,
including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights
laws (collectively, "IP Rights"). In addition to Alcatel-Lucents IP Rights in the Content, in part and in whole, Alcatel-Lucent,
and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and
presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these
Terms of Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification,
publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative
2
ALCATEL-LUCENT
2012.another
ALL RIGHTS RESERVED.
works from, distribution, performance, display,COPYRIGHT
incorporation
into
training course or presentation, or in any other way
9400 LTE
any ofOverview
the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited
RANexploiting
TLA3.0-LA4.0 Technical
and shall not be made without Alcatel-Lucents prior written consent. All characters appearing in this training course are
fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks
are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos,
marks, trademarks, slogans and product designations in any fashion. Granting of the right to access and use the Content for
training purposes does not confer upon you any license under any of Alcatel-Lucents or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES
AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute
or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision
that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal
Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder
without Alcatel-Lucents prior written consent. Nothing herein shall be deemed an employment agreement or an offer of
employment or an alteration in any way of a users terms of employment with or within Alcatel-Lucent.
Copyright 2011 Alcatel-Lucent. All Rights Reserved
Course outline
4. Topic/Section is Positioned Here
1. RAN TLA3.0-LA4.0 Technical Overview
Welcome
to 9400Overview
LTE
1.
LTE eUTRAN
2.
LTETLA3.0-LA4.0
Transport overview
RAN
Technical Overview
3. LTE eNodeB Hardware Description
4. LTE RAN OAM description
1. RAN TLA3.0-LA4.0 Technical Overview
1. LTE eUTRAN Overview
2. LTE Transport overview

3. LTE eNodeB Hardware Description
4. LTE RAN OAM description
3
9400 LTE
Course objectives
Upon completion of this course, you should be able to:
Welcome to 9400 LTE
Describe functions and the architecture of an LTE Access network
RAN
TLA3.0-LA4.0
Technical
Overview
Describe
the IP transport
layer in the radio
Access Network
Describe the portfolio of the Alcatel-Lucent LTE Radio equipment

Describe the eNodeB Operation and Maintenance Principles
Upon completion of this course, you should be able to:
z
z
z
z
Describe
Describe
Describe
Describe
4
9400 LTE
functions and the architecture of an LTE Access network

the IP transport layer in the radio Access Network
the portfolio of the Alcatel-Lucent LTE Radio equipment
the eNodeB Operation and Maintenance Principles
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:
Thank you!
11
Section 1
RAN TLA3.0-LA4.0 Technical
Overview
Do not delete this graphic elements in here:
Module 1
LTE eUTRAN Overview
TMO18213_V4.0-SG-Ed10 Module 1.1 Edition NA
9400 LTE
All Rights Reserved Alcatel-Lucent 2012

Section 1 Module 1 Page 1
Blank page
112
RAN TLA3.0-LA4.0 Technical Overview LTE eUTRAN Overview

9400 LTE RAN TLA3.0-LA4.0 Technical Overview
This page is left blank intentionally
Document History
Edition
Date
Author
Remarks
10
2012-02-01
Vincent, Cecile
Edition 10

Module objectives
Upon completion of this module, you should be able to:
Describe the eUTRAN architecture
List Network Elements and their functions
Describe interface names
Describe the protocol stack for User and Control Planes
Explain FDD and TDD transmission principles, OFDMA (Orthogonal FrequencyDivision Multiple Access) modulation scheme and MIMO (Multiple Input Multiple
Output) antenna technic.
List supported Mobility features
Describe eNodeB advanced features, (common to FDD et TDD, dedicated to
FDD or to TDD)
113

Module objectives [cont.]
114

Table of Contents
Switch to notes view!
1 EnodeB functions and protocols
1.1 eNodeB functions
1.2 LTE-Uu Radio interface
1.3 S1 interface
1.4 MME Overload Indication support
2 Air Interface Basics
2.1 FDD and TDD introduction
2.2 LTE frequency bands
2.3 OFDMA
2.4 MIMO
2.5 One antenna/single antenna transmit mode
3 Mobility in LTE
3.1 UE in Active or Idle mode
3.2 X2 interface
3.3 Intra-LTE mobility
3.4 Intra-LTE Inter-Frequency Mobility
3.5 supported IRAT Mobility in FDD
3.6 supported IRAT Mobility in TDD
4 FDD advanced features
4.1 Public Warning Systems in LTE network
4.1.1 CMAS principles
5 TDD advanced features
5.1 Beamforming
1 1 5 5.2 eMBMS
RAN TLA3.0-LA4.0
Technical eMBMS
Overview LTE eUTRAN
Overview
5.2.1
interfaces
5.2.2 eMBMS Alcatel-Lucent solution, phase 1

Page
7
8
9
11
13
18
19
21
22
23
24
26
27
28
29
31
32
34
36
37
38
39
40
42
43
44
Table of Contents [cont.]

116

117

1.1 eNodeB functions

ePC
eUTRAN
MME
eNodeB
Dynamic Resource
Allocation
(Scheduler)
NAS Security
Idle State Mobility
Handling
RB Control
EPS Bearer Control
RRC Connection
Admission control
Mobility
Anchoring
Measurement
Configuration
Packet
Filtering
eNodeB Functions
118
UE IP address
allocation
Ref 3GPP TS 36.300
eNB Functions:
It schedules the user traffic each 1 ms in DL and UL and it takes in account the QoS parameters
associated to the data (real time, guaranteed bit rate),
It controls the creation, modification and release of the radio bearers,

It handles the RRC connection for each UE,
It performs an admission control to avoid to accept too many users,
It configures the UE measurements on the adjacent cell to manage the mobility by Handover mechanism.
MME Functions :
NAS (Non Access Stratum) signaling and NAS signaling security,
NAS Security control,
Inter Core Network node signaling for mobility between 3GPP access networks,
Idle mode UE reachability (including control and execution of paging retransmission) and Tracking Area
list management (for UE in idle and active mode);
PDN GW and Serving GW selection, MME selection for handovers with MME change, SGSN selection for
handovers to 2G or 3G 3GPP access networks,
Roaming,
Authentication,
Bearer management functions including dedicated bearer establishment,

1.2 LTE-Uu Radio interface

User Plane
Control Plane
User Plane
Control Plane
NAS
Non Access Stratum

Signaling between Core Network and UE
NAS
RRC
Radio Signaling
RRC
PDCP
PDCP
Radio Bearer
RLC
RLC
Logical Channel
MAC Layer
MAC Layer
Transport Channel
Physical Layer
Physical Layer
Physical Channel
119
Physical (PHY) Sublayer : The physical layer is between the UE and the eNodeB. The physical layer in
LTE supports the Hybrid ARQ with soft combining, uplink power control and multi-stream transmission and
reception (MIMO).
Media Access Control (MAC) Sublayer : The MAC sublayer is between the UE and the eNodeB. MAC
sublayer performs error correction through HARQ, priority handling across UEs as well as across different
logical channels of a UE, traffic volume measurement reporting, and multiplexing/demultiplexing of different
RLC Sublayer. For the user plane, the PDCP sublayer performs header compression and ciphering.
Radio Link Control (RLC) Sublayer : The RLC sublayer is between the UE and the eNodeB. Along with
transferring upper layer PDUs. The RLC does error correction through ARQ, in-sequence delivery of upper
layer PDUs, duplicate detection, and flow control and concatenation/re-assembly of packets.
Packet Data Convergence Protocol (PDCP) Sublayer : For the user plane, the PDCP sublayer
performs header compression and ciphering.
Radio Resource Control (RRC) Sublayer : The RRC sublayer is between the UE and the eNodeB. The
RRC sublayer in essence performs broadcasting, paging, connection management, radio bearer control,
mobility functions, and UE measurement reporting and control.
Non Access Stratum (NAS) Sublayer : The NAS sublayer is between the UE and the MME. It performs
authentication, security control, idle mode mobility handling, and idle mode paging origination.

Transport Channels:
Logical channels:
PCH: Paging Channel
PCCH: Paging Control Channel.
BCH: Broadcast Channel.
BCCH: Broadcast Control Channel.
MCH: Multicast Channel.
CCCH: Common Control Channel.
DLSCH: Downlink Shared Channel.
DCCH: Dedicated Control Channel.
ULSCH: Uplink Shared Channel.
DTCH: Dedicated Traffic Channel.

MCCH: Multicast Control Channel.
MTCH: Multicast Traffic Channel.
On RRC level, System information is divided into the MasterInformationBlock (MIB) and a number of
SystemInformationBlocks (SIBs). The MIB includes a limited number of most essential and most frequently
transmitted parameters and is transmitted on BCH.
SIB are transmitted over DL-SCH.
Master Information Block: Most essential parameters

SIB 1: Cell access related parameters and scheduling
SIB 2: Common and shared channel configuration
SIB 3: Parameters required for intra-frequency cell reselections
SIB 4: Information on intra-frequency neighboring cells
SIB 5: Information inter-frequency neighboring cells
SIB 6: Information for reselection to UMTS (UTRAN) cells if no suitable LTE cell is available
SIB 7: Information for reselection to GSM (GERAN) cells if no suitable LTE or UMTS cell is available
SIB 8: Information for reselection to CDMA2000 systems (mostly for North America)
SIB 9: Home eNodeB name for future LTE femtocell applications
SIB 10 + 11: ETWS (Earthquake and Tsunami Warning System) information
SIB 12: Commercial Mobile Alerting System (CMAS) information.

1.3 S1 interface
User Plane (eNB - S-GW)

UE
User Apps
TCP, UDP, ICMP

IP (user)
eNodeB
SGW
IP (user)
IP (user)
GTP - U
GTP - U
PDCP
PDCP
Uu L2
RLC
RLC
MAC
MAC
Phy (L1)
Phy (L1)
UDP

UDP
IP (path)
IP (path)
Phy
Phy
LTE Uu
1 1 11
S1-U
When the UE send in UL an IP packet, it is treated by the LTE radio protocol before being transmitted
over the air interface. After the reception, the eNodeB send this data on the GTP tunnel (S1 bearer) to
the SGW.
S1-U (user plane)
The S1 user plane external interface (S1-U) is defined between the eNodeB and the S-GW. The S1-U
interface provides non guaranteed data delivery of user plane Protocol Data Units (PDUs) between the
eNodeB and the S-GW. Transport network layer is built on IP transport and GTP-U. UDP/IP carries the
user plane PDUs between the eNodeB and the S-GW. A GTP tunnel per radio bearer carries user traffic.
The S1-UP interface is responsible for delivering user data between the eNodeB and the S-GW. The IP
Differentiated Service Code Point (DSCP) marking is supported for QoS per radio bearer.

1.3 S1 interface [cont.]

Control plane (eNB MME)
UE
User Apps
MME
eNodeB
NAS
NAS
RRC
RRC
S1 - AP-
S1 - AP
PDCP
PDCP
Uu L2
RLC
RLC
MAC
MAC
Phy (L1)
Phy (L1)
SCTP

SCTP
IP
IP
Phy
Phy
LTE Uu
1 1 12
S1-MME
S1-MME (control plane)

The S1-MME interface is responsible for delivering a signaling protocol between the eNodeB and the
MME.
It consists of a Stream Control Transmission Protocol (SCTP) over IP and provides guaranteed data
delivery and multiple UEs are supported through a single SCTP association.
The application signaling protocol is an S1-AP (Application Protocol).
The S1-MME is responsible for Evolved Packet System (EPS) bearer setup/release procedures, the
handover signaling procedure, the paging procedure and the NAS transport procedure.
Transport network layer is built on IP transport, similar to the user plane but for the reliable transport
of signaling messages SCTP is added on top of the Internet Protocol.

1.4 MME Overload Indication support

Overload Start / Stop procedures is used by MME to inform an eNodeB
about an overload situation
The information helps the eNodeB to realize MME Selection :
MME 1
UE
load
Over
S1AP message with Overload start

indication sent to the eNodeB
st art
MME 2
Selection algo. takes MME1

overload situation into account
UE IMSI based attach request
sent to MME2
LA4.0
1 1 13
The purpose of the Overload Start / Stop procedures (3GPP TS 36.413 release 9) is to inform an eNodeB
to reduce the signaling load towards the MME.
The eNB realizes MME Selection : new entering calls, should not be established towards an overloaded MME.
The eNodeB that receives an OVERLOAD START message assumes the MME is in an overloaded state.
The message contains indication on signaling traffic (permitted RRC connections) the eNodeB is permitted
to send to the MME :
reject all RRC connection establishments for non-emergency mobile originated data transfer
reject all RRC connection establishments for signaling
only permit RRC connection establishments for emergency sessions and mobile terminated services
When receiving a RRC establishment request for an overloaded MME, the eNB checks the establishment
cause value included in the request and determines if it should accept or reject the RRC Connection.
In case of reject, the eNB sends back to the UE aRRCConnectionReject message with a waitTime set to
parameter UeTimers:tOverload value.
The eNB receiving the OVERLOAD STOP message assumes that the overload situation at the MME has
ended and the eNodeB resumes normal operation towards this MME.
Handovers are not impacted by Overload procedure: any S1 or X2 Handover related to an overloaded MME
are handled normally.
1.4 MME Overload Indication support [cont.]

MME Overload Indication method is also used to request the eNodeB to
reduce signaling load to MME :
MME
Overload start
Tracking Area Update request

including GUTI
Overload action included
Overload start indication

contains reject all RRC
connection establishments
for signalling
RRC connection rejected

(waitime set)
Service request from UE attached on this MME for

Emergency call service can still be sent to the
MME
MME
Tracking Area Update request
including GUTI
Overload stop
S1AP (NAS TAU Request)

LA4.0
1 1 14
Following mapping is performed between Overload Action and RRCConnection Establishment Cause
(EC)values:
RRC
Connection Establishment cause

emergency highPriorityAccess MT Access MO Signalling
Overload Action
reject all RRC connection establishments
accepted
accepted
accepted
for non-emergency mobile originated data accepted
transfer
reject all RRC connection establishments
accepted
accepted
accepted
rejected
for signalling
Permit
emergency sessions and mobile

terminated services only
accepted
rejected
accepted
rejected
MO
rejected
rejected
rejected
MT stands for Mobile Terminating and MO for Mobile Originating.
There is a mapping defined between NAS procedures and establishment causes. The relationship is
specified in 3GPP TS 24.301 Annex D.
For example :
Attach, Detach and Tracking Area Update procedures EC = MO Signalling
Service request for Paging response or mobile terminating call CSFB EC = MT Access
Service request for Mobile originating services EC = MO Data
Data
Answer the Questions

Link the interfaces or protocols names and the concerned peers :
Name of the
interface
S1-U
Between
NAS
Two eNodeBs for signaling

UE and MME
LTE-Uu
UE and eNodeB
GTP-U
RRC
S1-MME
Two eNodeBs for data

eNodeB and MME
eNodeB and SGW
Note : Multiple matches can be defined on the right table.

1 1 15

Name of the
interface
S1-U
Between
NAS
Two eNodeBs for signaling

UE and MME
LTE-Uu
UE and eNodeB
GTP-U
RRC
S1-MME
Two eNodeBs for data

eNodeB and MME
eNodeB and SGW
SCTP
1 1 15


In the TCP/IP suite, what is (are) the layer 4 protocol(s) used for
interfaces :
S1-U?
S1-MME ?
IPv4
IPv6
TCP
UDP
SCTP
IPv4
IPv6
TCP
UDP
SCTP
In the TCP/IP suite, what is (are) the layer 3 protocol(s) used for
interfaces :
S1-U?
S1-MME ?
IPv4
IPv6
TCP
UDP
SCTP
IPv4
IPv6
TCP
UDP
SCTP
1 1 16


What are the two main uses of MME overload indication procedure ?
To
To
To
To
stop sending signalling traffic to an overloaded MME,

reduce the signalling load to a MME,
avoid any new attach on an overloaded MME,
indicate the eNodeB to suppress MME attached UE contexts.
1 1 17

1 1 18

2.1 FDD and TDD introduction

TDD = Time Division Duplex
The Uplink and the downlink transmissions are separated by the time.
Only one bandwidth is used.
Example: WiMAX
frequency
DL
UL
DL
UL
time
FDD = Frequency Division Duplex

The Uplink and the downlink transmissions are separated by the frequency.
2 bandwidths are used.
Example: WCDMA, CDMA2000
frequency
DL
UL
DL
frequency
UL
1 1 19
time
LTE air interface characteristics are:

Supports both FDD and TDD modes
z
z
With FDD, DL and UL transmissions are performed simultaneously in two different frequency bands.
With TDD, DL and UL transmissions are performed at different time intervals within the same
frequency band.
Provides deployment flexibility in spectrum allocation.

2.1 FDD and TDD introduction [cont.]

The LA (LTE Access) release is the FDD solution
The TLA (TDD LTE Access) release is the TDD solution
The LE release is the solution release that houses both LA and TLA releases.
LTE-FDD
One standard
3GPP TS 36.xxx
TDD-LTE
(set of LTE specs)
One access Scheme
OFDMA for DL and SC-FDMA for UL
One Core Network
ePC
Channel BW
3Mhz (LA4.0) 5MHz (LA3.0), 10MHz and 20MHz from LE3.0

1.4MHz ,15MHz future
Sub-frame duration
1 ms
Frame duration
Ratio (DL:UL)
10ms
5ms, 10ms
1:1
5ms (2:2), (3:1) from TLA3.0

Future :
5ms (1:3)
10 ms (6:3), (7:2), (8:1), (3:5)
One technology, One standard 2 access options

1 1 20
This table illustrates the LTE TDD and FDD bands defined by 3GPP . The 3GPP has defined all these
frequencies, but all these bands are not available for LTE in each country.
LA4.0 modulation schemes : QPSK, 16QAM, 64QAM (UL & DL)
For TDD, 3GPP has defined 7 uplink-downlink allocation configurations (config 0 to 2 for 5 ms frame and
3 to 6 for 10ms frame). TLA3.0 supports configuration 1 (2:2) and configuration 2 (3:1).

2.2 LTE frequency bands

The first frequency bands usable by the operators are the DD bands and
the 2.6 GHz bands.
It will also possible to reuse 2G, 3G or CDMA bands for LTE (refarming)
1900Mhz
PCS
1GHz
2GHz
2.3 GHz 2.6 GHz
New band for LTE only
TDD
FDD and TDD
700 MHz
US DD
FDD
800 MHz
EDD
AWS
DCS
1800 Mhz
(European Didital Dividend)
LA4.0
FDD
TLA3.0
1 1 21
DD means Digital Dividend, it refers to the frequency band frees by the end of the analogical TV.
700Mhz frequency band on band 17/12 and 13 are available in LA3.0.
The AWS bands are for 1710-1755 MHz and 2110-2155 MHz.

2.3 OFDMA
In TDMA, the UE communications are separated in
time.
Example: GSM
In FDMA, the UE communications are separated by

frequency :
Several users can receive data in the same time but not
on the same frequencies.
OFDMA (Orthogonal FDMA) allows a high density of

sub-carrier, and so increases the performance
5, 10 or 20 MHz
15kHz Sub-Carrier
User 1
1 1 22
User 2
User 3
TDMA = Time Division Multiple Access.

The Sub-Carrier can carry only one symbol at each time. The number of Sub-Carrier depends on the
bandwidth. The scheduler allocated dynamically groups of sub-carrier to the UEs.

2.4 MIMO
MIMO is a multiple antenna technique to increase the performance

2 antennas on the enodeB side
2 antennas on the UE side
Antennas transmit 2 streams in parallel when the radio condition are good
enough.
freq
DL
time
1 1 23
Transmissions from each antenna must be uniquely identifiable so that each receiver can determine what
combination of transmissions has been received.
The UE needs to know the spatial signature of each transmission path : this identification is usually done
with pilot signals, which use orthogonal patterns for each antenna.
In TDD, the RRH (Remote Radio Head) module provides the RF part of the eNodeB. Depending on the
RRH, the eNodeB includes two or eight RF transmitters to enable 2x2 MIMO application.

2.5 One antenna/single antenna transmit mode

eNodeB supports following transmit scheme :
Transmit Diversity (TxDiv),
Multiple Input Multiple Output (MIMO),
Sector 1
Single Input Multiple Output (SIMO),

y Used in case of transmit path failure
y Or used for capex reduction (1 antenna only)
eNB automatically switches to

pseudo SIMO mode
FDD
only
RF
module
BBU
1 1 24
This feature supports single antenna mode (one transmit path only) as an official configuration on eNB.
Single antenna mode configuration allows:
- deployment scenarios that require single antenna operation for cost reason.
- degraded mode operation even when two antenna mode is configured in the case of one transmit path
failure by continuing to support users at maximum capacity.
When there is transmit path failure, eNB shall automatically transition to the pseudo single antenna
transmission mode without operator intervention via DCI change. The eNB shall operate in the pseudo
SIMO mode (Transmit diversity) after the transition.
Performance degradation (including call drops) is expected during this transition, especially for cell edge
users. Operator could decide whether to continue operating in the pseudo SIMO mode or switch to the
true SIMO mode by cell reconfiguration


What does LA3.0 support?
TDD
FDD
What does EDD mean?

Emergency Digital Data
European Digital Dividend
What is the frequency band for EDD?

700MHZ
800MHZ
2,6GHZ
1 1 25

3 Mobility in LTE
1 1 26

3 Mobility in LTE
3.1 UE in Active or Idle mode

In Active mode, the mobile is reachable and communication sessions are
active with eUTRAN.
MME
DRB
S1 Bearer
UE is in RRC-CONNECTED state
PDN
S5 Bearers
PGW
SGW
In Idle mode, the mobile is reachable but no communication sessions are

active with eUTRAN.
MME
PDN
S5 Bearers
SGW
PGW
UE is in RRC-IDLE state
1 1 27
DRB stands for Data Radio Bearer.

When UE is in RRC_connected mode (active state),
The UE in known in both EPC and eUTRAN (contexts exists in eNB, MME, SGW and PGW)
The UE location known on cell level;
In idle mode,
no UE context information is stored in E-UTRAN : no S1_MME, no S1_U connection for the UE.
The UE is known in EPC and has IP address
The UE location is known on a per Tracking Area level and UE can be reached after beeing paged by
the ePC.
The idle state enables battery power consumption reduction.

3 Mobility in LTE
3.2 X2 interface
eUTRAN
X2-C interface
X2-U interface
X2-AP
GTP-U
SCTP
UDP
IP
IP
Data link layer
Data link layer
Physical layer
Physical layer
eNodeB
X2-C
X2-U
Alcatel-Lucent eNodeB supports a true open

X2 interface for multi-vendor interworking.
True open
X2 interface
Third party
eNodeB
X2
eNodeB
Alcatel-Lucent
ENodeB
User
Control
Third party
eNodeB
1 1 28
X2-U (User Plane)

The X2-UP protocol tunnels end-user packets between the eNodeBs. The X2-U interface provides non
guaranteed delivery of user plane PDUs. X2-UP uses GTP-U over UDP/IP as the transport layer protocol
similar to S1-UP protocol.
S1-UP and X2-UP use the same U-plane protocol to minimize protocol processing for the eNodeB at the
time of data forwarding.
X2-C (Control Plane)
X2-CP has SCTP as the transport layer protocol is similar to the S1-CP protocol. The load management
function allows exchange of overload and traffic load information between eNodeBs to handle traffic load
effectively. The X2 control plane external interface (X2-CP) is defined between two neighbor eNodeBs
X2-CP protocol functions include:
z intra
LTE-Access-System mobility support for the UE
z context
z control
z
transfer from source eNodeB to target eNodeB

of user plane tunnels between source eNodeB and target eNodeB
handover cancellation
z uplink
load management
z general
z error
X2 management
handling
LA3.0 and TLA3.0 eNodeB offer True open X2 interface to Third party eNodeBs.

3 Mobility in LTE
3.3 Intra-LTE mobility

When UE in in RRC_CONNECTED state, mobility is called Handover :
X2 based HO when no MME change required and X2 interface exists between eNB.
S1 based HO when the X2-based handover cannot be used.
Serving MME
Serving eNB
MME
1 Measurement
Direct forwarding
Target MME
2 HO preparation
3 HO Execution
Direct forwarding
4 HO Completion
Serving eNB
User
Control
SGW
Target eNB
SGW
Target eNB
SGW
indirect forwarding
SGW
When UE in in RRC_IDLE state, the mobility is call Cell reselection.

1 1 29
A handover operation requires transfer of information necessary to maintain the LTE RAN services at
the new eNodeB. It also requires establishment and release of tunnels between source and target
eNodeB to allow data forwarding and inform the already prepared target eNodeB for handover
cancellations.
ALU solution supports lossless Intra-LTE Mobility with buffered PDCP packet forwarding over X2 interface.
UE in RRC_IDLE performs cell reselection :

The UE makes measurements of attributes of the serving and neighbour cells to enable the
reselection process.
There is no need to indicate neighbouring cell in the serving cell system information, E-UTRAN
relies on the UE to detect the neighbouring cells.
For the search and measurement of inter-frequency neighbouring cells, only the carrier
frequencies need to be indicated.
Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria :
Intra-frequency reselection is based on ranking of cells;
Inter-frequency reselection is based on absolute priorities where UE tries to camp on highest

priority frequency available. Priorities are given by the system information and valid for all UEs
in a cell.
Black lists can be provided to prevent the UE from reselecting to specific intra- and inter-frequency
neighbouring cells;

3 Mobility in LTE
3.3 Intra-LTE mobility [cont.]

The Mobility is based on preliminary radio measurements on serving and neighbour
cells.
Serving
eNB
SGW
Measurement Control
Radio bearers
S1 Bearers
Packet data exchanged
Cell1 becomes better than the serving cell

UL allocation
Measurement Report
RSRP
Serving Cell
HO
decision
Cell1
UE triggers intra-frequency
measurements
1 1 30
Timer
Cell 1 is Reselected
For each carrier frequency measurement, one or several reporting configurations can be defined. This
reporting configuration defines the reporting criteria : event triggered reporting, periodic reporting.
Two basic UE measurement quantities shall be supported: Reference symbol received power (RSRP) and
E-UTRA carrier received signal strength indicator (RSSI).
Events correspond to UE measurement quantities that matches criterias based on defined thresholds.
Example : the Neighbour RSRP becomes better than the serving cell ones.
Measurement commands are used by eNB to order the UE to start measurements, modify measurements
or stop measurements. The measurements for intra/inter-frequency mobility can be controlled by eNB,
using broadcast or dedicated control.
In RRC_IDLE state, a UE shall follow the measurement parameters defined for cell reselection specified
by the E-UTRAN broadcast.
In RRC_CONNECTED state, a UE shall follow the measurement configurations specified by RRC directed
from the eNB.
They are Intra-frequency neighbour (cell) measurements and inter-frequency neighbour (cell)
measurements (The UE should not be assumed to be able to carry out such measurements without
measurement gaps.)

3 Mobility in LTE
3.4 Intra-LTE Inter-Frequency Mobility

Mobility in RRC idle or RRC connected mode
Intra eNodeB
Inter band
Inter freq HO
800 MHZ
2,6GHZ
2,6GHZ
Inter eNodeB
Intra band
Inter freq HO
Inter eNodeB
inter band
Inter freq
HO
2,6GHZ
1 1 31
The Intra-LTE Inter-Frequency Mobility is supported on FDD and on TDD systems (respectively
FDD<>FDD and TDD<>TDD).
It concerns mobility of multi-frequency/band UE (in RRC IDLE or RRC-CONNECTED state) moving
from a cell operating at a LTE frequency to another cell operating at a different LTE frequency within or
in a different frequency band.
The two LTE cells operating at different carrier frequency can be either collocated or adjacent (intra or
inter-eNodeB).
This feature in LA3.0/TLA3 covers :
z Intra-eNB inter- FDD frequency, same band handover
Inter-eNB inter- FDD band handover
z Intra-eNB
inter-TDD frequency, same band handover

Inter-eNB inter-TDD frequency, same band handover
No inter-freq inter-band HO in TDD
This feature eases the deployment scenarios where different frequency carriers are used in different
regions (markets) for coverage purposes.
In addition, higher user capacity can also be achieved using multiple frequency carriers in the same
region.
Regarding mobility between different frequency layers (i.e. between cells with a different carrier
frequency), UE may need to perform neighbour cell measurements during DL/UL idle periods that are
provided by DRX or packet scheduling (i.e. gap assisted measurements).

3 Mobility in LTE
3.5 supported IRAT Mobility in FDD

UE is idle
UE connected
LTE coverage lost
No PS HO support
Data session ongoing

coverage lost
LA4.0
W or w/o NACC
LTE
GSM
LTE
GSM
Cell reselection
LTE UMTS
LTE
LTE UMTS
LTE
CDMA
LTE UMTS
Cell redirection
PS HO
CSFB
CDMA
Data continuity
Mobility in idle
1 1 32
LA3.0
EUTRAN-to-UTRAN Cell reselection and Redirection and PS Handover
EUTRA-to-GERAN Cell Reselection and Redirection
EUTRA-to-GERAN PS mobility via Network Assisted Cell Change (NACC) procedure.
CS Fallback to GERAN for Voice Calls
HRPD to LTE mobility, UE in idle state
LTE to HRPD mobility : cell reselection and redirection
LA4.0
CS Fallback to 1XRTT for Voice Calls : Dual receiver UE Standard based solution. The Dual-receiver
solution includes a UE that is capable to camp on both LTE and CDMA 1X RTT mode simultaneously. The
UE autonomously selects LTE for data services and CDMA 1XRTT circuit domain for voice
LTE and 1xRTT cell reselection

3 Mobility in LTE
3.5 supported IRAT Mobility in FDD [cont.]

Circuit switched (CS) fallback : mobility of UE from LTE network to a different RAT
(UTRAN, GERAN, 1xRTT) that supports CS voice service when a CS voice call needs
to be set up.
LTE
GSM
Data session suspended
LTE
LTE
CDMA

CSFB
UMTS
Voice continuity
1 1 33
Cell reselection
Cell redirection
PS HO

LA4.0
3 Mobility in LTE
3.6 supported IRAT Mobility in TDD

TLA3.0
UE is idle
UE connected
LTE coverage lost
No PS HO support
Data session ongoing

coverage lost
Cell reselection
Cell redirection
PS HO
CSFB
W or w/o NACC
TD-LTE
TD-LTE
GSM
UMTS
TD-LTE
GSM
TD-LTE
Mobility in idle
LTE
UMTS
TD-LTE
UMTS

UMTS
Voice continuity
Data continuity
1 1 34
LTE
GSM
D t
ti
it
This slide shows eUTRAN (TDD) to UTRAN (TDD) mobility only. UMTS in TDD is also called TD-SCDMA.
TLA2.0 :
eUTRAN to GERAN Inter-RAT Mobility Cell Reselection and redirection LA2.0
LTE to TD-SCDMA PS HO
TLA3.0 :
CS Fallback to UTRA for Voice Calls
CS Fallback to GERAN for Voice Calls
EUTRA-to-GERAN Inter-RAT Mobility NACC
LTE to TD-SCDMA cell reselection and redirection
TDSCDMA to eUTRAN IRAT PS Handover


Which sentences describe Intra-LTE Inter-Frequency Mobility?
HO from band 800MHZ (FDD) to band 2,1GHZ (FDD)
HO from band 800MHZ (FDD) to band 800MHZ (FDD)
HO from band 800MHZ (FDD) to band 2,3GHZ (TDD)
Which sentences describe Intra-LTE, intra band, Inter-Frequency Mobility?

HO from band 800MHZ (FDD) to band 2,1GHZ (FDD)
HO from band 800MHZ (FDD) to band 800MHZ (FDD)
HO from band 800MHZ (FDD) to band 2,3GHZ (TDD)
1 1 35

1 1 36


Public Warning systems are used to broadcast public warnings and
emergency messages during events such as natural disasters. It exists 2
variant of PWS :
Earthquake and Tsunami Warning system (ETWS) used in Japan,
Commercial Mobile Alert System (CMAS), used in Americas.
Alcatel-Lucent solution supports CMAS .

CMSP
LTE-Uu
UE
SBc
S1-MME
eNodeB
Gouvernent
MME
CBC
CMSP GW
Alert GW
CMSP :Commercial Mobile Service Provider

LA4.0
1 1 37
CMSP GW CBC interface defined by ATIS Spec.

CBC MME : SBc interface defined in 3GPP TS 29.168
3GPP TS 36.413 : S1 Application Protocol (S1AP)
3GPP TS 36.331 : Radio Resource Control (RRC); Protocol specification
3GPP TS 22.268 : Public Warning System (PWS) requirements
Commercial Mobile Alert System (CMAS) is used to send emergency alerts as text messages to CMAS
capable handsets.
The CMAS network will allow the Federal Emergency Management Agency (FEMA), to accept and
aggregate alerts (several levels defined : Presidential, Imminent Threats and Child Abduction
Emergency / AMBER Alerts.
The alerts are sent over a secure interface to participating commercial mobile service providers (CMSPs)
that will then distribute the alerts to their users.
The CMSP Gateway interfaces to the Federal Alert Gateway for application-dependent functions, and it
interfaces with the carrier network for technology-dependent functions.
The CBC determines the impacted network elements for CMAS alerts and manages the transmission and
retransmission of the alerts received by the CMSP Gateway.
Cell Broadcast Center (CBC) and CMSP Gateway functions are both supported by ALU 5140 BMC product.
The MME selects the appropriate eNBs based on information provided by the CBC and forwards the
messages to the selected eNBs. The eNB performs the transmission and re-transmission of CMAS
notifications over the air interface.
The eNB uses enhanced RRC Paging to alert CMAS-capable UEs of the presence of CMAS notification
broadcast in the eUTRAN (CMAS messages are broadcasted on SIB12).

4.1.1 CMAS principles
CMAS messages are transmitted using control plane signaling only, no user plane
bearer is required.
y Write-replace Warning Req./resp. messages and Stop Warning req/resp. messages
are used between the CBC and the MME
y Write-replace Warning Req./resp. and Kill req./resp. are used between the CBC
and the MME.
On CMAS indication reception
the UE acquires SIB12
3
CMAS indication
On Paging Control channel
Write-replace req.
Write-replace req.
2
CMAS Notification
On SIB12
Write-replace resp.
eNodeB
Write-replace resp.
MME
CBC
The UE can then retrieve

CMAS messages
1 1 38
The purpose of the Kill procedure is to cancel an already ongoing broadcast of warning
message.
E-UTRAN initiates the paging procedure : The PAGING message is used to inform CMAS (Commercial
Mobile Alert System) capable UEs (RRC_IDLE or RRC_CONNECTED UE) about presence of CMAS
notifications : cmas-Indication is included in the PAGING message transmitted on PCCH PCH
PDSCH channels.
Paging is realized on Logical Channel PCCH & Transport Channel DL-SCH. CMAS-indication is transmitted
in every Paging Occasion at the start of the CMAS transmission.
The UE reads SIB1 to know when SIB12 is scheduled (silent SIB1 update).
The UE re-acquires SIB12 immediately to retrieve CMAS-notification (SIB12 BCCH DL-SCH
PDSCH), that contains a CMAS message (or message segment).

1 1 39

5.1 Beamforming
Multiple transmit antennas are used to form a beam towards one user. This realized
by controlling the phase and the amplitude of the antenna dipoles separately.
Beamforming is performed only on the eNodeB side (DL).
RF
module
BBU
1 1 40
Multiple transmit antennas can be used to shape the overall antenna beam in the direction of a target
receiver. In general, such beamforming can increase the signal-strength at the receiver in proportion to the
number of transmit antennas.
The overall transmission beam can be adjusted in different directions by applying different phase shifts to
the signals to be transmitted on the different antennas. The adjustments are generally based on estimates
of the direction to the target mobile terminal derived from feedback measurements.
In general, the different multi-antenna techniques are beneficial in different scenarios. As an example, at
relatively low SINR, such as at high load or at the cell edge, spatial multiplexing provides relatively limited
benefits. Instead, in such scenarios, multiple antennas at the transmitter side should be used to raise the
SINR by means of beam-forming. On the other hand, in scenarios where there already is a relatively high
SINR, raising the signal quality further provides relatively minor gains. In such scenarios, spatial
multiplexing should be used instead in order to fully exploit the good channel conditions and increase the
rate. The multi-antenna scheme used is under control of the eNB, which therefore can select a suitable
scheme for each transmission

5.1 Beamforming [cont.]

Beam Forming is operated with broadband dual polarization smart antennas.
These antennas are 2 x 4 array cross polarized antenna panel with calibration port.
TLA3.0 supports 8x antenna beamforming using TD-RRH8x5-26 module.
Sector 1
2x4 Array crosspolarized antenna

8 ANT TX/RX
RF module RRH
1 1 41
TD-LTE 2.6GHZ eNodeB Configuration needs a d2UV5 for the 8-antenna beamforming application:
1eCCM-U + 2 bCEMs for 3x15MHz sectors with 8-antenna Beamforming;
1eCCM-U + 3 bCEM for 3x10MHz sectors with 8-antenna Beamforming;
1eCCM-U + 1 bCEM for 3x5MHz sectors with 8-antenna Beamforming
1eCCM-U + 1 bCEM for 6x5MHz sectors with 8-antenna Beamforming;

5.2 eMBMS
e-MBMS (Multimedia Broadcast Multicast System) is transport feature to send the

same content to a given set of users.
Content provider data
Tight synchronization
needeed on
eNodeB
BM-SC
MBMS GW
eNodeB
MCE
UE
Allocates radio
ressources
UE sees group of cells as a

single cell : the MBSFN area
eNodeB
1 1 42
SYNC protocol used to manage

timing and packet loss
e-MBMS provides Broadcast and multicast transport services, ie. unidirectional point-to-multi-point
transmissions of multimedia data. One of the main benefits of eMBMS is the resource savings in the
network as a single stream of data may serve multiple users (all for broadcast services, a set of
subscribers for multicast services).
eMBMS transmissions can be :
z
A single cell transmission, MBMS is transmitted on the coverage of a single cell
zA
multi-cell transmission. The terminal can combine multiple signals from multiple synchronized cells
as multi-path transmissions. This transmission scheme is called Multimedia Broadcast multicast
service over a Single Frequency Network (MBSFN). A MBSFN requires content-synchronized and
time-synchronized set of cells, they compose a MBSFN area. An MBMS service area can be
composed of several MBSFN areas.
The BM-SC (Broadcast Multicast Service Centre) provides the MBMS service to the end user. It is the
entry point for content provider, it assumes authentication/authorization of requesting users and
manages sessions and data functions.
Multi-cell/multicast Coordination Entity (MCE) is a logical entity that allocates the radio resources used by
all eNodeBs in the MBSFN area for multi-cell MBMS transmissions and decides the modulation and coding
scheme.
E-MBMS Gateway (MBMS GW) is a logical entity that :
z sends
content provider data to each eNodeB transmitting the service, using IP Multicast.
z performs
MBMS Session Control Signaling on EPS bearer level.

5.2 eMBMS
5.2.1 eMBMS interfaces

The e-MBMS GW has 3 interfaces :
Sm control plane interface , MBMS Session Control Signaling via MME.
pure userplane M1 interface to eNodeB
SGmb and SGi-mb interfaces to BM-SC
MCE
MME
M3
Sm
BM-SC
SGmb
M2
M1
MBMS GW
SGi-mb
Service
announcement
1
UE
eNodeB
Session
start/stop
2 Service joining
4 Service leaving
1 1 43
M3 Interface between the MCE and the MME is used for eMBMS Session Control Signalling on E-RAB
level including eMBMS Session Start and Stop. M3 is SCTP based.
M2 Interface between MCE and eNB: is used to convey radio configuration data for the multi-cell
transmission and Session Control Signalling. M2 iq SCTP based.
M1 Interface between MBMS GW and eNodeB is a user plane interface used to transport user IP
Multicast flows.
The Subscription phase, for multicast service, links the end-user to the service or content provider to
allow the end-user to receive the multicast service.
The end-users are informed about the available MBMS services during the Service announcement
phase.
They then need to join multicast service (they can then be charged for the multicast data).
Then MBMS session starts : the MBMS bearers are then reserved and established and the data are
transferred to the UE.
The users are then informed, during the the MBMS notification phase, of the upcoming MBMS
sessions.
At Session stop, ressources are released by the network. The user indicates that he no longer wants to
subscribe to the session in the leaving phase.

5.2 eMBMS
5.2.2 eMBMS Alcatel-Lucent solution, phase 1

OMC
5620 SAM
Operator
command to
start MBMS
service
Operator command to request

BM-SC to start data transfer
related to the service to the
service session
MCE
M2
TLA3.0
BM-SC
SGmb
M1
SGi-mb
UE
eNodeB
User
MBMS GW
MCE entity included

in eNodeB
Control
5910 MiTV
1 1 44
M1 interface is 3GPP release 9 compliant.

There is no special mobility procedures to support eMBMS continuity.
Service announcement (Electronic Service Guide) is generated by 5910 MiTV on an eMBMS broadcast
service using eMBMS bearer with constant bit rate of 256Kbps.
Session start should be initiated by BM-SC when ready to send data for a MBMS service. It should also
ensure session stop to release associated bearer ressources in downstream nodes. In a first phase, OAM
commands to start/stop MBMS sessions will be used instead on 5620 SAM and on MiTV EMS.
-On 5620 SAM, the start command allows the radio bearers and M1 transport layer to be setup.
-The start command is then issued on MiTV EMS and the data transfer starts for this session.
Then, the session is stopped first on MiTV EMS and after on 5620 SAM.
All the necessary information for the eMBMS service is pre-provisionned in the eNodeB and MiTV. For
example, the multicast IP flow is characterized by a GTP-U C-TEID and an multicast destination IP
address. The MBMS-GW marks the M1 Ip traffic with provisonned DSCP value.
A MBSFN area is composed of a group of cells. All enodeB involved in the MBSFN area use the same
radio frequency and have the same MBMS radio ressource allocation. This radio ressource allocation is
statically configured in phase 1.
MTCH and MCH channels are used for radio transmissions.
Layer 1 timing synchronization on the different cells is realized thanks to GPS in TLA3.0. BM-SC should
also be synchronized to a GPS source to provide timing accuracy for content synchronization for multi-cell
transmissions.

End of module
LTE eUTRAN Overview
1 1 45

12
Section 1
Overview
Module 2
LTE Transport overview
9400 LTE

Blank page
122
RAN TLA3.0-LA4.0 Technical Overview LTE Transport overview

Document History
Edition
Date
Author
10
2012-02-01
Vincent, Cecile
Remarks

Module objectives
Describe the eUTRAN transport architecture,
Explain the Ethernet and IP eNodeB transport configuration (i.e., VLAN, IP
addressing and IP Security (IPSEC),
Explain the eNodeB SCTP configuration and timers,
Describe IP Quality of Service (QoS) mechanisms used on LTE transport
network,
Describe synchronization solution for eUTRAN.
123

124

Table of Contents
1 Transport Network Requirements
1.1 End-to-End IP
2 Traffic Aggregation
2.1 Aggregation with 7705 SAR-F
2.2 7705 SAR-F
3 VLANs
3.1 eNodeB VLAN overview
3.2 Third VLAN in TDD configuration
4 IP addressing
4.1 IPv4 Addressing
4.2 IPv6 addressing
4.3 IPv6 configurations
4.4 DHCP process
5 IPSec
5.1 UE Security
5.2 IPSec LTE configurations
5.3 IPSec LTE Policies
6 SCTP Protocol
6.1 STP associations
6.2 SCTP Multi-homing
6.3 SCTP Timers
6.4 SCTP Failover Time Tuning
7 QoS
1 2 5 7.1 Introduction
RAN TLA3.0-LA4.0
LTE QoS
Transport parameters
overview
7.2 Technical
EPS Overview
bearer
7.3 QoS mapping on transport network
7.4 eNodeB traffic Management
7.5 eNodeB UL traffic Shaping
7.6 eNodeB Call Admission
8 Synchronization
8.1 Synchronization overview
8.2 Synchronization need for Handover
8.3 Synchronization need for TDD systems
8.4 Possible solutions
8.5 SyncE Principles
8.6 PTP principles

Page
7
8
9
10
11
13
14
16
20
21
22
23
26
28
29
32
34
38
39
40
41
42
45
46
47
48
50
51
53
55
56
57
58
59
61
62

126

Page
127

1.1 End-to-End IP
EUTRAN + EPC + Backhaul + Backbone = All-IP service delivery
Real-time, multiservice, high-bandwidth, end-to-end QoS
Traffic segregation
VLAN
QoS Management
DiffServ
IP Communications
(VoIP, Video)
Messaging SMS/MMS
Internet, Web 2.0
Advanced Location-based
Services
Mobile TV, IP Multimedia
Mobile office
Service Delivery Platforms
IP channel
SGW
eNode B
Synchronization
IP Backhaul
Aggregation of sites
traffic
128
MME
PCRF
PDN GW
Evolved Packet Core

(IP)
Security
Traffic Encryption and
authentication
LTE network is based natively on IP : all services are carried over IP from the mobile to the service
network.
LTE requires high data rates and offers a larger number of services that requires different QoS treatments
(real time services with low delay, guaranteed bit rate, low error rate ): as a consequence the transport
network needs to support high capacity and QoS management capabilities.
The transport network carries telecom traffic (signaling and user data), OAM traffic and Debug traffic. All
these types of traffic has to be separated in the transport network using VLANs.
The different natures of data (control plane traffic like signaling, or userplane data like internet, voice, video
traffic) have different constraints in terms of delay, error rate and bit rate. The transport network takes
them into account to ensure the services.
The eNodeB need to be synchronized (air interface requirement). This synchronization can be received from
the GPS or from the transport network. In this last case, the tranport network needs to be able to carry
synchronization data.
2G, WCDMA or CDMA BTS can be collocated to LTE eNodeB on site. The transport network is then used to
aggregate and backhaul the traffic to the core networks.
For security reasons, one or several eNodeB interfaces should be protected: eNodeB traffic could be
authenticated and even encrypted using IPSEC.

129

2.1 Aggregation with 7705 SAR-F

3G/LTE NodeB Cabinet
3G
NodeB
nxE1
(ATM)
LTE
eNodeB
SGW
GE
MME
PCRF
PDN GW
Evolved Packet Core
7705 SAR-F
IP Backhaul
CSA
RNC
UTRAN
1 2 10
3G and LTE can share the same site to provide 3G and LTE coverage on an given area. 3G and LTE traffic
can be aggregated on the same transport network using a 7705 SAR called a CSA (Cell Site Aggregator).
3G traffic can be ATM or IP traffic depending on the 3G release.

2.2 7705 SAR-F

The 7705 SAR-F is integrated in LTE solution as Cell Site Aggregator (CSA).
It multiplexes the different types of traffic (ATM & IP) over the IP Mobile
Backhauling network.
It can be connected to an MPLS transport network.
1 2 11
In the Alcatel-Lucent implementation the 7705 SAR-F is integrated in LTE solution as Cell Site Aggregator
(CSA). It allows to multiplex the different types of traffic (ATM & IP) over the IP Mobile Backhauling
network.
z The
7705 SAR is MPLS capable, so it can be connected to a MPLS transport network. In this case, the
Ethernet eNodeB traffic is carried over MPLS, in a so called Ethernet pseudowire or epipe.
z The
Alcatel-Lucent 7705 Service Aggregation Router (SAR) is optimized for multiservice adaptation,
aggregation and routing, especially onto a modern, economical Ethernet and IP/MPLS infrastructure.
Leveraging the powerful Service Router Operating System (SR OS) and 5620 Service Aware Manager
(SAM), it is available in compact, low power consumption platforms delivering highly available services
over resilient and flexible network topologies. Strong Quality of Service (QoS) capabilities ensure
service-level awareness and the management of multiple traffic streams. The 7705 SAR is well suited
to the aggregation, backhaul and routing of 2G, 3G and LTE mobile traffic providing cost-effective
scaling and the transformation to IP/MPLS networking


Which of these equipment do you choose to aggregate ATM and IP traffic on
radio site:
7705 SAR
7750 SR
7450 ESS
1 2 12

3 VLANs
1 2 13

3 VLANs
3.1 eNodeB VLAN overview

VLANs are used to separate different nature of traffic.
The eNodeB supports following configurations :
No VLAN configuration
GigE
S1
X2
IPV4 addressing only
OAM
One VLAN for all traffic
GigE
VLAN
S1
X2
OAM
VLAN tagging used to carry L2 QoSpriority

1 2 14
There are two main reasons for the development of VLANs:

z the
amount of broadcast traffic
z increased
security
Broadcast traffic increases in direct proportion to the number of stations in the LAN. VLANS are used to
create isolated of groups of devices so broadcast traffic of one group does not impact another group.
VLANs also provides a basic security function, separating the network into distinct logical networks. Traffic
in one VLAN is separated from another VLAN as if they were physically separate networks. If traffic is to
pass from one VLAN to another, it must be routed.
The IEEE 802.1Q standard defines tagging for Ethernet frames, additional bytes (called tag) contain implicit
VLAN membership information.
When Ethernet frames are tagged with VLAN membership, the frame header that contains the additonal
bytes also contains a3-bit field for Ethernet user priority. This field determines the packet network
treatment priority (802.1p) and may be used to implement the transport QoS in the case of an L2-switched
backbone network.
At Integration and commisionning,the eNodeB is pre-configured with a default OAM VLAN ID value of 400.

3 VLANs
3.1 eNodeB VLAN overview [cont.]

Two VLANS with 802.1Q tagging with :
y OAM VLAN for the OAM and synchro traffic
y Telecom VLAN for S1 and X2 interfaces.
S1
GigE
Telecom
VLAN
X2
OAM
VLAN
Four VLANS with 802.1Q tagging with (IPV4 only):

y OAM VLAN for the OAM
y OAM VLAN for synchro traffic
y One VLAN for control plane traffic
y One VLAN for user plane traffic.
OAM
OAM VLAN
GigE
1588 VLAN
CP VLAN
UP VLAN
1 2 15
No IPSEC is supported in the 3 vlans configuation with S1, X2 and OAM VLans.

LA4.0
3 VLANs
3.2 Third VLAN in TDD configuration

TDD eNodeB supports an additional VLAN configuration :
TLA3.0
Three VLANS with 802.1Q tagging with :

y OAM VLAN, TELECOM VLAN and M1-U VLAN
Or
y OAM VLAN, S1 VLAN and X2 VLAN
OAM VLAN
S1 VLAN
GigE
OAM VLAN
GigE
X2 VLAN
1 2 16
S1 VLAN
M1-U VLAN
IEEE 1588v2 dedicated IP address cannot be used in conjunction with eMBMS traffic (M1-U interface).
M1-U must be mapped on a dedicated eNodeB VLAN and not in 1 and 2 vlans config.
eMBMS is a donwlink multicast traffic, no uplink eMBMS traffic originates from eNodeB.

3 VLANs
3.2 Third VLAN in TDD configuration [cont.]

The third VLAN can be deployed for eMBMS Multicast trafic.
There is no IP address on this third VLAN for M1-U interface as it concerns
only downlink traffic.
IPv4
TLA3.0
MME
5620 SAM
IPv4
OAM VLAN
GigE
Telecom VLAN
M1-U VLAN
SGW
MBMS-GW
1 2 17
IEEE 1588v2 dedicated IP address cannot be used in conjunction with eMBMS traffic (M1-U interface).
M1-U must be mapped on a dedicated eNodeB VLAN and not in 1 and 2 vlans config.
eMBMS is a donwlink multicast traffic, no uplink eMBMS traffic originates from eNodeB.


What are the benefits of VLAN?
The use of VLANs optimizes the broadcast traffic by reducing the broadcast
domains
The use of VLANs can support QoS deployment strategy.
The use of VLANs provides basic security fucntions.
1 2 18


Which of the following are valid VLANs configurations :
One VLAN for UP, one VLAN for CP, one for OAM
One VLAN for S1, one for X2, one for OAM
One VLAN for X2 + S1, one for OAM
In LA4.0 what is the maximum number of VLANs supported by the

eNodeB?
2
3
4
OAM VLAN can be used for:

OAM traffic only
OAM and SynchE traffic
OAM and sync 1588v2 traffic
1 2 19

4 IP addressing
1 2 20

4 IP addressing
4.1 IPv4 Addressing

IPv4 is supported over all VLANs configurations.
the enodeB supports :
One optional dedicated 1588v2 IPv4 address for synchronization,
One IPv4 address for both OAM and Telecom traffic
Vlan
configuration
Possible IP configuration
No VLAN
One IPv4@ for OAM and One IPv4@ For Telecom
1 VLAN
from 1 to 3 possible IPv4@ for OAM, 1588v2 and Telecom
2 VLANs
from 1 to 2 possible IPv4@ for OAM

and 1588v2
3 VLANS (TDD only)
from 1 to 2 possible IPv4@ for OAM
1 IPv4@ For Telecom

1 IPv4@ For S1
Telecom traffic
1 IPv4@ For X2
Telecom traffic
3 VLANS (TDD only)
one IPv4@ for OAM
1 IPv4@ For Telecom
no IP @ for M1-U
traffic
4 VLANS
One IPv4@ for

One IPv4@ for 1588v2
OAM
1 IPv4@ For user

plane
(S1-U + X2-U)
1 IPv4@ For control

plane
(S1-C + X2-C)
1 2 21
S1 and X2 interfaces corresponds to Telecom traffic.

As eNodeB uses the private IPv4 192.168.0.0/16 prefix for internal addressing, this subnet must not be
used for telecom or OAM addressing.
OAM IP address can be set manually during eNodeB commissioning or can be distributed by a DHCP server.
Telecom address is then provisonned by the NM during commissioning phase. This process is part of SON,
self-organization Network, please refer to SON dedicated chapter.
The Telecom gateway is set thanks to the provisioning of a Telecom first hop router which is used as the
default route within eNodeB routing table.
eNodeB OAM first hop router configuration is done at Integration and commisionning.

4 IP addressing
4.2 IPv6 addressing

The eNodeB supports :
IPV6 Telecom address
one IPv6 address on OAM vlan if 1588v2 dedicated IP address is not used
either IPv4 or IPv6 addresses are supported on one VLAN
Vlan
configuration
Possible IP configuration
1 VLAN
2 IPv6 @ one for OAM and one for Telecom
2 VLANs
One IPv6@ or OAM
One IPv6@ for Telecom
2 VLANs
from 1 to 2 possible IPv4@ for

OAM and 1588v2
One IPv6@ for Telecom
3 VLANS (TDD only)
from one to 2 possible IPv4@ for

OAM and 1588v2
1 IPv6@ For S1
Telecom traffic
1 IPv6@ For X2
Telecom traffic
3 VLANS (TDD only)
One IPv6@ or OAM
1 IPv6@ For S1
Telecom traffic
1 IPv6@ For X2
Telecom traffic
1 2 22

4 IP addressing
4.3 IPv6 configurations

As either IPv4 addresses or IPv6 addresses are supported in a VLAN, 2 VLANS
must be configured to mix IPv4 and IPV6 addresses.
NM
IPv4
O&M network
MME
UE
GigE
IPv4
OAM VLAN
Telecom VLAN
Backhauling
network for
Telecom
1 2 23
IPv6
SGW
Either IPv4 addresses or IPv6 addresses are supported in a VLAN. It is not possible to have simultaneously
IPv4 and IPv6 addresses in a VLAN.
The eNodeB will be able to transmit IPv4 and IPv6 packets on one Ethernet port using 2 VLANs : one for
Telecom traffic and one for OAM traffic.
Configuration with IPv6 OAM IP address and IPv4 Telecom IP address is not supported.

4 IP addressing
4.3 IPv6 configurations [cont.]
5620 SAM
IPv6
GigE
MME
VLAN
SGW
One IPv6@ for OAM and

one IPv6@ for
Telecom
IPv6
MME
5620 SAM
IPv6
GigE
OAM VLAN
Telecom VLAN
SGW
1 2 24
eNodeB does not support dual IP stack.

OAM IP address can be set manually during eNodeB commissioning or can be distributed by a DHCP server.
DHCPv6 is used to retreive OAM IPv6 address.
Telecom address is then provisonned by the NM during commissioning phase.
The no VLAN configuration is not supported in IPv6, IPv6 traffic is carried over tagged Ethernet frames.
IPv6 does not support the 1588v2 can be carried over a dedicated IP address when IPv6 is deployed.
Configuration with one OAM IPv6 address and one IPv4 telecom address is not supported.

4 IP addressing
4.3 IPv6 configurations [cont.]

In 3 VLANS configuration, both S1 and X2 interfaces uses IPv6 addresses.
IPv6 or
IPv4
MME
5620 SAM
IPv6
OAM VLAN
GigE
S1 VLAN
X2 VLAN
SGW
OAM VLAN
GigE
S1 VLAN
IPv6
X2 VLAN
1 2 25

4 IP addressing
4.4 DHCP process

The OAM IP address and subnet mask may be manually configured
if not, the EnodeB starts a DHCP process to retrieve an OAM IP
configuration.
eNodeB broadcasts
DHCP
1
messages to
request an IP
configuration
5620 SAM
NM sends config.
including IP
3
configuration
DHCP Server
At next restart,
eNodeB uses
stored IP
4
configuration :
DHCP process no
more used
DHCP server sends

back IP
2 configuration
1 2 26
When the eNodeB first starts, if no OAM IP address has been set at Integration and configuration step,
the eNodeB triggers a DHCP procedure to get an IP address.
The DHCP server has a static database that associates eNodeB identification received in the request
(eNodeB serial number associated with LTE keyword) with its static reserved IP address.
In the same time, eNodeB has been provisionned in 5620 SAM database and so 5620 SAM polls the IP
address of the eNodeB. So, once the eNodeB is up, the OAM connection with the eNodeB is setup. The
5620 SAM sends its configuration to the eNodeB, including the OAM IP address (that should be the same
that the one retrieved by the DHCP server). At next restart, the eNodeB will use the NM configuration and
will not use anymore DHCP process.
The eNodeB identifier is the eNodeB serial number, the serial number is linked to the cabinet serial
number in the FAN tray.
eNodeB requests for an infinite DHCP lease.
If VLAN tagging is enabled then the DHCP messages are transported within the OAM VLAN.
DHCPv4 and DHCPv6 are supported.


Which of the following are valid IP configurations :
One 1588v2 IPv6 address + one OAM IPv6 address on OAM VLAN,
One IPv4 OAM address + one IPv6 Telecom @ on one VLAN,
One IPv4 OAM address + one IPv6 Telecom @ on two VLANs,
One IP address for S1 traffic + one IP address for X2 traffic + one IP address
for OAM + one IP address for 1588v2 using a 4 vlan configuration
1 2 27

5 IPSec
1 2 28

5 IPSec
5.1 UE Security
After UE authentication, the UE communications are secured on air interface :
Signaling Radio bearer are authenticated and encrypted
Data Radio Bearer are encrypted
S1 MME
MME
RB
S1-U
SRB
UE
SGW
Secured
unsecured network
or unsecured eNodeB location
Use IPSEC
1 2 29
Security Requirements :
Flat architecture:
z
All radio access protocols terminate in one node: eNodeB
IP protocols also visible in eNodeB
Security needed due to :

z
Architectural design decisions
Interworking with legacy and non-3GPP networks
z eNodeB
z
located in untrusted locations
New business environments with less trusted networks involved
As a result (when compared to UTRAN/GERAN):

z
Extended Authentication and Key Agreement
More complex key hierarchy
z Additional
security for eNodeB (compared to NB/BTS/RNC)

The following comments explain some general IPSEC concepts.

Internet Protocol Security (IPsec) is a protocol suite for securing IP communications.
It ensures IP packet integrity check and ciphering for a given communication session.
IPsec includes protocols for establishing mutual authentication between peers and for negotiation of
cryptographic keys to be used during the session.
IPSEC can operate between a pair of hosts (host-to-host), a pair of security gateways (network-tonetwork) or a security gateway and a host (network-to-host).
IPsec uses AH and/or ESP protocols to provide data integrity check, data origin authentication, anti-replay
protection or data encryption.
Security Associations (SA) contains the bundle of algorithms and data necessary for IPSEC operations for a
given session in a given direction.
In addition, various configurations and protocls can be used to initiate the IPSEC operations between peers
(authentication of peers and key exchanges), this can be realized by pre-shared secret configuration on
both peer or using one protocol like IKEv2 for example.
For each IP flow that needs to be protected, there is a SA that is associated. Each IP packet will be
matched against the flow characteristic and the corresponding SA will be applied, for outgoing packet to
protect the flow and for incoming packets to check and de-cipher the IP packet.
In LTE environment, tunnel mode with host-to-network communications are used.
The host is the eNodeB and the network element is called the Security Gateway.The entire incoming IP
packet is encrypted and/or authenticated and then encapsulated into a new IP packet with a new IP
header. The outgoing packet that needs to be protected is encapsulated into a new IP packet, this is the
tunnel principle.
new IP header, adds an IPSEC header and encapsulates
the protected original IP packet
2
NEW IP header
Sce IP C | dst IP D
Sce IP C | dst IP D
Sce IP C | dst IP D
Tunnel 2
Tunnel 1
For IP address pair (Sce IP & dst IP)

use tunnel 2
check and de-capsulate IP packet

Tun
nel
3
The original IP header (in green) is built using inner IP addresses.

The NEW IP header is built using outer IP addresses, they are routed on the unsecured network.
5 IPSec
5.1 UE Security [cont.]

IPSEC is used to secure the transport network on S1 interface.
LA4.0
S1 MME
MME
Security Gateway
(SEG)
S1 MME
RB
UE
S1-U
S1-U
SRB
Secured
Secure
IPSEC tunnel
Secure
IPSEC tunnel
SGW
Hub and Spoke architecture :

all tunnels for all nodes end at Security Gateway Node
1 2 31
To activate the eNB to SEG IPsec feature the customer need to purchase a Software License. Licensing is
offered in a per eNodeB basis.
Spokes are eNodeB, MME and SGW. Hubs are the SEGs that terminate all the IPsec tunnels. Spokes can
connect via IPsec tunnels only with hubs, while hubs can connect with spokes and other hubs.
In this Hub and Spoke architecture, the X2 traffic from an eNodeB to another eNodeB must enter the IPsec
tunnel to the SEG from eNodeB to SEG and then from SEG to destination eNodeB.

5 IPSec
5.2 IPSec LTE configurations

Up to 2 tunnels can be configured, and a maximum of one IPSEC tunnel per VLAN
is supported.
NM
O&M network
MME
OAM traffic
ePC
Telecom traffic in
IPSEC tunnel
SEG
SGW
Configuration example with one IPSEC tunnel.

A second tunnel could be deployed between eNodeB and 5620 SAM
1 2 32

5 IPSec
5.2 IPSec LTE configurations [cont.]

traffic is protected into one
IPSEC tunnel
SEG
GigE
VLAN
All traffic is protected using

one IPSEC tunnel
SEG
GigE
Telecom
VLAN
With 2 VLANS configuration, 0,1 or 2 IPSEC

tunnels can be deployed
1 2 33
GigE

OAM
VLAN
SEG
5 IPSec
5.3 IPSec LTE Policies

ENodeB supports 3 predefined IPSec policies :
No IPSEc (bypass)
Integrity protection : the traffic is not ciphered but data is protected to avoid
modification
Integrity protection and encryption : the traffic is protected against modification
and is ciphered.
2 different IPSEC policies can be applied for Telecom traffic

One policy applied on userplane (S1-U and X2-U)
One other applied on controlplane (S1-C and X2-C)
Telecom
VLAN
S1-U + X2-U
S1-C + X2-C
GigE
Example
OAM
VLAN
1 2 34
OAM
SEG
IPSEC policies can be defined to fine tune the protection depending on the trafffic flows : 2 different IPSEC
policies can be applied for Telecom traffic using the 2 VLANS configuration:
z One
policy applied on userplane (S1-U and X2-U)
z One
other applied on controlplane (S1-C and X2-C)
IPSEC policies are like rules :

If the traffic matches an IPSEC policy condition (i.e. traffic is OAM or Telecom or S1-C+X2-C or S1-U+X2-U)
then the associated protection is applied (none or integrity protection or integrity protection + encryption)
and the associated tunnel is used (none or tunnel 1 or tunnel 2).

What are IPSEC policies in enodeB?

IPsec policies are used in the eNodeB for inbound and outbound traffic to determine if a flow should be
sent into the tunnel or not, and what kind of protection should be aplied . Once IPSEC is activated,
IPSEC policies are applied.
IKE rules and IPsec policies in both IPsec peers must match.
Change of IPsec configuration, like change of IPsec policy or the value of some attribute require an
eNodeB reboot.
As an example, following diagram illustrates the 3 possible IPSEC policies options in LA2.0 (outband
direction only).
IP packets are generated and then, based on the kind of traffic the inner IP address is applied (OAM or
telecom IP address).
The chosen IPSEC policy is then applied to the IP packet. Depending on the policy, the IP packet is not
modified (bypass policy) or is encapsultated into a new IP packet using the outer IP address.
The final IP packet is then sent on the egress VLAN.
1) OAM traffic bypass IPsec (mandatory in LA2.0)
2) In addition, the customer can choose, using NM povisioning per enodeB, if :
z
All telecom traffic (S1 and X2) inbound and outbound bypass IPsec.
S1-C traffic is integrity protected and encrypted, but S1-U and X2 traffic bypass IPsec.
All telecom traffic (S1 and X2)is integrity protected and encrypted by IPsec.
Once IPSEC is activated, one IPSEC policies out of 3 is applied
eNodeB application generates

IP packets
OAM
S1-C
eNodeB application generates IP

packets
OAM
X2
eNodeB application
generates IP
packets
S1-C
X2
OAM
S1-C
X2
S1-U
S1-U
OAM IP@
TEL IP@
IPSEC policies
S1-U
OAM IP@
TEL IP@
OAM IP@
TEL IP@
Outer
IPSEC policies
IP@
OAM
TEL
OAM
TEL
vlan
vlan
vlan
vlan

Outer
IPSEC policies
IP@
OAM
TEL
vlan
vlan
5 IPSec
5.3 IPSec LTE Policies [cont.]

IPSEC can be deployed over an IPv6 transport network.
IPv4 and IPv6 configurations are supported, but inner and outer IP addresses
format are the same.
Inner IP :IPv4
SEG
Inner IP :IPv6
SEG
OR
Outer IP :IPv6
Outer IP :IPv4
1588v2 traffic cant use IPSEC tunnel

SEG
1588v2
1 2 36
Multiple IPsec tunnels can be deployed between one eNodeB and the Security Gateway (SEG). One IPSEC tunnel is
characterized by one pair of IP addresses (eNodeB outer IP@+ SEG IP@).
The inner IP address is the eNodeB Telecom IP address (initially provisioned during commissioning) while the outer IP
address is new and is provisioned together with an outer IP address subnet mask via NM. In addition, NM also
provide the SEG IP address (destination of the tunnel).
The IKE protocol version is IKEv2.
IKEv2 use the following encryption and integrity protection algorithms :
1. 3DES CBC for encryption
2. AES CBC 128 for encryption
3. HMAC-SHA1-96 for integrity protection and authentication
IKE authentication between the eNodeB and the SEG is performed using pre-shared secret keys. These secret is
provisioned in the eNodeB (via NM) and in the SEG.
The SEG can be any IPsec gateway supporting IPSEC IKEv2 standard protocols.
IPSEC is supported on various VLAN topologies, using IPv4 or IPv6 addresses format :
z
OAM and Telecom have the same IPv4 address.
z
OAM and Telecom interfaces have different IPv4 addresses, in the same or different VLANS
z
OAM and Telecom interfaces have different IPv6 addresses, in the same or different VLANS
z
OAM (IPv4) and Telecom (IPv6) interfaces have different address schemes (in different VLANS)
IPSEC is not supported on the 3 VLANS configuration (OAM, S1 and X2 vlans).


How many IPSEC tunnels can be setup on an eNodeB ?
What are the benefits of the use of IPSEC on eNodeB?
Improved performance on backhauling network

Enhanced security for eNodeB located in untrusted locations
data integrity is guaranteed
Radio traffic is ciphered
Which equipment is the IPSEC peer of the eNodeB :
The
The
The
The
serving Gateway,
PDN Gateway
MME
Security Gateway
1 2 37

6 SCTP Protocol
1 2 38

6 SCTP Protocol
6.1 STP associations

SCTP transport protocol is used between eNodeB and peer to carry
S1-AP or X2-AP messages. Among oters, it provides :
Heartbit mechanism for failure detection
Multi-homing defense mechanisms
Data exchange with retransmission
X2-AP
2
ort 3642
tion on p
ia
oc
ss
a
SCTP
IP@1
SCTP association on port 36412
IP@2
IP@3
MME
S1-MME
SCTP associations are created between SCTP endpoints, ie between at

least a pair of IP addresses.
1 2 39
The eNodeB maintains management of the SCTP association retransmission timer.

sctpAccessAssociationMaxRetrans defines the maximum number of retransmissions a data Chunk should
be subjected to if it is not acknowledged.
The sctpAssocHeartbeatInterval defines the delay between successive Heartbeats transmitted by the
SCTP entity over an association when no Data is transmitted. With the HB Acknowledgement it acts
both as a keep-alive and as a linkfailure detector.

6 SCTP Protocol
6.2 SCTP Multi-homing

The ALU eNodeB does not support multi-homing, ie there is only one
local IP@ as SCTP endpoint on the eNodeB.
The ALU eNodeB supports SCTP peer multi-homing.
Several remote IP addresses are provisioned in the eNodeB and the
peer advertises its SCTP IP addresses at association setup.
S1-MME
ONE SCTP association on port
36412
IP@1
MME
IP@3
IP@4
When the eNodeB detects too much retransmissions on the failed

path, it uses another remote IP@ as peer address.
1 2 40
Peer eNB IP addresses can be configured statically by OAM or learned dynamically.

Each eNodeB can discover a peer at any time and initiates SCTP association as soon as the remote IP
address is known. Then, an eNodeB supports being either server or client.
The eNodeB selects one of the multihomed MME or eNB peer IP addresses as Primary. The eNodeB
should always transmit to the primary peer address unless specifically commanded to use an
alternative due to fault conditions.
The sctpAccessPathMaxRetrans parameter defines, in the multi-homed environment, the maximum
number of retransmissions on each path that should be attempted for a Data chunk for which an
acknowledgment has not been received.

6 SCTP Protocol
6.3 SCTP Timers

SCTP Retransmissions are timer-controlled, a dynamic algorithm is used to fine tune
the SCTP RTO timer.
MME
SCTP data
SCTP data ACK
SACK timer
SCTP data retransmission
RTO timer expiracy
SCTP data ACK
RTO timer Doubled
SCTP data retransmission

Retransmissions occur till
Max retransmit value
is reached
Min, Max and Init RTO values can be configured to improve the global behavior of
SCTP. These values are limit values for the calculated RTO value.
1 2 41
Whenever a retransmission timer expires, all non-acknowledged data chunks are retransmitted and the
RTO timer is started again doubling its initial duration (like in TCP). In normal operation, the RTO
value is constantly alculated based on experimented network delay.
The following parameters are introduced in LA4.0:
z sctpSACKTimer - Selective Acknowledgment Timer defines the time to wait before transmitting
Acknowledgement. This parameter tuning helps to save bandwidth as it reduces the number of SACK
messages sent.
sctpRTOMin - Retransmission TimeOut Minimum && sctpRTOMax - Retransmission TimeOut
maximum
These timers defines respectively the minimum/maximum time limit for the Retransmission timer on the
eNodeB. This is used to trigger the retransmission of a Data chunk in response to a lack of receipt of a
SACK acknowledgement from the peer SCTP entity.
The RTO Min parameter has a range of [0...10000] msecs and a default recommended of 1000msecs.
The RTO Max parameter has a range of [0...60000] msecs and a default recommended of 30 seconds.
z
sctpRTOInit - Retransmission TimeOut initial

The RTO Init parameter has a range of [0...10000] msecs and a default recommended of 3000
milliseconds. This value is used for the first calculation of the RTO.
RFC2960/RFC4960 details the algorithm for calculating the RTO within an SCTP end-point. If the
calculated RTO is lower than the RTOmin configuration parameter, the SCTP end-point rounds-up the
value it uses to the configured value. If the SCTP RTO algorithm calculates an RTO which is greater
than the RTOMax configured parameter, then the RTO is truncated to the configured value.

6 SCTP Protocol
6.4 SCTP Failover Time Tuning

SCTP Failure detection time is calculated as illustrated.
Following example is based on RTOmin = 1 sec, RTOmax = 60 secs and PathMaxRetransmits = 5.
data sent
Data retransmissions
1
Timer expiracy &

PathMaxRetransmits reached
PATH failure detection

and SCTP path switchover
T1 T2
T3
T4
T5
T6
T1 = T0 + RTO (with RTO = RTOMin) = T0 + 1 sec.

T2 = T1 + 2 x 1 sec. = T0 + 3 sec.
T3 = T2 + 2 x 2 sec. = T0 + 7 sec.
T4 = T3 + 2 x 4 sec. = T0 + 15 sec.
T5 = T4 + 2 x 8 sec. = T0 + 31 sec.
T6 = T5 + 2 x 16 sec. = T0 + 63 sec.
Total failure detection time = 63 sec

1 2 42
SCTP Failover Time can be tuned using RTO Configuration Parameters.

z
The section discusses the impacts of certain settings for RTOmin, RTOmax and
sctpAccessPathMaxRetransmits.
Example 1
Consider the RFC2960/4960 defaults:
z RTOmin = 1 sec
z RTOmax = 60 secs
z PathMaxRetransmits = 5
z
SCTP Link Failure detection occurs after 5 retries. If the link has settled at RTOmin prior to fault, the
following time is required to detect the link break= 1+2+4+8+16+32 = 63 seconds
The first packet transmission failure has RTO = RTOmin = 1 sec, the first RE-transmission has RTO = 2
secs, the fith RE-transmission has RTO = 32 secs. This aggregate time is a considerable time to detect
a failure of a path and invoke a switchover to an alternate path in a multi-homed environment.
Potentially, the association could be torn-down before a switchover is invoked.

6 SCTP Protocol
6.4 SCTP Failover Time Tuning [cont.]

SCTP Failover Time can be tuned using RTO Configuration Parameters.
Using RTOmin = 120 msec, RTOmax = 500 msecs and PathMaxRetransmits = 5.
data sent
Data retransmissions
1
Timer expiracy &

PathMaxRetransmits reached
Fine Tuning RTOMax and Reducing

global timers values can help
improving Failure detection.
PATH failure detection

and SCTP path switchover
T1 T2
T3
T4
T5
T6
T1 = T0 + RTO (with RTO = RTOMin) = T0 + 120 msec.
T2 = T1 + RTO (2 x 120 msec.) = T0 + 360 msec.
T3 = T2 + RTO (2 x 240 msec.) = T0 + 840 msec.
T4 = T3 + 500 msec. (as RTO = 2 x 480 msec > RTOMax) = T0 + 1,34 sec.
T5 = T4 + 500 msec = T0 + 1,84 sec.
T6 = T5 + 500 msec.= T0 + 2,34 sec.
Total failure detection time = 2,34 sec

1 2 43
Failure detection occurs after 5 retries, which requires the following time if the link is at minimum RTO.
The first failed transmission will have a RTO=RTOmin=0.12sec, the first RE-transmit will be offered
RTO of 0.24 secs for a reply. Due to RTOmax limit, the 3rd, 4th & 5th: RE-transmissions will be given
a RTO=RTOmax = 0.5 secs
total time = 0.12+0.24+0.48+0.5+0.5+0.5 = 2.34 seconds
This is a considerably quicker response to detecting a link break and invoking a switchover.
For MMEs which are multihomed the eNodeB must detect a link failure and switch to the alternate path
sufficiently quickly to prevent the MME tearing down the link.


How many association are used between an eNodeB and a MME ?
Please, complete the sentence :
A ___________ is SCTP peer that uses two IP addresses as SCTP endpoint.
Which of these values is dynamically re-computed during data exchange :
The
The
The
The
SCTP
SCTP
SCTP
SCTP
RTO Min value,

RTO Max value,
RTO value,
Max Retransmit value.
1 2 44

7 QoS
1 2 45

7 QoS
7.1 Introduction
Based on its associated E2E services, an EPS bearer is associated to a set of QoS
parameters, mainly :
QCI,
ARP,
Maximum and Guaranteed bit rate in UL and DL.
ePC
eUTRAN
VoIP (real time)

MME
Internet access (BE)

SGW
PGW
Streaming (Guaranteed bit rate))
1 2 46
EPS network (eUTRAN + EPC) provides EPS bearer between the UE and the PGW.
An EPS bearer/E-RAB is the level of granularity for bearer level QoS control in the EPC/E-UTRAN.
The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on
subscription data.
An EPS bearer/E-RAB is referred to as a GBR (Guaranteed Bit Rate) if dedicated network resources are
permanently allocated by an admission control function in the eNodeB, at bearer
establishment/modification.
Otherwise, an EPS bearer/E-RAB is referred to as a Non-GBR bearer.
A dedicated bearer can either be a GBR or a Non-GBR bearer while a default bearer shall be a Non-GBR
bearer.
The bearer QoS parameters are QCI, ARP, GBR, and AMBR.

7 QoS
7.2 EPS bearer QoS parameters

The Maximum Bit Rate (MBR) and GBR are defined per EPS bearer :
y The MBR defines the bit rate that the traffic on the bearer may not exceed
y The GBR defines the bit rate that the network guarantees (e.g. through the use of an
admission control function)
QCI
Resource
Type
Priority
Packet Delay
Budget
Packet Error Loss

Rate
100 ms
10-2
Conversational Voice
150 ms
10-3
Conversational Video (Live Streaming)
50 ms
10-3
Real Time Gaming
300 ms
10-6
Non-Conversational Video (Buffered Streaming)
100 ms
10-6
IMS Signalling
300 ms
10-6
Video (Buffered Streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing)
100 ms
10-3
Video (Live Streaming)

Interactive Gaming
300 ms
10-6
1
2
GBR
Non-GBR
Example Services
Video (Buffered Streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file
sharing, progressive video, etc.
1 2 47
The QoS Class Identifier (QCI) is a index that identifies a pre-defined packet forwarding treatment
(scheduling, admission control, queuing, link layer protocol configuration (ARQ and HARQ), etc.).
The standardized QCI label characteristics describe the packet forwarding treatment through the network
based on the following parameters:
Resource Type (GBR or non-BR)
Priority (= ARP)
Packet Delay Budget (PDB)
Packet Error Loss Rate (PLR)
Allocation and Retention Priority (ARP) is used to determine whether a bearer establishment or modification
request should be accepted or rejected in case of eNodeB resource limitations.
In addition, the ARP can be used by the eNodeB to decide which bearer(s) to drop during exceptional
resource limitations.
In addtion a GBR bearer is allocated Guaranteed Bit Rate value (one in UL and one in DL)that the eNodeB is
expected to provide to the bearer.

7 QoS
7.3 QoS mapping on transport network

EPS bearer QoS parameters are mapped on:
Radio bearer which is affected a scheduling type, a retransmission policy and an
ARP priority.
S1 and S5 bearers
The Main QoS mechanism on S1 and S5 bearers are:

Diffserv at L3
p-bit at Ethernet level
MME
RB
UE
S5 Bearer
S1 Bearer
SGW
eNodeB
Radio bearer Qos
PGW
Transport network QoS
1 2 48
The end to end QOS functions are performed at four levels : UE , eNodeB , ePC and the transport network
levels.
The EPC bearer QoS parameters are mapped to each corresponding QoS parameters :
-Radio QoS parameters on LTE-Uu interface
-Transport network QoS parameters on S1 and S5 interfaces.
On the transport network, the used mechanisms are :

-Diffserv QoS on layer 3 IP network
-p-bit QoS on layer 2 Ethernet network
-Traffic management to ensure efficient bandwidth usage and traffic policing or shaping to enforce QoS,
GBR, MBR and AMBR compliance.
In addition, the transport network also ensure control plane traffic prioritization using the same Layer 3 and
Layer 2 mechanisms.

7 QoS
7.3 QoS mapping on transport network [cont.]
Bearer-level QoS (QCI) is translated to to L3 and L2 transport-level QoS (DSCP at L3 and

p-bit at L2)
QCI
DSCP
p-bit
Service Example
1 (GBR)
EF (46)
Conversational Voice
2 (GBR)
EF (46)
Conversational Video (Live Streaming)
3 (GBR)
EF (46)
Real Time Gaming
4 (GBR)
AF42 (36)
Non-Conversational Video (Buffered Streaming)
UDP GTP-U header E2E IP packet 5 (non-GBR) AF41 (34)
IMS Signalling
6 (non-GBR) AF42 (36)
Video (Buffered Streaming), TCP-based (e.g.,

www, e-mail, chat, ftp, p2p file sharing,
progressive video, etc.)
7 (non-GBR) AF22 (20)
Voice, Video (Live Streaming), Interactive Gaming
8 (non-GBR) AF21 (18)
Video (Buffered Streaming), TCP-based (e.g.,

www, e-mail, chat, ftp, p2p file sharing,
progressive video, etc.)
Tunnel header
L2
L3
ETH
IP
L4
..TEid..
IP@(PGW/SGW),DSCP [BE, EF, AF]
P-bit [0,,7]
Diffserv packet marking (DSCP) is used to propagate QoS information on the mobile
backhauling network. It is Implemented in PGW for DL packets and eNodeB for UL
packets
1 2 49
Packet marking needs to be consistent from an end-to-end perspective.

7 QoS
7.4 eNodeB traffic Management

eNodeB supports UL traffic scheduling to ensure the QoS differentiation
between high priority flows and low priority flows.
VoIP (real time)
Lower priority flow
5620 SAM
UE
OAM
GigE
SGW
eNodeB
High priority
flow
PGW
eNodeB supports UL traffic shaping to adapt to the available backhaul

transport bandwidth.
1 2 50
The eNodeB implements UL QoS class based queuing to provide the priority in UL transmission based on
QoS needs.
In addition, depending on backhauling network capacity, the UL traffic needs to support rate limit according
to the backhaul bandwidth provided. The UL traffic shaping applies on the aggregated traffic which
egresses the Ethernet port.
In LA2.0, the initial feature Uplink traffic shaping goal was to support an UL basic traffic shaping only. The
basic requirement is when the eNB transport bandwidth is capped ie limited. In this case the EnodeB
supports UL rate limiting on the total aggregated traffic flow and yet still maintains the QoS needs for
individual flows in the UL.
Backhauling network
capacity limited
GigE
UL shaping used to
adapt UL rate to
backkaul capacity

7 QoS
7.5 eNodeB UL traffic Shaping

The committed Information Rate (CIR in b/s) is the average bandwidth
guaranteed by a backhauling network and that should be respected by the
EnodeB.
An allowance of extra bandwidth can be given, known as the Excess
Information Rate (EIR).
In excess UL eNB traffic is
dropped by the network
EIR
bandwidth
CIR
Backhauling network
time
UL eNB traffic between CIR
and EIR may be dropped
by the network in case of
congestion
1 2 51
For a flow, the Committed Information Rate ( CIR) is the average bandwidth guaranteed by a backhauling
provider to work under normal conditions. At any time, the bandwidth should not fall below this
committed figure. The CIR is guaranteed on a period of time T. If T is high enough, traffic can exceed
CIR during some time and can be lower than CIR the remaining time. To respect the average value CIR,
the maximum quantuty of data that can be sent during T is determined by : T CIR = CBS (Committed
Burst Size).
Above the CIR, an allowance of extra bandwidth is often given, known as the Excess Information Rate
(EIR). The provider guarantees that the connection will always support the CIR rate, and sometimes the
EIR rate provided that there is adequate bandwidth. The CIR plus excess burst rate (EIR) is either equal
or less than the speed of the access port into the network.
Extra data that exceed EIR are dropped. On the period of time T, the extra traffic can reach a value of EBS
(Excess Burst Size), equal to T (EIR CIR) = EBS.

7 QoS
7.5 eNodeB UL traffic Shaping [cont.]

eNodeB supports UL traffic shaping to adapt to the available backhaul
transport bandwidth :
Average rate shaping (rate limited to CIR)
Excess Information (EIR) shaping
UL traffic shaping with bandwidth profiles (CIR/CBS, EIR/EBS values) :

per physical port : one set of CIR/CBS, EIR/EBS values
The eNB performs traffic
shaping for all UL traffic
of egress physical port
EIR
CIR
GigE
per VLAN
EIR
CIR
Telecom
VLAN
EIR
OAM
VLAN
1 2 52
The eNB performs traffic

shaping for UL traffic for
each VLAN with different
values of CIR/EIR
CIR
average rate shaping limits the transmission rate to the CIR (Committed Information Rate).
Excess Information (EIR) shaping allows to send more traffic than the CIR. However, the traffic sent
above the CIR (the delta) could be dropped if the network becomes congested. If the network has
additional bandwidth available (over the provisioned CIR) and the application or class can tolerate
occasional packet loss, that extra bandwidth can be exploited through the use of EIR shaping.
However, there may be occasional packet drops when network congestion occurs.
The UL traffic shaping can be defined on a per VLAN basis or on a per physical port basis (available from
LA3.0). Bandwidth profiles need to be defined with following parameters: CIR/CBS, EIR/EBS.
Per VLAN configuration: as much set of parameters as VLAN number
Per Physical Port configuration: 1 set of parameters
Allow the following bandwidth granularity:
100 Kbit/s steps up to 1 Mbit/s

1 Mbit/s step beyond 1 Mbit/s up to 10 Mbit/s
5 Mbit/s step beyond 10 Mbit/s up to 100 Mbit/s
10 Mbit/s step beyond 100 Mbit/s up to 1 Gbit/s
Support 3 modes of shaping per Bandwidth profile to be shaped:
CIR
CIR and EIR
No shaping

7 QoS
7.6 eNodeB Call Admission

Radio Call Admission Control (Radio CAC) is a functionality of RRC layer :
helps to decide whether to accept or reject a new UE context or new
bearer creation request .
It manages the deletion of bearers or UE contexts.
It maintains the current estimated cell resource consumption in DL and
UL.
Radio CAC can admit/reject new entrants on a per QCI basis :
Based on the type of service required
Based on the experience (self-learn) impact of the service on the
resources
In addition, Radio CAC can perform pre-emption of lower priority existing
connections/bearers based on ARP value. The preempted connections can
be :
Offloaded to another cell
Released
1 2 53
The Call Admission Evolutions feature provides an evolution of the Admission Control from a token-based to
a measured-based solution. (LA2.0 Static CAC no longer used).
The Radio CAC solution allows admitting or rejecting new entrant bearers on a per QCI basis.
The Admission Control function on a per cell basis has to experience the average cost/impact onto both the
eNodeB and the Air Interface resources of the different types of services/applications. Based on the
experienced average costs versus the maximum eNodeB and Air Interface resources, the admission
decisions are the most in line with the on-per-cell basis live impact of an application depending on the local
radio conditions in the cell.
The Admission Control or admission decisions is also considering the ongoing average situation on served
QoS for existing bearers, and the impacts on the new entrant bearer onto the UL backhaul resources.
The solution allows the operator to control the admission on new entrant bearer on a per service type
basis. The operator/customer may then favor or restrict the admission of certain applications toward their
impact/cost on the LTE network resources.
In addition, from LA4.0, pre emption of existing bearer can be performed. The proper pre-emption action is
configurable by the operator (on a per QCI basis) and may be either:
z offloaded
to another cell: Trigger the Alcatel-Lucent proprietary mobility management framework

feature, enhanced Multi-Carrier Traffic Allocation (eMCTA), to route existing UE connection(s) (with all
its eRABs) to another less loaded layer (inter-Freq or Inter RAT).
z Released:
Trigger lower ARP bearer release. Careful analyses of the bearers are performed and
decision taken to release a bearer with minimum impact to end-user services and experience.
This is used especially for emergency VoIP calls.


Which sentence best describes p-bit?
P-bit is used for QOS purpose, it is a level 2 implementation (Ethernet)
P-bit is used for QOS purpose, it is a level 3 implementation (IP)
In the eNodeB, for DL traffic, QoS packet marking is applied:

At UDP level
At Ethernet and/or IP level
None of them, it is only applied at PGW
Call Admission Control is based on :

The QCI of the required service
The experience of the eNodeB to evaluate the cost of a required service
Both of them
1 2 54

8 Synchronization
1 2 55

8 Synchronization
8.1 Synchronization overview

In the eUTRAN, 2 principal synchonization needs:
Handover control Frequency Division Duplex
(FDD) systems only require frequency
synchronization
Radio Framing accuracy in TDD (Time
Division Duplex) systems or feature such as
MBMS require both frequency and time-ofday (ToD, also called phase)
synchronization.
Technology
Freq.
ToD
GSM
50 ppb
UMTS FDD
50 ppb
UMTS TDD
50 ppb
LTE FDD
50 ppb
LTE TDD
50 ppb
1.5 s
WiMAX TDD
2 ppm
3 s
WiMAX FDD
2 ppm
CDMA
50 ppm
2.5 s
-
10 s
Mobile Synchronization Requirements

(3GPP, 3GPP2 and IEEE 802.16e specifications)
1 2 56
The eNodeB has an internal clock to synchronize the air interface (time and frequency). But it can drift
slowly and disturbs the cells. It is why the eNodeB must receive an external synchronization.
The modulated carrier frequency of the BS shall be accurate to within 0.05 ppm observed over a period of
one subframe (1ms). The requirement applies on the radio interface.
3GPP TS36.104 [R6] specifies that LTE networks require stability of transmitted radio signal better than
50 ppb.
Phase synchronization is the process by which two or more cyclic signals tend to oscillate with a repeating
sequence of relative phase angles.
Problem of synchronization has not the same impact in FDD or in TDD systems.
z In FDD, the frequency synchronization is required to avoid the drift of the frequency center as this
disturbs the handover.
z In TDD, the time synchronization is also required for the radio frame synchronization.

8 Synchronization
8.2 Synchronization need for Handover

The UE expects to see the target cell carrier at F2
If F2>50ppb from nominal, the UE can not find it and call drops
Frequency
Frequency
eNodeB drifts ouside 50ppb window
F2
F2
+/- 50ppb
+/- 50ppb
UE can not lock to the
target eNodeB.
HO is unsuccessful
Handover
F1
F1
Time
Time
frequency synchronization is
required
1 2 57
Ppb : Parts-per-billion, it is a unit of concentration.

In FDD, the system must be synchronized on the frequency to avoid bad HO success rate. Actually, if the
frequency center of the target cell drifts, the UE can have difficulties to re-establish the RRC connection.
3GPP standard requirement for air interface clock:
z in
FDD/TDD, a frequency accuracy of 50 ppb is always required
z in
TDD, in addition, a phase accuracy of +/-1.5us

8 Synchronization
8.3 Synchronization need for TDD systems

If UE1 and UE2 are not synchronized, UE1 transmission can affect UE2
reception
If eNodeB not synchronized, eNB1 transmission can affect eNB2 reception
eNB1
eNB2
both frequency and phase

synchronization are required
UE1
UE2
time
UE1 TX
Overlap
Overlap
UE2 RX
1 2 58
time
eNB1 TX
eNB2 RX
TDD mode often requires synchronization between various transmitters and receivers in different cells.
Two non-synchronized close UEs jam each other in a nearfar context. The strong signal from the UE1
(transmitter) destined to eNB1 (receiver) can jam the UE2 if the UE1/UE2 ranges overlap.
A nearly same issue can appear between eNodeBs.
Phase Synchronization (same frame start-time among eNodeB) is reaquired :
In TDD mode
In FDD mode, in case eMBMS feature or CDMA/LTE HO feature
Accuracy: Requirement is +/- 1.5 sec phase accuracy

8 Synchronization
8.4 Possible solutions

Local GPS (internal or external receiver)
Synchronous Ethernet (SyncE)
IEEE 1588v2, Precision Time Protocol (PTP).
Ethernet
FDD only solution
Sync Ethernet
clock master
Synchronous Ethernet
GPS
1588v2
server
1588v2
client
1 2 59
IEEE1588v2 Precision Time Protocol
z There is a GPS receiver embedded in the eNB, an RS422 is available to connect GPS antenna. There is
also an External timing port to connect an external GPS receiver. GPS supports phase and frequency
reference.
z IEEE1588v2 is the recommended clock delivery over IP networks.
Note : IEEE 1588v2 is used for frequency reference from LA3.0.
z SyncE can only be used for frequency reference, so syncE cant be used in TDD systems.
Two reference sources can be combined in other to have a primary reference source and a backup
reference source, but syncE and IEEE 1588v2 cant be combined in LA3.0.
The eNodeB can run in free running for 72 hours for Frequency and 1 hour for phase (standard).

8 Synchronization
8.4 Possible solutions [cont.]

Synchronization can be performed with single reference source, or with
multiple reference sources. In this case, two or three reference sources
can be combined in other to have:
a primary reference source (Top Priority),
backup reference sources.
TDD solution supports GPS and 1588v2 solutions for frequency and phase
synchronization. If both are used, GPS is the ToP priority solution,
1588v2 is the backup reference source.
FDD solution supports GPS, SyncE and 1588v2 solutions for frequency
synchronization.
multiple reference source
Top priority
GPS
GPS
SyncE
GPS
2nd priority
1588v2
SyncE
1588v2
SyncE
3rd priority
1588v2
Flywheel
Holdover
1 2 60
Holdover
Holdover
Holdover
If no more reference clocks are available the eNB enters holdover, relying on the flywheeling function of
the internal oscillator. While the oscillator flywheels, the clock drifts from the optimum frequency and
phase. The eNB generates alarms when the drift reaches certain thresholds.
GPS is this only available solution for phase synchronization in LA4.0, only TDD TLA3.0 release supports
phase synchronization using PTP 1588v2.

8 Synchronization
8.5 SyncE Principles

Ethernet PHY layer can be used to inject clock into Ethernet stream.
ToD / phase synchronization is not possible using SyncE.
Equipment chooses the best clock,
and sends it as a reference
clock on all the line cards.
Ethernet
Sync Ethernet
clock master
LA3.0
Optionnally, eNodeB supports SSM

messages that inform on
synchronization quality.
1 2 61
A physical layer clock is delivered to the eNodeB over the Ethernet network from the Ethernet switch. This
is the same technique as using recovered E1 or T1 clock to derive the master clock on a Base Station for 2G
/3G /CDMA.
The Ethernet switch connected to the eNodeB must derive its reference clock from a signal traceable to a
Primary Reference Clock (PRC). This may be via a dedicated port, or it may be by using the recovered clock
from an ingress port.
There may be a number of Ethernet switches involved in the distribution of the reference timing signal : all
adjacent switches are running syncE.
Synchronous Ethernet uses synchronization status message (SSM) used in SDH networks. These messages
contain an indication of the quality level of the clock that is driving the synchronization chain. SSM is carried
over Channel ESMC, using the Ethernet OSSP Organization Specific Slow Protocol.
If the eNB is informed that the upstream equipment has lost its clock reference, it can decide what action
to take from a number of option, like for example holdover and ignore incoming reference or Ignore the
message and remain locked to reference. The configuration parameter syncEssmEnable must be set
to Enable to actiavte SSM support on eNodeB.
http://www.explania.com/fr/chaines/alcatel-lucent/detail/synchronous-ethernet

8 Synchronization
8.6 PTP principles

1588v2 protocol is also called Precision Time Protocol (PTP).
A PTP server must be deployed and the eNodeB acts as a PTP client.
the eNodeB only supports unicast mode transmission.
Timestamps are used to
deduce network delay and
RTT
PTP server
grandmaster
PTP client
T1
T1
RTT = ((T2-T1)+(T4-T3)):2
mean delay = RTT/2
DL delay = T2-T1
UL delay = T4-T3
T2, local
reception time
T3
Delay request
T4
Delay response T4
1 2 62
IEEE 1588v2 is suppoted in LA3.0 and TLA3.0.

PTP is a Timing over Packet Protocol (ToP). The root timing reference is called the grandmaster.
Two PTP transport modes exist : PTP protocol over UDP or PTP protocol directly over Ethernet. UDP mode
is used.
The PTP server can distribute synchronization information using multicat mode (all client receive the
multicast timing messages) or in unicast mode (each client gets its own targeted timing messages). The
eNodeB only support unicast mode.
The network between the master and the slave introduces packet delay, packet delay variation (PDV) and
packet loss.
Several timestamps are used to compute network these delays :
z T1: server sends Sync message.
z The grandmaster conveys to the slave the timestamp t1 by Embedding the timestamp t1 in the Sync
message. This requires some sort of hardware processing for highest accuracy and precision (one-step
clock), or by embedding the timestamp t1 in a Follow_Up message (two-step clock). (message not
shown on the diagram).
z T2: client receives servers sync message.
z T3: client sends Delay request to server. This is optional for frequency synchronization
z T4: server receives it and responses Delay response with t4
At the conclusion of this exchange of messages, the slave possesses all four timestamps.
RTT = ((T2-T1)+(T4-T3)):2
mean delay = RTT/2
DL delay = T2-T1
UL delay = T4-T3

8 Synchronization
8.6 PTP principles [cont.]

Messages transmission rate are negociated between the client server.
Knowing the network delay, the client can compare the receiving rate with the
negotiated server transmission rate.
The client deduces drift of its clock compared to the server reference .
PTP client
PTP server
grandmaster
Several messages
are used to
negociate PTP
exchanges rate.
Request unicast transmission

Grant unicast transmission
(logmessage interval, Duration)
Sync
Sync
Sync
1 2 63
logmessage interval
Duration
The messages exchanged are Request unicast transmission messages (sent by the eNodeB) and Grant
unicast transmission messages (sent by the server). These Messages contains different messages types
used to convey synchronization information : Announce, Sync, Delay response.
These information are sent at a regular period called interMessagePeriod over during a defined period.
This sending rate (pps) is negociated at the beginning of PTP messages transmission using sync type
messages.
The receiver records the time when packets are received after which the local interval between two
received packets is compared to the difference between the timestamps. The time stamps inside the
consecutive packets are compared with local arrival times.
Theorically one can determine the frequency error of the local clock compared to the reference by sending
two packets. In reality it is more complex due to Packet Delay Variation in the network, thats why the
number of hops must be limited between Server and eNodeBs.
The eNodeB supports the 1588 v2 server redundancy. In case of primary server lost the eNodeB fallbacks
to a secondary PTP server or another clock reference source. Fallback from primary to secondary is non
revertive.


What is the main benefit of 1588v2 synchronization protocol compared to GPS solution ?
Cost reduction
More accuracy
List the possible general solution for frequency and phase synchronization solutions :
y GPS
y 1588v2 PTP
y SyncE
List the available solution(s) for phase synchronization on FDD system :

y GPS
y 1588v2 PTP
y SyncE
List the available solution(s) for frequency and phase synchronization on TDD system :
y GPS
y 1588v2 PTP
y SyncE
1 2 64

End of module
LTE Transport overview
1 2 65

13
Section 1
Overview
Module 3
LTE eNodeB Hardware Description
9400 LTE

Blank page
132
RAN TLA3.0-LA4.0 Technical Overview LTE eNodeB Hardware Description
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition

Module objectives
Describe the eNodeB architecture
Describe the eNodeB Base Band Unit and Radio modules
Describe some eNodeB special configurations
133

134

Table of Contents
1 eNodeB description
1.1 General Architecture
1.2 RF Modules
1.3 Standard configuration
2 9926 BBU (Base Band Unit)
2.1 BBU design
2.2 BBU Shelf and Rack Backplane
2.3 RUC description
2.4 Controller Board Description
2.4.1 Controller Board backhauling interfaces
2.4.2 Controller Board CPRI interfaces
2.5 Modem Board Description : eCEM-U
2.6 Modem Board Description bCEM-U
2.7 External Alarm
2.8 eNodeB R-OCM configuration
3 TRDU Macro modules
3.1 eNodeB configurations with Macro Modules
3.2 TRDU2X overview
4 MC-TRX module
4.1 MC-TRX principles
4.2 eNodeB enclosures with MC-TRX
4.3 MC-TRX overview
5 Distributed eNodeB with RRH modules
RF
1 3 5 5.1 eNodeB configurations with RRH
RAN TLA3.0-LA4.0
Technical
Overview
5.2
9442
RRH
5.3 9442 TD-RRH
5.4 antenna cross connect configuration
5.5 RDEM
5.6 Fiber Delay Compensation
5.7 Distributed solution RRH benefits
6 eNodeB advanced capabilities
6.1 Capacity
6.2 eNB Reliability
7 Appendix A : RF modules description
8 Appendix B : eNodeB enclosures

Page
7
8
9
10
11
12
13
15
16
18
20
22
23
24
25
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
44
45
46
47
51

136

137

1.1 General Architecture

Cabinet
Antenna
eNode B
Digital <-> Radio

Receives and sends digital signal to/from Base Band
Receives and sends radio signal to/from antennas
Includes Power Amplifier, Duplexers, Receivers
RF module
CPRI
Base Band Unit
S1 & X2
eNode B brain and link to the network

S1 and X2 interface to ePC and other eNode Bs through
Gigabit Ethernet port
Processing capabilities
Send/Receive signal to/from radio through CPRI link
EPC and other

eNodeB
138
The antenna represented on the diagram is not considered as being part of the eNodeB.

1.2 RF Modules
The eNodeB is an integrated system composed of a cabinet, a BBU and RF
modules that can be :
Macro modules in compact eNodeB
RRHs in distributed eNodeB
MC-TRX Modules in compact eNodeB
RF module : macro
modules
CPRI
Base Band Unit
eNodeB cabinet
139
RF module :
RF module : RRH
MC-TRX
CPRI
CPRI
Base Band Unit
Base Band Unit
eNodeB cabinet
eNodeB cabinet
In TLA3.0, only distributed eNodeB can be deployed.

1.3 Standard configuration

The eNodeB can have up to 3 sectors.
x2
x2
x2
TRDU
TRDU
Or
Or
Or
RRH
RRH
RRH
Or
Or
Or
MC-TRX x2
MC-TRX x2
MC-TRX x2
CPRI
TRDU
CPRI
CPRI
Base Band Unit
1 3 10
In LA4.0 the RF part is ensured by either TRDU or RRHs or MC-TRX only (no mix).
The 2x2 MIMO is the normal base station transmit scheme for all eNodeB variants. In addition, the eNodeB
supports :
Single Antenna Transmit Scheme
The 4-way Receive Diversity (4br Rx Diversity) on RRH equiped with a RDEM module.
TLA3.0 eNodeB supports 8x antenna Beam Forming.
Using cross-polar antennas, each TRDU and/or RRH has two TX/RX paths that are connected to the two RF
connectors of the antenna.
In case of TRDU usage, and depending of the distance between the TRDUs (eNodeB cabinet) and the
cross-polarized antennas, TMAs may be needed,

1 3 11

2.1 BBU design
eNode B
RF module
CPRI
Base Band Unit
1 3 12
The eNodeB is an integrated system, composed of

-a cabinet, indoor or outdoor
-a Base Band Unit (BBU) : 9926 BBU
-Transmit/Receive Duplex Units (TRDUs) and/or Remote Radio Heads (RRHs).
From the architecture point of view, two types of eNodeBs are available:
Compact eNodeB, based on Transmit/Receive Duplex Units (TRDUs),
Distributed eNodeB, based on Remote Radio Heads (RRHs).
Digital processing is ensured by the Base Band Unit (BBU), it remains the same whatever the eNodeB type.
In any case, communication between the BBU and the RF modules use CPRI interface.
The 9926 Base Band Unit (BBU) is the Alcatel-Lucent converged product for W-CDMA, LTE-FDD and LTETDD BBU. It is composed of :
1 d2U shelf that includes the Rack Backplane (RBP)
CCM board (Core Controller Module) that supports OAM functions, external interfaces to RF
modules and to backhauling network.
CEM board (Channel element Module) also called Modem (up to 3 modules)
RUC, Rack User Commisionning also called the Fan Rack Unit or Fan Tray. This RUC plays an
important role in eNodeB commisioning.
The eAM, Enhanced Alarm module is an additional optional module.

2.2 BBU Shelf and Rack Backplane

The 9926 BBU can be installed horizontally or vertically.
CEM Slot 4
CEM
CEM Slot 3
CEM
CEM Slot 2
CEM
CCM Slot 1
CCM
fan tray / RUC
Fan Rack Unit
The RBP (Rack Backplane) allows

communications between CCM and CEM boards.
Power distribution from input (Fan tray) to boards
Power connector for CEM
High frequencies connection
Digital connector
Input Power connector

Power connector for CCM
d2U v3 RBP
1 3 13
CEM : Channel Element Module

There are two BBU versions supported :
9926 BBU V1 using a subrack version d2Uv3
9926 BBU V2 using a subrack version d2Uv5.
For all common characteristics between the two versions they are referred to as 9926 BBU.
The d2Uv5 shelf offers a new d2U sub-rack (with a new RBP) and new +24V High Capacity Fan Tray (RUC)
or a -48V High Capacity Fan Tray (RUC).
V5 Fan Tray should be installed in v5 d2U sub-rack, even if cross compatibility exists.
A d2Uv4 version has also been introduced in TLA2.1 release.
The d2Uv5 differs from the d2Uv4 as it may contain two CCM controllers in the future.
The RBP (Rack Back Plane) supports all internal links between CCM and CEM modules. It allows the
signaling interconnections between the CCM and the CEM modules inserted within the digital shelf. The
backplane board also gives a power supply to the CCM and CEM modules.
d2Uv5 RBP
2.2 BBU Shelf and Rack Backplane [cont.]

The BBU is a 2U/19 shelf with no back access.
The BBU can be installed in either :
Indoor or outdoor eNodeB cabinets,
In indoor standard 19 and 23 racks
In outdoor existing GSM or CDMA cabinets, or inside power supply cabinets.
Air flow
1 3 14
The 9926 BBU can be installed in a standalone indoor mode or in an existing indoor or outdoor AlcatelLucent Base Station cabinet for Multi-Standard configuration.
The 9926 BBU rack has the following characteristics:
width (W): 482.6 mm
depth (D): 300 mm
height (H): 88.1 mm
weight (fully equipped): from 9.8 kg up to 10.5 kg (depending on the number of CEM(s) in the
digital shelf).
Unused CEM slots on a powered BBU rack must be equipped with filler modules. The filler modules maintain
ElectroMagnetic Interference (EMI) integrity, as well as shelf airflow patterns to ensure proper cooling.
The Fan tray includes two fans. The air enters on the right side of the shelf, drawn through the shelf to cool
the boards, and exhausted on the left side of the shelf.

2.3 RUC description

The RUC (Rack User Commisioning) provides :
Power supply and filtering functions,
Commisioning and inventory functions (non volatile memory)
To eAM alarm
module
To CCM ext.
alarm port.
-48VDC
RUC
Front View
FAN
-24VDC
RUC
Front View
1 3 15
The Fan Rack (also referred to as Rack User Commissioning ) manages :

Power filtering
Commissioning
Inventory
Fan alarms report and power supply
DC power supply connectivity.
For LA3.0, it exists in two versions to meet different deployment requirements, -48V DC power version or
+24V DC power version.
Note
Important note : TDD BBU will only operate under -48VDC.
Two versions of Fan tray exists : V3 and V5.

V3 version can be installed in d2Uv3 subrack, V5 in both d2Uv3 and d2Uv5.
Configuration with V3 version in d2Uv3 subrack is not compatible with bCEM board introduction in LA
release.


The controller board is composed of
a main mother board (MB) providing Internal interfaces to CEM boards and to
RF modules (CPRI connectivity)
A Gigabit Ethernet (GE) MDA (Media dependant Adaptor) daughter board that
provides backhauling network connectivity
This controller board is called a eCCM-U GE module.

In addition, its functionality are :
eNodeB synchronization
O&M functions
Collection of BBU alarms, inventory and commissioning data,
1 3 16
In LE3.0 The 9926 BBU houses one eCCM-U. The eCCM-U is a controller in charge of part of :
call processing,
OA&M management,
internal/external data flow switching/combining,
external/internal alarm connectivity, and an external synchronization reference interface.
CPRI interfaces to the RRHs.
Collection of BBU alarms, inventory and commissioning data,
Collection of own 9926 BBU alarms, inventory and commissioning data,
Collection of external user alarms from optional alarm module (eAM),
OIM (Optical Interface Module) features to support up to six optical links,
Integrated GPS receiver
High stability OCXO (Oven-Controlled Crystal Oscillator) for frequency stability.
The eCCM-U supports multiple wireless access technologies (one at a time), providing the foundation for
converged RAN.Configuration of the technology is done at commissioning time via a HW technology
switch located on the main mother board.
There is eCCM Controller board convergence between FDD and TDD in LA3.0/TLA3.0 concerning SW design,
this ensures common MIM model, common internal eNB interfaces (CCM CEM interfaces), common
OMC, NPO and WPS for TDD and FDD but still there is different FDD and TDD eCCM-U Hardware used
in LA3.0 and in TLA3.0 : TLA3.0 uses eCCM-U high CPRI rate GE modules whereas LA3.0 used eCCM-U
P2 boards (and previously eCCM-U P0bis version).
The MDA is not a field replaceable unit.
2.4 Controller Board Description [cont.]

Not used in LTE
GE Ethernet MDA
6 SFP cages
for links to
radio modules
1 3 17
The face plate of the eCCM-U provides the following connectors (please refer to figure below):
LEDs providing the current status of the module,
One port for connection to external GPS antenna (in case of integrated GPS receiver) via a SMB
connector,
One RJ45 connector used for PPS input from an external GPS receiver; this connector also can
provide one RS232 port for control of external equipment,
One block of 6 SFP connectors for connectivity to the radios (RRH, TRDU); each SFP connector is
equipped with two light indicators; they support 6 CPRI links or 3 CPRI + 3 HHSL links,
One RJ45 connector used for a 1-wire interface (connectivity to external alarm module,
commissioning...),
One dual SMP connector providing input for 10MHz/15MHz input and 15MHz output,
Two RJ45 connectors used for debug (RS232) (debug/NEM port refered as Eth2) and Ethernet
(SiteLAN port, used for RETA); each connector is equipped with two LEDs (a yellow one showing
Ethernet activity status and a green one for Ethernet link status),
One J20 connector (not used in LA3.0).
RJ45 Debug interfaces must not be used during normal operation of the BBU.
MDA Geth port is refered as Eth0.
LA4.0 release supports eCCM-U GE modules eCCM-U P0bis or eCCM-U P2 modules.

2.4.1 Controller Board backhauling interfaces

To connect the eNodeB to the backhaul network, the MDA used in LTE provides:
RJ45 connector for GE electrical backhaul
Category 5e Ethernet cable (max 100m)
Two SFP connectors for GE optical backhaul

Single Mode Dual Fiber or Multi Mode Dual Fiber
GE Ethernet MDA for

S1 and X2 interfaces
SFP transceiver
Optical port
RJ45
Ethernet port
Backhauling
network to EPC and
other eNodeB
1 3 18
Optical or
electrical
The LTE digital does not support traffic backhaul over PCM links but only over Ethernet links, the J20
connector for 4 E1/T1 connections is not used in LTE case.
The face plate of the GE MDA provides:
One RJ45 connector for GE electrical backhaul
Two SFP (Small Form-Factor Pluggable) connectors for GE optical backhaul
On MDA, ports are named SFP1, SFP2 and RJ45, from left to right.
Only SFP-2 or RJ45 connector shall be used : if both connected, then SFP-2 port is used a,d RJ45 port is
disable.
In LA4.0 release, only one single GE Interface is supported for the backhaul. In case of optical link, only
the SFP-2 port is enabled.
RJ45 connexion
The physical length of the channel (fixed horizontal cable & patch cords + cross-connect jumpers) shall not
exceed 100 m (Ethernet standard) so that means that horizontal cable physical length shall not exceed
90 m (+ 10m for patch).
Cables should be F/UTP minimum constructed cables, Category 5e, compliant with IEC11801 & TIA/EIA568 standards.
Fast Ethernet on the embedded RJ45 port can also be used, but not recommended.

2.4.1 Controller Board backhauling interfaces [cont.]

Optical Connexion uses LC connectors and can be based on :
Multi Mode Dual Fiber using 1000BaseSX SFP.
UL
DL
EPC
850 nm
850 nm
Single Mode Dual Fiber using 1000BaseLX SFP.
UL
EPC
DL
1310 nm
1310 nm
1 3 19
On optical connections, one fiber carries the downlink signal and a second one the uplink signal.
The multimode fiber is used for a maximum distance of 220 meters using 1000BaseSX SFP (850 nm
wavelength) 62,5 micron fibers or 550 using 850nm and 50 micron multimode fibers.
The monomode fiber is used for a maximum distance of 10km meters using 1000BaseLX SFP (1310 nm
wavelength) / 62,5 micron fibers or 550 using 850nm and 9 micron multimode fibers.

2.4.2 Controller Board CPRI interfaces

CPRI (Common Public Radio Interface) connections are used between
the BBU and the RF modules.
RF
module
RF
module
RF
module
CPRI slave port

CPRI master port
BBU
Star configuration
CPRI uses optical links and possibly electrical links for short distance
(compact eNodeB). SFP are used to adapt connectors.
1 3 20
CPRI connections are based on V4.0 and V4.1 CPRI standard. CPRI standard plans to cover UMTS + LTE
mixity and CDMA + LTE mixity.
The Alcatel-Lucent BBU supports the following topology:
Star configuration (up to 6 ports on 4G BBU)
Daisy chain configuration will be supported in future release.
Various bits rates are supported :
614.4 Mbit/s (Rate 1), TDD
1228.8 Mbit/s (Rate 2), FDD&TDD
2457.6 Mbit/s (Rate 3) FDD&TDD
3072.0 Mbit/s (Rate 4),
4915.2 Mbit/s (Rate 5). TDD
Secondary port can also be used in case of Antenna cross-connection configuration (described later in this
module).

2.4.2 Controller Board CPRI interfaces [cont.]

The CPRI interface supports:
Multi Mode dual fiber
Single Mode single fiber
Single Mode Dual Fiber
Ethernet Cable
BBU to RRH connections are optical connections whereas BBU to TRDU

connections can also be electrical based.
RF
module
R2CT weatherized connector
BBU
LC connector
1 3 21
SFP
Depending on customer optical link choice (Multi or Single mode), the SFP cage of the eCCM-U board will be
equipped with CPRI optical SFP transceivers to support the connection to the Radio Module.
Various SFP are used to adapt to bit rate and transmission mode (wavelenghth, one or two fibers).
Multi Mode (MM) dual fiber: One fiber carries the downlink signal and a second one the uplink signal.
The MM fiber is used for short distance (<= 500 m). The SFP module in Multimode uses a transmitter 850
nm wavelength.
Single Mode (SM) Dual Fiber: one fiber carries the downlink signal and a second one the uplink signal.
The SM is used for high distance (up to 20 Km). The same Single Mode SFP transmitter is used on both
ends of the fiber, 1310 nm wavelength transmitters.
Single Mode single fiber: one single fiber carries both downlink and uplink signal. The SM must be used
for high distance up to 15 Km. The SFP module on BBU uses a 1550 nm wavelength transmitter. On the
RRH the SFP module uses a 1310 nm wavelength transmitter.

2.5 Modem Board Description : eCEM-U

The eCEM-U (enhanced Channel Element Module) provides base-band
signal processing for the eNodeB.
FDD
only
1 sector per eCEM-U

3 eCEM-U max per eNodeB
1 3 22
Per Modem (CEM)

Bandwidth/eCEM-U
2X2 MIMO 1X20 MHz

2X2 MIMO 1X10 MHz
2X2 MIMO 1X5 MHz
Peak throughput/
eCEM-U
Peak L1: 172 Mbps DL
Nb sector eCEM-U
The eCEM-U performs digital signal processing for both the Tx and Rx paths. The eCEM supports the
following functions:
- Board level OA&M functions,
- Call processing,
- L2 processing (Radio Link Control function (RLC), Media Access Control function (MAC),Downlink
Scheduler, Uplink Schedule).
- L1 processing
The eCEM-U provides two debug ports that should not be used during normal eNodeB operation.
Each eCEM-U modem supports one sector. Up to a maximum of three eCEM-U modules can be inserted in
the 9926 BBU so a maximum 3 sectors can be handled by one eNodeB.

2.6 Modem Board Description bCEM-U

The bCEM-U (enhanced Channel Element Module) provides base-band
signal processing for the eNodeB.
TLA3.0
Modem (CEM)
Bandwidth/
bCEM-U
2X2 MIMO 1X20 MHz

2X2 MIMO 1X10 MHz
Beamforming 1X10 MHz
Beamforming 1X20 MHz
Nb sector /
bCEM-U
3 using 2x2 MIMO in 10Mhz and 20

Mhz configurations
1 using beamforming in 10Mhz and
20Mhz configurations
1 3 23
The bCEM-U performs digital signal processing for both the Tx and Rx paths. The bCEM-U supports the
following functions:
- Board level OA&M functions,
- Call processing,
- L2 processing (Radio Link Control function (RLC), Media Access Control function (MAC),Downlink
Scheduler, Uplink Schedule).
- L1 processing
The bCEM-U provides three debug ports that should not be used during normal eNodeB operation.
In TLA3.0 release, a bCEM-U modem can support up to 3 sectors in 2X2 MIMO 10 or 20 Mhz configuration.
First bCEM is installed in slot bCEM-U1, the second in slot bCEM-U2, the third in slot bCEM-U3.
Two different HW version of bCEM-U exists : P0.1 and P1 they must not be mixed inside one BBU shelf.
P0.1 bCEM are used in d2Uv4 BBU and P1 bCEM in d2Uv5 BBU.

2.7 External Alarm

The 9926 BBU can be equipped with an optional
external alarm module.
The Indoor version: eAMi
The Outdoor version: eAMo (Integration in outdoor
eNodeB cabinets)
Connected to RUC
Ext. port alarm
1 3 24
The 9926 BBU can be equipped with an external alarm module that provides an extension to support up to
32 external user alarms.
These alarms include power systems and battery backup alarms, cell site door alarms, external alarms
provided by other cell site equipment such as backhaul modems.
Alarms :
10 Frame/Cabinet Alarms
4 Power Alarms
Secondary protection on all alarm inputs
Primary protection on user and power alarms (eAMo)
Future support for I2C controller interface
Powered from eCCM-U controller
The eAMi, as well as the eAMo, are 19 modules, U high for rack mount enclosure.

2.8 eNodeB R-OCM configuration

The Reverse-OCM (R-OCM) is the connection between the LTE BBU and the OneBTS
Digital Shelf. It converts the optical CPRI from the BBU and connects to the OneBTS
backplane to facilitate use of OneBTS RF assets
The CDMA RF resources are shared between the eNodeB and the CDMA BTS.
R-OCM fits into a channel card slot in the BTS
FDD
only
Enables LTE in existing BTS

Allows de-growth of CDMA and
increasing LTE bandwidth
Optical CPRI
Connection
3 LTE 5Mhz cells on one ROCM.

LTE Band IV AWS
Modular Cell 4.0B and Compact
odular Cell 4.0B cabinets.
Reverse OCM
circuit pack
1 3 25
The eNodeB R-OCM (Remote OneBTS CPRI Module ) is used in 9228 or 9226 Digital Shelf. It enables the
reuse of RF assets in a CDMA Modular Cell BTS.
The CDMA RF resources are shared between the eNodeB and the CDMA BTS. The eNodeB BBU
communicates via the CPRI links with the R-OCM located in the CDMA BTS. The R-OCM creates Virtual
Remote RF Heads (VRRHs) that are seen by the eNodeB as a new type of Remote RF Heads (RRHs).
Using this RF path sharing instead of an external RF combining solution (antenna sharing), the combiner
guard band is not necessary
more available BW for additional CDMA carrier.
The feature is focused on LTE cells with 5 Mhz bandwidths, in the 3GPP Band Class 4-AWS, which
corresponds to Band Class 15 in CDMA standard.
Considering eNodeB capacity in LA4.0, the following RF configurations are supported:
1 to 3 sectors 2T2R shared radios (two TX and two RX paths)
1 to 3 sectors 2T2R stand alone radios
The eNodeB R-OCM configurations are supported in Modular Cell 4.0B and Compact Modular Cell 4.0B
cabinets.
In Indoor Modular Cell 4.0B cabinet, the LTE BBU shares the same cabinet with CDMA equipment.
In the case of Compact Modular Cell 4.0B outdoor cabinet, the LTE BBU is located in a separated
weatherized cabinet


Which sentence best describes the eNodeB architecture?
One BBU linked to the TRDU with an Ethernet link
Three BBU for one TRDU and one RRH
One BBU for up to three remote radio units
One BBU linked to radio modules through CPRI links
The 1588 v2 synchronization is obtained through the

CPRI link
External synchro port
GPS antenna port
One of the Ethernet port
1 3 26

1 3 27

3.1 eNodeB configurations with Macro Modules

9412 compact eNodeB
Digital module
Outdoor Cabinets
MBO2 GSM cabinet
or
Baseband and RF cabinet
RF Macro Module
Indoor Cabinets
MBI5 GSM cabinet
or
9926 BBU
CPRI
Ethernet cable
TRDU 2X
Transceiver
Duplexer Unit
FDD
only
1 3 28
Cube Indoor
Cabinet
Compact
indoor Rackmount shelf
Using TRDU, TMA could be needed depending on the distance between antenna and TRDU.
The 9412 eNodeB is a compact eNodeB in the Alcatel-Lucent Solution. The 9412 eNodeB is a self-contained
solution, often called the LTE cube or the 9412 eNodeB Compact smart.
Compact eNodeB can be located in indoor or outdoor environments :
Indoor cabinet, also called Cube Indoor Cabinet, designed to support LTE service in the 700 MHz
spectrum in a all in one cabinet.
Compact Indoor Rack-mount shelf
Outdoor cabinets (Baseband cabinet and RF cabinet)
The 9412 eNodeB is an integrated system. However, it is the same as a distributed eNodeB with a
separation of the digital and RF processing by a CPRI interface.
Electrical SFP are used to connect CPRI interface between the BBU and the macro module. In outdoor
configurations, Multi Mode Dual Fiber can also be recommended.

3.2 TRDU2X overview

Radio technology : LTE, on 5 or
10 MHz LTE bandwidth
Functions:
RF converters
Tx amplifier
Features:
cell
Rx LNA
One TRDU supports 2X2 MIMO.
RF Filter
2 Tx path
EAC
RF jumpers
TRDU2X
TRDU Naming
BW
Frequency Band
Output
RF Power
TRDU2x40-07U
10 Mhz
Band XIII (700 MHz Upper)
2 x 40W
TRDU-2x40-07PS
5 Mhz
Band XIV (Public Safety)
2 x 40W
TRDU2x40-08U
5 & 10 Mhz
EDD Band XX (800 MHz) (upper)
2 x 40W
TRDU2x40-08L
5 & 10 Mhz
EDD Band XX (800 MHz) (lower)
2 x 40W
1 3 29
CPRI
Base Band
Unit
Compact eNodeB
The TRDU (TRansceiver Duplexer Unit) has two RF transmitters (two Tx paths with 40W per path), two
receivers (Low Noise Amplifier) and a double duplex filter, packaged in a single shelf-mounted module.
It is MIMO capable and there is one TRDU2X per cell.
The nominal transmit power of the TRDU is 2 x 45 Watts at the duplexer ports : this is to support 40W at
the external antenna connector (EAC), (up to 0.5dB of loss in the jumper cable between the TRDU and top
of cabinet).

4 MC-TRX module
1 3 30

4 MC-TRX module
4.1 MC-TRX principles

TheMC-TRX is based on Software Designed Radio (SDR) technology :
The same Hardware module can support different technologies thanks to
software reconfiguration from O&M center, without any site visit.
GSM B12 and
UMTS UA8.0
2G
2G
+
3G
3G
GSM B12 and

LTE LA4.0
2G
+
4G
4G
Multistandard
1 3 31
Multimode
Thanks to SDR, the module is able to handle simultaneously several carriers from different technologies and
offers the possibility to evolve smoothly from GSM to W-CDMA and LTE for a dedicated frequency band.

4 MC-TRX module
4.2 eNodeB enclosures with MC-TRX
Digital module
9926 BBU
MC-TRX Module
CPRI
Ethernet cable
MC-TRX
FDD
only
1 3 32
MBI5 Cabinet
MBO2 Cabinet
The MC-TRX is a multi carrier transceiver which can operate in LTE technology only, but it is mainly
intended to be used in dual technology: LTE+GSM.
The MC-TRX is located in MBI5 and/or MBO2 GSM cabinets.
The MC-TRX takes place in subracks (called STASR) installed in indoor (MBI5) and outdoor (MBO2) GSM
cabinets.
The solution based on 9926 BBU + MC-TRX module in MBI/MBO cabinet is also called a 9412 Compact
enodeB.

4 MC-TRX module
4.3 MC-TRX overview

Radio technology : LTE and GSM
2 LTE Tx path
5 or 10 MHz LTE bandwidth

Features:
Two MC-TRX to support 2X2 MIMO.
up to 40W for LTE carrier
AN
Up to 6 MC-TRX connected on BBU (3

sectors with MIMO)
MC-TRX
TRDU Naming
BW
Frequency Band
Total
Output
RF Power
MC-TRX
10,20
Mhz
Band III (DCS 1800 Mhz)
1 x 60w
MC-TRX
CPRI
Base
Base Band
Band
Unit
Unit
GSM
GSM SUM-X
SUM-X
Backplane
Evolution Cabinet
1 3 33
60 watts are provided at RF module. 40 watts maximum for LTE carrier at top of Cabinet.
GSM SUM-X board is the controller board, the GSM modem is included in the MC-TRX module. MC-TRX and
BBU connection is ensured by the backplane.
The MC-TRX is connected to an Antenna Network (AN) before interfacing the antenna. The AN playing the
Duplexer role.
Following carriers/power configurations are available :

1 3 34

5.1 eNodeB configurations with RRH RF
Digital module
RF Module
Outdoor PSU Cabinet
Md4 oudoor cabinet
9926 BBU
CPRI
optical
1 3 35
9442 RRH
Remote Radio
Head
The RRH (Remote Radio Head) module provides the RF part of the eNodeB. It includes :
At least two RF transmitters to enable 2x2 MIMO applications
Two Multi Carrier Power Amplifiers (MCPA)
Four 20MHz Receivers to support 4-way Receive Diversity
The RRH can be on the same site where the BBU is located, or on a remote site. In any case, the BBU and
the RRH are linked by optical fibers (CPRI). One optical link is used between the BBU and the RRH for both
UL and DL based band signals (and OAM info).
The HW is capable of supporting a single or multiple LTE carriers over up to 20 MHz of spectrum of
bandwidth.
The RRH includes :
Its own energy system
Its own cooling system
AISG interface (allowing remote control and monitoring capabilities of the antennas)
The outdoor PSU cabinets provide DC power supply to LTE equipments (BBU and RRHs).
They include AC/DC rectifiers, batteries, but also free space for other RAN equipments (GSM, W-CDMA,
CDMA).
Md4 outdoor cabinet, offering 14U user space can be used:

5.2 9442 RRH
The various models for the 9442 RRH differs by:

supported bandclass
maximum RF output power
number of transmit and receive paths
Radio technology : FDD LTE

Functions:
One RRH per sector
RF converters
Tx amplifier
Rx LNA
RF Filter
RRH Naming
Frequency Band
Output RF Power
BW
RRH2x40-AWS Band IV AWS (2100/1700 MHz)
2 x 40W
5, 10, 20 Mhz
RRH2x40-07L
Band XII / XVII (700 MHz Low)
2 x 40W
5,10 Mhz
RRH2x40-07U
Band XIII (700 MHz Up)
2 x 40W
10 Mhz
RRH2x40-08
Band EDD (upper and lower
2 x 40W
5, 10 Mhz
RRH2x40-26
Band VII (2600 MHz)
2 x 40W
10,20 Mhz
4 x 40W
(1.4, 3, 5, 10 ,15
or 20 Mhz)
Band II (PCS 1900 MHz)

RRH4x40-19 Dual technology RRH LTE/CDMA
1 3 36
RRH2x40-AWS
FDD
only
The RRH has 2 RF transmitters to enable 2x2 MIMO applications and 4 Receivers to support 4-way Receive
Diversity.
RRH delivers 40W output power per antenna connector when the RRH is configured with 2 independent RF
Paths (2x40W combined).
RRH4x40-19 supports simultaneoulsy CDMA and LTE signals over a 65Mhz band. Various configurations
are possible :
-from 0 up to 2 CDMA carriers
-from 0 up to 2 LTE carriers depending on chosen bandwidth
-LTE 2x2 MIMO or 4x4 MIMO

5.3 9442 TD-RRH
For TDD solution, The RRH is called TD-RRH.

Radio technology : TD-LTE
10 or 20 MHz LTE bandwidth
Functions:
supports 2X2 MIMO or Beam Forming (8 transmitters case)
up to 20W for LTE carrier
Fiber delay compensation over 10km fiber distance.
TD-RRH2x20
RRH Naming
Frequency Band
Output RF Power
TD-RRH2x20-23
Band 40 (2300 to 2400 Mhz)
2 x 20W
10, 20 Mhz
TD-RRH2x20-26
Band 38 (2570 to 2620 MHz)
2 x 20W
10,20 Mhz
TD-RRH8x5-26
Band 38 (2570 to 2620 MHz)
8x5W
10,20 Mhz
1 3 37
BW
TLA3.0
No daisy chaining supported so far.

From TLA3.0, the Fiber Delay Compensation feature (FRS T113612) allows to support 10km fiber
length. This allows up to 10km distance between the BBU and the RRH.

5.4 antenna cross connect configuration

The RRH can be configured to support 2 sectors in Cross Connect Configuration
It provides the RRH redundancy to the sectors.
Sector 1
Sector 2
RRH 1
RRH 2
1 3 38
Sector 3
RRH
FDD
only
LA3.0 eNodeB supports the deployment of RRHs with antennas in cross connect configuration.
This provides redundancy in the case of RRH failures as the eNodeB reverts to a SISO configuration on
detection of failure of an RRH.
In the Antenna Cross Connect configuration, each RRH serves one TX/RX path for two sectors. In case of
RRH failure, the eNodeB defense will change the diversity path of a remaining RRH into main path for the
affected sector.
CPRI fiber cable length to RRH shall be as much as possible the same for all RRHs (max.? Difference of
2meters) This fulfillment is mandatory to be in the 11ns maximum delay acceptable between TX Main and
TX Diversity paths of a RF sector.

5.5 RDEM
9442 RRH2x40-26 can be ordered with RDEM (Receive Diversity Expansion

Module) that provides two additional RX ANT ports.
TX/RX Connectors
Additional Receive
Diversity Expansion
Module (RDEM)
RRH Top connections
As a consequence, 9442 RRH2x40-26 are 4-Way Rx Diversity capable

Tx/Rx
BBU
BBU
CPRI
LTE 2x2 MIMO

with 4-way Rx
RRH
RDEM
1 3 39
Rx Only
FDD
only
9442 RRH2x40-26 can be equipped (factory configuration) with RDEM (Receive Diversity Expansion Module)
to provide 4-Way Rx Diversity.
Extension of a RRH with RDEM is not allowed on site as the configuration requires calibration at factory
level so if 4Rx Diversity shall be supported, the good RRH variant shall be ordered.

5.6 Fiber Delay Compensation

The fiber connection on BBU-RRH or eNodeB-DAS (distributed Antenna System)
links introduces additional round-trip delay which skews the RACH preamble arrival
time at the eNodeB.
BBU
BBU
CPRI
RRH
L3
L1
UE
L2
L1: BBU-RRH distance

L2: RRH-DAS Antenna distance
BBU
BBU
CPRI
DAS
RRH
L3: Over The Air distance
The BBU-RRH delay is measured and compensated by the eNodeB software.

The RRH-DAS delay is compensated using eNodeB RRH-DAS tunable antenna
path delay parameter setting.
1 3 40
A Distributed Antenna System, or DAS, is a network of spatially separated antenna nodes connected to
a common source. The transmitted power is spit among several antennas, separated in space so as to
provide coverage over the same area as a single antenna but with reduced total power and improved
reliability.
A downlink broadcast signal can be sent to the users in order to allow a preliminary timing and frequency
estimation by the mobile.
The eNodeB has also to perform fine timing estimation when the signals coming from users are detected :
PRACH is used to obtain ne time synchronization by informing the mobile users how to compensate for the
round trip delay. After a successful random access procedure, the eNodeB and the UE are synchronized
within a fraction of the uplink cyclic pre x, and so, the uplink signals can be correctly decoded and does not
interfere with other users connected to the network.
The fiber connection between LTE modem and radio (RRH/TRDU) adds delay to eNodeB timing. This delay
impacts PRACH processing due to the round trip delay which skews the RACH preamble arrival time
at the eNodeB.
The eNodeB must adjust the center of its search window so that the search window range of the eNodeB
can be used fully for cell range.
From LA4.0, the eNodeB can compensate for BBU-RRH delay. The feature supports :
- a total distance from BBU to Antenna tip of up to 15 km without impacting the max cell radius (L3).
- a BBU-Radio distance up to 15 km
- A Radio to DAS antenna distance up to 400 m
TLA3.0 system supports a 10km fiber delay between BBU and RRH.

5.7 Distributed solution RRH benefits
19W
44W
33W
0,3dB
TMA
Jumpers
0,5 dB
7/8" feeders
30m 2dB
Jumpers
0,4 dB
Jumpers
0,8 dB
(5m)
no more RF losses
66% more power @ antenna !
40W
Optical fiber
1 3 41
RRHs are designed for close connection to the antennas (3 to 5 meters maximum), therefore the usage of
TMAs between RRHs and antennas is not recommended.

5.7 Distributed solution RRH benefits [cont.]

RRH smooth integration
Antenna
RF Feeder
Antenna
RF Jumper
RRH
Before
Radio
Optical Link
Digital
Digital
Backhaul
1 3 42
Backhaul
After
On physical characteristic aspects, the RRH is a zero footprint solution, very light, which doesnt require
any craning for installation.
With a reduced power consumption and noise-free solution (no fan used), the RRH doesnt require any
maintenance.


Complete the following sentence:
Compact eNodeBs host _____ radio modules whereas distributed eNodeBs are
equiped with _____ radio modules.
What is the benefit of using RRH rather than TRDU?

Reduce the loss between the cabinet and radio unit
Reduce the cost, because the footprint is smaller
What is the benefit of LTE antenna cross connect function?

Improve the throughput
Improve the reliability in case of RRH failure
1 3 43

1 3 44

6.1 Capacity
For each connected UE, the eNodeB maintains:

SRB for the signaling
Data Radio Bearer (DRB) for the user traffic. The DRB is mapped on the S1 bearer (GTP
tunnel) on the S1-U interface.
From LA3.0 there can be up to 8 DRBs per User.

S1 MME
MME
DRB
SRB
UE
S1-U
SGW
Assuming :
One 5MHZ cell/modem (or 10MHZ cell/modem)
4,5 data radio bearers/user in average
8 bearers/user at maximum
Up to 167 active users per Cell committed

1 3 45
The SRB, Signaling Radio Bearer, is a bearer on the air interface used to carry the radio signaling (radio
bearer addition request or HO command for example) and the NAS signaling, i.e. the signaling between
the UE and the MME. The DRB, Data Radio Bearer, is used to carry the user traffic. Depending on the
service established for the user, it possible to have several radio bearers for the user traffic.
The eNodeB allocates dynamically the radio resources in UL and DL to all the DRB and SRB depending on
the amount of data, the QoS and the radio conditions.
up to 8 concurrent data radio bearers [that is, DRB(s)] per user are supoorted, as defined by 3GPP as
upper multi-bearer capability for UE categories 1 to 5.
The given eNodeB Software Capacity Configurations corresponds to the maximum number of Active
User(s) supported by an eNodeB from a software standpoint regardless of throughput constraints per
users that may be observed over the air interface.
LA3.0 supports for up to 167 Active Users assuming:
One 5 MHz-cell/modem or one 10MHz-cell / modem
Up to 4.5 concurrent data radio bearers/user in average. For example:
1 Default non-GBR DRB, plus
1 Dedicated non-GBR DRB (for example, SIP)
1 Dedicated GBR DRB (for example, VoIP)
1 Dedicated GBR DRB
0.5 Dedicated non-GBR DRB.
Up to 8 concurrent bearer/user at maximum regardless of the DRB type (that is, GBR or non-GBR).
In TLA3.0, the eNodeB software capacity is 100 active users per cell (with MIMO).
6.2 eNB Reliability

eNodeB fonctions improved :
eNodeB start-up and restart time
eNodeB failure detection and reporting
eNodeB automatic recovery
SW Reset
Time to complete a software reboot < 2 minutes and

30 seconds for 95% of the reboot occurrences
< 230
5620 SAM
eNB Software Upgrade Outage: < 2 mn 30 seconds
SW
Software Download
Software Activation (eNodeB reboot)
Software Accept
1 3 46
FDD
only
Start-up and restart time

In case of Software Reboot/ Warm Reset (Without SW activation), the time to complete a software
reboot shall be less than 2 minutes and 30 secondes (in 95% of the occurences). This is also the
Downtime for the eNB.
eNB Software Upgrade Outages should also be less than 2 mn 30 seconds, from the SW Activation of the
new load and parameters in the NM server (SW download and installation already done in
background) till the eNB is ready to accept calls (S1 & X2 are up, The SIB are transmitted, the first cell is
ready to accept calls )
eNB Software upgrade success ratio: 99,9%
The Warm-up time for outdoor systems at the minimum storage temperature to reach operational
temperature shall be at most 60 mn (System Cold Start) .
For indoor systems and outdoor systems already at operating temperature when not powered, start time
shall be no more than 10 minutes.
Failure detection and recovery
A minimum of 95% of eNB failures that can result in total or partial outages shall be automatically
detected and reported to the external entity controlling the base station within 15 seconds.
99% of software trap and firmware failures shall be automatically recoverable. Recovery is defined as
returning to a state wherein the software is able to serve the designed traffic objective. It can range from
an automatic reset to an eNB reboot. Manual recovery shall also be supported in case operator
intervention becomes necessary or is preferred by the service provider.

1 3 47

TRDU 2X overview
CPRI ports
PRI & SEC
TX/RX Antenna ports
Power entry
1 3 48
AISG port
(Antenna Line Device)
On the TRDU frontplate :

One 2W2 socket connector for power entry (-48 VDC or +24VDC)
Two ANT TX/RX (N coaxial female connector) (RF ports)
Two SMA connectors for auxiliary RX (AUX RX for future antenna sharing feature)
Two SMA connectors for TX main and TX Diversity testing (TX MON)
Two SMA connectors for external VSWR (Voltage Standing Wave Ratio )test ports
Two CPRI ports for SFP Transceivers :
CPRI PRI to connect the TRDU to the BBU
CPRI SEC
One Ethernet RJ45 connector for on-site configuration
One RJ45 connector for I2C interface
VSWR (voltage standing wave ratio) measures the size of signal reflections of transmission lines between
transmitters or receivers and antennas.
TRDU daisy chaining not supported in LA4.0.
AISG interface is not supported on TRDU2x40-08L and TRDUx40-08U.

MC-TRX overview
RX connectors
On/off switch
CPRI ports
PRI & SEC
1 3 49

TX connector
RRH 2X Overview
2 RF transmitters to enable 2x2 MIMO
Top View
Power supply
Links to BBU (optic fiber)
Alarms
Bottom View
1 3 50
The Alcatel-Lucent Remote Radio Head (RRH) specified here is a platform asset that can support LTE in
2.6GHz FDD frequency band. The unit has 2 RF transmitters to enable 2x2 MIMO applications. The RRH
specified is for 3GPP Band VII (2600MHz) and supports 2x40W..

1 3 51

Cube Indoor Cabinet

9412 compact eNodeB
Enhanced Alarm Module

eAM
BBU
Fan Tray
Power
Distribution
Panel
3 TRDU2X
(3 cells)
1 3 52
The eNodeB Indoor cabinet is optimized for small size and small footprint, with a size of 599mm in
width, 575mm in depth, and 675mm in height. It is a riveted cabinet, made of galvanized steel with
exterior powder coat. Assets are mounted along a horizontal upper and lower support shelf. Assets and
rack are EIA-310D compliant (19 standard rack).
From connectivity point of view, only the RF and GPS connectors are present and fixed to the cabinet:
6 ANT TX/RX (7/16 DIN coaxial female connector)
One GPS RX (N coaxial female connector)
The optical and alarm cables enter the cabinet through the top-left side and are directly connected to the
BBU and to the eAM board. The DC power cables enter the cabinet through the top-right side, and are
directly connected to the PDP.


9412 compact eNodeB
1 3 53
In addition, there is also a cabinet called Compact Indoor Rack-mount shelf, designed for easy
integration in 19 or 23 standard racks.

Compact Outdoor cabinets

9412 compact eNodeB
eNodeB
Power
Distribution
Panel
TRDUs
BBU
Power
Distribution
Panel
Fan Tray
Fan Tray
BaseBand Cabinet
1 3 54
RF Cabinet
the Baseband cabinet houses:

One Power Distribution Panel (PDP) equipped with circuit breakers
One Heater located behind the Power Distribution panel,
One Baseband Unit (BBU),
One Alarm Module: eAMo,
One fan tray assembly and one Fresh Air Filter (FAF).
Besides these units, free space remains for options. As such, following options can be inserted:
A supplementary Heater. (Refer to 8.3.1.4 for conditions)
A Baseband Cabinet version in -48 VDC with Dual BBU also exists.
The radio frequency cabinet houses:
One RF specific Power Distribution Panel (PDP) equipped with circuit breakers
One TRDU Shelf
From one to Three TRDUs depending on the eNodeB configuration.
One fan tray assembly and a Fresh Air Filter (FAF)
One Alarm Module (the AM-r)
Two variants of cabinets are possible : +24VDC variant, and +48VDC variant.
The Baseband and RF cabinets can be mounted a floor-stand mount, on a wall or a pole.

LTE Cube in 9100 MBI/MBO cabinets for LTE

The LTE Cube supported configurations in MBI5/MBO2 GSM
cabinets is based on one of the following TRDUs:
TRDU2x40-08L
TRDU2x40-08U
TRDU2x60-26
Cube Indoor Cabinet
1 3 55

FDD
only
eNodeB enclosures with RRH RF

Outdoor PSU Cabinet
Md4 oudoor cabinet
For BBU and transport

Network Elements
1 3 56
The outdoor PSU cabinets provide DC power supply to LTE equipments (BBU and RRHs).
They include AC/DC rectifiers, batteries, but also free space for other RAN equipments (GSM, W-CDMA,
CDMA).
Two different PSU cabinets can be used:
Md4 outdoor cabinet, offering 14U user space
S3 outdoor cabinet, offering 11U user space
The cabinet can power several telco equipments (Installed inside):
LTE BBU or other technology Controllers (W-CDMA BBU or GSM SUMX)
Transport network elements like 9600 MPR or 7705 SAR
Up to 6 external RRHs.

Cabinet 922x 1xEVDO Base Station (BS) for LTE

FDD
only
9228 Macro
Reverse OCM
+
BBU
Combined CDMA1X/EV-DO + LTE

M4.0B indoor Frame
Or
BTS-4401 outdoor with Weatherized enclosure for BBU
1 3 57
The eNodeB R-OCM configurations are supported in Modular Cell 4.0B and Compact Modular Cell 4.0B
cabinets. In Indoor Modular Cell 4.0B cabinet, the LTE BBU shares the same cabinet with CDMA
equipment.
In the case of Compact Modular Cell 4.0B outdoor cabinet, the LTE BBU is located in a separated
weatherized cabinet.
In both cases the R-OCM board is inserted in the CDMA Digital Module (CDM), in one free CCU slot (CDMA
Channel Unit).

End of module
1 3 58

14
Section 1
Overview
Module 4
LTE RAN OAM description
9400 LTE

Blank page
142
RAN TLA3.0-LA4.0 Technical Overview LTE RAN OAM description

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition

Module objectives
Describe the main 5620 SAM features for the RAN
Describe WPS and NPO functions
Explain SON features
143

144

Table of Contents
1 eUTRAN management via 5620 SAM
1.1 5620 SAM System overview
1.2 configuration Management
1.3 5620 SAM eNodeB Self Configuration
1.4 5620 SAM support of eNodeB upgrade
1.5 Offline configuration
1.6 eNodeB Licensing
1.7 eNodeB Performance management
1.8 eNodeB Troubleshooting and Supervision
2 9952 Wireless provisioning System
2.1 Overview
2.2 5620 SAM and 9952 WPS : Offline configuration
3 9958 Wireless Trace Analyzer
3.1 WTA overview
4 9959 Network Performance Optimizer
4.1 Introduction to 9959 NPO
4.2 NPO Web client
4.3 PCMD
4.4 PCMD Real Time Monitoring Dashboard
5 Self Optimization Process
5.1 Self Organizing/Optimization Opportunities
5.2 eNB Self Establishment/Configuration
5.3 Intra-LTE ANR Configuration and Optimization
1 4 5 5.4 Inter RAT ANR
RAN TLA3.0-LA4.0
Overview LTE
RAN OAM description
5.5 Technical
Automatic
Configuration
of Physical Cell ID
5.6 Cell outage detection

Page
7
8
9
11
12
13
14
15
16
18
19
20
22
23
24
25
26
27
28
29
30
31
32
33
34
35

146

147

1.1 5620 SAM System overview

GUI Client
WS
GUI Client delegate WS
Server + Database
Standby
Collocated
Distributed
Primary
Redundant solution
Standalone solution
Auxiliary
Managed Network
Collect Call trace and

Performance Management to
off-load SAM server
LA2.0
LA3.0
TLA3.0
148
eUTRAN
Reserved
Preferred
Backhaul
ePC
The 5620 SAM (Service Aware Manager) is a system that is designed to manage Alcatel-Lucent network
elements, or NEs, such as routers and switches.
A 5620 SAM system has client, server, and database components that are deployed in a standalone or
redundant configuration.
A 5620 SAM operator performs network management or system administration tasks using a GUI or OSS
client that connects to a main server. The main server sends and receives NE management traffic, and
directs optional auxiliary servers to perform intensive tasks such as NE statistics collection. Main and
auxiliary servers store information in the same 5620 SAM database.
5620 SAM runs on Solaris 10 on various SUN architecture (Intel, AMD, Sparc). As illustrated above, the
servers can be Co-located, Distributed and Georedundancy can be provided.
The 5620 SAM client runs on Windows-based PCs and Solaris-based platforms.
Citrix is supported.

1.2 configuration Management

Two mediations type are used for eNodeB 5620 SAM communications :
SNMPv3 protocol
Netconf protocol
5620 SAM sends configuration to enodeB using netconf.
EnodeB reports state information to 5620 SAM using SNMPv3
Set/Get
SNMPv3
Trap
5620 SAM
Netconf
MIB
149

1.2 configuration Management [cont.]

Physical VIEW in
navigation Tree
5620 SAM proposes various eNodeB

management view :
Physical view on navigation tree
Topology map view
Logical View of cells, sectors
Network Element
View
eNodeB Logical
View
1 4 10
5620 SAM eNodeB Element Management feature

The 5620 SAM displays the physical components that comprise an eNodeB in the existing equipment tree.
These include the following:
zeNodeB (NE Level)
zD2U (Shelf level d2U)
zControl Board (eCCM w GigE MDA)
zBase Band (eCEM)
zRRH & antenna port or TRDU

1.3 5620 SAM eNodeB Self Configuration

Pre-provision manager
creates an eNodeB
template
5620 SAM
eNodeB and pre-provisioned NE
match during eNodeB
discovery
Pre-Provisionned
NE
Activation
Manager
DB
Integration takes place based on

defined policy
Configuration data is
pushed to the
template
1 4 11
WO
This feature describes the capability of the 5620 SAM to pre-provision eNodeB equipment, activate
discovery rules, and automatically configure and upgrade the software of managed NEs.
The user is able to create a pre-provisioned configuration either offline through the WPS, or online through
the 5620 SAM pre-provisioning capabilities. The goal of the first task is to provide users with a way to
create a starting configuration in terms of release, SW load state, and configuration parameters that will be
applied on the node when it appears in the network.
The user can specify which policy needs to be applied for discovery of the node. The process flow consists
of 4 main steps:
eNodeB auto-start
SW download
configuration deployment
set administrative state to enable
This allows the user to control which steps are performed automatically, and which steps require manual
intervention from the user.

1.4 5620 SAM support of eNodeB upgrade
5620 SAM
SW
SW upgrade
policy
1 4 12
SW upgrade in 3 steps:
Software Download
Software Activation
(eNodeB reboot)
Software Accept
A framework for eNodeB SW upgrade is provided by the 5620 SAM through a policy-based mechanism. The
policy supports the following options:
z select
a set of nodes to which SW will be downloaded
z schedule
for later or immediate execution
z immediate
activation after download
By default, there are pre-created policies that represent different families of nodes or technology areas. The
eNodeB policy is represented by the RAN Policy (ID 5). The user may create new policies, or modify those
that are already present by clicking on the Create or Properties buttons (respectively).

1.5 Offline configuration

The 5620 SAM offers two methods to configure a managed eNodeB :
Online configuration : objects are directly modified in 5620 SAM GUI using Logical
Object Manager
Offline configuration : 5620 SAM applies an imported Work-Order created by the
external tool 9452 WPS
WO
Managed node
Activation
Manager
Logical object
manager
Online
configuration
Offline
configuration
5620 SAM
1 4 13

1.6 eNodeB Licensing

RAN licence manager is used to import licence
file used to authorize feature and define
capacity.
Licence consuption can be verified

per eNodeB basis.
1 4 14
The goal of this feature is to introduce a licensing mechanism for function and capacity, which are licensed
separately from the main eNodeB functionality set.
The license set that a customer purchases is produced by the LKDI and defined in a digitally signed file.
This file contains licenses that are applicable to the portion of the network that is covered by the
management scope of a single 5620 SAM platform.
This license file is placed on the 5620 SAM server and the file contents are used to control the online/offline
configuration of eNodeB features and capacities.
A licences can have an expiration date (feature license can no longer be configured).
Alarms are generated for event related to licence issues (invalid, usage expiratio, thresholds crossed,
license violations)

1.7 eNodeB Performance management

2
Policies are defined to

retrieve collected data
eNodeB automatically collects

counters and records them
1
locally at the end of the
defined collection interval
5620 SAM
SNMP
Local repository
5620 SAM retrieves collected info

at the end of collection
3
interval
5620 SAM statistics plotter
Available for external tools
9459 NPO
2
1 4 15
The eNodeB automatically starts recording performance management statistics. Counters are stored in
eNodeB memory and the writen to a file at the end of the collect interval.
The user can create 5620 SAM RAN performance management policies with different granularities for
dedicated subsets of eNodeBs to retrieve collected data on the 5620 SAM servers. The collection policies
specify:
network or service objects from which to collect statistics
counters to collect
the rate of collection
the length of time that the 5620 SAM database retains the collected Statistics
The 5620 SAM retrieves the statistics file from the eNodeB via SNMP at the end of the collection interval
that is defined in the policy. The default collection interval for statistics files is 15 min. Statistics are
collected and sent even when no counter changes are occurring on an eNodeB.
The 5620 SAM and managed eNodeBs must use a common time-synchronization server that runs a
protocol such as NTP. The retrieval of eNodeB PM statistics files by the 5620 SAM will fail when the
eNodeB and 5620 SAM real-time clocks are not synchronized.
Operators can view RAN performance management statistics using the statistics plotting framework of the
5620 SAM.
The counters can also be exported to OSS applications using the 5620 SAM-O interface (data converted to
3GPP XML format). An external system can retreive the collection via SFTP on northband interface to
integrate the results into 9459 NPO for performance monitoring and optimization.

1.8 eNodeB Troubleshooting and Supervision

eNodeB objects state
Management in
5620 SAM
Aalrm management
in 5620 SAM
Alarm
Windows
1 4 16
5620 SAM provides states and statuses repotting for the underlying Managed Objects of the eNodeB:
z Administrative
(configurable): Operational,
Status : gives info on Communication status (read-only field) and Managed state
(declared in GUI but not connected).
z Availability
z Connection
z Alignment
{
State : Offline, Not Connected, Online
Status :
softwareAlignmentStatus: used to indicate if requested SW version is running on eNodeB.
When not aligned, configuration operations are inhibited.
confAlignmentStatus: used to indicate the logical configuration alignment.
The 5620 SAM framework has been enhanced to support eNodeB-generated alarms and display them
within the alarm view in order to have one single point of alarming towards all NEs supported by the 5620
SAM (such as MME, eNodeB, SGw, and PGW). In addition, all functionalities of the 5620 SAM framework are
applicable to the alarms generated by the eNodeB (acknowledge, delete, filter, and view history).

1.8 eNodeB Troubleshooting and Supervision [cont.]

Policies define call trace
sessions (trigger conditions)
5620 SAM
Ca
2
ll t
r
ac
e
eNodeB sends call trace

messages to Aux server
CT Aux Server
Wireless Trace Analyzer
9459 NPO/PCMD
Aux Server converts

messages and adds
them to call trace file
Local repository
Traces available for external tools

1 4 17
The 5620 SAM supports call trace on eNodeB NEs. Call trace is a function that collects call-level data on an
interface. . This data can be transferred to an external system for processing and analysis, and the
resulting information can help a network operator do troubleshoot performance issues, troubleshoot device
malfunctions, monitor resource usage for capacity management or validate end-to-end network
transmission.
Call traces sessions can be activated through 5620 SAM interface and are retreived from the eNodeB to the
5620 SAM. This feature requires dedicated HW called a Call Trace Auxilliary server to be added to the
existing 5620 SAM architecture.
The activation mechanisms are schedulable, and the system allows the retrieval of data in binary format via
UDP streaming and conversion into 3GPP format for external analysis.
The 5620 SAM supports the following call-trace session types:
cell-baseda trace that the 5620 SAM initiates at operator request or as a scheduled task
event-baseda trace that begins when a specified threshold value is reached
signaling-baseda trace that the 9471 MME initiates
debuga troubleshooting trace performed by Alcatel-Lucent technical support
Call trace requires SAM-A, SAM-E and SAM-P modules.
The 5620 SAM raises an alarm when it detects a call-trace condition.
5620 SAM supports integration with Wireless Trace Analyzer in LE3.0.

1 4 18

2.1 Overview
WPS is a computer based application that simplifies :

The eNodeB provisioning & reverse engineering
Auditing of the network
Planning tools
Other WPS
WPS data sharing

and multi user
collaboration
Work-order import / export

in XML format
for interfacing
with 3rd party tools
Initial snapshot
import and
resynchronization
Work-order export
for activation
Main NM server
1 4 19
The 9452Wireless Provisioning System (9452 WPS) is a powerful tool suite that simplifies the provisioning,
reverse engineering or auditing of the network. WPS can be installed on any PC.
The 9452 WPS uses the rule sets, template and task-based wizards to hide the complexity of system
provisioning from the user while taking care of the vendor-specific and technology engineering guidelines.
Alcatel-Lucent's wireless network evolution toward further plug-and-play, self- organizing, self-optimizing
networks associated with the 9452 WPS delivers a much simplified operational system.
The Alcatel-Lucent 9452 WPS is a high-performance kernel that provides support to design and configure
Alcatel-Lucent LTE networks based on specific network recommendations. The Alcatel-Lucent 9452 WPS
offers a centralized view and configuration of all LTE RAN network elements (NEs) and parameters.
The Alcatel-Lucent 9452 WPS can be used for configuration at every stage of LTE RAN management
including:
z Data
engineering of a new network.
z Data
engineering for network expansion, additional density.
Data engineering for network optimization.
z Data
engineering for upgrade provisioning.
The Alcatel-Lucent 9452 WPS manages configuration data coming from various sources and the file format
used is CM XML.
Very large networks are supported with workable and acceptable performance. TheAlcatel-Lucent 9452
WPS supports multiple Alcatel-Lucent 5620 Service Aware Manager(SAM) servers within a Regional
Operating Center (ROC).

2.2 5620 SAM and 9952 WPS : Offline configuration

Offline Mode is used for massive change. A WO is created using WPS and is applied to
eNodeB using 5620 SAM Activation Manager.
WPS
snapshot
WO
5620 SAM server

snapshot
WO
5620 SAM
Operator
Local repository
On demand snapshot creation
or scheduled export
1 4 20
WO activation
Snapshot export
The snapshot is the current configuration of NE exported by the 5620 SAM. It can be a full configuration or
only a subset of managed objects. The snapshot data file for the eNodeB includes the following
identifications:
Hardware frame of the target eNodeB
Management information model version used to prepare the snapshot file
Specific build identity of the snapshot file
Workorder imports
The workorder is a list of configuration changes, for example, create, delete, and modify.
WPS loads a cmXML snapshot and creates workorders that contain actions/commands. The follow-up of
these configuration changes is done only in 5620 SAM. No status report is sent to WPS.
This feature provides enhancements to the area of Configuration Management by supporting the
configuration of 9412 eNodeB equipment.
In terms of off-line configuration, the 5620 SAM is able to interact with the WPS in order to exchange
configuration snapshots and workorders for bulk configuration changes.
In order to activate workorders produced by the WPS, the 5620 SAM provides a dedicated activation
manager that allows the user to manage the different sessions, import workorders, launch a wide set of
checks, and activate the changes in the network. In addition, the system provides a one-shot fallback
mechanism that allows users to revert the changes (reverse Work-order) that have been caused by
workorder activation.
Exercise
Does the SAM client an be installed on a laptop ?
yes, checking the prerequisites
no, SAM client requires Solaris based platform
Using 5620 SAM, which of the following can be observed :
Number of controller boards in the eNodeB

RRH or TRDU
Software version
S1 interface information
S6 interface information
X2 interface information
Administrative status
What does the best describe the interaction between SAM and WPS?
NEs (eNodeBs) snapshots are done by the SAM and then exported to the WPS. The WPS
uses them to compute work orders that are transmitted to the SAM and then applied to
the NEs
WPS is used to provision the NEs, the result of this provisioning is called a snapshot
which is transmitted to the SAM which applies them to the NE
1 4 21

1 4 22

3.1 WTA overview

WTA is PC or server based application used to post process call traces :
Supports eNB & MME, correlates traces

End-to-End View of Calls based on 3GPP Specifications
Supports Per Call Analysis
Combine Call Trace files by IMSI, Trace Reference, Time
WTA uses SSH to connect to NE to launch & collect call traces

MME
Call traces
activation
request
Ca
ll
tr
ac
e
Call trace
5620 SAM
CT Aux Server
1 4 23
Wireless Trace Analyzer

Pulls call traces
9958Wireless Trace Analyzer (WTA) is a post-processing and analysis tool for Call Trace data. The WTA
provides a quick way of analyzing end-to-end call scenarios that exist within any given set of traces.
The 9358 RFO used for W-CDMA optimization has evolved to the 9958 WTA (Wireless trace Analyzer), a
product used for both W-CDMA and LTE.
9958 WTA correlates trace data and provides per call trace analysis. Trace data is generated by the eNB,
9471 MME and S&P GW and analyzed by WTA (limited post-processing of S&P GW traces).
WTA supports tracing multiple UE sessions at the same time, can copy traces that match the category
that is wanted for future reuse, provides analysis reports in the form of call flow diagrams and detailed
message view.
The following interfaces are supported:
9471 MME: S1-MME, S11, S6a, S3, S10
eNB: S1MME, Uu, X2
S&P GW: S11, S5/S8

1 4 24

4.1 Introduction to 9959 NPO

The NPO offers a full range of multi-standard QoS Monitoring and radio network
optimization facilities, including:
9959 MS-NPO
QoS analysis
GSM
QoS decrease cause diagnosis
WCDMA
LTE
Radio resource configuration

tuning
Cartographic telecom
management
Performance
Reporting
Hardware inventory
management
Geographical analysis
QoS Alerter & Warning
Rules & CM Tuning
1 4 25
Diagnostic
The 9459 Network Performance Optimizer (9459 NPO) is the Alcatel-Lucent main solution for wireless
network optimization.
The 9459 NPO toolset enables QoS diagnostics, correlation of performance and configuration, QoS tuning is
based on network performance collection across multi-standard wireless networks (2G/3G/LTE).
The 9459 NPO includes advanced reporting functions and is intended for deployment at a regional level to
complement the capabilities of national network optimization solutions.
NPO is a GUI driven Alcatel-Lucent application with the flexibility for reporting (drag and drop, markers, and
so on) and creation of indicators. It offers the following multi-standard QoS monitoring and radio network
optimization facilities:
Powerful GUI supporting all the efficient use of the MS-PO functions
QoS analysis
Customizing
This product includes a powerful Oracle database containing performance measurements and calculated
indicators.

4.2 NPO Web client
QoS analysis
Cartography
Radio tuning
1 4 26
The NPO client represents a PC machine running on Windows XP Professional SP2 or Windows Vista
operating system.Java 1.6 (JRE and JDK) and the Flash Player software must be installed on the NPO
Client.
The web client application allows the operator to browse the NPO topology and functions, and to execute
classical views and reports for a quick analysis of daily checks without running the NPO Analysis Desktop.
The main operations available with the web client application are:
z In
a web navigator, the operator can browse the topology and functions to set a double selection, and
then the operator can execute an interactive view, as in the Analysis Desktop
z Added
search facilities help the operator to perform selections
z The
operator can store selections as favorites. The web client provides a selection cart, which is a
preset of topology elements and function elements, in order to facilitate the use of selection lists.

4.3 PCMD
PCMD (Per Call Measurement Data)

New module integrated in 9959 NPO, from LE3.0
new processing functions in the MME and in the eNodeB's
Its main purpose is to provide:

PCMD Statistics: Advanced KPIs to better reflect end-user experience
Break-down: Deep investigation possibilities during QoS troubleshooting
Browser/RT: Detect problems that would remain unseen otherwise
5620 SAM
UE 1
UE 2
B counters
statistical EN
UE activity
PC
MD
UE activity
PC
MD
(E
NB
)
t
sta
(E
NB
)
l
i ca
ist
Ec
MM
rs
nte
ou
cla
ssi
ca
lP
M
file
PCMD (MME+ENB)
MME
PCMD (MME+ENB)
NPO
animated slide
1 4 27
NPO without Per Call Measurement Data (PCMD)

NPO without Per Call Measurement Data (PCMD) comprises:
A main server. This server supports the oracle database and the reporting functions.
An optional QoS auxiliary server. This server hosts the loading process that converts the 3GPP PM file
into a format that can be directly loaded into NPO Oracle tables.
The main server stores the data. The auxiliary server stores the file while they are being loaded. Backup
and restore procedure only applies to the main server. NPO client are either Windows PC or Windows server
running Citrix.
NPO with Per Call Measurement Data (PCMD)
NPO with Per Call Measurement Data (PCMD) requires:
A connection to MME from both NPO main server and NPO auxiliary servers.
For 12K cells and above, dedicated NPO auxiliary server(s) are required for PCMD.

4.4 PCMD Real Time Monitoring Dashboard

Focus on
FCA & CD
only (raw +
Based on
last 60
values
rate)
1 line
per MME
Highlight
based on
Threshold
MME 1
One or
more
charts
FCA%
CDR%
: last 10 mn
One or
more MME
per chart
Chart
area can
be hidden
MME 2
MME 3
FCA%
CDR%
: last 40 mn
Zoom
(Nice to have
Step 2)
1 4 28

1 4 29

5.1 Self Organizing/Optimization Opportunities
1 4 30
Overview
Self Optimizing Network (SON) feature introduced in 3GPP Release 8 reduces the operating expenditure.
The objective is to minimize pre-provisioning, manual network planning and human intervention during LTE
network deployments.
The SON features are implemented using the centralized solution technique. Centralized SON is a SON
solution, wherein SON algorithms are executed in the OAM system. In such solutions, the SON functionality
resides in a small number of locations, at a high level in the architecture.
In the Alcatel-Lucent LTE solution, all the mechanisms and SON algorithms are implemented either in
eNodeB, SAM, WPS, NPO or other OAM tools. Centralized automatic allocation of PCI is one of the features
of SON. It automatically allocates a PCI value for each cell from the OAM system, and ensures the
uniqueness within the area of the neighbor cells and the neighbors neighbor cells.
There are 504 unique physical-layer cell identities. A physical-layer cell identity is uniquely defined by a
number in the list of 0 to 167, representing the physical-layer cell-identity group, and a number in the list of
0 to 2, representing the physical-layer identity within the physical-layer cell-identity group.
The physical cell identity is used in the generation of the cell-specific reference signal, as well as the
primary and secondary synchronization signals. The physical cell identity must be unique within a given
region, as it is used to identify a cell in the UE eNodeB interactions.

5.2 eNB Self Establishment/Configuration

4
MME
5620 SAM
eNodeB Discovery :
connection established.
Authentication with SNMPV3
eNOdeB
1
preparation
DHCP
Server
Security
Gateway
OAM checks the SW

version on the eNB if
an upgrade is needed
then send the SW to
the eNB
8
eNB configuration
activation
3 DHCP provides: OAM

IP@ configuration
Mobile Core Network
9
eNB is establishing an IPsec
tunnel to the security gateway
and connect to MME
IP Network
2
6
7
1 4 31
eNodeB power up
eNB is rebooting
eNB is making a self test
z This
feature describes a range of requirements for the automatic self-configuration of the eNB during
initial deployment or subsequent upgrades. It includes a number of distinct functions:
eNB Self-Test
Plug-and-play eNB
Auto eNB Authentication
Automatic download of eNB Parameters from OMC
Automatic inventory
Auto SW Download
z Driving
towards zero-touch comissioning LTE eNB, this feature reduces the planning&deploymentrelated CAPEX and OPEX of the operator by automating the currently manually intensive tasks of
deploying, initial configuration and subsequent configuration updates of a deployed eNB. In addition it
will further speed up the time between the eNB switch on and the eNB becoming operational. Rollout
Time To Market shall be reduced allowing faster profitability.

5.3 Intra-LTE ANR Configuration and Optimization

eNode request UE measurement and UE
sends info on PCI to eNodeB
Cell A : PCI 3 , Cell

Global ID 17
Optional: Neighbour List

for initial NRT:
White and black lists
2 check
UE reports that
PCI 5 has strong
Signal
FDD
only
Neighbour Relations Table

(NRT) per cell
5620 SAM
Check operator preferences
before NRT table
3 update
X2
MME
Cell B : PCI 5 , Cell
Global ID 19
Served Cell information sent

over X2 interface
eNodeB retrieves neighbor IP address for dynamic X2

configuration, MME acts as relay
1 4 32
LA4.0 supports Intra-LTE ANR ANR functionality (L81872 and L108172).

The eNB is able to autonomously generate and manage its own intra-frequency neighbor relation
tables (NRTs) by requesting UE to report neighbors identifiers (PCI, CGI) and/or by sharing infos with
another eNB through an X2 connection. The operator can keep full control (in particular White and
Black lists are supported) from the 5620 SAM. Note that the feature requests the ability to setup S1-AP
connections between eNB and ePC to retrieve the IP@ of the neighboring eNB, when x2 connection is
requested.
As a component of Self Organizing Network functionality this feature benefits the operator by reducing
the planning & deployment-related CAPEX (when ANR is played at new site integration), but also OPEX
as it will work as an autonomated Planning Optimization tool on a daily operational basis. Network
rollout and upgrade, plus Time to Market are shortened.
5620 SAM ENB synchronization ensures that data is consistent between 5620 SAM and eNB. It is
triggered by 5620 SAM after the eNB notifies what is changed on eNB configuration regarding SON
configuration to the 5620 SAM server via a specific event reporting mechanism, at anytime.
The event reporting mechanism is used by eNB only if eNB configuration has been updated by one of
the features IRAT ANR, intra-LTE ANR, or PCI Allocation, Conflict Detection and Correction.

5.4 Inter RAT ANR

eNodeB request UE measurement for
UTRAN frequency
FDD
only
UE reports new Primary Scrambling Code
UE reports
strongest cell for
given UTRAN freq
2 check
Optional: Neighbour List

for initial NRT:
White and black lists
Neighbour Relations Table

(NRT) per cell
5620 SAM
LAC and RAC present in CGI report used by

eNB to add UTRAN neighbor relation
in NRT.
4
Check operator preferences

before NRT table
3 update
NodeB
1 4 33
EUTRAN can automatically generate and manage neighbor relation tables that include UMTS neighbours
(L108084.1) : inter-RAT automated neighbor list information are obtained only from UE measurements
since there is no X2 interface to IRAT neighbors.
In order to discover unknown UTRAN neighbors, the eNB must provide UEs with a measurement
configuration to report the strongest cells for a given UTRAN frequency. One of the main difference
between inter-RAT and LTE ANR is the fact that event-triggered measurement reports cannot apply to
inter-RAT. Inter-RAT ANR measurements need to be re-configured periodically to ensure efficiency of the
ANR function.
When a new UTRAN neighbor (FDD only) is discovered (meaning Primary Scrambling Code received in the
measurement report is unknown to the eNB), the eNB will ask the UE to perform the CGI reporting
procedure.
LAC and RAC are present in the measurement report received from the UE, they are used to characterize
an UTRAN neighbor relation. The new neighbor will automatically be added as an
UtraFddNeighboringCellRelation object in the NetConf MIB. As soon as an UTRAN neighbor has been added
in the NetConf MIB, it can be used for inclusion in UTRAN inter-RAT mobility measurements configured to
the UEs. This is exactly same behavior as if the neighbor relation would have been created online by the
operator through the OMC.
Each time an UTRAN neighbor relation has been discovered, it needs to be associated to the RNC serving
the target cell in order to make possible outgoing mobility towards UTRAN. The ANR function will support
retrieving RNC id from cell id.
5.5 Automatic Configuration of Physical Cell ID

FDD
only
UE connected on one cell

but highly interfered by
the other
PCI algo
UE reports measurement
but Source eNodeB is
confused with provided
PCI
Collision Free:
CellID unique to immediate neighbours
1 4 34
PCI algo
Confusion Free:
CellID unique to neighbours neighbours
A physical-layer cell identity must be allocated to each cell, it is defined by a physical cell-identity group and
physical identity within the group (from 0 to 2). There are 504 PCIs available per network. This identity is
the cell identity on radio side. For PCI allocation, there are constraints related to not reusing the same
value among a given cell and its neighbours.
The PCI SON feature is used to select and configure a PCI value for each cell, taking into account
constraints, detect potential conflicts and solve these conflicts autonomously.
The eNB shall use a list of allowed PCI values received from the OAM and use any incoming information
(from connected UEs and neighbor eNodeBs) to eliminate values that would already be in use by neighbor
cells and choose randomly one of the values that remain free to use.
This highlights the dependency between this function, dynamic X2 configuration and ANR.
PCI collision: two cells that are neighbors share the same PCI. Consequence: At best, a UE will be able to
access one of the cells but will be highly interfered.
PCI Confusion : when a cell has two neighbors sharing the same PCI, the eNB knows of only one cell and
could trigger a UE handover to that cell, whereas the UE may have been reporting the other cell. This may
lead to a high number of handover failures and ultimately, call drops

5.6 Cell outage detection

A sleeping Cell is a cell that shows no alarms that indicate an outage, but that
cant support a call : the EnodeB supports a Cell outage detection and
reporting mechanism based on a timer expiration.
No RRC connected UE :
sleepingCellInactivityTimer
timer is triggered
Last UE leaves
coverage area
Expiracy
Timer needs to be finetuned to avoid

excessive alarms
reporting
5620 SAM
Sleeping cell
alarm raised
UE back in cell
covergae (RRC
connection)
5620 SAM
Sleeping cell
alarm cleared
In the future, the sleeping cell information will be used by the SON
compensation mechanism to realize self-healing.
1 4 35
FDD
only
Unplanned Outages can be hardware/software failures, external failures (such as power failure, S1
failure). This kind of outage is accompanied by alarms, but for Sleeping Cells, there is no standard failure
indication.
If the cell is enabled and is not locked (no planned outage), barred, or reserved and the last call ends (no
more RRC connected UEs) a specific timer set to sleepingCellInactivityTimer starts :
If a UE successfully connects with the cell, then stop the timer
If the timer expires, raise a MAJOR alarm that is visible at 5620 SAM
If a UE successfully connects with the cell while the sleeping cell alarm is set, then clear the alarm
If the value of parameter sleepingCellInactivityTimer is 0, then the feature is disabled.The value must be
tuned for each cell, depending on the expected traffic levels, to avoid excessive alarms.
In the future, the sleeping cell information will be used by the SON compensation mechanism to reconfigure
the network to reduce the outage impact.

End of module
LTE RAN OAM description
1 4 36

Last but one page
Congratulations
You have finished the training
Your feedback is appreciated!
Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the training reference in your email (see cover page)
Thank you!
All Rights Reserved Alcatel-Lucent @@YEAR
@@PRODUCT
@@COURSENAME

@@COURSENAME - Page 1
All rights reserved Alcatel-Lucent

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
@@COURSENAME - Page 2

LA4.0 LTE RAN Technical Overview PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

LA4.0 LTE RAN Technical Overview PDF

Hochgeladen von

Copyright:

Verfügbare Formate

9400 LTE

RAN TLA3.0-LA4.0 Technical Overview

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Passing on and copying of this document, use and communication of its

Terms of use and legal notices

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

7. Topic/Section is Positioned Here

2. LTE Transport overview

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Upon completion of this course, you should be able to:

Welcome to 9400 LTE

Describe functions and the architecture of an LTE Access network

Describe the portfolio of the Alcatel-Lucent LTE Radio equipment

Upon completion of this course, you should be able to:

functions and the architecture of an LTE Access network

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Your feedback is appreciated!

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Do not delete this graphic elements in here:

TMO18213_V4.0-SG-Ed10 Module 1.1 Edition NA

All Rights Reserved Alcatel-Lucent 2012

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

RAN TLA3.0-LA4.0 Technical Overview LTE eUTRAN Overview

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Module objectives [cont.]

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Table of Contents [cont.]

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1 EnodeB functions and protocols

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1 EnodeB functions and protocols

1.1 eNodeB functions

EPS Bearer Control

Ref 3GPP TS 36.300

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

associated to the data (real time, guaranteed bit rate),

It controls the creation, modification and release of the radio bearers,

list management (for UE in idle and active mode);

handovers to 2G or 3G 3GPP access networks,

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1 EnodeB functions and protocols

1.2 LTE-Uu Radio interface

Non Access Stratum

COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

PCH: Paging Channel

PCCH: Paging Control Channel.

BCH: Broadcast Channel.

BCCH: Broadcast Control Channel.

MCH: Multicast Channel.

CCCH: Common Control Channel.

DLSCH: Downlink Shared Channel.