LTE (T) LA5.0 EUTRAN Technical Overview

9400 LTE
(T)LA5.0 eUTRAN Technical Overview

Student Guide
TMO18213_V5.1-SG Edition 12
COPYRIGHT ALCATEL-LUCENT @@YEAR. 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 to notes view!

TERMS OF USE 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
2 who have licensed and/or contributed to the Content, owns a copyright in the formatting and presentation of the
COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.
Content.
@@PRODUCT
@@COURSENAME
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
works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way
exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited 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
1.Welcome to 9400 LTE

eUTRAN Technical Overview 4. Topic/Section is Positioned Here
1. LTE eUTRAN
(T)LA5.0 eUTRAN Overview
Technical Overview
5. Topic/Section is Positioned Here
2. LTE Transport Overview
1.3.
eUTRAN Technical Hardware
LTE eNodeB Overview Description
6. Topic/Section is Positioned Here
1. LTE eUTRAN Overview
4. LTE eUTRAN OAM Overview
2. LTE Transport Overview 7. Topic/Section is Positioned Here
3. LTE eNodeB Hardware Description
4. LTE eUTRAN OAM Overview
3 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

@@PRODUCT
@@COURSENAME

Course objectives
z9400 LTE
Upon completion of this course, you should be able to:
Describe functions and the architecture of a LTE Access network
Describe the IP transport layer in the radio Access Network
Describe
Upon the portofolio
completion of the Alcatel-Lucent
of this course, you should be LTE
ableRadio
to: equipment
Describe the eNodeB Operation and Maintenance Principles
z Describe functions and the architecture of a LTE Access network

z Describe the IP transport layer in the radio Access Network
z Describe the portofolio of the Alcatel-Lucent LTE Radio equipment
z Describe the eNodeB Operation and Maintenance Principles

@@PRODUCT
@@COURSENAME
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!

@@SECT
Do not delete this graphic elements in here:
Section 1
eUTRAN Technical Overview
Module 1
LTE eUTRAN Overview
TMO18213_V5.1-SG-(T)LA5.0-Ed12 Module 1.1 Edition N/A
LE
9400 LTE
All Rights Reserved Alcatel-Lucent @@YEAR

Section 1 Module 1 Page 1
Blank page

eUTRAN Technical Overview LTE eUTRAN Overview
9400 LTE (T)LA5.0 eUTRAN Technical Overview
This page is left blank intentionally
Document History
Edition Date Author Remarks
10 2012-02-01 Vincent, Cecile Edition 10
11 2012-10-15 Andonian, Ikram V5-Edition 11
12 2012-12-28 Andonian, Ikram V5-Edition 12

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
List the main LTE new mobile services
Describe eNodeB advanced features, (common to FDD et TDD, dedicated to
FDD or to TDD)


Module objectives [cont.]


Table of contents
Switch to notes view! Page
1 EnodeB functions and protocols 7

1.1 Overview Of LTE Network Architecture 8
1.2 eUTRAN & ePC Functions 9
1.3 eUTRAN Protocol Stack 10
1.4 ePC Protocol Stack 11
1.5 MME Overload Indication support 12
1.6 eNodeB Reliability 14
2 LTE Network Services 20
2.1 Public Warning Service (PWS) 21
2.1.1 PWS Functions In LTE Network 22
2.1.2 CMAS principles 23
2.1.3 SBc Protocol Stack 24
2.2 RAN Sharing Model In LTE 25
2.2.1 Multi-operator Core Network (MOCN) 26
2.3 Beamforming 27
2.4 eMBMS 29
2.4.1 eMBMS interfaces 30


Table of contents [cont.]


1 EnodeB functions and protocols


1.1 Overview Of LTE Network Architecture
HSS
S6a
MME PCRF
S1-MME Rx
S10
S11 Gx
PDN
Serving PDN (Operators IP
eUTRAN S1-U
Gateway
S5
Gateway
SGi services:
UE Internet, MS,..)

LTE network which is a Packet switched (PS) only system and is all-IP, because every standardized
interface is based on a protocol stack where L3 is IP.
The Evolved Packet System provides IP connectivity between a UE and a PLMN external packet data
network and is referred to as PDN Connectivity Service.
The LTE architecture can be further described as follow:
The E-UTRAN consists of set of eNodeBs connected to the EPC through the S1.
eNodeBs can be interconnected through the X2.
S1 and X2 are logical interfaces.
The E-UTRAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL)
S1-MME: Reference point for the control plane protocol between E-UTRAN and MME.
S1-U: Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and
inter eNodeB path switching during handover.
S5: It provides user plane tunneling and tunnel management between Serving GW and PDN GW. It is
used for Serving GW relocation due to UE mobility and in case the Serving GW needs to connect to a non-
collocated PDN GW for the required PDN connectivity.
S6a: This interface is defined between MME and HSS for authentication and authorization.

1.2 eUTRAN & ePC Functions
eUTRAN ePC
eNodeB MME
NAS Security
Dynamic Resource
Allocation(Scheduler) Idle State Mobility
Handling
RB Control
EPS Bearer Control
RRC Connection
SGW PGW
Admission control
UE IP address
allocation
Measurement Mobility
Configuration Anchoring
Packet Filtering

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.3 eUTRAN Protocol Stack
Control Plane User Plane
(eNodeB & MME) (eNodeB & SGW)
(eNodeB&eNodeB)
(S1 or X2)- AP User Plane PDUs
GTP-U
SCTP UDP
IP IP
Data link Layer Data link Layer
Physical Layer Physical Layer
1 1 10 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

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.

1.4 ePC Protocol Stack
Control Plane User Plane
GTPv2-C Diameter User Plane PDUs
GTP-U
UDP SCTP UDP
IP IP IP
Data link Layer Data link Layer Data link Layer
Physical Layer Physical Layer Physical Layer
SGW & PGW SGW &PGW

MME& HSS
MME & SGW

GTPv2-C is used on the following standardized interfaces:

SGSN-MME S3
SGSN-SGW S4
SGW-PGW S5-S8
MME-MME S10
MME-SGW S11
MME-MBMS GW Sm
Diameter is used on the following standardized interfaces:

MME-HSS S6A
MME-EIR S13
PGW-PCRF S7 (Gx)
MME-GMLC SLg
GTP-U is used on the following standardized interfaces:

SGW-PGW S5-S8

1.5 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
S1AP message with Overload start

indication sent to the eNodeB
UE MME 1
art
lo ad st
Over
MME 2
Selection algo. takes MME1 Overload

situation into account UE IMSI based
attach request sent to MME2

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.5 MME Overload Indication support [cont.]
MME Overload Indication method is also used to request the eNodeB to reduce
signaling load to MME :
MME
2
Tracking Area Up
request including date Overload start
GUTI
Overload action included
ion rejected Overload start indication contains reject

RRC connecttime set) all RRC connection establishments for
(w ai
signalling
Service request from UE attached on this

MME for Emergency call service can still
be sent to the MME
Tracking Area Up
request includin date Overload stop
g GUTI MME
2
S1AP (NAS TAU Re
quest)

Following mapping is performed between Overload Action and RRCConnection Establishment Cause
(EC)values:
RRC Connection Establishment cause

emergency highPriorityAccess MT Access MO Signalling MO Data
Overload Action
reject all RRC connection establishments for
non-emergency mobile originated data accepted accepted accepted accepted rejected
transfer
reject all RRC connection establishments for
accepted accepted accepted rejected rejected
signalling
Permit emergency sessions and mobile
accepted rejected accepted rejected rejected
terminated services only
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

1.6 eNodeB Reliability
>> The eNB Reliability target for LA5.0
The standard configuration shall have a minimum total system availability of 99.995%.
Total MTTR of 2.0 hrs
Time to complete a software reboot shall be 2 minutes and 30 seconds (This duration
shall be reached for 99% of the reboot occurrences)
eNB Software upgrade success ratio: 99,9%
eNB Software Upgrade Outage: < 2 mn 30 seconds
Warm Reset (Without SW activation): 2 minutes 30 s (with GPS & 1588 & SyncE)
eNB Software Upgrade Outage (Reboot Time):2 minutes 30 s (with GPS & 1588 &
SyncE)
eNB number of SW upgrade 2 per year
eNB availability (Partial and full outage) 99.995%"


Answer the Questions
Link the interfaces or protocols names and the concerned peers :
Name of the Between

interface
S1-U Two eNodeBs for signaling
NAS UE and MME
LTE-Uu UE and eNodeB
GTP-U Two eNodeBs for data
RRC eNodeB and MME
S1-MME eNodeB and SGW
Note : Multiple matches can be defined on the right table.


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


What are the two main uses of MME overload indication procedure ?
To stop sending signalling traffic to an overloaded MME,
To reduce the signalling load to a MME,
To avoid any new attach on an overloaded MME,
To indicate the eNodeB to suppress MME attached UE contexts.


Answer the questions
1- What are the advantages of MIMO techniques?
a)Increase throughput
b)Increase SNR
c)Simplify eNodeB algorithms
2- What are the transmission techniques used in LTE network?
a)Rx diversity
b)Tx diversity
c)DL_MiMo Single user
d)UL_Mimo Multiple User
e)DL_MiMo Single user
f)UL_Mimo Multiple User


What does LA5.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


2 LTE Network Services


2.1 Public Warning Service (PWS)
The public warning system cell broadcast enables sending out a short message to
all handsets in a particular cell, group of cells, or the entire network.
Every handset that has a listening CB channels enabled and is within the coverage area
of cells that are broadcasting a CB message, will receive this message.
PWS
(Public Warning Services)
CB CMAS
(Cell Broadcast) (Commercial Mobile Alert System)
Using Cell Broadcast (CB) technology and the CMAS (Commercial Mobile Alert
System) recommended as standardized network architecture, allows cellular
subscribers to be alerted based on their location at the time of the alert even
when the network is congested.

CMAS system in Japan or US country is deployed to allow federal agencies to accept and
aggregate alerts from first the President, the National Weather Service (NWS) and emergency operations
centers (EOCs), then send the alerts to participating wireless providers who will distribute them to their
subscribers.
Cell Broadcast is location specific; only people in the disaster area, to whom it concerns, are
contacted; enabling real-time crowd control, guiding them to safety.

2.1.1 PWS Functions In LTE Network
Alert Delivery
Alert Origination
CMSP
Gateway
3
1
CMSP
(Commercial Mobile Service Provider )
Federal Agencies
CBC
2
SBc
Alert
Alert Aggregation
Gateway
MME
Local
EOC
S1-AP enhancement to receive and respond to

CMAS warning notification from the MME.
Air interface modifications to support the
delivery of CMAS alerts to CMAS capable UEs
including SIB 12 setting.

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. It 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 (Broadcast
Message Center) 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).

2.1.2 CMAS principles
The CMAS (Commercial Mobile Alert System) is the principal alert system
CBC that allows broadcasting short messages to UEs present in specific cells of the
network. It relies on SIB12 transmission.
SBc
The MME selects the appropriate eNB(s) based on information provided by the
CBC for the purpose of CMAS message distribution and forwards these messages
MME to the selected eNBs.
The eNB Determines the affected cells from the notification list in the
message.
S1-
MME For each affected cell, it:
Schedules the transmission of SIB12,
Indicates the scheduling of the SIB 12 in SIB,
Prepares SIB12 which contains the CMAS notification message then begins
transmitting SIB12 over the air interface on the schedule indicated.
The eNB uses RRC Paging to alert CMAS-capable UEs of the presence of CMAS
notification broadcast(s) information.

The CMAS Feature adds three parameters:

At Enb level it requires the activation of the CMAS feature and for this purpose a licensing
token must be available at SAM before setting this feature.
At LteCell level parameter that provides the emergency areas that are supported by the
associated cell. If no Warning Area List is received from the MME, the eNB will broadcast the
CMAS notification on all of its cells.
On the S1 interface between the MME and the eNB , there are three ways in which the broadcast area
can be defined:
as a list of cells
as a list of TAs
As a list of Emergency Areas.
The method used will be determined between the operator and the emergency service provider.
The purpose of the Kill procedure is to cancel an already ongoing broadcast of warning
message.

2.1.3 SBc Protocol Stack
The SBc interface is the reference point which lies the cell broadcast center (CBC)
and the MME for warning delivery and control functions.
MME CBC
SBcAP SBcAP
SCTP SCTP
IP IP
Data link Layer Data link Layer
Physical Layer Physical Layer
SBc

The SBc-AP is the application between the MME and the Cell Broadcast Center (CBC) and is used to
transport messages associated with the Warning Message Delivery function.
Transport Rule:
supports IPv4, IPv6, or IPv4 and IPv6 addressing
Recommended port for Sbc is the SCTP port 29168 SBcAP is defined in 3GPP TS 29.168.

2.2 RAN Sharing Model In LTE
Evolved Packet Core (A) Evolved Packet Core (B)
Optional
Shared MME/ SGW Shared MME/ SGW Shared MME/ SGW
S1 Flex
S1
Common Shared eUtran

Two different network sharing architectures are described in 3GPP TS 23.251 recommendation: Multi-
Operator Core Network (MOCN) and Gateway Core Network (GWCN)
In MOCN, only the radio resources are common to 2 or more operators. The ePC elements are
not shared. S1-flex interface allows for a single eNodeB to be connected to several ePCs and/or several
MME and SGW in a given ePC.
In GWCN architecture, some elements of the Core (MME/SGW) might also be shared by several operators
(in addition to radio resources)
Both mechanisms, MOCN and GWCN, are supported in LE5.0

2.2 RAN Sharing Model In LTE
2.2.1 Multi-operator Core Network (MOCN)
In Multi-Operator Core Network (MOCN) architecture, the following network resources may
be shared by 2 or more operators based on mutual agreement:
RAN equipments: including base stations, antenna and other radio assets
Radio spectrum: independently of which operator own the spectrum license.
Backhaul transmission: optionally shared or not The figure illustrates the MOCN
concept where operators A and B share a eUTRAN portion as well as deploying its own
dedicated radio resources.
PlmnA PlmnB PlmnA PlmnB

frequency frequency
f1 f2 f1 f2
Dedicated Spectrum
Plmn A&B
frequency
f1+f2
Shared Spectrum

The spectrum allocated to operators involved in a RAN sharing agreement might be dedicated or shared.
In dedicated spectrum mode, available spectrums are partitioned with portions dedicated to each
partner operator.
This mode of sharing may lead to denial of service to one operators subscribers
when its entire spectrum is in use, while there is still available bandwidth in the partners spectrum.
In shared spectrum mode, available spectrums are pooled and accessible to all subscribers of the
partner operators. This mode of sharing provides more efficient use of the radio spectrum. However,
depending on the resources allocation strategy selected, fairness cannot be guaranteed if subscribers of
one operator overload the shared carrier.

TDD
2.3 Beamforming Only
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

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

TDD
2.3 Beamforming [cont.] Only
Beam Forming is operated with broadband dual polarization smart antennas.

These antennas are 2 x 4 array cross polarized antenna panel with calibration port.
TLA5.0 supports 8x antenna beamforming using TD-RRH8x5-26 module.
2x4 Array cross-

Sector 1 polarized antenna
8 ANT TX/RX
RF module RRH

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;

TDD
2.4 eMBMS Only
e-MBMS (Multimedia Broadcast Multicast System) is transport feature to send the
same content to a given set of users.
Tight synchronization Content provider data

needeed on eNodeB
BM-SC
eNodeB MBMS GW
MCE Allocates radio

UE ressources
UE sees group of cells as a

single cell : the MBSFN area
eNodeB 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.

2.4 eMBMS
TDD
2.4.1 eMBMS interfaces Only
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 1
M3
Sm
BM-SC
Content provider data
SGmb
M2
SGi-mb
M1 MBMS GW
1
Service
announcement
UE Session
3
eNodeB start/stop
2 Service joining
4 Service leaving

M1 Interface between MBMS GW and eNodeB is a user plane interface used to transport user IP
Multicast flows.
M2 Interface between MCE and eNB: is used to convey radio configuration data for the multi-cell
transmission and Session Control Signalling. M2 is SCTP based.
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.
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.

1- Please check TRUE or FALSE for each of the following:
TRUE FALSE
The public warning system cell broadcast enables sending out a short
message to all handsets in a particular cell, group of cells, or the
entire network.
The SBc interface is the reference point which lies the cell broadcast center
(CBC) and the eNodeB for warning delivery and control functions.
The CBC selects the appropriate eNB(s) based on information provided by

the MME for the purpose of CMAS message distribution and forwards
these
messages to the selected eNBs.
Using Cell Broadcast (CB) technology and the CMAS (Commercial
Mobile Alert System) recommended as standardized network
architecture, allows the VIP subscribers only, to be alerted based on
their location at the time of the alert even when the network is
congested.


2- What are the benefit of eUTRAN sharing configuration?

3- How many configurations of eUTRAN sharing are supported?
4- What are the benefits of each configuration?
5- How the spectrum is managed in the case of eUTRAN Sharing?


6- What is the difference between eMBMS and CMAS ?

7- Could eMBMS replace CMAS ? Why?
8- From the following list, please select the three interfaces that has the eMBMS
GW?
a) S1-AP, M1, M2
b) SGmb, M2, Sm
c) Sm, M1, M2
d) Sm, M1, SGmb


End of module
LTE eUTRAN Overview


@@SECT
Section 1
Module 2
LTE Transport Overview
LE
9400 LTE

Blank page

eUTRAN Technical Overview LTE Transport Overview
Document History
10 2012-02-01 Vincent, Cecile
11 2012-10-15 Ikram Andonian Edition 11
12 2012-12-28 Ikram Andonian Edition 12

Module objectives
Describe the eUTRAN transport architecture,

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




Table of contents
1 LTE Transport Network Requirements 7

1.1 Layer2/Layer3 Transport Requirement 8
1.2 7705 SAR-F 9
1.3 Aggregation With 7705 SAR-F 10
1.4 Physical Backhaul Connectivity 11
2 VLANs Configurations & IP Addressing 14
2.1 No Vlan Configuration 15
2.2 One Vlan Configurations 16
2.3 Two Vlans Configurations 17
2.4 Third VLAN in TDD Configurations 18
2.5 Four Vlans Configuration 20
2.6 eUTRAN Sharing Vlan Configuration 21
2.6.1 Supported Configurations For The Master Operator 22
2.6.2 Supported Configurations For A Non Master Operator 23
2.7 IP Addressing 24
2.8 DHCP Process 27
3 IPSec 31
3.1 UE Security 32
3.2 Transport Security Gateway In LTE network 34
3.3 IPSec Traffic Flow 35
3.4 IPSec LTE Specifications 36
3.5 IPSec LTE Configurations 37
1 2 5 3.6 IPSec LTE Policies 38
3.7Overview
IPSec LTEeUTRAN Sharing Configuration
eUTRAN Technical Transport Overview
41
4 QoS 44
4.1 Main QOS functions and mapping on LTE NE 45
4.2 QoS mapping on Bearers 46
4.3 Standardized QoS characteristics 47
4.4 QoS mapping on transport network 48
4.5 Traffic Management Functions 49
4.6 eNodeB traffic Management 50
4.7 eNodeB UL traffic Shaping 51
4.8 eNodeB UL traffic Shaping 52
5 eNodeB Call Admission Control 56
5.1 Call Admission Control 57
5.2 Radio Admission Control 58
5.2.1 Radio CAC Criteria 59
5.2.2 Reactive Load Control 60
5.3 eNodeB Call Admission: T-CAC 61
5.3.1 T-CAC Algorithms Triggers 62
6 Synchronization 67
6.1 High Level Overview 68
6.2 Synchronization Need For Handover 70
6.3 Possible solutions 71
6.4 Synchronization need for TDD systems 73
6.5 Synchronous Ethernet 74
6.6 PTP principles 75



1 LTE Transport Network Requirements


1.1 Layer2/Layer3 Transport Requirement
Layer 3 Requirement Layer 2 Requirement
IP v4 and possibility to migrate to IPV6 Support of Jumbo frame
DSCP, traffic shaping and policing Ethernet 802.1Q for VLAN segregation
IP header compression OQS support at layer 2 with PBit (802.1p)
IP fragmentation and assembly security of traffic
IPSec to secure the L3 layer
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 Backhaul
PCRF
MME PDN GW
SGW Evolved Packet
Core (IP)

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.

1.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.
P-GW S-GW
EPC MME PCRF
Applications
IMS
Ethernet HLR/HSS
HLR AAA
ATM Backhaul
7710/
7705 7750SR
Internet
Aggregator
TDM
RNC
BSC

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

1.3 Aggregation With 7705 SAR-F
3G/LTE NodeB
Cabinet
ePC
NodeB MME
PCRF
nxE1 eNodeB
(ATM) SGW PGW
7705 SAR-F
Backhaul UTRAN
RNC

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.

1.4 Physical Backhaul Connectivity
This Gigabit Ethernet interface is provided through the use of the GiGE MDA which
is the daughterboard of the eCCM.
SFP1, SFP2, RJ45
Gigabit Ethernet (MDA)

2 SFP cages for optical GE
1 RJ45 for electrical GE
The GE MDA provides on the face plate three GE ports, two SFP cages and one
RJ45.
Each SFP cage can be equipped with an optical or electrical TRX.
eNodeB only enables one ETH PHY device of GE-MDA.
.
In case of detection of an optical interface within the SFP2 cage, the SFP is used
instead of the Electric RJ45 which is invalidated.

Note: The choice was done to enable the ETH PHY which handles SFP2 and RJ45.
SFP1 can't be used at all.
SFP2 or RJ45 are mutually exclusive:
The default Ethernet backhaul interface is the electrical RJ45.
MDA: Media dependent adapter

1- Which of these equipment do you choose to aggregate ATM and IP traffic on

radio site:
a) 7705 SAR
b) 7750 SR
c) 7450 ESS
2- Which technique allows to handle ATM, TDM and Frame Relay over Packet
Service Network?
a) Encryption
b) Pseudowire
c) Aggregation


3- Check the correct sentence from the following:
a) The GE MDA provides on the face plate fours GE ports, two SFP cages and
two RJ45.
b) The GE MDA provides on the face plate three GE ports, three SFP cages.
c) The GE MDA provides on the face plate three GE ports, two SFP cages and
one RJ45.
d) The GE MDA provides on the face plate fours GE ports, three SFP cages and
one RJ45.


2 VLANs Configurations & IP Addressing


2.1 VLAN: Configuration
2.1 No Vlan Configuration
VLANs are used to separate different nature of traffic.
The eNodeB supports following configurations :
No VLAN configuration
S1
GigE X2
IPV4 addressing only
OAM
Only one configuration is supported with untagged Ethernet frames

1588 & M1-U are not supported with untagged Ethernet traffic
No VLAN
OAM S1-U S1-C X2-U X2-C M1-U 1588
Config 1 IPv4@1 IPv4@2

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.
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.

2.2 One Vlan Configurations
VLAN tagging used to carry
L2 QoS priority
S1
X2 IPV4 addressing only Or
GigE VLAN
OAM IPV6 addressing only
VLAN 1
1588 OAM S1 X2
Config 1 IPv4@2 IPv4@1 IPv4@3
Config 2 IPv4@1


2.3 Two Vlans Configurations
Two VLANS with 802.1Q tagging with :
y OAM VLAN for the OAM and synchro traffic
y Telecom VLAN for S1 and X2 interfaces. Telecom VLAN
(S1&X2)
GigE
OAM VLAN
(OAM & Synch)
VLAN1 VLAN 2
1588 OAM S1 X2


2.4 Third VLAN in TDD Configurations TDD Only
Three VLANS with 802.1Q tagging with :
OAM VLAN OAM VLAN
GigE S1 VLAN GigE S1 VLAN
X2 VLAN M1-U VLAN
5620
MME
SAM
OAM VLAN
GigE Telecom VLAN
M1-U VLAN SGW
MBMS-
GW

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.
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.

2.4 Third VLAN in TDD Configurations [cont.]
1588 OAM S1-U S1-C X2-U X2-C M1-U
Config 1 IPv4@1 IPv4@1 No IP@
Config 2 IPv4@1 IPv4@2 IPv4@3 IPv4@2 IPv4@3
Config 10 IPv4@2 IPv4@1 IPv4@3 IPv4@4 IPv4@3 IPv4@4
Config 14 IPv6@1 IPv6@2 No IP@
Config 15 IPv4@2 IPv4@1 IPv4@3 IPv4@4
Config 16 IPv4@2 IPv4@1 IPv6@3 IPv6@4
Vlan1 Vlan2 Vlan3

1) 1588 cannot be used with eMBMS traffic (M1-U interface).

(2) M1-U must be mapped on a dedicated eNodeB VLAN. This VLAN terminates at a Network
Processor that does not require a standard IP interface for being able to receive and process IP
packets. eMBMS is a DL broadcast traffic, no UL eMBMS traffic originates from eNodeB.
(3) OAM must be mapped on the first TrafficDescriptor instance of the first VLAN instance

2.5 Four Vlans Configuration
Four VLANS with 802.1Q tagging with
(IPV4 only): OAM VLAN
y OAM VLAN for the OAM 1588 VLAN
GigE
y OAM VLAN for synchro traffic
CP VLAN
y One VLAN for control plane traffic
UP VLAN
y One VLAN for user plane traffic.
The 4 VLANs configuration is supported for separating traffic flows as

follows:
IP version(s) as well as number of IP @s supported per VLAN are given in
the table below.
1588 OAM S1-U S1-C X2-U X2-C M1-U
Vlan1 Vlan2 Vlan3 Vlan4


2.6 eUTRAN Sharing Vlan Configuration
eUTRAN sharing permits to share eUTRAN resources between several operators.
ALU eNodeB supports the Multiple Operators Core Network (MOCN) model where all
operators share the RAN resources (eNodeBs, backhaul) while each operator manages its own
core network (MMEs, SGWs).
The L2 backhaul access is shared between the operators but the telecom traffics of the
operators are logically separated logically with VLANs. This allows each operator to manage its
own policy for QoS.
eUTRAN sharing is supported with up to 2 operators.
The X2-C traffic cannot be
split between operators and
is carried in the telecom SGW PGW
VLAN of the master operator. CN (Operator A)
Backhaul
SGW PGW
Shared
eUTRAN CN (Operator B)
eUTRAN sharing architecture for MOCN

Operators PLMN configuration is done through:

Object: Enb/PlmnIdentity, Parameter: isPrimary , Value: true/false
Object: Enb/PlmnIdentity, Parameter: plmnMobileCountryCode, decimal of 3 characters
Object: Enb/PlmnIdentity, Parameter: plmnMobileNetworkCode, decimal of 2-3 characters
Amongst the operators, a master operator manages not only its telecom traffic but also the OAM and
1588 traffics as wells as the X2-C traffics of all the non master operator(s).
A non master operator only manage its S1-U, S1-C and X2-U traffics.
PlmnIdentity instance which parameter isPrimary = true defines the PLMN of the master operator.
In release (T)LA5.0, there are 1 master operator and 1 non master operator.
Each operator has 1 telecom VLAN.
Within its telecom VLAN, the master operator manages its telecom traffic as well as non master operator
X2-C traffic.
In add, the master operator has another VLAN for OAM (and 1588 if used).
Within its telecom VLAN, a non master operator manages its S1-U, S1-C and X2-U traffics.
There are a maximum of 3 VLANs (1 telecom VLAN per operator (x2) + 1 OAM(/1588) VLAN).

2.6.1 Supported Configurations For The Master Operator
2 VLANs are dedicated to the master operator for separating traffic flows as
follows:
1 VLAN for OAM (and 1588 if used) traffic
1 VLAN for the master operator telecom traffic (S1, X2) and the non master
operators X2-C traffic IP version(s) as well as number of IP @s supported per VLAN
are given in the table below.
VLAN1 VLAN2
S1-U S1-C X2-U X2-C
1588 OAM All
Master Operator Only
Operators

(1) 1588 requires a dedicated IPv4 address. 1588 is not supported over IPv6.
(2) M1-U is not supported with eUTRAN sharing.
(3) OAM must be mapped on the first TrafficDescriptor instance of the first VLAN instance.

2.6.2 Supported Configurations For A Non Master Operator
1 VLAN is dedicated to a non master operator for its S1 and X2-U traffic flows.
IP version(s) as well as number of IP @s supported per VLAN are given in the
table below.
VLAN3
S1-U S1-C X2-U
1588 OAM X2-C
No Master Operator
Config 1 IPv4@3
Config 2 IPv4@4
Config 3 IPv6@3
Config 4 IPv6@3


2.7 IP Addressing
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
OAM VLAN
GigE
Telecom VLAN
IPv4
Backhauling
network for
IPv6 SGW
Telecom

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.

2.7 IP Addressing [cont.]
5620
SAM
MME
IPv6
GigE VLAN
SGW
One IPv6@ for OAM and one

IPv6@ for Telecom
5620
SAM
IPv6
MME
IPv6
OAM VLAN
GigE
Telecom VLAN
SGW

IPv6 as specified in IETF RFC 2460 is supported for the Telecom traffic (S1 & X2) and for OAM.
eNodeB does not support IPv6 for 1588v2 traffic.
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.

2.7 IP Addressing [cont.]
In 3 VLANS configuration, both S1 and X2 interfaces uses IPv6 addresses.
IPv6 or 5620
SAM
IPv4 MME
IPv6
OAM VLAN
GigE S1 VLAN
X2 VLAN SGW
OAM VLAN
GigE S1 VLAN IPv6
X2 VLAN


2.8 DHCP Process
eNodeB broadcasts
DHCP messages to
request an IP 5620
configuration SAM
1
NM sends config. 3
including IP
configuration
DHCP
Server
At next restart, 2 DHCP server sends

4 eNodeB uses stored IP back IP configuration
configuration : DHCP
process no more used

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.

1- What are the benefits of VLAN?

a)The use of VLANs optimizes the broadcast traffic by reducing the broadcast
domains
b)The use of VLANs can support QoS deployment strategy.
c)The use of VLANs provides basic security functions.
2- What VLANs are supported when 4 Vlans configuration is enabled?
XXX VLAN
XXX VLAN
GigE
XXX VLAN
XXX VLAN


3- Which of the following are valid VLANs configurations :

a) One VLAN for UP, one VLAN for CP, one for OAM
b) One VLAN for S1, one for X2, one for OAM
c) One VLAN for X2 + S1, one for OAM
4- In LA5.0 what is the maximum number of VLANs supported by the eNodeB?

a) 2
b) 3
c) 4
5- OAM VLAN can be used for:

a) OAM traffic only
b) OAM and SynchE traffic
c) OAM and sync 1588v2 traffic


6- Which of the following are valid IP configurations :
a)One 1588v2 IPv6 address + one OAM IPv6 address on OAM VLAN,
b)One IPv4 OAM address + one IPv6 Telecom @ on one VLAN,
c)One IPv4 OAM address + one IPv6 Telecom @ on two VLANs,
d)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


3 IPSec


3 IPSec
3.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
MME
S1 MME
RB
SRB S1-U SGW
UE
Secured
unsecured network or unsecured

NodeB location Use IPSEC

Security Requirements :
Flat architecture:
z All radio access protocols terminate in one node: eNodeB
z IP protocols also visible in eNodeB
Security needed due to :

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

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

3 IPSec
3.1 UE Security [cont.]
IPSEC is used to secure the transport network on S1 interface.
MME
Security E
Gateway M
M
(SEG) S1
S1 MME
SRB
DRB S1-U S1-U SGW
UE
Secured Secure Secure
IPSEC tunnel IPSEC tunnel
Hub and Spoke architecture :

all tunnels for all nodes end at Security Gateway Node

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.

3 IPSec
3.2 Transport Security Gateway In LTE network
The Security Gateway (SEG) is the central hub of communications between the
eNodeB and other LTE components (i.e. eNodeB, MME and SGW).
Security Domain MME
eNB
eNB
Ethernet
eNB Backhaul Intranet
eNB SGW
eNB
Intranet
IPSec Tunnels
MME
eNB
eNB
Ethernet Intranet
eNB Backhaul
eNB SGW
eNB

The Security Gateway (SEG) is the central hub of communications between the eNodeB and other
LTE components (i.e. eNodeB, MME, SGW)
The diagram depicts the logical functionality of the SEG within the network. The physical SEG
component can be the same router that would normally aggregate traffic from the eNodeBs, given
the router supports IPsec functionality. Most larger core routers that aggregate traffic should
support IPsec tunnels. The SEG will usually contain a robust IPsec feature set to allow compatibility
with a wide variety of vendors IPsec implementation.

3 IPSec
3.3 IPSec Traffic Flow
MME
Ethernet
Backhaul Intranet
eNB
Secure S1-MME Traffic
Ethernet
Backhaul Intranet
SGW
eNB
Secure S1-U Traffic
eNB LTE Traffic
Ethernet Backhaul Encrypted

Traffic
eNB IPSec Tunnel
Secure X2 Traffic


3 IPSec
3.4 IPSec LTE Specifications
eNodeB can have a different IP adresses for each traffic type OAM, 1588 and telecom.
For 1588 traffic the eNodeB always has a dedicated IP address in the same VLAN as
OAM traffic.
If no VLAN is configured, then 1588 traffic is not supported.
If no VLAN is configured and if the eNodeB has different IP address for OAM and telecom
traffic, then those IP addresses are in the same subnet or in different subnets.
IPv4 or IPv6 is used at layer 3.
Two VLANs can handle different IP versions.
1588 traffic does not support IPv6.Up to 2 tunnels can be configured, and a maximum of
one IPSEC tunnel per VLAN is supported.
Telecom traffic NM
in IPSEC tunnel O&M
MME
network
OAM traffic
ePC
SGW
SEG

In the release LA5.0, the operator will be able to select digital certificates as a new method for IKEv2
authentication in addition to the existing pre-shared secret key method.
Digital certificate based authentication is adequate for large IPsec deployments like the LTE backhaul
because it is more scalable than pre-shared keys.
Without digital signatures, the operator must either manually exchange public keys or secrets between
each pair of systems that use IPsec to protect communications.
By using digital certificates, the operator can simply register each eNodeB system with a Certificate
Authority (provided by CMS), and systems like the SEG needs no modification while implementing digital
certificates.
When a new eNodeB attempts an IPsec connection, IKEv2 automatically exchanges certificates with the
peer SEG and the eNodeB and SEG systems authenticate each other.

3 IPSec
3.5 IPSec LTE Configurations
Traffic is protected into one IPSEC

tunnel
GigE
SEG
All traffic is protected using one IPSEC tunnel

VLAN
GigE SEG
With 2 VLANS configuration, 0,1 or 2 IPSEC tunnels can be deployed
Telecom VLAN
GigE
OAM VLAN
SEG


3 IPSec
3.6 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)
Example
Telecom S1-U + X2-U
VLAN
S1-C + X2-C
GigE SEG
OAM OAM
VLAN

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

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.
z S1-C traffic is integrity protected and encrypted, but S1-U and X2 traffic bypass IPsec.
z 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 eNodeB application generates IP eNodeB application

IP packets packets generates IP
packets
OAM
OAM X2 S1-C OAM S1-C
S1-C
X2 S1-U X2
S1-U S1-U
OAM IP@ TEL IP@

OAM IP@ TEL IP@ OAM IP@ TEL IP@
Outer Outer
IPSEC policies IPSEC policies IPSEC policies
IP@ IP@
OAM TEL OAM TEL TEL

OAM
vlan vlan vlan vlan vlan
vlan

3 IPSec
3.6 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.
SEG Inner IP :IPv6

SEG
Inner IP :IPv4
Outer IP :IPv4 Outer IP :IPv6
1588v2 traffic cant use IPSEC tunnel
SEG
1588v2

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

3 IPSec
3.7 IPSec eUTRAN Sharing Configuration
Master Operator
OAM Ipsec Tunnel
Telecom Ipsec Tunnel
CN (Operator A) CN (Operator B) CN (Operator C) CN (Operator D)
SEG SEG SEG SEG
Backhaul Backhaul
IPSec Tunnel
IPSec Tunnel
IPSec Tunnel RAN (shared) IPSec Tunnel

In the eUtran shared architecture the eNodeB will only have one OAM network connection.
The OAM network connection will belong to the master operator. AN IPsec tunnel can be configured for the
OAM or Telecom traffic. Each of the telecom transport commuications will belong to their respective
operator (i.e S1-U, S1-C, X2-U). It is expected that each operator will have their own Security gateway and
LTE transport network components (i.e. MME, SGW). The X2-U traffic will only be transported on the
master operators IPsec communications since this is an eNodeB to eNodeB communications and owned by
the master operator. Each Operator can independently enable/disable IPsec tunnels.

1-How many IPSEC tunnels can be setup on an eNodeB ?
2- 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
3- Which equipment is the IPSEC peer of the eNodeB :

The serving Gateway,
The PDN Gateway
The MME
The Security Gateway


Exercise
For each of the following configuration, ONE VLAN for all traffic, please
complete the table with the correct state after the security is activated:
Before After
One eNodeB OAM IP address
One eNodeB Sync IP address if the

traffic is in1588v2
One eNodeB Telecom IP address
No IPsec tunnel


4 QoS


4 QoS
4.1 Main QOS functions and mapping on LTE NE
Based on its associated E2E services, an EPS bearer is associated to a set of QoS
parameters such as: QCI, ARP, Maximum and Guaranteed bit rate in UL and DL.
eNB RRM
eNB RRM QOS
QOS
RBC
RBC eNB Backhaul
eNB Backhaul QOS
QOS
RAC
RAC Backhaul CAC
Backhaul CAC
DRA- Packet
DRA- Packet scheduling
scheduling DSCP Mapping
DSCP Mapping
(DL Ratecontrol)
(DL Ratecontrol) S1U/ X2U
S1U/ X2U flow
flow control
control
Overload and
Overload and queuing
queuing control
control X2c/S1MME flow
X2c/S1MME flow control
control
VoIP Backhaul congestion
Backhaul congestion control
control
(real time)
MME
Internet
Access (BE)
SGW PGW
Streaming
(GBR)
Transport QOS
Transport QOS
Diffserv Dimensionning
Diffserv Dimensionning
UE QOS
UE QOS Control
Control IP QOS
IP QOS toto L2
L2 mapping
mapping
SIP/SDP Qos
SIP/SDP Qos signaling
signaling Traffic Management
Traffic Management
App/SDF/RBMapping
App/SDF/RBMapping MPLS
MPLS
UL Rate
UL Rate control
control (PBR
(PBR support)
support)

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.

4 QoS
4.2 QoS mapping on Bearers
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)
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
SGW PGW

The end to end QOS functions are performed at four levels : UE , eNodeB , ePC and the transport network
levels.
The EPS 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.

4 QoS
4.3 Standardized QoS characteristics
The goal of standardizing QCI characteristics is to ensure the same minimum level of QoS :
In multi-vendor network deployments
In case of roaming
Packet Packet
Resource Error Loss
QCI Priority Delay Example Services
Type
Budget Rate
1 GBR 2 100 ms 10-2 Conversational Voice
2 GBR 4 150 ms 10 -3 Conversational Video (Live Streaming)
3 GBR 3 50 ms 10-3 Real Time Gaming
Non-Conversational Video (Buffered
4 GBR 5 300 ms 10-6
Streaming)
5 NGBR 1 100 ms 10-6 IMS Signalling
Video (Buffered Streaming)
6 NGBR 6 300 ms 10-6 TCP-based (e.g., www, e-mail, chat, ftp, p2p
file sharing)
Video (Live Streaming)
7 NGBR 7 100 ms 10-3
Interactive Gaming
Video (Buffered Streaming)
8 NGBR 8 300 ms 10-6 TCP-based (e.g., www, e-mail, chat, ftp, p2p
file
9 NGBR 9 sharing, progressive video, etc.

The Standardized QCI characteristics defines packet delay and packet loss rate per QCI at access
side from UE to PCEF (Policy and Charging Enforcement Function, in the PDN GW). Jitter is not
addressed by this 3GPP standard.
The 3GPP assumption is that delay from eNodeB to PDN GW should be in average of 20 ms (with
min=10ms and max=50ms).
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)
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.

4 QoS
4.4 QoS mapping on transport network
Bearer-level QoS (QCI) is translated to to L3 and L2 transport-level QoS (DSCP at L3 and
p-bit at L2)
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.
Tunnel header
L2 L3 L4
ETH IP UDP GTP-U header E2E IP packet
..TEid..
IP@(PGW/SGW),DSCP [BE, EF, AF]

P-bit [0,,7]

Packet marking needs to be consistent from an end-to-end perspective.
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.

4 QoS
4.5 Traffic Management Functions
Ingress traffic Egress traffic
Classifier Marker Conditioner Queuing

(Shaping, Dropping) (Scheduling, Dropping)
Most QoS mechanisms include some type of classification but only a small number
of mechanisms also include marking capability.
Classification: used for identifying a Behavior Aggregate to which a packet
belongs.
Marking: used for coloring packets by applying a class-identifying Value to
one of the following markers: IP precedence, DSCP, QoS group ..
Traffic shaping: aims to control the rate at which packets are sent out of an
interface, while preventing packet loss.
Traffic policing: aims to control the amount of bandwidth consumed by an
individual microflow, or an aggregate of flows.
Queuing: Queues are created at the interface where congestion is expected.
Scheduling: Determines order in which queues (and then packets) are served.


4 QoS
4.6 eNodeB traffic Management
eNodeB supports UL traffic scheduling to ensure the QoS differentiation between
high priority flows and low priority flows.
eNodeB supports UL traffic shaping to adapt to the available backhaul transport

bandwidth.
SAM5620
Lower priority
flow
UE
OAM
VoIP GigE
(real time) SGW PGW
High
priority
flow

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.
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

4 QoS
4.7 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
CIR
Backhauling
bandwidth
Network
time
UL eNB traffic between CIR and EIR may be

dropped by the network in case of congestion

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.

4 QoS
4.8 eNodeB UL traffic Shaping
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
EIR The eNB performs traffic

CIR
shaping for all UL traffic
GigE
of egress physical port
per VLAN
EIR
CIR The eNB performs traffic
Telecom
VLAN shaping for all UL traffic
traffic for each VLAN with
EIR different values of CIR/EIR
OAM
VLAN 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.
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

1- please complete the table below and for each type of bearer:


2- Please match each description with its related object
QCI is used within the access network as a reference to

node-specific parameters that control packet-forwarding Default Bearer
treatment.
established during attachment and maintained throughout

Dedicated
the lifetime of the connection (always-on IP connectivity)
Bearers
is the set of all packet filters associated with that EPS

QCI (QoS Class
bearer. Every dedicated bearer is associated with a TFT.
ID)
can be established dynamically as a result of service

Traffic Flow
requests or access to services
Template (TFT)


Exercise
Please put the corresponding letter to each description:
Aims to control the amount of bandwidth consumed by an individual

microflow, or an aggregate of flows.
Determines order in which queues (and then packets) are served. D

Aims to control the rate at which packets are sent out of an interface,
while preventing packet loss.
Queues are created at the interface where congestion is expected.
Classification: used for identifying a Behavior Aggregate to which a

packet belongs.
Marking: used for coloring packets by applying a class-identifying
Value to one of the following markers: IP precedence, DSCP, QoS
group ..
Ingress traffic A B C D Egress traffic

Classifier Marker Conditioner Queuing


5 eNodeB Call Admission Control


5.1 Call Admission Control
Radio Call Admission Control (Radio CAC). Radio CAC is responsible for:
y Deciding whether to admit or reject requests for new entrant bearers or
modification of established bearers.
y Ensuring efficient use of radio resources by accepting radio bearer requests
as long as configurable limits are not exceeded and sufficient radio
resources are available.
y Minimize the impact on the QoS of established bearers, with preference
given to higher priority bearers over lower priority bearers when the cell is in
congestion.
ENodeB Call Admision Control

(CAC)
1 2 Transport CAC
Radio CAC
(T-CAC)
LA5.0


5.2 Radio Admission Control
Radio CAC admits or rejects:
Establishment of SRBs for new incoming calls.

Establishment of new incoming VoIP, GBR, and non-
GBR Data Radio Bearers (DRBs).
Modification of established eRABs.
Establishment of bearers in handover that were
previously established in the source cell before handover.
Establishment of bearers in RRC Connection Re-
establishment that were previously established before
radio link failure.
Establishment of bearers required for CS Fallback
(CSFB).

Radio CAC gives special consideration to the admission of emergency calls.

Two types of emergency calls are supported:
IMS VoIP EC: emergency services provided on LTE.
Emergency CSFB: requires the UE to change to another RAT to obtain emergency services.

5.2.1 Radio CAC Criteria
Criteria
Number of Number of
PRB consumption
connected users established data Transport
(per Cell, per
(per Cell, per bearers (per Cell, bandwidth
PLMN per cell)
Trigger PLMN per cell) per PLMN per cell)
RRC connection request

RRC connection setup
Handover request (Inter-
eNB)
Handover request (Intra-
eNB inter cell)
RRC connection re-
establishment in non-
serving cell
Initial UE context setup or
eRAB setup
eRAB modify with higher
GBR
eRAB modify with new QCI
Incoming IMS VoIP
Emergency call or
Emergency CSFB call

In LA5.0, the following Radio CAC criteria are checked:

Number of connected users (per eNB, per cell, per PLMN per cell)
Number of established data bearers (per eNB, per cell, per PLMN per cell,
per QCI group per cell, per PLMN per QCI group per cell, VoIP per cell)
Transport bandwidth
PRB consumption (per cell, per PLMN per cell)
The CAC criteria which are checked in LA5.0 depend on the type of incoming request,
In LA5.0, enhanced eUTRAN sharing is introduced which enables the eNB to additionally perform admission
control on a per PLMN per cell basis when a cell is shared by multiple operators. Refer to Volume 5 for an
overview of eUTRAN sharing. Per PLMN admission criteria are checked when more than one PLMN is
broadcast in SIB1 in the cell. The resources which are checked per PLMN for admission control fall under
the 3 Radio CAC criteria (number of connected users, number of established data bearers, and PRB
consumption).
The data parameters used to configure PLMN admission control are associated with object
RadioCacCellPerPlmn and are described in the sub-sections corresponding to their respective criteria type.
Parameter RadioCacCellPerPlmn::plmnId identifies the instance of the PlmnIdentity object that defines MCC
and MNC of the concerned PLMN. See Volume 5 for additional discussion of PlmnIdentity.
Also in LA5.0, PRB licensing is introduced which allows the eNB to additionally perform admission control on
a per band basis across all cells of the eNB if parameter flag isUnlimitedPRBLicenseAllowed = false. Refer
to section 5.3 for an overview of PRB licensing.

5.2.2 Reactive Load Control
RRC Connection request: emergency
Or
Incoming bearer with Pre-emption Capability: may trigger pre-emption , Priority Level 15.
Radio Admission Control

Checks Failure
If:
isReactiveLoadControlAllowed:: True
Reactive Load Control

Pre-emption Bearers Pre-emption UE
candidates list candidates list
Off-loading of UE to another eNB.

Release of UE or of bearer.

The choice of pre-emption action to be taken is based on the data parameter settings described
subsequently in this section. In the case of off-loading, Radio CAC will invoke eMCTA to off-load UEs.
A fallback to UE/bearer release may occur when off-loading may not be processed or fails.
Bearer candidates for reactive load control are selected if they meet the following criteria:
It is not the only bearer of a UE;
Its pre-emption vulnerability is pre-emptable, and its Priority Level is not 15;
Its priority is lower than that of the bearer which triggered reactive load control;
Its UE is not in an ongoing procedure, including release, handover, CCO and ANR procedure;
Its UE is not a CSFB call;
Its UE is not in coverage alarm (event A2 for Entering-Coverage-Alarm has been received);
Its UE is not the same UE of the bearer which triggered reactive load control;
A UE is a candidate for off-loading if:
Parameter isOffloadUponLoadControlAllowed is set to True
It has a pre-emption candidate bearer configured and parameter
ReactiveLoadControlActionForBearerAdmission::action (in the instance
of TrafficRadioBearerConf with qCI=incoming bearer QCI) is set to outgoingMobility
All the bearers belonging to the UE are pre-emptable.
All the bearers belonging to the UE have a lower priority than that of the bearer which triggered reactive
load control.

LA5.0
5.3 eNodeB Call Admission: T-CAC
T-CAC feature is subject to license per eNB,

T-CAC supports eUTRAN sharing,
T-CAC is enabled through the parameter : isTransportCacAllowed = TRUE,
T-CAC applies to the S1-U traffic only,
T-CAC may apply in a per port or mode or in a per VLAN mode,
An eRAB is rejected if T-CAC fails in one of the direction (DL or UL).

An eRAB is accepted if T-CAC succeeds in both directions (DL and UL).

eNB Call Admission Control (CAC) includes Radio CAC and Transport CAC (T-CAC).
When both T-CAC and Radio CAC are applicable, T-CAC is performed first.
T-CAC may apply in a per port or mode or in a per VLAN mode.
If eUTRAN sharing is activated it is only possible to configure the per VLAN mode.
In case eUTRAN sharing is activated, the number of VLAN and the number of PLMN managed by T-CAC
are the same. There is one VLAN handling S1-U per operator (i.e. per PLMN identified by
VLAN::plmnId). There is one T-CAC runing per VLAN (i.e. per operator).
T-CAC applies separately on uplink (egress) and downlink (ingress) direction.
At RAB set-up (or modify) T-CAC controls if the associated S1-U UL and DL volume of traffic can be
satisfied according to the remaining UL and DL bandwith of the transport link to the backhaul network.
The Call Admission Evolutions feature provides an evolution of the Admission Control from a token-based
to a measured-based solution. (Static CAC no longer used).
A transport link is;
either a physical link, that is an ethernet port, for which T-CAC applies on
the port aggregated traffic (even if some VLANs are defined),
or a VLAN, for which T-CAC applies on the VLAN aggregated traffic.

5.3 eNodeB Call Admission: T-CAC
5.3.1 T-CAC Algorithms Triggers
Consummed transport
Event that triggers T-CAC algorithm
link bandwitdh is:
S1-AP INITIAL CONTEXT SETUP REQUEST
S1-AP E-RAB SETUP REQUEST
S1-AP E-RAB MODIFY REQUEST: GBR of eRAB is increased Increased (2)
S1-AP HANDOVER REQUEST: S1 inter-eNB incoming HO
X2-AP HANDOVER REQUEST: X2 inter-eNB incoming HO
S1-AP E-RAB RELEASE COMMAND

S1-AP CONTEXT RELEASE COMMAND
X2-AP CONTEXT RELEASE
S1-AP E-RAB MODIFY REQUEST: GBR of eRAB is decreased
S1-AP HANDOVER REQUEST: X2 inter-eNB outgoing HO Decreased
X2-AP HANDOVER REQUEST: X2 inter-eNB outgoing HO
X2-AP HANDOVER CANCEL: X2 inter-eNB HO cancel
Call drop without S1-AP CONTEXT RELEASE COMMAND
S1-AP E-RAB MODIFY REQUEST: QCI of eRAB is modified (1) Increased (2) or
Intra-eNB HO involving QCI change Decreased

(1) QCI online modification for existing data bearers is possible for QCI in range [6..9]. This is enabled
by setting ActivationService::isQciArpOnLineModificationAllowed to true.
(2) If the transport bandwith is not sufficient, the QoS of existing eRABs is maintained by rejecting
the new eRAB.
T-CAC does not modify QoS characteristics of existing eRABs nor pre-empt ressources in case of
transport link bandwith exhaustion.
T-CAC algorithm operates in an open loop mode. T-CAC does not get feedback from the user-plane
transport layer (i.e. WinPath) of UL and DL bandwidth consumption measurement.
A mechanism is provided to accept some extra emergency eRABs in case of transport link bandwith
reaching exhaustion. Emergency calls correspond to calls set up with an ARP that equals to
PlmnIdentity::arpPriorityEmergency.
It is based on provisioning a percentage of the transport link bandwidth that is reserved for
emergency calls.

1- 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)
2- 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
3- 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


4- From the list, please select the triggers radio CAC algorithms:
a) Establishment of SRBs for new incoming calls.

b) Establishment of new incoming VoIP, GBR, and non-GBR Data
Radio Bearers (DRBs).
c) Modification of established eRABs.
d) Establishment of bearers in handover that were previously
established in the source cell before handover.
e) Establishment of bearers in RRC Connection Re-establishment that
were previously established before radio link failure.
f) Establishment of bearers required for CS Fallback (CSFB).
g) All the previous ones


5- Please check for CAC algorithm, the corresponding critera to each

trigger:
Criteria
Number of Number of
PRB consumption
connected users established data Transport
(per Cell, per
(per Cell, per bearers (per Cell, bandwidth
PLMN per cell)
Trigger PLMN per cell) per PLMN per cell)
RRC connection request
RRC connection setup
Handover request (Inter-
eNB)
Handover request (Intra-
eNB inter cell)
RRC connection re-
establishment in non-
serving cell
Initial UE context setup
oreRAB setup
eRAB modify with higher
GBR
eRAB modify with new QCI


6- select for each sentence True/ False:

T-CAC
Feature is subject to license per eNB, True/ False
Supports eUTRAN sharing, True/ False
Is applied for emergency call only, True/ False
Is enabled through the parameter : isTransportCacAllowed, True/ False
Applies to all types of traffic only, True/ False
Can not be applied in per port but only per VLAN, True/ False
An eRAB is rejected if T-CAC fails in both directions (DL or UL). True/ False
An eRAB is accepted if T-CAC succeeds in one direction (DL or UL). True/ False


6 Synchronization


6 Synchronization
6.1 High Level Overview
Synchronization is the generic concept for distributing common phase, time or frequency to
all the nodes that require it to coordinate their local phase, time or frequency.
Frequency synchronization is the distribution of a common frequency reference

to the nodes for controlling their local oscillator. Those can be frequency
synchronized and at the same time have no common phase.
Phase synchronization implies that all the nodes have access to the reference
timing signal of which rising edges occur at the same time.
Time synchronization means distributing a common time reference to the
network.
The reference timing is delivered to the nodes over the backhaul transport network
in a master-slave architecture
The frequency reference source(s) must deliver a signal of sufficient accuracy and
the synchronization network must be designed to ensure the eNodeB RF carrier
meets this requirement.
The eNodeB supports multiple synchronization methods
3GPP TS36.104 [R6] specifies that LTE networks require stability of

transmitted radio signal better than 50 ppb.

. The master nodes usually have access to a Primary Reference Clock (PRC) traceable reference signal.
PRC is a high accuracy clock of which long-term frequency stability error should be below 1 part per 10 11
as per ITU-T G.811.
At the receiver of the timing signal a PLL (phase-locked loop) controls the frequency or the phase of the
local oscillator according to the received reference timing signal. The function of PLL is to lock the local
clock to the incoming reference signal. Radio networks require always frequency stability.
Phase and time synchronization are additional requirements in some technologies as in LTE TDD and
LTE MBMS.
The purpose of synchronization is to make sure that equipments send and receive data at the same
rate and possibly also at the same time.
Accurate frequency synchronization is a crucial requirement on radio interface, for instance for
handovers.
Frequency synchronization requirements are expressed in parts-per notation. Parts-per notation is
the ratio between the observed frequency and the reference frequency ( i.e. = (measured frequency
/ reference frequency) 1)) expressed in parts-per-million (ppm) or parts-per-billion (ppb).
The clock generator within eNodeB generates the bit, basic frame, hyper frame, CPRI-10ms frame
and BS super frame synchronization signals from a timing source input signals (such as local GPS,
syncE, IEEE1588v2).

6 Synchronization
6.1 High Level Overview [cont.]
In the eUTRAN, 2 principal synchronization

needs:
Technology Freq. ToD
Handover control Frequency Division Duplex GSM 50 ppb -

(FDD) systems only require frequency UMTS FDD 50 ppb -
synchronization
UMTS TDD 50 ppb 2.5 s
Radio Framing accuracy in TDD (Time LTE FDD 50 ppb -
Division Duplex) systems or feature such as LTE TDD 50 ppb 1.5 s
MBMS require both frequency and time-of-
day (ToD, also called phase) WiMAX TDD 2 ppm 3 s
synchronization. WiMAX FDD 2 ppm -
CDMA 50 ppm 10 s
Mobile Synchronization Requirements

(3GPP, 3GPP2 and IEEE 802.16e specifications)

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.

6 Synchronization
6.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

outside 50ppb window
F2 F2
+/- 50ppb +/- 50ppb

UE can not lock to the
Handover target eNodeB.
HO is unsuccessful
F1 F1
Time Time
Frequency synchronization is required

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

6 Synchronization
6.3 Possible solutions
Local GPS (internal or external receiver)
Synchronous Ethernet (SyncE)
IEEE 1588v2, Precision Time Protocol (PTP).
Sync Ethernet
clock master
Ethernet
Synchronous Ethernet
GPS
1588v2
server
1588v2 IEEE1588v2 Precision Time Protocol

client

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.
IEEE1588v2 is the recommended clock delivery over IP networks.

Note : IEEE 1588v2 is used for frequency reference from LA3.0.
SyncE can only be used for frequency reference, so syncE cant be used in TDD systems.
The eNodeB can run in free running for 72 hours for Frequency and 1 hour for phase (standard).

6 Synchronization
6.3 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 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.

6 Synchronization
6.4 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
UE1 Overlap
UE2
Overlap
UE1 TX eNB1 TX
time time
UE2 RX eNB2 RX
Both frequency and phase synchronization are required

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 of CDMA/LTE HO feature
Accuracy: Requirement is +/- 1.5 sec phase accuracy

6 Synchronization
6.5 Synchronous Ethernet
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
Optionally, eNodeB supports SSM

messages that inform on
synchronization quality.

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.

6 Synchronization
6.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
PTP server delay and RTT
grandmaster
PTP client
T1
T1
T2,
local reception time
RTT = ((T2-T1)+(T4-T3)):2
mean delay = RTT/2
DL delay = T2-T1
UL delay = T4-T3
T3 Delay reques
t
T4
Delay response T4

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 :
T1: server sends Sync message.
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).
T2: client receives servers sync message.
T3: client sends Delay request to server. This is optional for frequency synchronization
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

6 Synchronization
6.6 PTP principles [cont.]
Messages transmission rate are negotiated 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 Request unica
negociate PTP st transmission
exchanges rate.
nsmission
Grant unicast tra
erval, Duration)
(logmessage int
Sync logmessage
interval
Sync Duration
Sync

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 phrequency 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


Appendix A IPSec Concept


IPSec Definitions
Security Association (SA): Before two communicating entities can exchange

secure communications, they need to agree on the nature of the security to be
applied to those communications: which security headers (AH, ESP, or both) will be
applied, the cryptographic algorithms to be used, the secret keys, and so forth.
A security association (SA): consists of all the information needed to
characterize and exchange protected communications.
Security Association DataBase (SADB or SAD): An list of SAs and their
associated information which can indexed traffic selector rules.
Security Policy Database (SPD): A security policy is a rule that is programmed
into the IPSec implementation that tells it how to process different datagrams
received by the device.
If security is required, the security policy provides general guidelines for how it
should be provided, and if necessary, links to more specific detail.

IPsec consists of several protocols to administer the secure tunnel and perform the encryption of user
traffic. IPsec suite of protocols contains three main protocols, Internet Key Exchange (IKE), Authentication
Header (AH), and Encapsulating Security Payload (ESP).
The administrative portion of IPsec is either performed manually or dynamically. The dynamic method of
tunnel negotiation is performed by the IKE protocol. There are two flavors of IKE (IKEv1 and IKEv2) that
may be supported on a SEG. In case of the eNodeB, IKEv2 is the only supported IKE mechanism. For the
remainder of the IPsec discussion, we will only refer to IKEv2.
IKE is the protocol used to set up a SA in the IPsec protocol suite. IKE builds upon the Internet Security
Association and Key Management Protocol (ISAKMP) and uses a Diffie-Hellman Key exchange to set up a
shared session secret, from which crytographic keys are derived.
Public key techniques, certificates, alternatively, a pre-shared key, are used to mutually authenticate the
communicating parties.
The ISAKMP SA should not be confused with the IPsec SA. The ISAKMP SA is meant to secure (encrypt) the
remaining phase 1 and phase 2 negotiations.
.

Transport Modes
Transport Mode: Only the payload (the data you transfer) of the IP packet is
encrypted and/or authenticated. The routing is intact, since the IP header is neither
modified nor encrypted
Tunnel Mode: The entire IP packet is encrypted and/or authenticated. It is then

encapsulated into a new IP packet with a new IP header.
The original IP packet source and destination address will be referred to as the
Inner Tunnel Address. The new IP headers source and destination IP addresses will
be referred to as the Outer Tunnel Address.
Encrypted
Originial
New IP Header Original Data
New IP Header
IP Data
IP ESP
Tunnel Mode Header AH
Header
Header Header
Authentication/ Integrity Authentication/ Integrity

Encrypted
Original Original Header
Ip Header Ip Data
Transport Mode Header AH
Data
Header
ESP
Authentication/ Integrity Authentication/ Integrity

Transport mode will reformat the original IP packet by inserting an IPsec header to form a new Ipsec
packet for transmission. The Ipsec header is inserted between the IP header and the payload. The original
header remains unaltered. Tunnel mode will reformat the original IP packet by inserting a new IP header
and an Ipsec header in front of the original IP packet. The Ipsec header is either the AH or ESP format.
AH addresses the following security issues:

Packet Integrity
Data origin Authentication
Replay protection (optional)
ESP addresses following security issues:
Confidentiality
Traffic analysis protection
Packet Integrity - offered by AH method as well.
Data origin Authentication - offered by AH method as well.
Replay protection (optional) - offered by AH method as well.

IP Security Integration
SEG
Traffic Selector
Unprotected
Subnet
Protect eNB Inner Subnet
eNodeB Bypass Unprotected Subnet
eNodeB Ipsec Feature Activation

Inner
Subnet Unprotected
Subnet
SEG
Traffic Selector
eNodeB
Protect eNB Inner Subnet
Bypass Unprotected Subnet
eNodeB
without IPsec

The IP security feature is activated to protect the various traffic types in an eNodeB. If the IP security
feature is not activated, peer entities in the core network or the OAM network reaches the eNodeB through
a Security Gateway (SEG) or router without any protection.
After the IP Security feature is activated, the peer entities reach the eNodeB through the SEG or router
based on some policies. Enabling IP Security feature allows to protect all or a part of the traffic to the
eNodeB.
Protecting the eNodeB traffic is achieved in the IP Security feature by defining a new eNodeB inner subnet.
After activating the IPsec feature, the protected traffic
can be part of a private eNodeB subnet or the eNodeB inner subnet
can be the telecom and OAM traffic between eNB and SEG (one VLAN used for OAM and telecom traffic)
can be the independent OAM traffic or telecom traffic, if two VLANs are used
After IPsec feature activation, a new eNodeB inner subnet is defined for the traffic flow concerned by this
activation. The eNodeB IP address defined in this inner subnet is not routable and this can be a private
address if IPv4 is used.
Note: The customer should purchase a software license offered by Alcatel-Lucent to enable the IPsec
feature. Software licenses are offered on a per eNodeB basis.

IPsec IKE (Phase 1)
IKE is a two phase approach, Phase 1 establishes an ISAKMP SA, which is a secure channel
through which the IPsec SA negotiation can take place. Phase 2 establishes the actual IPsec
SA or, more precisely, a pair of one-way IPsec SAs: an inbound SA and an outbound SA.
1 HDR, SA1,KE,N
IKE_SA_INIT
HDR, SA1, KE, N, 2

[CERTREQ] Auth: Authentication
CERT: Certificate
CERTREQ: Certificate Request
HDR,IDi,[CERT],[CERTREQ], HDR: IKE Header
Idi: Identification - Initiator
Initiator [IDr], AUTH, SA, TSi, TSr Responder Idr: Identification
Responder
KE: Key Exchange
3
N: Nonce
HDR,IDi,[CERT], SA: Security Association
TS: Traffic Selector
AUTH, SA, TSi, TSr
IKE_Auth
IKEv2 Phase 1 Negotiation

Message 1:
The initiator sends the IKE Header with possible supported SAs (Crytographic algorithms), KE Diffe-
Hellman Value, and nonce value.
Message 2: The responder sends the IKE Header with the SA selected from one of the possible Sas
provided by the Initiator from message 1.
Included as well is the responders KE Diffe-Hellman Value, nonce and optionally the Certificate Request.
Dashed Line: At this stage of the negotiation, the two participants have exchange Diffe-Hellman Values and
they can derive shared secret
keys. From this point on, all information after the IKE Header will be encrypted and provides Integrity
Protection.
Message 3: The Initiator sends the IKE Header, Identification, Certificate response if there was a request in
message 2, optional certificate request, optional ID of
responder, Authentication could contain the pre-shared keys or digital certificate verification. SA and
traffic selectors for traffic flow.
Message 4: The responder sends the IKE Header with an ID, Certificate response if a certificate request was
present in message 3.
Authentication could contain the pre-shared keys or digital certificate verification. SA and traffic selectors
for traffic flow. Peer Authentication has been
validated after this stage

IKE Key Calculation with Pre-Shared Key Authentication
Responders Preshared Key Initiators Preshared Key
Initiators Nonce Initiators Nonce

Responders Nonce Responders Nonce
IKE Derivation IKE Authentication IKE Encryption

Key Key Key
IKE Key calculation with Pre-Shared Key Authentication

After the second message, the IKE encryption key is calculated and used to encrypt the remaining
message transfers between the initiator and responder. The Key calculation is dependant on the
negotiated method of authentication. T

IKE Key Calculation with Digital Signatures Authentication
Responders Responders
DH Public Key DH Private Key Initiators
Initiators DH DH Public Key
Private Key
IKE Derivation IKE Authentication IKE Encryption

Key Key Key
LA5.0

The IKE Encryption Key, Authentication and Derivation key are valid for all future communications,
unless otherwise renegotiated in the Phase 2 stage.

IPSec IKEv2 (Phase 2)
As part of the phase 2 negotiation, new Diffie-Hellman keys and nonce values different from
phase 1 could be exchanged to allow additional security (Perfect Forwarding Secrecy, PFS).
Create_Child SA
Auth: Authentication
HDR, SA, N, [KE], CERT: Certificate
[3GPP TS i, TS] CERTREQ: Certificate Request
5 HDR: IKE Header
Idi: Identification - Initiator
Initiator HDR, SA, N, [KE], Responder Idr: Identification
[3GPP TS i, TSr] Responder
KE: Key Exchange
6 N: Nonce
SA: Security Association
TS: Traffic Selector
[]: optional parameter
IKEv2 Phase 2 Negotiation

IKE phase 2 negotiation creates the IPsec SA that will determine if any subsequent packet will be
encrypted prior to transmission or reception of pack Dashed Line:All traffic remains encrypted as a result of
the phase 1 negotiation.
Message 5: The Initiator sends the IKE Header, SA offers, a new nonce value different from the phase 1
transmission, optional KE if you want to create a new calculated key, and optional Traffic selection offers.
Message 6: The responder sends the IKE Header with a selected SA from message 5, a new nonce value
different from the phase 1 transmission, optional KE if you
want to create a new calculated key, and optional traffic selector chosen from the offers provided in
message 5.
Note: [KE] Diffie-Hellman keys are exchanged if Perfect Forwarding Secrecy is selected.
Note: A Child SA is a unidirectional connection. Therefore a connection to an end point will require a TX and
RX SA for a bidirectional IPsec tunnel.
The phase 2 will be repeated for additional SAs setup.
IKE negotiation is completed at the end of the Phase 2 negotiation. The Agreed upon SA for each direction
will be entered into the Initiators and responders local SA database. The agreed upon traffic selectors will
be entered into the Initiators and responders local security policy database.
The agreed upon SA will contain:
Encryption Algorithms to protect data
Hash algorithms to reduce data for signing ets.
An authentication method for signing data
Information about a group over which to do a Diffie-Hellman exchange.
A pseudo-random function (PRF) to hash certain values during the key exchange.
Type of protection to use - either ESP or AH.

IPSec Stages
Stage 0: Ipsec IKE Phase 1 & Phase 2
Stage 1: IPsec traffic selection and SA database

lookup
Stage 2: IPsec Encryption and Transmission
Stage 3&4: IPsec Transmission and Reception
Stage 5&6: Receiving Packet Inspection
Stage 7& 8:Decrypting IPsec Packet

Stage 1: Out going IP traffic are examined on a packet basis and compared to the Security Policy Database
(SPD) for a corresponding valid entry. If a valid entry is found, the specified action in the SPD is followed. If
the specified action is IPsec, the corresponding SAD lookup is performed to determine the IPsec specifics
for encryption.
Depending on the rules validation the transmitted packet can have several possibilities. The packet can be
dropped, transmitted without IPsec encryption or IPsec encryption is enforced. If the Ipsec encryption is
required, an SADB lookup is performed to retrieve the corresponding SA.
With the Stage 2 - IPsec Encryption and Transmission

Based on the cryptographic modes that were negotiated in the ISAKMP (stage 0) phase, each packet will be
encrypted. The packet will transmitted in either AH or ESP encryption method in either Tunnel or Transport
mode.
IPsec Transmission and Reception (Stage 3 & 4):This is a generic step where the route table lookup to send
the packet to the proper interface. The receiving IPsec termination will inspect the packet to determine if
the packet is IPsec encrypted.
Receiving Packet Inspection (Stage 5 & 6): Stage 5 represents a NON IPsec protected packet and sent to
the internal IP stack for proper decoding. Stage 6 represents an IPsec protected packet, that requires a
SADB/SPD validation. The IPsec decryption will be performed if a valid SADB/SPD pair has been found and
the decryption will be performed based on entries of the match SA/SP parameters.
Decrypting IPsec Packet (Stage 7 & 8): Stage 7 represents a packet that successfully validated an SADB
entry and corresponding SP in the SPD. The packet was decrypted and sent to the IP stack for further
processing. Stage 8 represents a packet that failed to find a SA entry in the SADB for a SP in the SPD. In
either case the packet is discarded.
Appendix B SCTP Protocol


SCTP Protocol
SCTP protocol is the choosen to transport control messages between the
eNodeB and the MME over the S1-MME interface and between eNodeBs over
the X2-C interface.
An SCTP association can be uniquely identified by the transport addresses
used by the endpoints in the association.
SCTP transport protocol provides:
Heartbit mechanism for failure detection
Multi-homing defense mechanisms
Data exchange with retransmission
SCTP associations are created between SCTP endpoints, ie between at least
a pair of IP addresses.
X2-AP
36422 IP@2
on port
ociation
SCTP ass
IP@1 SCTP association on port 36412 MME

IP@3
S1-MME

A transport address is unique to an SCTP endpoint and is defined by the combination of an IP address and
an SCTP port number (case of single-homed SCTP endpoint) or by the combination of multiple IP addresses
and an SCTP port number (case of multi-homed SCTP endpoint).
Stream Control Transmission Protocol is specified in IETF RFC 4960.

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.

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.
When the eNodeB detects too much retransmissions on the failed path, it
uses another remote IP@ as peer address.
S1-MME
ONE SCTP association

on port 36412 IP@3 MME
IP@1
IP@4

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 in this node.
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.

Association Initiation Failure: ALU Implementation
Peer SCTP
eNodeB endpoint
Start T1-Init timer INIT #1
Start T1-Init timer INIT #2
Up To MAX
InitRetransmits
Start T1-Init timer INIT # n
X SCTP Association failure alarm

sctpAccessEstablishmentRetryInterval
up to
sctpAssocEstablishmentMaxRetries

Similarly during Initialisation, if the eNodeB receives the INIT-ACK and sends COOKIE, it starts the T1-
cookie timer. If the timer expires the eNodeB resends the COOKIE message a maximum number of times
set also by the parameter max.INIT.Retransmits.
If the COOKIE-ACK is not forthcoming on the last re-send the eNodeB raises alarm SCTP ASSOCIATION
FAILURE.
The eNodeB after it sends INIT message sets the T1-init timer. If the timer expires before an INIT-ACK is
received from the peer, the eNodeB resends the INIT message a maximum number of times set by the
parameter max.INIT.Retransmits.
If the INIT-ACK is not forthcoming on the last re-send the eNodeB raises alarm SCTP ASSOCIATION
FAILURE.
The eNodeB requests the SCTP protocol retry to initialize the association a repeated number of times as
defined by ALU proprietary parameter sctpAssocEstablishmentMaxRetries.
The value 255 defines infinite number of retries.Similarly during Initialisation, if the eNodeB receives the
INIT-ACK and sends COOKIE, it starts the T1-cookie timer. If the timer expires the eNodeB resends the
COOKIE message a maximum number of times set also by the parameter max.INIT.Retransmits.
If the COOKIE-ACK is not forthcoming on the last re-send the eNodeB raises alarm SCTP ASSOCIATION
FAILURE.

SCTP Association Establishment
Local SCTP Peer SCTP

endpoint endpoint
INIT
Start T1-Init timer
State Cookies creation with: INIT ACK

-timestamp=t t State cookie embedded Stop T1-Init timer
-Lifespan= valid.cookie.life
Cookie Echo
t + t State Cookie sent back Start T1-cookie timer
If (t =< valid.cookie.life) Cookie Ack Stop T1-cookie timer
ERROR
If (t > valid.cookie.life) Cause:Stale cookie Error

re-started if either end sends another INIT later

terminated if either end sends an ABORT
SCTP supports :
multiple streams, where a packet error in one stream does not delay data in other streams.
This protocol thus addresses the head-of-line blocking issues apparent with TCP
multi-homing, end-points of an SCTP association may have multiple IP addresses allowing
resiliency of using different routes/media between equipments.

Association Failure / Path Failure
eNodeB Peer: (eNB/MME)
Data to IP@1
Start T3- rtx
RTO Data and/or SACK Primary path
T3- rtx expiry X (IP@1)
Error_path1=+1
Heartbeat to IP@1
Start HB Timer
HB Timer Heartbeat ACK
HB Timer expiry X
Error_path1=+1
error_path1 >
X Switch to secondary path
sctpAccessPathMaxRetrans
Data to IP@2 Secondary path
Start T3- rtx
T3- rtx expiry RTO Data and/or SACK (IP@2)
X
Error_path2=+1
error_assoc>
sctpAccessPathMaxRetrans X Alarm-SCTP association down

The eNodeB monitors the SCTP associations for failure based on Heartbeat ACKs and Data ACKs
monitoring. Data Chunks are retransmitted based on the RTO Retransmission Timer within the SCTP
stack. If the RTO expires before a Data Chunk is acknowledged then the Data Chunk will be
retransmitted.
The Heartbeat repetition interval is function of parameter HB.Interval.

SCTP maintains a retransmission counter per path. When a counter exceeds the Path.Max.Retrans
the destination address is marked as inactive.
The only action performed on path failure is the switching of the primary path by the SCTP stack.
No indication is sent to OAM when this occurs.
SCTP also maintains a counter for the total number of retransmissions to the peer over all paths (if
peer is multi-homed). When the counter exceeds the Association.Max.Retrans to the peer the
eNodeB considers the peer unreachable, stops transmitting and raises alarm SCTP ASSOCIATION
DOWN.
The eNodeB requests the SCTP protocol retry to initialize the association a repeated number of
times as defined by ALU proprietary parameter sctpAssocEstablishmentMaxRetries.

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

RTO timer
Doubled
Retransmissions
occur till Max
retransmit value SCTP data retransmi
ssion
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.

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 supported:

zsctpSACKTimer - 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.
zsctpRTOMin - 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.
zsctpRTOInit - 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.

End of module
LTE Transport Overview


@@SECT
Section 1
Module 3
LTE eNodeB Hardware Description
LE
9400 LTE

Blank page

eUTRAN Technical Overview LTE eNodeB Hardware Description
Document History
11 2012-10-15 Andonian, Ikram Edition 11
12 2012-12-28 Andonian, Ikram Edition 12

Module objectives
Describe the eNodeB architecture

Describe the eNodeB Base Band Unit and Radio modules
Describe some eNodeB special configurations




Table of contents
1 eNodeB description 7
1.1 General Architecture 8
1.2 General eNodeB Architecture 9
1.3 Standard Configuration 10
1.4 RF Architecture 11
1.5 Supported Frequency Bands & Carrier Bandwidth in LA5.0 12
2 9926 BBU (Base Band Unit) 15
2.1 BBU Design 16
2.1.1 BBU Shelf and Rack Backplane 17
2.2 Fan Tray (Rack User Commissioning) Description 20
2.3 BBU Configurations For LA5.0 Release 21
2.4 Enhanced Core Controller Module (eCCM) Description 23
2.4.1 eCCM Functionnalities 24
2.4.2 eCCM Face Plate Description 25
2.4.2.1 GE MDA Face Plate 26
2.4.2.2 eCCM Backhauling Optical Interfaces 27
2.4.3 CPRI Interfaces 28
2.4.4 GPS Connection via GPS-RF Input Port Overview 29
2.4.5 GPS Signal Splitting for Collocated BBU 30
2.4.6 GPS Connection Via PPS Input Port 31
2.5 Enhanced Channel Element Module (eCEM) Description 32
2.6 b Channel Element Module (bCEM) Description 33
1 3 5 2.7 Enhanced Alarm Module (EAM) 34
2.8Overview
eNodeB R-OCM Configuration
eUTRAN Technical LTE eNodeB Hardware Description
35
2.9 RETA Control Via RFM AISG Connector 37
2.10 RETA Control Via RFM AISG Connector Configuration 38
2. 11 RETA Control Via RFM AISG Connector Configuration 39
3 TRDU Macro modules 44
3.1 TRDU Description 45
3.1.1 TRDU Configurations 47
3.1.2 Cabinet/ TRDU Configurations 48
4 Remote Radio Head (RRH) 52
4.1 RRH Description 53
4.2 RRH Benefits 54
4.3 RRH With RDEM 55
4.4 FDD RRH Configurations 56
4.5 TD-RRH Configurations 57
4.6 CPRI Configuration Of the RRH 58
4.7 Beamforming Configuration for TD-RRH 59
4.8 Antenna Cross Connect Configuration 60
4.9 Cabling Delays 61
4.10 Fiber Delay Compensation 62
5 MC-TRX Module 64
5.1 MC-TRX Description 65
5.1.2 eNodeB Architecture Based On MC-TRX 67
5.1.3 Carrier/Power Configurations 68
6 eNodeB advanced capabilities 71
6.1 Feature And Capacity Licensing 72
6.1.1 Number of Active Users Licensing 73
6.2 Capacity 74
6.3 eNB Reliability 75
7 Appendix A : RF modules description 77
8 Appendix B : eNodeB enclosures 81



1 eNodeB description


1.1 General Architecture
Antenna
Digital <-> Radio

eNodeB Receives and sends digital signal to/from Base
Band
RFmodule Receives and sends radio signal to/from antennas
Includes Power Amplifier, Duplexers, Receivers
CPRI
eNode B brain and link to the network
S1 and X2 interface to ePC and other eNode Bs
BaseBandUnit through Gigabit Ethernet port
Processing capabilities
Send/Receive signal to/from radio through CPRI
S1&X2 link
EPCandother
eNodeB

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

1.2 General eNodeB Architecture
The eNodeB is an integrated system composed of a cabinet, a BBU and RF modules
that can be : TRDUs, RRHs or MC-TRX
GPS
Digital
Radio Module
eAM (enhanced Alarm Module)
CPRI
RRH
(Base Band Unit)
(Radio Remote Head)

BBU
OR
CPRI TRDU
(Transmit Receive Duplex)
Frame
Alarms
User
DC- PS Backhaul
Alarms

From architecture point of view, two types of eNodeB can be found:

Compact eNodeB, based on TRDUs (Transmit Receive Duplex Unit) or on MC-TRXs (MultiCarrier TRX)
Distributed eNodeB, based on RRHs (Remote Radio Heads)
In both cases:
The separation between digital and RF processing is ensured through CPRI interface,
The digital processing is ensured by the BBU (Base Band Unit), the BBU architecture being the same for
compact and distributed eNodeBs.

1.3 Standard Configuration
x2 x2 x2
TRDU TRDU TRDU

Or Or Or
RRH RRH RRH
Or Or Or
MC-TRX x2 MC-TRX x2 MC-TRX x2
CPRI CPRI CPRI
Base Band Unit

In LA5.0 the RF part is ensured by either TRDU or RRHs or MC-TRX only (no mixture is allowed within the
same eNodeB).
The 2x2 MIMO is the normal base station transmit scheme for all eNodeB variants.
However, other transmit schemes are supported since LA4.0 Release, thus to serve in-building systems, and
to provide service where two transmit paths per sector are too costly or infeasible. These transmit schemes
are:
Single Antenna Transmit Scheme
Low Power eNodeB DAS Support Configuration

1.4 RF Architecture
In LA5.0, eNodeBs can have up to 6 sectors (Case of dual band).
The following diagram shows the potential sectors configurations with one or two
bands.
Band #1
Band #2
3- Antennas 6- Antennas
3- Sectors 6- Sectors
3-Cells 6-Cells


1.5 Supported Frequency Bands & Carrier Bandwidth in LA5.0


Check the correct corresponding module for each function, in the
table below:
Functions Base Band Unit Radio Module

Receives and sends digital signal to/from
Base Band
Processing capabilities
Send/Receive signal to/from radio
through CPRI link
Receives and sends radio signal to/from
antennas
S1 and X2 interface to ePC and other
eNode Bs through Gigabit Ethernet port
Includes Power Amplifier, Duplexers,
Receivers


Exercise
Please fill in the gaps with
Radio Module
the correct modules names
OR
GPS
.
.
Backhaul

BBU
(Base Band Unit)
DC- PS
. User
Alarms


2 9926 BBU (Base Band Unit)


2.1 BBU Design
- 48VDC
Frame Ext User
Alarms Alarms Alarms
-48VDC Fan Rack
+ 5 VDC
External RUC
Alarm Module (Front & Backplane (RBP)
External
Alarms Back Unit)
1 Wire Bus GigE
HSSL
(GRU) Internal Alarms
GPS Receiver 1 Wire Bus
eCEM eCEM eCEM

1PPS Or Or Or
bCEM bCEM bCEM
CCM
MDA
SFP SFP
GigE
Fiber Optic Cable
CPRI Links
to 7705 SAR
(Up to six units)

The 9926 BBU consists in four types of boards and/or module:
The BBU shelf, including the RBP (Rack Back Plane)

The eCCM-U which controls OAM management, part of call processing and internal/external data flow
switching/combining, supporting external/internal alarm connectivity and external synchronization reference
interface. Depending on the BBU configuration, one or two eCCM-U boards are fitted in the BBU shelf.
The eCEM-U or bCEM which controls part of call processing and base band transmit/receive digital signal
processing. Depending on the eNodeB configuration, up to three eCEM-U boards, or up to two bCEM could
be fitted in the BBU shelf.
The RUC (Rack User Commissioning) supports all commissioning of non-volatile memories, and fan
alarms.
Two variants of RUC exist: -48VDC variant, or +24VDC variant

The 9926 BBU can be installed in a standalone indoor mode or in an existing indoor or outdoor Alcatel-
Lucent 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.1 BBU Design
2.1.1 BBU Shelf and Rack Backplane
The 9926 BBU has been specifically designed for coverage within constrained
Environments. It can be installed in:
Indoor environments: eNodeB cabinets, or standard 19 and 23 racks

Outdoor environments: eNodeB cabinets, or existing GSM or CDMA outdoor
cabinets, or inside power supply cabinets.
The 9926 BBU can be installed horizontally or vertically.
eCEM Slot 4
eCEM Slot 3 Air
eCEM Slot 2 flow
eCCM Slot 1
9926 BBU d2Uv3 fantray/RUC
FanRackUnit
bCEM Slot 4
bCEM Slot 3 Air
bCEM Slot 2 flow TDD
eCCM Slot 1 Only
9926 BBU d2Uv5
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.
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.
Globally, the BBU operates under following climatic conditions:

Operational Environment: ETS 300 019-1-3, Part 1-3, class 3.2
Operating Temperature Range: 5C up to +65C
Operating Relative Humidity: +8% to +100%
Absolute humidity: 0.03 g/m3 to 36 g/m3
and under seismic conditions defined by IEC 721-2-6, Zone 4.

2.1 BBU Design
2.1.1 BBU Shelf and Rack Backplane [cont.]
The RBP (Rack Backplane) allows:

communications between eCCM and eCEM/ bCEM boards inserted into the
shelf.
Power distribution from the fan tray module to eCCM and eCEM/ bCEM
boards.
9926 BBU 9926v2 BBU

(d2uv3) (d2uv5) LA5.0
eCCM-u (1) (1 or 2)
eCEM-u (3) (3 or 2)
bCEM X (3 or 2)

The RBP has also its own signals:

Dallas bus for remote inventory,
Backplane identification,
Module slot identification.
Boards detection
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.

2.1.1 BBU Shelf and Rack Backplane [cont.]
d2UV3 Subrack Powerconnector
Rack Back Plane Front View forCEM
Powerconnector
forCCM Input
Power
connector
Highfrequencies
Digital connections
connectors
a flexible slot that can act as a controller slot d2UV5 Subrack

or a modem slot Rack Back Plane Front View

RBP (user Rack Back Plane), supports all internal links between CCM-U and CEM-Un modules.
The d2Uv5 backplane feature a flexible slot that can act as a controller slot or a modem slot. Hence it can
support either one controller plus three modems, or two controllers plus two modems, in a programmable
fashion

2.2 Fan Tray (Rack User Commissioning) Description
The RUC (Rack User Commissioning) provides :
Power supply and filtering functions,

Current limitation,
Commissioning and inventory functions (non volatile memory),
Fan alarms report and power supply,
DC Power supply connectivity
Fan Tray
-48VDC RUC -24VDC RUC
Front View Front View

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.
As previously said, the 9926 BBU can operate either in -48VDC or +24VDC.
The nominal DC voltage ranges are:
40,5 VDC to -57 VDC
+20 VDC to +28.8 VDC
Within these nominal voltage ranges, the BBU operates at full performance.
The BBU will not suffer any irreversible damage when powered within an abnormal voltage within the range
-0 VDC to -40.5 VDC.
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 BBU Configurations For LA5.0 Release
The 9926 BBU configuration depends on the following eNodeB parameters and/or
characteristics:
Number of sectors
Backhaul physical interface (Gigabit Ethernet, or Fast Ethernet)
CPRI Rate
Power supply (-48VDC or +24VDC)
TDD
Only
9926 BBU 3 sectors with eCEM-U 9926 BBU 3 sectors with bCEM-U
In LA5.0 only one bCEM is supported in the eNodeB, per band.

If dual-band configuration, than two bCEM must be installed.

The d2Uv3 provides the following attributes:

eCCM-U (enhanced Core Controller Module)
Three eCEM-Us (enhanced Channel Element Module)
RUC (Rack User Commissioning)
RBP (Rack Back Plane)
d2UV5 subrack is mandatory for BBU configurations with bCEM board.

The d2Uv5 provides the following attributes:
eCCM-U (enhanced Core Controller Module)
Three bCEM-Us (broadband Channel Element Module)
RUC (Rack User Commissioning)
RBP (Rack Back Plane)

2 9926 BBU (Base Band Unit) TDD
2.3 BBU Configurations For LA5.0 Release [cont.] Only
With the introduction of the bCEM modem board in LA5.0, other BBU configurations
are possible, such as:
6 sectors or 2 carriers 3 sectors
CCM
Band#1
Carrier#1 RRH
Band#1
Band#1 RRH
Carrier#1 Band#2
Band#1
Carrier#1 RRH
Band#1 Band#1
Carrier#1 Band#1 RRH
RRH Band#2
Carrier#1 Band#1
RRH
Band#1 Band#2
Carrier#1
9926 BBU Dual Band Configuration - 3 sectors with 2 x bCEM

6 sectors or 2 carriers 3 sectors using:

1 x BBU shelf, including the rack back panel,
1 x eCCM-U controller board,
2 x bCEM modem board (each bCEM handles 3 sectors),
1 x Fan Tray on the right side, including fans and power entry module.

2.4 Enhanced Core Controller Module (eCCM) Description
The eCCM-U (enhanced Core Controller Module) is composed of:
The eCCM-U MB (Mother Board).

The MDA (Media Dependent Adaptor) daughter board providing
different backhauling options.
The eCCM-U used in LA5.0 is equipped with a Gigabit Ethernet MDA (GE MDA).
The eCCM-U MB together with the GE MDA constitutes the eCCM-U GE module.
This eCCM-U GE module provides interfaces for external connectivity through:

The eCCM-U own face plate
The GE MDA front plate

In LE5.0 The 9926 BBU could house up to 2 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 MDA is not a field replaceable unit. The MDA is a mezzanine board fixed on the eCCM-U MB and
providing, via its face plate, different connectivity options.

2.4.1 eCCM Functionnalities
The functionalities provided by the eCCM-U GE module used in LA5.0 are the
following:
Internal interfaces to eCEM-U/bCEM boards,

Base band samples routing and summing,
IP plane support,
CPU power to manage the eNodeB terminated flows,
eNodeB synchronisation,
O&M functions,
Collection of own 9926 BBU alarms, inventory and commissioning data,
Collection of external user alarms from optional alarm module (eAM),
OIM features to support up to six optical links,
Integrated GPS receiver (Refer to APPENDIX C)
High stability OCXO


2.4.2 eCCM Face Plate Description
Not Used
In LTE
GE MDA
for links
6 SFP cages ules
To radio m od
In LA5.0 only one single GE Interface is supported for the backhaul.

The face plate of the eCCM-U provides the following connectors and LEDs:
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 format connectors for connectivity to the radio modules (RRH, TRDU); each SFP
connector is equipped with two light indicators;
they support 6 CPRI links or 3 CPRI + 3 HSSL 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,
One double RJ45 connector used for debug (RS232) and Ethernet (NEM); each connector is equipped
with two LEDs (a yellow one showing Ethernet activity status and a green one for Ethernet link status),
Note: RJ45 Debug interfaces must not be used during normal operation of the BBU. (Risk of unstable
behavior, crash, )
The face plate of the GE MDA provides:
One RJ45 connector for GE electrical backhaul
Two SFP connectors for GE optical backhaul
Due to the GE MDA hardware design, a total of two connectors (i.e. 2 optical or 1 optical + 1 electrical) can
be used at a given time on the GE MDA.
In case of optical link, only the SFP-2 port is enabled.

2.4.2.1 GE MDA Face Plate
SFP1 SFP2 RJ45
GE MDA Face Plate
In LA5.0 release, only one single GE Interface is supported for the backhaul. In
case of optical link, only the SFP-2 port is enabled.

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.
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/EIA-568
standards.
Fast Ethernet on the embedded RJ45 port can also be used, but not recommended.

2.4.2.2 eCCM Backhauling Optical Interfaces
Two different optical modes are possible: LC connector
Single Mode Dual Fiber

Multi Mode Dual Fiber (recommended solution)
Optical
Use Wavelenght Functionnalities
Mode
Multi
Short
Mode 850 nm
Distance
Dual Fiber
Single
Long
Mode 1310 nm
Distance
Dual Fiber
SFP Variants vs Optical Modes chosen for backhaul links

The Network Engineer must then take care of the distance between the BBU and the ODF (Ethernet
Backhaul connection point). For both optical modes, LC-LC fiber cables of 15m length are defined for
ordering.
Depending on customer optical link choice (Multi mode or Single mode), the SFP cages of the eCCM-U
board will be equipped with corresponding optical SFP transceivers.
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.
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).

2.4 Controller Board Description
2.4.3 CPRI Interfaces
Between the BBU and the RRHs, the CPRI links are carried over optical fibers.
The following diagram shows the configuration in three sectors case:
BBU
eCCM-U RRH RRH RRH
board
Frame (Option)

1.
Distribution
Optical
2.
3.
CPRI
4.
R2CT weatherized
5. connector
6.
LC-LC connectors

CPRI (Common Public Radio Interface) 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.
For information, the CPRI links bit rates supported in LA5.0 release are: 1228.8 Mbit/s (Rate 2) and 2457.6
Mbit/s (Rate 3).
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
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.

2.4.4 GPS Connection via GPS-RF Input Port Overview
The eCCM-U board of the BBU is equipped with an integrated GPS receiver board
having a GPS-RF input port (SMB connector) and a PPS input port (RJ45
connector).
The main components entering in the GPS chain are: the GPS antenna, the
lightning protector and the coaxial cables.
High-quality, low-loss 50 Ohm coaxial cables should be used for the GPS antenna
connections.
eCCM-U board
RF GPS cable SMB_F-N_F
Optional Secondary Protection N_F-N_M
RF GPS cable N_M-DIN_M Indoor

Outdoor
Lighting Protector
DIN_F-DIN_M GPS antenna
Optional Shield Tap Kit N_F

The usage of the GPS-RF input port is the recommended Alcatel-Lucent solution, but the usage of the PPS
input port can still be used if the operator has already an external GPS receiver with PPS interface.
Note: Secondary protection is an option, it can be required by some customers.

2.4.5 GPS Signal Splitting for Collocated BBU
If two or more eNodeB are collocated, it is possible to split the GPS signal to the
different eCCM-U integrated GPS receivers. In that case a GPS splitter will be
required.
eCCM2-U
eCCM1-U RF GPS cable SMB_F-N_F
board
board
Optional Secondary Protection N_F-N_M
RF GPS cable N_M-DIN_M

Indoor
Outdoor
Lighting Protector
DIN_F-DIN_M GPS antenna
Optional Shield Tap Kit N_F

Note: Secondary protection is an option, it can be required by some customers.

2.4.6 GPS Connection Via PPS Input Port
The PPS input port allows providing clock synchronization and
communication with TMU.
The eCCM-U can talk with the TMU with the serial link.
Pin
Signal
Num
1 2 3 4 5 6 7 8 9 10 1 PPS_P (Input or Output, by SW control)
2 PPS_N (Input or Output, by SW control)
3 TMU_TXD_P(RS422)
4 TMU_TXD_N(RS422)
5 GND
6 NC
7 TMU_RXD_P (RS422 input or RS485 I/O, by SW
control)
8 TMU_RXD_N (RS422 input or RS485 I/O, by SW
control)
9 EXT1_TX_RS232
10 EXT1_RX_RS232

The PPS input port can still be used if the operator has already an existing TMU (i.e external GPS receiver)
with PPS interface.
The TMU_RXD_P/N pins can be configured as either input-only for RS422 full duplex or as bidirectional
signals for RS485 half duplex for the RET interface (AISG-compliant) via software control. The termination
is software switchable. The software can then switch out the termination when the Rx pins are used for
transmit (RS-485) or when a termination exists outside the board in a daisy-chained configuration.
The GPS PPS_P/N pins can be configured as either inputs or outputs via software control. The termination
is software switchable. The software can then switch out the termination when these pins are used for
transmit or when a termination exists outside the board in a daisy-chained configuration.
The cable type to be used will be of RS422 type.

2.5 Enhanced Channel Element Module (eCEM) Description
The eCEM-U (enhanced Channel Element Module) provides base-band signal
processing for both the Tx and Rx paths of the eNodeB.
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 face plate of the eCEM-U provides a dual port RJ45 connector for debug (first port labelled ICU,
second port labelled BBU).
Both provide a 10/100Base-T Fast Ethernet interface, including an RS232 UART line and synchronisation
output (from eCEM-U FPGA).
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 b Channel Element Module (bCEM) Description
The bCEM supports the following functions:
Board level OA&M functions,
Call processing,
L1& L2 processing: TDD
Radio Link Control function (RLC) Only
Media Access Control function (MAC)
DL/ UL Schedulers
2X2 MIMO 1X20 MHz/ 2X2 MIMO 1X10 MHz

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

The face plate of the bCEM provides triple port RJ45 connector for debug, labelled Test BBU, Test SW
and Test ICE.
Debug ports Test SW and Test ICE provide a 10/100/1000 Base-T Ethernet interface, and Test BBU
debug port provide including an RS232 UART line and Synchronisation.
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.
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.
The bCEM modem has the ability to be configured for all 3 cells on the eNodeB.
By doing so it allows the eNodeB to have fewer units within its framework. Having fewer units in the
eNodeB frees up existing space for future use, such as redundant modem or redundant controller and
allowance for 6 sector support by using 2 bCEMs.

2.7 Enhanced Alarm Module (EAM)
If external alarms shall be managed, an External Alarms module (eAM) can be
connected to the BBU. (It is optional)
The eAM is available in two different HW versions:
The Indoor version: eAMi
The Outdoor version: eAMo (Integration in outdoor eNodeB cabinets)
The eAM will be installed collocated to the BBU, as it receives power and signals
from the eCCM-U board.
Connected to RUC
Ext. port alarm

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.
The eNodeB collects alarm information using the eAM and the internal one-wire interface. All user alarms
and internal alarm connections, such as the door-intrusion and fan- alarm signals, must use the eAM.
The eNodeB collects frame alarms directly with no external module needed. The remaining d2Uv3 frame
alarms are unassigned. TRDUs will convey all alarm information via the CPRI interfaces to the controller in
the BBU.

2 9926 BBU (Base Band Unit) FDD
2.8 eNodeB R-OCM Configuration Only
The Reverse-Optical Communications Module (R-OCM) configuration is used for

compatibility with existing ALU CDMA equipment.
It allows sharing of existing RF equipment, feedlines, and antennas when LTE shares a
block of RF spectrum with CDMA.
The following Figure provides a high level overview of the sharing. The R-OCM module
replaces a modem unit in the CDMA base station.
CDMA_ BTS
3G-1X CDM
MCR-1+
eNB BBU Channel
Tx AMP
& Filer
Card
eCCM-U Channel
CPRI Card MCR-2+
GPS Tx AMP
10/15Mhz Ref CPRI & Filer
Backhaul(Gig E) R-OCM
Alarm CPRI
MCR-3+
CDMA Tx AMP
eCEM-U eCEM-U eCEM-U & Filer
Controller

The R-OCM takes baseband signals from the d2u BBU and inserts them onto the backplane of the CDMA
base station in a manner similar to a CDMA modem unit.
The R-OCM appears to the BBU to be three individual RRHs that are connected to three of the BBUs CPRI
ports.
The R-OCM arrangement supports 2Tx/2Rx (refer to table 3) . The RF power is dependent on the CDMA
equipment.

2 9926 BBU (Base Band Unit) FDD
2.8 eNodeB R-OCM Configuration [cont.] Only
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.
Optical CPRI
Connection
Reverse OCM
circuit pack

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 LA5.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
No bCEM support on R-OCM configurations. R-OCM configurations are only supported with eCEM boards.

2.9 RETA Control Via RFM AISG Connector
The AISG protocol is designed to provide the means by which antenna line
products with remote control and monitoring capabilities can be introduced.
It is currently defined for two types of Antenna Line Devices: ANT-1
Remote Electrical Tilt (RET) Antennas

Tower Mounted Amplifiers (TMA).
The maximum AISG cable length depends on the RET

following parameters:
Output Power supply on AISG connector (pin 6)
of the RFM (or TMA) AISG
RF Cable
AISG topology (Star, daisy chaining, )
Number of RCUs connected
RCU (RET) power consumptions (standby and
with motor rotating)
Conductor size of AISG cable (typically pin 6) RRH_1
Note: In LA5.0 all RRHs and TRDUs support the AISG feature. But
No AISG on MC-TRX.

AISG protocol uses a 3-layered model comprising a physical layer, a data link layer and an application
layer.
RETAs dont allow AISG daisy chaining.
Each RFM drives the RETA to which it is associated.

2.10 RETA Control Via RFM AISG Connector Configuration
Direct Connection between AISG Daisy Chaining
RFM and RET
RETAs dont allow AISG daisy chaining. RETAs allow AISG daisy chaining.
Each RFM drives the RETA to which it is All RETAs are driven from the same
associated. RFM (RRH_1 in our case)
The AISG cables have approximately
the same length as the RF feeders.
ANT-1 ANT-2 ANT-3 ANT-1 ANT-2 ANT-3
RET RET RET RET RET RET

AISG
Cable
RF RF RF RF RF RF
RRH_1 RRH_2 RRH_3 RRH_1 RRH_2 RRH_3


2. 11 RETA Control Via RFM AISG Connector Configuration
AISG Connection through AISG Splitter
The RETAs dont allow AISG daisy chaining.

All RETAs are driven from the same RFM
(RRH_1 in our case)
A 1:3 AISG splitter is used (Specific Cable)
ANT-1 ANT-2 ANT-3
RET
RET RET
RET RET
RET
1:3 Splitter
AISG
RF RF RF Cable
RRH_1 RRH_2 RRH_3


Exercise
1- Please fill in the gaps the correct modules names
- 48VDC Alarms
Frame Ext User

Alarms Alarms -48VDC

+ 5 VDC
External
Alarm Module
External
Alarms
1 Wire Bus
Internal
Alarms
1 Wire Bus
(GRU) 1PPS
GPS Receiver .. .. .

MDA
SFP SFP
..
CPRI Links
(Up to six units)


Exercise
2- Fill in the gaps the interfaces and connectors names of eCCM module:
.. ..
..
.. ..

..
..


3- 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
4- The 1588 v2 synchronization is obtained through the

CPRI link
External synchro port
GPS antenna port
One of the Ethernet port


Exercise
5- Which protocol is designed to provide the means by which antenna line products
with remote control and monitoring capabilities??
a) CPRI
b) AISG
c) Ethernet
d) HSSL


3 TRDU Macro modules


3 TRDU Macro modules FDD
3.1 TRDU Description Only
The TRDU (Transmit Receive Duplex Unit) has two RF transmitters, two receivers
(LNA), and double duplex filter, packaged in a single shelf-mounted module.
TRDUs are not supported for TDD.
TMA TMA TMA
TRDU TRDU TRDU

CPRI CPRI CPRI
Optical
fiber
CPRI CPRI CPRI LTE BBU
Backhaul Compact eNodeB with TRDU/

Functional Diagram
The TRDU will be located in Compact eNodeB, either in indoor cabinet, or in outdoor cabinet.
The TRDU supports 2-way MIMO. Two TRDU modules can be combined to support 4 x 4 MIMO, or 2-way
MIMO with 4 receive branch.
Taking the case of 2 x 40W TRDU, the nominal transmit power is 2 x 45 Watts at the duplexer ports. This is
to support 40W at the external antenna connectors (EAC), accounting for up to 0.5dB of loss in the jumper
cable between the TRDU and top of cabinet.
The principle is the same for the 2 x 60W TRDU.

The TRDU supports CPRI Rates 2 to 4 (and is hardware ready to support CPRI Rate 1).
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.

3 TRDU Macro modules FDD
3.1 TRDU Description [cont.] Only
Two SMA connectors for CPRI PRI

external VSWR test ports Two SMA connectors CPRI SEC
for auxiliary RX (AUX RX)
connector for power entry

(-48 VDC or +24VDC)
Two ANT TX/RX
Two SMA connectors for TX main

AISG Port and TX Diversity testing (TX MON)

On the TRDU front plate, the following connectors are available:

One 2W2 socket connector for power entry (-48 VDC or +24VDC)
Two ANT TX/RX (7/16 coaxial female connector on TRDU2x60-26, N coaxial female connector on other
TRDU types)
Two SMA connectors for auxiliary RX (AUX RX)
Two SMA connectors for TX
Two SMA connectors for external VSWR test ports
Two CPRI ports for SFP Transceivers
CPRI PRI to connect the TRDU to the BBU
CPRI SEC to support daisy-chaining in and TX Diversity testing (TX MON)
Restriction: Daisy-chaining not supported in LA5.0 release.

3.1 TRDU Description FDD
3.1.1 TRDU Configurations Only
The following table lists the different TRDU available for LA5.0 release,
with their related frequency band and output RF power.
Output PS PS
TRDU Naming Frequency Band
RF power (+24VDC) (-48VDC)
Band XIII
TRDU2x40-07U 2 x 40W
(700 MHz Upper)
Band XIV
TRDU2x40-07PS 2 x 40W
(700 MHz)
EDD Band
TRDU2x40-08L 2 x 40W
(800 MHz Lower)
EDD Band
TRDU2x40-08U 2 x 40W
(800 MHz Upper)
Band VII
TRDU2x60-26 2 x 60W
(2600 MHz)


3.1.2 Cabinet/ TRDU Configurations Only
Rack
TRDU 9412 ID 9412 OD MBI5 MBO2
Mount ID
TRDU2x40-07U
TRDU2x40-07PS
TRDU2x40-08L (*)
TRDU2x40-08U (*)
TRDU2x60-26 (*)
(*) only if customer identified
Cabinet/TRDU configurations foreseen for LA5.0 release

The TRDU will be located in Compact eNodeB, either in indoor cabinet, or in outdoor cabinet.

3.1.2 Cabinet/ TRDU Configurations [cont.] Only
Indoor Cabinets
Top fan
Connection area
PDP
Air inlet
T T T
R R R
RackDMountDCUBED
U U U
2x 2x 2x
Fan Stage
Air inlet
PDP
Air inlet
T T T
R R R
RackDMountDCUBED
d2U
TRDUU800 Sub-Rack
U U
2x 2x 2x
Fan Stage
Air inlet
Options (2U)
Stand


3.1.2 Cabinet/ TRDU Configurations [cont.] Only
Multi standards Outdoor Cabinets
PDP
Air inlet
T T T
R R R
RackDMountDCUBED
TRDUU800 Sub-Rack
U U
2x 2x 2x
Fan Stage
Air inlet
Options (2U)
AC/DC
MBO1 Socket
MBO1 MBO2


Exercise
1- Please Link the TRDUto eCCM, using the correct connectores and name
the interfaces



4 Remote Radio Head (RRH)


4.1 RRH Description
The RRH (Remote Radio Head) module provides the RF part
of the eNodeB.
It includes :
Two RF transmitters to enable 2x2 MIMO applications
Two Multi Carrier Power Amplifiers (MCPA)
Two to four 20MHz Receivers to support 4-way Receive
Diversity
Solar shield removed

The HW is capable of supporting a single or multiple LTE
carriers over up to 20 MHz of spectrum of bandwidth.
The RRH can be on the same site where the BBU is located,
or on a remote site.
In both cases, these two equipments are linked by optical
fibers supporting CPRI interface.
In TLA5.X releases, only distributed eNodeBs can be deployed.

Solar shield in place
The RRH can be on the same site where the BBU is located, or on a remote site.
In both cases, these two equipments are linked by optical fibers supporting CPRI interface, carrying LTE
downlink and uplink (main and diversity) base band digital
signals along with OAM information.
Each RRH is equipped with two CPRI interfaces.
The RRH also include :
Its own energy system
Its own cooling system
AISG interface (allowing remote control and monitoring capabilities of the antennas)
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
Functions
Self contained radio part of distributed solution
Radio Transceiver
Power amplifier
Low Noise Amplifier
Filter front end (Duplexer)
Power system (-48V)
Power consumption ~ 320W
40% amplifier efficiency, 2x 40W EAC Tx + 2x Rx (exc AISG, RET, TTLNA)
Field installable & swappable Optical Transceiver/Fiber options
Multimode to support of to 500m
Single Mode to support up to 20km
Single and dual fiber variants

4.2 RRH Benefits
19W
44W
7/8" feeders
30m 2dB 0,3dB
Jumpers
TMA 0,4 dB
Jumpers
0,5 dB
33W Jumpers
0,8 dB
no more RF losses /(5m)
66% more power @ antenna !
40W
Optical fiber

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.

4.3 RRH With RDEM
To support 4-way Receive Diversity, the RRH will be coupled with a RDEM
module. (Dedicated variant of the RRH)
Extension of a RRH with RDEM is not allowed on site as the configuration requires
calibration at factory level.
If 4br Rx Diversity shall be supported, the good RRH variant shall be ordered.
RF Antennas
RDEM Module
RRH with RDEM Top Connection

All unused connectors shall be closed by a protection cap to prevent any contact and humidity entry.
(Protection caps are provided with the RRH at delivery time)
All unused RF connectors shall be protected with a metal cap.
4-Way Rx Diversity
Supported by use of optional RDEM (Rx Diversity Expansion Module)
Low installation weight
Weight below 13.5kg, using removable solar shield and heat-sink
Wide temperature range
-40 deg C to +50 with 1120W/mk of solar load
-40 deg C to +55 with no solar load.
TMA and RET support with AISG 2.0

4 Remote Radio Head (RRH) FDD
4.4 FDD RRH Configurations Only
The following table lists the different RRH available for LA5.0 release, with their
related frequency band, output RF power, and RDEM option.
Output RF
RRH Naming Frequency Band RDEM
Power
RRH2x40-AWS Band IV AWS (2100/1700 MHz) 2 x 40W
RRH2x40-07L Band XII, XVII (700 MHz Low) 2 x 40W
RRH2x40-07U Band XIII (700 MHz Up) 2 x 40W
RRH2x40-08L EDD band (800 MHz Low) 2 x 40W
RRH2x40-08U EDD band (800 MHz Up) 2 x 40W
RRH2x40-26 Band VII (2600 MHz) 2 x 40W
RRH4x40-19 (25MHz) 3GPP Band II (PCS 1900 MHz) 4 x 40W
RRH4x45-19 (65MHz) 3GPP Band II (PCS 1900 MHz) 4 x 45W
MC-RRH2x40-18 3GPP Band III (1800 MHz) 2 x 40W


TDD
4.5 TD-RRH Configurations Only
The following table lists the different RRH available for TLA5.0 releases,
with their related frequency band and output RF power.
RRH Naming Frequency Band Output RF Power

TD-RRH2x20-23 Band 40 (2300-2400 MHz) 2 x 20W
TD-RRH2x20-23-4R Band 40 (2300-2400 MHz) 2 x 20W


4.6 CPRI Configuration Of the RRH
The Common Public Radio Interface (CPRI) of the RRHs can be connected in two
different ways to the Base Band Unit:
Sector Sector Sector Sector Sector Sector
RRH1 RRH2 RRH3 RRH1 RRH2 RRH3

CCM CCM
CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI
CPRI CPRI
Star Configuration Daisy Chain Configuration*

(*Not supported in T/LA5.0)

Star configuration: The star configuration is used when the RRHs are being mounted far from each
other, but nearly equally spaced from the Base Band Unit.
Daisy chain configuration: The daisy chain configuration is used when the RRHs are being mounted
close together but far from the Base Band Unit

TDD
4.7 Beamforming Configuration for TD-RRH Only
Beam Forming is operated with "broadband dual polarization smart antennas".

These antennas are 2 x 4 array cross polarized antenna panel with calibration
port.
Sector Sector Sector

2x4 Array Cross
polarized Antenna
Calibration Port
TD-RRH1 TD-RRH2 TD-RRH3

CPRI CPRI CPRICPRI CPRI CPRI CPRICPRI CPRI CPRI CPRICPRI
3 sectors / Beam Forming RF Configuration


4.8 Antenna Cross Connect Configuration
Introduced from LA3.0 release, the Antenna Cross Connect feature avoids losing
one sector in case of RRH failure.
Sector Sector Sector
RRH1 RRH2 RRH3
Antenna Cross Connect between RRH and Cross Polarized Antennas

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.

4.9 Cabling Delays
In order to keep correct MIMO quality, the maximum delay between TX Main path
and TX Diversity path must be less than 11 ns.
The delay includes:
Optical Delay (optical cable length)
RRH transfer delay (delay to transfer the signal from CPRI input to RF port)
Copper Jumper + feeder delay
Note that the cabling delay does not include the BBU
and/or RFM processing delays
Delay 2
RRH
Delay 3
d2U
Delay 1
Antenna Cross Connect Total Delay to Antenna

The maximum delay (11ns) between TX Main path and TX Diversity paths is not without impacts on the
fibers length (CPRI), as well as on the RF jumpers and feeders.
CPRI fiber cable length to RRH shall be as much as possible the same for all RRHs. However, a maximum of
2m difference is acceptable between two CPRI fibers serving the same sector. (This fulfillment is
mandatory to be in the 11ns maximum delay acceptable between TX Main and TX Diversity paths of a RF
sector).

4.10 Fiber Delay Compensation
1. Simplified view of RRH-based Hardware and associated delays when

DAS is not used (cell view, case of 1 transmit antenna per antenna node)
CPRI Link (Fiber) RRH Feeder (Coaxial Cable)

d2U
CPRI Delay Antenna Path Delay
2. Simplified view of RRH-based Hardware when DAS is used (cell view,

case of 1 transmit antenna per coverage area)
DAS Delay
Feeder Delay
DAS
Feeder DAS Fiber Remote Unit
CPRI Link (Fiber) RRH (Coaxial Cable) DAS
d2U Optical DAS
Host DAS Fiber Remote Unit
CPRI Delay
Antenna Path Delay

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 fine 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 prefix, 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

1- How many ways, the CPRI could be connected with?
2- What is the benefit of using Antenna Cross Connect?
3- what does the red cable in the picture below used for?
Sector
???
TD-RRH1
CPRI CPRI CPRICPRI


5 MC-TRX Module


5 MC-TRX Module
5.1 MC-TRX Description
The MC-TRX is a multi carrier transceiver which
can operate in LTE technology only, but it is LTE
mainly intended to be used in dual technology:
LTE+GSM.
3G
In LA5.0 release, only the 1800 MHz MC-
TRX is supported.
The MC-TRX will be located in MBI5 and/or

MBO2 GSM cabinets. 2G
The MC-TRX is connected to an Antenna Network

(AN) before interfacing the antenna. The AN
playing the Duplexer role. MC-TRX 1800 MHz Front View

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.
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.
Rule: Not more than 2 MC-TRX can be connected per AN.
Multi-Technology support
20 MHz total bandwidth
Based on SDR technology principles
Ouput power
GSM: 6 carriers - up to 60W
W-CDMA: 2 carriers up to 60W
LTE: 1 carrier - 2x20W
Interface directly to LTE digital unit (BBU) via CPRI interface
GSM Modems included in the module
Zero foot print solution
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.

5 MC-TRX Module
5.1 MC-TRX Description [cont.]
Receiver Connector
Transmitter Connector
High Speed Ethernet

Interfaces
ON/ OFF
Rocket Switch
LEDs
Test
Connector
CPRI
MC-TRX 1800MHz Front Panel

The MC-TRX offers the following connections on the front panel:

One TX connector (QN female), providing a transmit RF interface to the antenna network module (AN)
One RX0 connector (SMA connector), providing a receive RF interface from the AN module via the
normal RF path
One RX1 connector (SMA), providing a receive RF interface from the AN module via the antenna diversity
path
Two CPRI interfaces: CPRI1 and CPRI2, providing two Common Public Radio Interfaces used to
interconnect the BBU (LTE)
Two HSE interfaces (RJ45 connectors): HSE1 and HSE2 for connection with the SUMX (GSM)
One Test interface (RJ45 connector), providing an interface to the TRE for factory test and debugging

5.1.2 eNodeB Architecture Based On MC-TRX

AN AN AN
MC-TRX MC-TRX MC-TRX MC-TRX MC-TRX MC-TRX

CPRI Ethernet CPRI Ethernet CPRI Ethernet CPRI Ethernet CPRI Ethernet CPRI Ethernet
CPRI CPRI CPRI CPRI CPRI CPRI
LTE BBU (d2U)

Ethernet
GSM SUM-X
Backhaul
eNodeB Architecture based on MC-TRX 3 sectors / 2x2 MIMO

The MC-TRX (Multi-carrier transceiver) is used to support LTE + GSM on single RF path. The Figure 3.2-7
shows the eNodeB architecture based on MC-TRX.
It shows MC-TRX connectivity to the GSM controller (SUM-X) and to the LTE BBU (d2U).
The connection between MC-TRX and BBU is ensured by CPRI links, and the connection between MC-TRX
and GSM SUM-X is ensured by Ethernet links.
Up to 6 MC-TRXs can be connected to the BBU in a star configuration.
The MC-TRX is connected to an Antenna Network (AN) before interfacing the antenna. The AN playing the
Duplexer role.
Rule: Not more than 2 MC-TRX can be connected per AN.
Note: For LTE MIMO 2x2, 2 x MC-TRX per sector are used.

5.1.3 Carrier/Power Configurations
the MC-TRX will support the following carrier/power configurations in dual

mode. (Always defined as W/carrier at Top of Cabinet for single MC TRX
module):
GSM LTE
1x16 1X40 1X16 + 1X35 / 1X10 + 1X40
1X16 1X30
2X16 1X20 2X16 +1X15 / 2X12 + 1X20
1X33 1X20
2X10 1X30 2X10 + 1X22/ 2X6 + 1X30
MC-TRX 1800MHz Carrier/Power Configurations


1- Complete the following sentence:
Compact eNodeBs host _____ radio modules whereas distributed eNodeBs
are equiped with _____ radio modules.
2- 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
3- What radio module is intended to be used in dual technology: LTE+GSM ?


Exercise
4- What is odd within the sketch below:4

AN AN AN
MC-TRX MC-TRX MC-TRX MC-TRX MC-TRX MC-TRX

CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI CPRI
CPRI CPRI CPRI CPRI CPRI CPRI

LTE BBU (d2U)
CPRI CPRICPRICPRICPRICPRI
GSM SUM-X
Backhaul


6 eNodeB advanced capabilities


6.1 Feature And Capacity Licensing

Following feature or capacity purchase (Purchase Order) for a specific number of eNB or cell optional
features or capacity resources, licenses are created for each feature or capacity unit with the ALU Licensing
tool (also called LKDI). The Licenses are available through an encrypted file, protected by a digital
signature.
The license (file) is installed into SAM using an application called RAN License Manager (also referred to as
RAN-LM in this document). This license file creates at SAM a pool of Tokens (RTUs) that are available for all
eNBs managed by SAM.
The operator can then distribute the pool of available optional feature or capacity tokens among all eNB(s)
via specific OAM parameters (also called Licensing Parameters).
These Licensing parameters are checked for each licensed resource by SAM (RAN-LM) anytime a change is
made so that the global license capacity provided by the License file is not exceeded Lixcense file (RTUs)
(Licensing parameters)
If the above mentioned SAM check fails for one of the licensed resources, the configuration of that specific
optional feature or capacity element is blocked, the configuration work-order is rejected, and no changes
covered by that work order will be activated for any eNB. No activations of the optional feature or capacity
element will be allowed until the number of available tokens exceeds the number of activations.
The following eNB capacity elements are managed by Capacity Licensing:
Transmission Power (per cell)
Number of Active users per eNB
Allocated Operating Bandwidth (per cell)

6.2 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.
In LA5.0 there can be up to 8 DRBs per User.

MME 1
S1 MME
DRB
SRB S1-U
UE
Assuming : SGW
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

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.

6.3 eNB Reliability
eNodeB start-up and restart time
eNodeB failure detection and reporting
eNodeB automatic recovery
Software Download
Software Activation (eNodeB reboot)
Software Accept
< 230 5620

SAM
Software
eNB Software Upgrade

SW Outage: < 2 mn 30 seconds
Time to complete a software reboot

< 2 30 for 99% of the reboot occurrences

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.

7 Appendix A : RF modules description


TRDU 2X overview
CPRI ports
PRI & SEC
TX/RX Antenna ports
Power entry 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 LA5.0.
AISG interface is not supported on TRDU2x40-08L and TRDUx40-08U.

MC-TRX overview
RX connectors
TX connector
On/off switch
CPRI ports
PRI & SEC


RRH 2X Overview
2 RF transmitters to enable 2x2 MIMO
Top View
Power supply
Links to BBU (optic fiber)
Alarms
Bottom View

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..

8 Appendix B : eNodeB enclosures


Cube Indoor Cabinet
9412 compact eNodeB
Enhanced Alarm Module

eAM
BBU
Fan Tray
Power
Distribution
Panel
3 TRDU2X
(3 cells)

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

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 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 FDD
only
TRDU2x40-08U
TRDU2x60-26
Cube Indoor Cabinet


eNodeB enclosures with RRH RF
Outdoor PSU Cabinet
Md4 oudoor cabinet
For BBU and transport

Network Elements

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
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
LTE eNodeB Hardware Description


@@SECT
Section 1
Module 4
LTE eUTRAN OAM Overview
LE
9400 LTE

Blank page

eUTRAN Technical Overview LTE eUTRAN OAM Overview
Document History
11 2012-10-15 Andonian, Ikram

Module objectives
Describe the main 5620 SAM features for the RAN

Describe WPS and NPO functions
Explain SON features




Table of contents
1 eUTRAN management via 5620 SAM 7

1.1 5620 SAM System overview 8
1.2 Configuration Management 9
1.3 5620 SAM eNodeB Self Configuration 11
1.4 5620 SAM support of eNodeB upgrade 12
1.5 Offline configuration 13
1.6 eNodeB Licensing 14
1.7 eNodeB Performance management 15
1.8 eNodeB Troubleshooting and Supervision 16
2 9952 Wireless provisioning System 18
2.1 Overview 19
2.2 5620 SAM and 9952 WPS : Offline configuration 20
3 9958 Wireless Trace Analyzer 22
3.1 WTA overview 23
4 9959 Network Performance Optimizer 24
4.1 Introduction to 9959 NPO 25
4.2 NPO Web client 26
4.3 PCMD 27
4.4 PCMD Real Time Monitoring Dashboard 28
5 Self Optimization Process 29
5.1 Self Organizing/Optimization Opportunities 30
5.2 eNB Self Establishment/Configuration 31
1 4 5 5.3 Intra-LTE ANR Configuration COPYRIGHT and Optimization 32
5.4 Inter RATeUTRANANR
ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.
eUTRAN Technical Overview LTE OAM Overview
33
5.5 Automatic Configuration of Physical Cell ID 34
5.6 Cell outage detection 35



1 eUTRAN management via 5620 SAM


1.1 5620 SAM System overview
GUI Client GUI Client delegate WS

WS
Server + Database
Primary Standby
Distributed
Collocated
Standalone solution Redundant solution
Collect Call trace and Performance

Auxiliary Management to off-load SAM
server
Preferred Reserved
Managed Network eUTRAN 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


1.2 Configuration Management [cont.]
5620 SAM proposes various eNodeB Physical VIEW in

management view : navigation Tree
Physical view on navigation tree
Topology map view
Logical View of cells, sectors
Network Element
View
eNodeB Logical
View

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 1
5620 SAM
Pre-Provisionned
eNodeB and pre-provisioned NE NE
match during eNodeB
discovery
3
Activation WO
Manager
4 Integration takes place based on DB

defined policy
Configuration data is
pushed to the
2
template

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 upgrade in 3 steps:

Software Download
SW Software Activation
(eNodeB reboot)
Software Accept
SW upgrade
policy

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 Logical object

Manager manager
Offline Online
configuration configuration
5620 SAM

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.

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
Policies are defined to
2 retrieve collected data
eNodeB automatically collects

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

3
at the end of collection
interval
5620 SAM statistics plotter Available for external tools
9459 NPO

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

5620 SAM provides states and statuses repotting for the underlying Managed Objects of the eNodeB:
z Administrative (configurable): Operational,
z Availability Status : gives info on Communication status (read-only field) and Managed state
(declared in GUI but not connected).
z Connection State : Offline, Not Connected, Online
z Alignment 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.]
1 Policies define call trace
sessions (trigger conditions)
5620 SAM
Ca
ll t
r ac
e
2 eNodeB sends call trace
messages to Aux server
CT Aux Server
Wireless Trace Analyzer
Aux Server converts

3 messages and adds
them to call trace file
9459 NPO/PCMD
Local repository
Traces available for external tools

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.

2 9952 Wireless provisioning System


2.1 Overview
WPS is a computer based application that simplifies :

The eNodeB provisioning & reverse engineering
Auditing of the network
Planning tools Other WPS
Work-order import / export WPS data sharing

in XML format and multi user
for interfacing collaboration
with 3rd party tools
Initial snapshot
Work-order export import and
for activation resynchronization
Main NM server

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.
z 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
Local repository Operator
On demand snapshot creation
or scheduled export 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


3 9958 Wireless Trace Analyzer


3 9958 Wireless Trace Analyzer
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
Ca
Call traces ll
tr
activation ac
e
request
Call trace
5620 SAM Wireless Trace Analyzer

Pulls call traces
CT Aux Server

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

4 9959 Network Performance Optimizer


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 WCDMA LTE
QoS decrease cause diagnosis
Radio resource configuration

tuning
Cartographic telecom
management
Performance
Reporting Geographical analysis
Hardware inventory
management QoS Alerter & Warning
Rules & CM Tuning 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

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, starting 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 activity B counters
UE 1 statistical EN
cla
ssi
rs ca
PC nte lP
UE activity MD ou M
(E Ec file
UE 2 NB l MM s
PC ) i ca
MD t ist
sta
(E
NB PCMD (MME+ENB)
)
MME PCMD (MME+ENB) NPO
animated slide

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 Based on
only (raw + last 60
rate)
values
1 line
Highlight
per MME
based on
Threshold
MME 1
One or FCA%
more
charts CDR%
: last 10 mn
Chart
area can
MME 2 be hidden
One or
more MME MME 3
per chart
FCA%
CDR%
: last 40 mn
Zoom
(Nice to have
Step 2)


5 Self Optimization Process


5.1 Self Organizing/Optimization Opportunities

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
5620 SAM
eNodeB Discovery :
4 connection established.
MME eNOdeB 1
Authentication with SNMPV3 preparation
OAM checks the SW

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

IP@ configuration
Mobile Core Network
eNB is establishing an IPsec

tunnel to the security gateway
and connect to MME IP Network 2 eNodeB power up
6 eNB is rebooting
7 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&deployment-
related 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 1 FDD
only
Cell A : PCI 3 , Cell

Global ID 17 Optional: Neighbour List
for initial NRT:
2 check White and black lists
UE reports that Neighbour Relations Table
PCI 5 has strong (NRT) per cell
Signal
5620 SAM
X2 Check operator preferences

before NRT table
3 update
MME
Cell B : PCI 5 , Cell

Global ID 19
Served Cell information sent eNodeB retrieves neighbor IP address for dynamic X2
over X2 interface 5 configuration, MME acts as relay 4

LA5.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 1 FDD
UE reports new Primary Scrambling Code only
Optional: Neighbour List

for initial NRT:
2 check White and black lists
UE reports
strongest cell for
given UTRAN freq Neighbour Relations Table
(NRT) per cell
5620 SAM
Check operator preferences

before NRT table
3 update
LAC and RAC present in CGI report used by
eNB to add UTRAN neighbor relation
in NRT. 4
NodeB

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
UE reports measurement
PCI algo but Source eNodeB is
confused with provided
PCI PCI algo
Collision Free: Confusion Free:

CellID unique to immediate neighbours 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.
Timer needs to be fine-

No RRC connected UE : tuned to avoid
sleepingCellInactivityTimer excessive alarms
Last UE leaves timer is triggered reporting
coverage area
5620 SAM
Expiracy
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 FDD
compensation mechanism to realize self-healing. 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.

Optimization SAM Client
Radio Trace OSS Customer
Analasys Provisionning
Planning OSS
SAM Client CM
FM
CT/ Soap PM
xml / xml
CM CM FM
QOS/ Parameters
Tunning/ PCMD
CM FM PM
Ssh, sftp
5620 SAM
CT
PCMD
Netconf CM Snmp CM Netconf CM

Snmp FM Snmp FM Snmp FM
Xml/ Snmp PM Snmp PM Snmp/ sftp/ xml PM
Ssh SW SW
CT CT
Sftp DDT SSh PCMD


Exercise
Please complete the missing tools on the following LTE OAM Architecture.
SAM Client
Trace OSS
Radio Customer
Analasys Optimization Provisionning
Planning OSS
SAM Client CM
FM
PM
CT/ Soap
/ xml CM CM FM
xml
QOS/ Parameters
Tunning/ PCMD
CM FM PM
5620 SAM
Ssh, sftp
CT
PCMD
Netconf CM Snmp CM Netconf CM

Snmp FM Snmp FM Snmp FM
Xml/ Snmp PM Snmp PM Snmp/ sftp/ xml PM
Ssh SW SW
CT CT
Sftp DDT SSh PCMD

Hint: use the interfaces names provided to complete the blue boxes.

End of module
LTE eUTRAN OAM Overview


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!
1 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

LTE (T) LA5.0 EUTRAN Technical Overview

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LTE (T) LA5.0 EUTRAN Technical Overview

Încărcat de

Drepturi de autor:

Formate disponibile

9400 LTE

(T)LA5.0 eUTRAN Technical Overview

COPYRIGHT ALCATEL-LUCENT @@YEAR. ALL RIGHTS RESERVED.

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

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Switch to notes view!

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1.Welcome to 9400 LTE

3 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

z Describe functions and the architecture of a LTE Access network

4 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

All Rights Reserved Alcatel-Lucent @@YEAR

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

112 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Edition Date Author Remarks

10 2012-02-01 Vincent, Cecile Edition 10

11 2012-10-15 Andonian, Ikram V5-Edition 11

12 2012-12-28 Andonian, Ikram V5-Edition 12

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

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

Describe the eUTRAN architecture

113 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

114 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Switch to notes view! Page

1 EnodeB functions and protocols 7

115 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Switch to notes view!

116 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

117 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

118 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

119 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

(S1 or X2)- AP User Plane PDUs

1 1 10 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Control Plane User Plane

GTPv2-C Diameter User Plane PDUs

SGW & PGW SGW &PGW

1 1 11 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

GTPv2-C is used on the following standardized interfaces:

Diameter is used on the following standardized interfaces:

GTP-U is used on the following standardized interfaces:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

S1AP message with Overload start

Selection algo. takes MME1 Overload

1 1 12 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

ion rejected Overload start indication contains reject

Service request from UE attached on this

1 1 13 COPYRIGHT ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.