9YZ039910004TQZZA - V1 - Alcatel-Lucent 9400 LTE Radio Access Network RAN Overview PDF

Use pursuant to applicable agreements
Title page
Alcatel-Lucent 9400
LTE Radio Access Network | Release LA6.0
RAN Overview
9YZ-03991-0004-TQZZA
Issue 1 | April 2013
Alcatel-Lucent – Proprietary
Legal notice
Legal notice
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective
owners.
The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2013 Alcatel-Lucent. All rights reserved.
Contains proprietary/trade secret information which is the property of Alcatel-Lucent and must not be made available to, or copied or used by anyone outside
Alcatel-Lucent without its written authorization.
Not to be used or disclosed except in accordance with applicable agreements.
Alcatel-Lucent – Proprietary
Contents
About this document

Purpose ............................................................................................................................................................................................. ix
ix
Intended audience .......................................................................................................................................................................... x

x
Supported systems ......................................................................................................................................................................... x

x
How to use this document ........................................................................................................................................................... xx
Conventions used ........................................................................................................................................................................... x

x
Related information ..................................................................................................................................................................... xi

xi
Document support ........................................................................................................................................................................ xi

xi
Technical support .......................................................................................................................................................................... xi

xi
How to order ................................................................................................................................................................................... xi

xi
How to comment ........................................................................................................................................................................... xi

xi
1 Long Term Evolution System Overview
Overview ...................................................................................................................................................................................... 1-1

1-1
Long Term Evolution .............................................................................................................................................................. 1-1

1-1
LTE functions ............................................................................................................................................................................. 1-3

1-3
LTE network components ..................................................................................................................................................... 1-4

1-4
LTE interfaces ............................................................................................................................................................................ 1-6

1-6
LTE protocol stacks .................................................................................................................................................................. 1-7

1-7
2 LTE Radio Access Network
Overview ...................................................................................................................................................................................... 2-1

2-1
LTE RAN ..................................................................................................................................................................................... 2-1

2-1
LTE RAN interfaces ................................................................................................................................................................ 2-2

2-2
....................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary iii
9YZ-03991-0004-TQZZA Release LA6.0 Use pursuant to applicable agreements
Issue 1 April 2013
Contents
....................................................................................................................................................................................................................................
3 Architecture
Overview ...................................................................................................................................................................................... 3-1

3-1
5620 Service Aware Manager (SAM) ............................................................................................................................... 3-1

3-1
9959 Network Performance Optimizer (NPO) .............................................................................................................. 3-3

3-3
9412 eNodeB .............................................................................................................................................................................. 3-5

3-5
Network Element Manager (NEM) .................................................................................................................................... 3-7

3-7
9958 Wireless Trace Analyzer (WTA) ............................................................................................................................. 3-7

3-7
Wireless Provisioning System (WPS) ............................................................................................................................... 3-7

3-7
4 LTE RAN OAM functions
Overview ...................................................................................................................................................................................... 4-1

4-1
Fault management ..................................................................................................................................................................... 4-1

4-1
Configuration management ................................................................................................................................................ 4-15

4-15
Performance management ................................................................................................................................................... 4-30

4-30
Security ...................................................................................................................................................................................... 4-47

4-47
Call Trace .................................................................................................................................................................................. 4-48

4-48
Self Optimizing Network (SON) ...................................................................................................................................... 4-49

4-49
Transport call admission control ....................................................................................................................................... 4-50

4-50
5 LTE Services
Overview ...................................................................................................................................................................................... 5-1

5-1
Synchronization ......................................................................................................................................................................... 5-1

5-1
Quality of Services (QoS) ...................................................................................................................................................... 5-3

5-3
A Abbreviations
Overview ..................................................................................................................................................................................... A-1

A-1
Initialisms ................................................................................................................................................................................... A-1

A-1
Acronyms .................................................................................................................................................................................... A-5

A-5
Index
....................................................................................................................................................................................................................................
iv Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Use pursuant to applicable agreements 9YZ-03991-0004-TQZZA Release LA6.0
Issue 1 April 2013
List of tables
1-1 LTE interfaces ............................................................................................................................................................. 1-6

1-6
4-1 Fault types .................................................................................................................................................................... 4-2

4-2
4-2 State types .................................................................................................................................................................... 4-5

4-5
4-3 Alarm termination ..................................................................................................................................................... 4-8

4-8
4-4 AvailabilityStatus values and default states ................................................................................................... 4-19
4-5 Parent-child object .................................................................................................................................................. 4-20

4-20
4-6 eNodeB XML file naming convention ............................................................................................................ 4-43
....................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary v
Issue 1 April 2013
List of tables
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
vi Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
List of figures
1-1 LTE network components ..................................................................................................................................... 1-4
1-2 User-plane protocol stack ....................................................................................................................................... 1-8
1-3 Control plane protocol stack .................................................................................................................................. 1-9
2-1 LTE RAN interfaces ................................................................................................................................................. 2-2

2-2
2-2 S1 interface .................................................................................................................................................................. 2-3

2-3
2-3 X2 interface ................................................................................................................................................................. 2-4

2-4
2-4 LTE air interface ........................................................................................................................................................ 2-5

2-5
3-1 Standalone 5620 SAM system .............................................................................................................................. 3-2
3-2 9959 NPO with auxiliary server ........................................................................................................................... 3-4
3-3 9959 NPO with PCMD support (48K configuration) .................................................................................. 3-4
3-4 9412 eNodeB architecture ...................................................................................................................................... 3-5
4-1 Configuration extract view .................................................................................................................................. 4-23
4-2 Configuration import view .................................................................................................................................. 4-23
4-3 Offline configuration activation view .............................................................................................................. 4-24
4-4 cmXML interface overview ................................................................................................................................ 4-25
4-5 9952 WPS positioning within OAM ................................................................................................................ 4-28
4-6 Measurement scheduling and reporting .......................................................................................................... 4-32
4-7 Functional view of the counter observation domain .................................................................................. 4-37
4-8 Measurement files - schedule ............................................................................................................................. 4-40
4-9 SAM Call Trace Architecture ............................................................................................................................. 4-48
5-1 Synchronization distribution ................................................................................................................................. 5-3
5-2 QoS ................................................................................................................................................................................. 5-4

5-4
....................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary vii
Issue 1 April 2013
List of figures
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
viii Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
About this document
About this document
Purpose
This document provides an overview of Long Term Evolution Radio Access Network
(LTE RAN) system. The document can be used to understand the different aspects of
LTE, LTE RAN, architecture, interfaces, OAM functions and services.
Attention: Starting with Release LA5.0, all LTE RAN customer document numbers
will have a 17-digit format to meet Alcatel-Lucent documentation standards.
Therefore, this document number format has changed from 418-000-012 to
9YZ-xxxxx-xxxx-TQZZA
Issue 1
The reissue history for Issue 1 is shown in the following table.
Location Change
First page Update for final delivery LA6.0 .
Issue 0.02
The reissue history for Issue 0.02 is shown in the following table.
Location Change
Release Modified some titles of document and added
the doc ID for LA6.0
Issue 0.01
The reissue history for Issue 0.01 is shown in the following table.
Location Change
Release Release updated for LA6.0
...................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary ix
Issue 1 April 2013
About this document
....................................................................................................................................................................................................................................
Intended audience
This document provides an overview of the LTE technology and introduces the
Alcatel-Lucent solution to operations and maintenance personnel and to other users who
want to know more about the LTE RAN for LTE network management.
Supported systems
This document applies to the System Release LTE RAN LA6.0 (frequency division
duplex - FDD).
How to use this document

The following table describes how to use this document.
Document organization When to use

Chapter 1, “Long Term Evolution To know about Long Term Evolution.
System Overview”
Chapter 2, “LTE Radio Access Network” To know about Long Term Evolution Radio Access
Network.
Chapter 3, “Architecture” To know about different architecture and various
components involved in the Long Term Evolution
Radio Access Network solution.
Chapter 4, “LTE RAN OAM functions” To know about LTE RAN OAM functions.
Chapter 5, “LTE Services” To know about Long Term Evolution services.
Conventions used
The following typographical conventions are used in this guide:
Appearance Description
italicized text Used for:
• File and directory names
• Emphasized information
• Titles of publications
• A value that the user supplies
graphical user interface text or key name Used for:
• Text that is displayed in a graphical user
interface or in a hardware label
• The name of a key on the keyboard
....................................................................................................................................................................................................................................
x Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
About this document
....................................................................................................................................................................................................................................
Appearance Description
input text Command names and text that the user types
or selects as input to a system
output text Text that a system displays or prints
Related information
The following document is referenced in this document or includes additional information
relevant to this document. Refer to Alcatel-Lucent 9400 LTE Radio Access Network
Customer Documentation Overview, 9YZ-03991-0002-ACZZA for the purpose of the
listed document.
• Alcatel-Lucent 9400 LTE Radio Access Network Terminology Overview,
9YZ-03991-0003-TQZZA
Document support
For support in using this or any other Alcatel-Lucent document, contact Alcatel-Lucent at
one of the following telephone numbers:
• 1-888-582-3688 (for the United States)
• 1-630-224-8618 (for all other countries)
Technical support
For technical support, contact your local Alcatel-Lucent customer support team. See the
Alcatel-Lucent Support web site (http://www.alcatel-lucent.com/support/) for contact
information.
How to order
To order Alcatel-Lucent documents, contact your local sales representative or use Online
Customer Support (OLCS) (http://support.alcatel-lucent.com).
How to comment
To comment on this document, go to the Online Comment Form (http://infodoc.alcatel-
lucent.com/comments/) or e-mail your comments to the Comments Hotline
(comments@alcatel-lucent.com).
....................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary xi
Issue 1 April 2013
About this document
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
xii Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
1 1ong Term Evolution
L
System Overview
Overview
Purpose
This chapter provides an overview of the Long Term Evolution (LTE).
Contents
Long Term Evolution 1-1

LTE functions 1-3
LTE network components 1-4
LTE interfaces 1-6
LTE protocol stacks 1-7
Long Term Evolution

Introduction
Long Term Evolution (LTE) is the next generation broadband wireless technology for
3GPP and 3GPP2 networks with the support of up to 20 MHz of bandwidth. LTE is
predominantly associated with the radio access network (RAN). The system architecture
evolution (SAE) specifications defines the core network which is termed as evolved
packet core (EPC) including all Internet Protocol (IP) networking architecture.
LTE provides high data rate by combining four important mechanisms:
• Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink to
achieve high peak data rates in high spectrum bandwidth.
• Single Carrier Frequency Division Multiple Access (SC-FDMA), a technology that
proves advantageous in terms of power efficiency on the uplink.
...................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary 1-1
Issue 1 April 2013
Long Term Evolution System Overview Long Term Evolution
....................................................................................................................................................................................................................................
• Use of 64-Quadrature Amplitude Modulation (QAM).
• Advanced Antenna techniques such as Multiple Input Multiple Output (MIMO).
LTE features
The following are the features of LTE:
• Spectral efficiency (5 bps/Hz DL, 2.5 bps/Hz UL), user throughput (up to 100 Mbps),
latency (10 ms UE-eNodeB), cell edge bit rate
• Simplification of the radio network with flexible spectrum allocation (1.4 – 20 MHz)
• Support of efficient packet-based services such as Multimedia Broadcast Multicast
Service (MBMS) and IP Multimedia Subsystem (IMS)
• Converged baseband and Software-Defined Radio (SDR) modules
• Self-Organizing Network (SON) capabilities
• Inter-working with GSM, W-CDMA, and CDMA networks
• Radio resource management and fair scheduler
• IP transport
• Interoperability with networks such as UTRAN, GERAN, and EV-DO
Benefits of LTE
LTE provides global mobility with a wide range of services that includes voice, data, and
video in a mobile environment with lower deployment costs.
The following are the benefits of LTE:
• Support for higher user data rates
• Reduced packet latency and rich multimedia user experience
• Increased spectral efficiency. Offer new services and adapt to available spectrum
• Improved system capacity and coverage as well as variable bandwidth operation
• Lower deployment costs
• Excellent performance for outstanding quality of experience
• Wide spectrum and bandwidth range
• Cost effective with a flat IP architecture
• Smooth integration and mobility with the networks
• Optimized usage of radio resource management and fair scheduler
....................................................................................................................................................................................................................................
1-2 Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
Long Term Evolution System Overview LTE functions
....................................................................................................................................................................................................................................
LTE functions
Overview
This section describes the LTE functions hosted by 9412 eNodeB from 3GPP standard
perspective.
9412 eNodeB functions

The 9412 eNodeB performs the following functions:
• Radio Resource Management, Radio Bearer Control, Radio Admission Control,
Connection Mobility Control, Dynamic allocation of resources to UEs in both Uplink
and Downlink (scheduling)
• IP header compression and encryption of user data stream
• Selection of MME at UE attachment
• Routing User Plane data to SAE Gateway
• Scheduling and transmission of paging messages (originated from the MME)
• Scheduling and transmission of broadcast information (originated from the MME or
Operations, Administration and Maintenance (OAM)
• Measurement and measurement reporting configuration for mobility and scheduling
Mobile Management Entity (MME) functions

The MME performs the following functions:
• Distribution of paging messages to the 9412 eNodeBs
• Security control
• Idle state mobility control
• SAE bearer control
• Ciphering and integrity protection of NAS signaling
System Architecture Evolution (SAE) functions

The SAE Gateway performs the following functions:
• Termination of U-plane packets for paging reasons
• Switching of U-plane for supporting UE mobility
• QoS handling and tunnel management
....................................................................................................................................................................................................................................
Issue 1 April 2013
Long Term Evolution System Overview LTE network components
....................................................................................................................................................................................................................................
LTE network components

Overview
Figure 1-1, “LTE network components ” (p. 1-4) describes the LTE network components
and interfaces.
Figure 1-1 LTE network components
User equipment
The User Equipment (UE) is a combination of Mobile Equipment (ME) and Subscriber
Identity Module / Universal Mobile Telecommunications System Subscriber Identity
Module (UMTS SIM/USIM) with LTE capabilities.
LTE RAN
LTE RAN provides the physical radio link between the User Equipment (UE) and the
Evolved Packet Core (EPC) network. LTE RAN comprises 9412 eNodeBs. The 9412
eNodeB contains Transmit Receive Duplex Units (TRDUs) or Remote Radio Heads
(RRHs) and communicates with the UEs. The 9412 eNodeB supports Multiple Input
Multiple Output (MIMO).
The 9412 eNodeB provides:
• Radio resource management: Radio Bearer Control, Radio Admission Control,
Connection Mobility Control, and Dynamic allocation of resources to UEs in uplink
and downlink (scheduling)
• S1-MME interface to Mobility Management Entity (MME)
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• S1-U interface to Serving Gateway (S-GW)
• IP header compression and encryption of user data stream
• Routing of user plane data towards S-GW
• Scheduling and transmission of paging messages (originated from MME)
• Scheduling and transmission of broadcast information (originated from MME or
Operations, Administration, and Maintenance (OAM))
• Bearer level rate enforcement and bearer level admission control
• Handover support
Evolved Packet Core

The LTE related core network evolution is referred to as Evolved Packet Core (EPC).
LTE architecture is based on the system architecture evolution (SAE) model defined by
the 3G Partnership Project (3GPP). EPC consists of the following network elements:
Mobility Management Entity
The Mobility Management Entity (MME) is the LTE mobility management and session
management entity of the evolved packet core. MME is responsible for selection of the
P-GW, triggering and enabling authentication, and saving the subscriber profile
downloaded from the HSS.
The MME handles signaling traffic from the UE/9412 eNodeB through any of the
following:
• S1-MME interface
• MME talks to other MMEs through the S10 interface
In the evolved packet core, the MME terminates the control plane with the mobile device.
MME is responsible for terminating Non Access Stratum (NAS) signaling such as
Mobility Management (MM) and Session Management (SM) information as well as
coordinating Idle Mode procedures. The MME also includes the gateway selection inter
MME Mobility and authentication of the mobile device.
Serving Gateway
The Serving Gateway (S-GW) is responsible for anchoring the user plane for
inter-eNodeB handover and inter-3GPP mobility. S-GW in LTE terminates the LTE RAN
and a UE that has only one S-GW at any instance. S-GW handles the user data
functionality and is involved in routing and forwarding the data packets to P-GW through
S5 interface.
Packet Data Network Gateway
The Packet Data Network Gateway (PDN-GW) is responsible for IP address allocation to
the UE. The PDN-GW is also the policy enforcement point to enforce Quality of Service
(QOS) specific rules on traffic packets. The PDN-GW terminates the signaling gateway
(SG) interface in evolved packet core network. PDN-GW is responsible for functions
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
such as policy enforcement based on the traffic monitoring characteristics on a subscriber
by subscriber basis and ensures the appropriate traffic policy. The PDN-GW connects the
UE to external PDNs (Packet Data Networks) and acts as the UE's default router.
Policy Control and Charging Rules Function
The Policy Charging Rules Function (PCRF) is a functional entity of the 3GPP PCC
(Policy and Charging Control) architecture. The PCRF plays a vital role and makes
Quality of Service (QOS) and charging policy decisions. The Home PCRF (HPCRF)
interfaces with the CSCF, it retrieves IMS layer QOS and makes policy decisions. These
policies are passed down to the P-GW, S-GW, and H-SGW for policy enforcement
through the visited PCRF in the regional center.
LTE interfaces
Overview
The Table 1-1, “LTE interfaces” (p. 1-6) describes the LTE interfaces and communication
between the network elements.
Table 1-1 LTE interfaces
Interface Description
LTE-Uu The LTE-Uu point is between the UE and E-UTRAN. OFDM - based
LTE air interface protocol is used across this interface.
S1-UP The GTP-U protocol interface is between the E-UTRAN and the
Serving Gateway. This interface supports bearer user plane tunneling
and inter-eNodeB path switching during handover.
S1-MME The S1-MME point for control plane protocol interface is between the
LTE RAN and the MME. All signaling between the 9412 eNodeB and
the Serving Gateway (S-GW) is carried over this interface.
S3 The S3 interface carries mobility/handover signaling between 2G /3G
and LTE systems. S3 reference points between the SGSN and the
MME.
S6a The S6a interface is between the MME and the HSS. It enables
transfer of subscription and authentication data for authenticating/
authorizing user access to the evolved system between MME and
HSS.
S4 S4 is the user plane counter part of S3. This interface enables user and
bearer information exchange for inter-3GPP access system mobility.
....................................................................................................................................................................................................................................
Issue 1 April 2013
Long Term Evolution System Overview LTE interfaces
....................................................................................................................................................................................................................................
Table 1-1 LTE interfaces (continued)
Interface Description
S11 The S11 interface is between the MME and the serving gateway. All
control information between the MME and Serving Gateway is carried
over this interface.
S12 The S12 interface introduced in 3GPP Rel-8 supports direct user plane
tunneling between the UMTS RNC and the SGW of the LTE network.
S5 The S5 interface is between the Serving Gateway and the PDN
Gateway. S5 interface is used to move traffic between the two
Gateways.
S7 The S7 interface is between the Evolved Packet Core and the Policy
Charging and Rule Function (PCRF). S7 interface transfers QOS
policy and charging rules from the PCRF to the policy and charging
enforcement function in the PDN gateway.
X2 The X2 interface is the interface between the 9412 eNodeBs.
X2-CP The X2-CP traffic supports mobility signaling traffic between two
9412 eNodeBs.
X2-UP The X2-UP supports data forwarded between 9412 eNodeBs during
the hard handover procedures.
LTE protocol stacks

Introduction
Protocol stacks have a conceptual model of the layered architecture of communication
protocols in which layers within a station are represented in hierarchical order. Each layer
in the protocol stack is defined in generic terms describing functionality and mode of
operation. The LTE protocol stacks are divided into user plane and control plane.
User plane protocol stacks

The user plane includes the data streams and the data bearers for the data streams. The
data streams are characterized by one or more frame protocols specified for that interface.
Figure 1-2, “User-plane protocol stack” (p. 1-8) comprises Medium Access Control
(MAC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC) and
Physical (PHY) sub layers. Apart from the serving gateway protocols, all radio interface
protocols terminate in the 9412 eNodeB on the network side.
....................................................................................................................................................................................................................................
Issue 1 April 2013
Long Term Evolution System Overview LTE protocol stacks
....................................................................................................................................................................................................................................
Figure 1-2 User-plane protocol stack
The LTE user plane protocol performs the following functions:

• Physical (PHY) Sublayer : The physical layer is between the UE and the 9412
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 9412 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.
• Radio Link Control (RLC) Sublayer : The RLC sublayer is between the UE and the
9412 eNodeB. Along with transferring upper layer PDUs, the RLC does error
correction through ARQ, in-sequence delivery of upper layer PDUs, duplicate
detection, flow control and concatenation or re-assembly of packets.
• Packet Data Convergence Protocol (PDCP) Sublayer : For the user plane, the
PDCP sublayer performs header compression and ciphering.
Control plane protocol stacks

The control plane includes the application protocol. It also includes the signaling bearers
for transporting the application protocol messages. The application protocol is used for
setting up bearers in the radio network layer. For example, radio access bearers or radio
links.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 1-3, “Control plane protocol stack” (p. 1-9) comprises Radio Resource Control
(RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium
Access Control (MAC), Physical (PHY) and Non Access Stratum (NAS) sub layers.
Apart from the non access stratum (NAS) protocols, all radio interface protocols
terminate in the 9412 eNodeB on the network side.
Figure 1-3 Control plane protocol stack
The LTE control plane protocol functions are:

• Physical (PHY) Sublayer : The physical layer is between the UE and the 9412
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 9412 eNodeB. Along with scheduling, it 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 or demultiplexing of
different RLC radio bearers from the physical layer on transport channels.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• Radio Link Control (RLC) Sublayer : The RLC sublayer is between the UE and the
9412 eNodeB. Along with transferring upper layer PDUs, the RLC does error
correction through ARQ, in-sequence delivery of upper layer PDUs, duplicate
detection, flow control and concatenation or re-assembly of packets.
• Packet Data Convergence Protocol (PDCP) Sublayer : The PDCP sublayer is
included in the control plane and is used for ciphering and integrity protection. In
addition, PDCP sublayer is used for control plane data transmission. The PDCP
receives PDCP SDUs from the RRC and forwards them to the RLC layer.
• Radio Resource Control (RRC) Sublayer : The RRC sublayer is between the UE
and the 9412 eNodeB. The RRC sublayer in essence performs broadcasting, paging,
connection management, radio bearer control, mobility functions, 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.
....................................................................................................................................................................................................................................
Issue 1 April 2013
2 LTE Radio Access Network
2
Overview
Purpose
This chapter provides information on Long Term Evolution Radio Access Network (LTE
RAN).
Contents
LTE RAN 2-1

LTE RAN interfaces 2-2
LTE RAN
Overview
The 9412 eNodeB communicates with the Evolved Packet Core (EPC) using the S1
interface, specifically with the MME (Mobility Management Entity) and S-GW (Serving
Gateway) using S1 interface. The MME and S-GW are implemented as separate network
nodes to facilitate independent scaling of the control and user plane.
The 9412 eNodeB communicates to each other through the X2 interface. For example,
support of handover of UEs in LTE_ACTIVE.
...................................................................................................................................................................................................................................
Issue 1 April 2013
LTE Radio Access Network LTE RAN interfaces
....................................................................................................................................................................................................................................
LTE RAN interfaces

Overview
LTE contains a radio interface and access network to deliver higher data rates and faster
connection.
Figure 2-1 LTE RAN interfaces
S1 interface
The S1 interface is the interface between the LTE RAN and evolved packet core. S1
interface protocol stack is described in Figure 2-2, “S1 interface” (p. 2-3)
S1 performs the following functions:
• S1-UP (user plane)
• S1-CP (control plane)
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 2-2 S1 interface
S1-UP (user plane)

The S1 user plane external interface (S1-U) is defined between the 9412 eNodeB and the
S-GW. The S1-U interface provides non guaranteed data delivery of user plane Protocol
Data Units (PDUs) between the 9412 eNodeB and the S-GW. Transport network layer is
built on IP transport and GTP-U. UDP/IP carries the user plane PDUs between the 9412
eNodeB and the S-GW. A GTP tunnel per radio bearer carries user traffic.
The S1-UP interface is responsible for delivering user data between the 9412 eNodeB and
the S-GW. The IP Differentiated Service Code Point (DSCP) marking is supported for
QoS per radio bearer.
S1-MME (control plane)
The S1-MME interface is responsible for delivering a signaling protocols between the
9412 eNodeB and the MME. S1-MME interface consists of a Stream Control
Transmission Protocol (SCTP) over IP and supports multiple UEs through a single SCTP
association. It also provides guaranteed data delivery. The application signaling protocol
is an S1-AP (Application Protocol). The S1-MME is responsible for Evolved Packet
System (EPS) bearer setup/release procedures, the handover signaling procedure, the
paging procedure and the NAS transport procedure. Transport network layer is built on IP
transport, similar to the user plane but for the reliable transport of signaling messages
SCTP is added on top of the Internet Protocol.
X2 interface
The X2 interface is the interface between the 9412 eNodeBs. X2 interface protocol stack
is described in Figure 2-3, “X2 interface” (p. 2-4).
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
X2 performs the following functions:
• X2-UP (User Plane)
• X2-CP (Control Plane)
Figure 2-3 X2 interface
X2-UP (User Plane)

The X2-UP protocol tunnels end-user packets between the 9412 eNodeBs. The tunneling
function supports the identification of packets with the tunnels and packet loss
management. X2-UP uses GTP-U over UDP or IP as the transport layer protocol similar
to S1-UP protocol. S1-UP and X2-UP use the same U-plane protocol to minimize
protocol processing for the 9412 eNodeB at the time of data forwarding. The X2 user
plane external interface (X2-U) is defined between 9412 eNodeBs. The X2-U interface
provides non guaranteed delivery of user plane PDUs. The transport network layer is built
on IP transport and GTP-U is used on top of the UDP or IP to carry the user plane PDUs.
The X2-UP interface protocol stack is identical to the S1-UP protocol stack.
X2-CP (Control Plane)
X2-CP has SCTP as the transport layer protocol which is similar to the S1-CP protocol.
The load management function allows exchange of overload and traffic load information
between 9412 eNodeBs to handle traffic load effectively. The handover function enables
one 9412 eNodeB to handover the UE to another 9412 eNodeB. A handover operation
requires transfer of information necessary to maintain the LTE RAN services at the new
9412 eNodeB. It also requires the establishment and release of the tunnels between source
and target 9412 eNodeB to allow data forwarding and informs the already prepared target
9412 eNodeB for handover cancellations.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
X2-CP protocol functions include:
• intra LTE-Access-System mobility support for the UE
• context transfer from source 9412 eNodeB to target 9412 eNodeB
• control of user plane tunnels between source 9412 eNodeB and target 9412 eNodeB
• handover cancellation
• uplink load management
• general X2 management
• error handling
The X2 control plane external interface (X2-CP) is defined between two-neighbor 9412
eNodeBs. The transport network layer is built on SCTP on top of IP. The application layer
signaling protocol is referred to as X2-AP (X2 Application Protocol).
Air Interface
The air interface is the radio-based communication link between the mobile station and
the active base station. LTE air interface supports high data rates. LTE uses Orthogonal
Frequency Division Multiple Access (OFDMA) for downlink transmission to achieve
high peak data rates in high spectrum bandwidth. LTE uses Single Carrier Frequency
Division Multiple Access (SC-FDMA) for uplink transmission, a technology that
provides advantages in power efficiency.
Figure 2-4 LTE air interface
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
LTE air interface characteristics
LTE air interface characteristics are:
• Downlink (DL) based on OFDMA. OFDMA offers improved spectral efficiency
capacity using OFDMA technology.
• Uplink (UL) based on SC-FDMA. SC-FDMA is similar to OFDMA for uplink from
hand-held devices such as mobile phones which requires better battery power
conservation.
• Supports both FDD and TDD modes:
– Provides deployment flexibility in spectrum allocation.
– With FDD, DL and UL transmissions are performed simultaneously in two
different frequency bands.
– With TDD, DL and UL transmissions are performed at different time intervals
within the same frequency band.
• Significant reduction in delay over air interface and idle to active mode transition.
Suitable for real-time applications, for example, VoIP, PoC, gaming, and so on.
• Large improvement in uplink spectral efficiency.
• Advanced adaptive MIMO support. Balance average/peak throughput,
coverage/cell-edge bit rate.
LTE channel
Channels are used to transport and segregate different types of data across the LTE radio
access network interface.
The various data channels are grouped into three categories:
• Physical channels - The physical channels are transmission channels that carry user
data and control messages.
• Transport channels - The physical layer transport channels offer information transfer
to Medium Access Control (MAC) and higher layers.
• Logical channels - The logical channels provide services for the Medium Access
Control (MAC) layer within the LTE protocol stack.
....................................................................................................................................................................................................................................
Issue 1 April 2013
3 Architecture
3
Overview
Purpose
This chapter describes the various components involved in the LTE RAN solution and
their architecture.
Contents
5620 Service Aware Manager (SAM) 3-1

9959 Network Performance Optimizer (NPO) 3-3
9412 eNodeB 3-5
Network Element Manager (NEM) 3-7
9958 Wireless Trace Analyzer (WTA) 3-7
Wireless Provisioning System (WPS) 3-7
5620 Service Aware Manager (SAM)

Overview
The 5620 SAM system is designed to manage Alcatel-Lucent network elements (NEs).
The 5620 SAM manages the following devices in the Alcatel-Lucent portfolio:
• IP/MPLS routers and switches
• 9471 MME, 7750 SR-MG, and 5780 DSC in the LTE ePC space
• 9412 eNodeB in the LTE RAN space
The 5620 SAM system also supports few telecom devices and provides limited
management of other third-party devices. The third-party devices are know as generic
NEs.
...................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture 5620 Service Aware Manager (SAM)
....................................................................................................................................................................................................................................
5620 SAM system components
The 5620 SAM system has client, server, and database components that are deployed in a
standalone or redundant configuration. Figure 3-1, “Standalone 5620 SAM system”
(p. 3-2) shows a block diagram of a standalone 5620 SAM system and the network. The
management network contains the 5620 SAM components and connects to the managed
network of NEs from one or more points, depending on the complexity of the
deployment.
Figure 3-1 Standalone 5620 SAM system
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.
The 5620 SAM uses a Java-based technology that provides distributed, secure, and
scalable processing. For more information about the 5620 SAM, see the complete product
documentation available at (http://www.alcatel-lucent.com/myaccess).
Note: If you are a new user and require access to this service, contact your
Alcatel-Lucent sales representative.
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture 9959 Network Performance Optimizer (NPO)
....................................................................................................................................................................................................................................
9959 Network Performance Optimizer (NPO)

Overview
The 9959 Network Performance Optimizer (9959 NPO) is the main solution for wireless
network optimization provided by Alcatel-Lucent. The 9959 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 9959 NPO includes advanced reporting functions and is intended for deployment at a
regional level to complement the capabilities of national network optimization solutions.
9959 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 which supports 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.
9959 NPO without Per Call Measurement Data (PCMD)

9959 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 9959 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. 9959
NPO client are either Windows PC or Windows server running Citrix.
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture 9959 Network Performance Optimizer (NPO)
....................................................................................................................................................................................................................................
Figure 3-2 9959 NPO with auxiliary server
Note:
• A number of concurrent users can use the analysis desktop application. Usage of
external export interface is not considered in the count of concurrent users.
• In case 5620 SAM has an auxiliary server, then 9959 NPO retrieves PM from the
5620 SAM auxiliary server and CM from the 5620 SAM main server.
9959 NPO with Per Call Measurement Data (PCMD)

9959 NPO with Per Call Measurement Data (PCMD) requires:
• A connection to MME from both 9959 NPO main server and 9959 NPO auxiliary
servers.
• For 12K cells and above, dedicated 9959 NPO auxiliary server(s) are required for
PCMD.
Figure 3-3 9959 NPO with PCMD support (48K configuration)
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture 9412 eNodeB
....................................................................................................................................................................................................................................
9412 eNodeB
9412 eNodeB architecture
The 9412 eNodeB is an integrated system, composed of a cabinet, a Base Band Unit
(BBU), Transmit/Receive Duplex Units (TRDUs) and Remote Radio Heads (RRHs).
Figure 3-4, “9412 eNodeB architecture” (p. 3-5) shows the block diagram of a general
9412 eNodeB.
Figure 3-4 9412 eNodeB architecture
From the architecture point of view, two types of 9412 eNodeBs are available:
• Compact 9412 eNodeB
• Distributed 9412 eNodeB
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture 9412 eNodeB
....................................................................................................................................................................................................................................
Compact 9412 eNodeB is based on Transmit/Receive Duplex Units (TRDUs), and
distributed 9412 eNodeB is based on Remote Radio Heads (RRHs). In both types, the
separation between digital and RF processing is ensured through the CPRI interface.
Digital processing is ensured by the Base Band Unit (BBU), the BBU architecture being
the same for compact and distributed 9412 eNodeBs.
Hardware equipments for 9412 eNodeB

This topic provides a short description on hardware equipments for 9412 eNodeB
involved in LTE RAN solution.
9926 Base Band Unit (BBU)
The 9926 Base Band Unit (BBU) is the Alcatel-Lucent converged product for W-CDMA,
LTE-FDD and LTE-TDD BBU. There are two BBU versions which are known as 9926
BBU V1 (d2U V3) and 9926 BBU V2 (d2U V5). For all common characteristics between
the two versions they are referred to as 9926 BBU.
The 9926 BBU is a digital NodeB with four types of hardware boards:
• eCCM-U (with MDA E1/T1 or GE or T3) (1 module only)
• eCEM-U (up to 3 modules)
• RBP
• RUC
9442 Remote Radio Head (RRH)
The Remote Radio Head (RRH) is a platform asset that can support both 3G (WCDMA
and CDMA) and 4G (LTE and WIMAX-FDD) technologies. This unit can also operate as
a single Tx unit for both single and dual sector configurations. The unit has 2 RF
transceivers to enable 2x2 MIMO applications.
9412 eNodeB Compact
The 9412 eNodeB is an integrated system. However, logically it is the same as a
distributed 9412 eNodeB with a separation of the digital and RF processing by a CPRI
interface. There are two types of 9412 eNodeB compact systems; indoor and outdoor. The
9412 eNodeB Compact indoor system is designed to support LTE service in the 700 MHz
spectrum. This system is housed as an integrated system, all in one cabinet, serving 5 or
10 MHz LTE bandwidth carriers in the 700 MHz spectrum.
The standard 9412 eNodeB Compact outdoor comprises of the following two cabinets.
These cabinets are physically identical, but provide different functionality.
• BB (Baseband) cabinet
• RF (Radio Frequency) cabinet
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture Network Element Manager (NEM)
....................................................................................................................................................................................................................................
Network Element Manager (NEM)

Overview
The Network Element Manager (NEM) application is instantiated in the Local
Maintenance Terminal (LMT) of the related 9412 eNodeB and in the 5620 SAM. The
LMT is connected locally to the 9412 eNodeB. For example, a portable PC connected
directly to the 9412 eNodeB using a 10/100 Base-TX Ethernet interface.
The NEM is used for monitoring, maintaining and commissioning the 9412 eNodeB.
NEM uses SNMP v3 for communication with 9412 eNodeB. NEM also supports
NETCONF as NEM supports modifying the 9412 eNodeB Netconf parameters.
9958 Wireless Trace Analyzer (WTA)

Overview
9958 Wireless Trace Analyzer (WTA) is a post-processing and analysis tool for Call Trace
data. The 9958 WTA provides a quick way of analyzing end-to-end call scenarios that
exist within any given set of traces.
9958 WTA is used to analyze call trace data for the following NEs:
• 9412 eNodeB (eNB)
• 9471 MME
Wireless Provisioning System (WPS)

Overview
The 9952 Wireless Provisioning System (9952 WPS) is a powerful tool suite that
simplifies the provisioning and reverse engineering or auditing of the network. WPS can
be installed on any PC. The 9952 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 towards further plug-and-play, self- organizing, self-optimizing networks
associated with the 9952 WPS delivers much more simplified operational system.
For information on WPS software installation procedures, see Alcatel-Lucent 9952
Wireless Provisioning System Version 2.0 Installation and Administration Guide,
9YZ-05134-0001-RJZZA.
....................................................................................................................................................................................................................................
Issue 1 April 2013
Architecture Wireless Provisioning System (WPS)
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
Issue 1 April 2013
4 LTE RAN OAM functions
4
Overview
Purpose
This chapter provides information on OAM functions.
Contents
Fault management 4-1

Configuration management 4-15
Performance management 4-30
Security 4-47
Call Trace 4-48
Self Optimizing Network (SON) 4-49
Transport call admission control 4-50
Fault management
Overview
The Fault management tasks are monitoring tasks that detect and analyze hardware,
software and network problems to execute corrective maintenance procedures according
to the type of alarm. The FM tasks detect failures as soon as they occur and limit their
impact on the network Quality of Service (QoS).
The monitoring levels available in the LTE RAN are:
• Network-level monitoring
• Element-level monitoring
• Service-level monitoring
...................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Fault management
....................................................................................................................................................................................................................................
Fault Management concepts
The functions of Fault Management are:
• “Alarm surveillance” (p. 4-2)
• “Fault localization” (p. 4-2)
• “Fault correction” (p. 4-2)
• “Testing” (p. 4-3)
Alarm surveillance
Alarm surveillance function detects faults in a network. It monitors and interrogates
Network Elements (NE) about events or conditions. Event data is generated by an NE
when an abnormal condition is detected.
Table 4-1, “Fault types” (p. 4-2) lists the different types of faults that occur in a network.
Table 4-1 Fault types
Type Description
Hardware faults Malfunction of physical resource within the
network element.
Software faults Malfunction of software component (software
bug or database inconsistency).
Functional faults Failure of a functional resource in the NE and
no hardware component has been detected as
faulty.
Overload conditions Loss of some or all of the specified
capabilities of an NE due to overload.
Quality of service failures Failure to meet the given threshold values.
Communication failures Communication failure between NEs, between
the NE and the operating system (OS), or
between operating systems.
Fault localization
Fault localization function determines the root cause of a fault. Additional failure
localization routines provide information which must be added when the initial failure
information is insufficient for fault localization. The routines can employ internal or
external test systems and can be controlled by a Network Element Manager (NEM).
Fault correction
Fault correction function takes the appropriate action to correct a fault once the root cause
is identified. It transfers data concerning the repair of a fault. This function also controls
procedures that use redundant resources to replace equipment or facilities that have failed.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Testing
Testing conducts tests to determine the root cause of a fault. To analyze the problem,
access the relevant functionality of the NE using the Network Element Manager to
conduct tests.
General problem solving model

The general problem solving model provides a general approach for troubleshooting
situations. The stages for the general problem solving workflow are:
...................................................................................................................................................................................................
1 Define the problem.

When analyzing a network problem:
• Make a clear problem statement.
• Define the problem in terms of a set of symptoms and potential causes.
To analyze the problem, identify the general symptoms and ascertain what kinds of
problems (causes) could result in these symptoms.
...................................................................................................................................................................................................
2 Gather the facts.

Gathering facts involves:
• Collecting information from affected users, network administrators, managers and
other key people.
• Collecting information from sources such as network management systems, protocol
analyzer traces, serial line traces, stack dumps or software release notes.
...................................................................................................................................................................................................
3 Consider the possibilities.

This stage involves:
• Eliminating problems in the network.
• Narrowing the number of potential problems.
...................................................................................................................................................................................................
4 Create an action plan.

The action plan is based on the remaining potential problems.
...................................................................................................................................................................................................
5 Implement the action plan.

...................................................................................................................................................................................................
6 Observe the results.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
...................................................................................................................................................................................................
7 If the problem remains unsolved then return to Stage 2.
Fault management process

The Fault management stages in 5620 SAM are:
...................................................................................................................................................................................................
1 Receive notification from eNodeBs in the network.

The eNodeBs in a network generate the following types of notifications:
• Events inform the operator of a non-continuing occurrence of interest. An event is
never cleared by the NE.
• Alarms are used by the NE to raise or clear alarms on logical or hardware
components.
• State changes are used by the NE to notify the change of states on a Managed Object
(MO). For more information on state changes, see Table 4-2, “State types” (p. 4-5).
The 5620 SAM gathers these notifications using SNMP V3 traps. Each alarm/event has a
unique ID. Each MO class is assigned a range of alarm IDs so that two different MOs do
not raise the same alarm.
...................................................................................................................................................................................................
2 Sort notifications.
The Node Manager layer of the 5620 SAM sorts the following notifications:
• Alarms are stored in the 5620 SAM database and include the following information:
alarm ID, alarm name, alarm severity, alarm type, probable cause, timestamp,
managed object and additional text. A visual display of object alarm status is done in
equipment tree and network map.
• Events are stored in the 5620 SAM database and include the following information:
alarm ID, alarm name, alarm type, probable cause, timestamp, managed object and
additional text.
• State changes are stored in the 5620 SAM database. The new state is displayed in the
equipment management and in the supervision view beside the corresponding
managed object.
...................................................................................................................................................................................................
3 Display the Alarms and State changes in the Supervision windows.
Maintenance states
This topic defines the maintenance states that apply to LTE RAN managed objects (MO)
and resources and the valid values for those maintenance states.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Table 4-2, “State types” (p. 4-5) lists the different states of MO that occur in a network.
Table 4-2 State types
State type Description States Meaning

Administrative Administrative state Unlocked Use of MO is permitted.
state indicates whether the
use of an MO by the Locked Use of MO is prohibited.
NE is allowed or not.
This state is set by the Indetermi- NEM/SAM is unable to compute the
operator either from nate state.
SAM or NEM.
Operational Operational state Enabled MO is either fully or partially
state indicates whether an operational.
MO is installed and is
working or not. This
state is determined by
the eNodeB and cannot Disabled MO is inoperable.
be changed by the
operator.
Availability Availability state Empty (0) None of the available states or
state qualifies the combination of states are present.
operational state. This
state is determined by
the eNodeB based on
the operational state
and cannot be changed
by the operator.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Table 4-2 State types (continued)

Powered The resource is powered off. The
off (1) operational state is disabled.
In test (2) The resource is undergoing a test
procedure. The operational state can
be either enabled or disabled.
Faulty (4) The resource has an internal fault but
is able to operate. The operational
state is enabled.
Degraded The service available from the
(8) resource is degraded. The operational
state is enabled.
Depen- The resource cannot operate because
dency (16) another resource, on which it depends,
is not available. The operational state
is disabled.
LogFull This indicates a log full condition, the
(21) semantics of which are defined in
CCITT Rec. X.735.
NotIn- The resource represented by the MO
stalled (22) is not present, or is incomplete. For
example, a plug-in module is missing,
a cable is disconnected or a software
module is not loaded. The operational
state is disabled.
OffLine The resource requires a routine
(23) operation to be performed to place it
online and make it available for use.
The operation may be manual or
automatic, or both. The operational
state is disabled.
OffDuty The resource has been made inactive
(24) by an internal control process in
accordance with a predetermined time
schedule. Under normal conditions
the control process can be expected to
reactivate the resource at some
scheduled time, and it is therefore
considered to be optional. The
operational state is disabled.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Table 4-2 State types (continued)

Failed (32) The resource has an internal fault that
prevents operation. The operational
state is disabled.
Initializing The resource is initializing. The
(64) operational state is disabled.
x Combination of errors. For example,
33 means powered off and failed. The
operational state depends on status.
Communica- Communication state Reachable Indicates that the SAM/NEM can
tion state indicates which reach the NE. Configuration changes
manager (SAM or are possible from the SAM and NEM.
NEM) can modify the Unreach- Indicates that the SAM/NEM cannot
eNodeB configuration. able reach the NE. Configuration changes
This state is set only are possible only from NEM. Changes
by the operator from the SAM are rejected by
through the NEM. eNodeB.
Indetermi- NEM/SAM is unable to compute the
nate state.
Network resource and service supervision

The following functions are available from the 5620 SAM GUI for supervision of LTE
RAN resources and services:
• A visual display of object alarm status is available in equipment tree and network
map.
• Alarms can be viewed in the Alarm window.
• Details of a specific alarm can be viewed.
• The managed object state can be viewed in the equipment management view and in
the network map view beside the corresponding managed object.
• Detailed information about network elements can be viewed in the equipment
management view.
• eNodeB equipment problems can be troubleshot with the integrated Network Element
Manager (NEM).
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Alarm management
In the 5620 Service Aware Manager (SAM), fault management is based on the retrieval
and analysis of unsolicited messages sent by the NEs or OAM applications. An
unsolicited message is a message that the NEs or the OAM applications issue
spontaneously concerning software or hardware faults and state and attribute value
changes. The resulting notifications and alarms warn users of NE malfunctions and
inform them about internal system operating changes. OAM maintenance tasks are based
on notifications and alarms.
Alarm state detection mechanisms
The alarm messages are obtained after transmission of the following events:
• CommunicationsAlarm
• EnvironmentalAlarm
• EquipmentAlarm
• ProcessingErrorAlarm
• QualityofServiceAlarm
The conditions in which alarms are triggered or terminated are defined in the
configuration data and depend on the type of the notification issued.
Table 4-3, “Alarm termination” (p. 4-8) describes only the conditions specific to each
notification type.
Note: All the alarms can be terminated by users or on system time-out.
Table 4-3 Alarm termination
Event type Alarm termination mode

CommunicationAlarm The alarm is terminated on time-out only.
An alarm is generated if the system operating
conditions are severely degraded.
EnvironmentalAlarm The alarm is terminated by user.
An alarm is generated when an issue occurs on
the equipment cabinet elements (door open,
fan failure, fire alarm).
EquipmentAlarm The alarm is terminated if one of the following
An alarm is generated after a failure that events occur:
triggers this type of message. • An end-of-alarm message is received
• The defective object is deleted or unlocked
• The defective object depends on an
unlocked object
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Table 4-3 Alarm termination (continued)
Event type Alarm termination mode

ProcessingErrorAlarm The alarm is terminated by user or on timeout.
An alarm is generated when this message is
received.
QualityOfServiceAlarm The alarm is terminated when an end-of-alarm
An alarm is generated when a permanent message is received, indicating that the
observation counter crosses a high or low counter is operating normally.
threshold. The operator can set threshold values
dynamically for each observation counter
occurrence. If a counter alarm is reported and
the newly read value is no longer above or
below the defined threshold, an end-of-fault
message is automatically generated.
Alarm life cycle

When the NE sends a notification to the system, the system ensures the mediation from
the interface model to the object model. These notifications are stored in a local database.
When the notification is identified as an "alarm start":
• The system creates and stores an alarm.
• The system ensures a correlation between the alarm and the notification.
• The created alarm is propagated through SAM.
When the notification is identified as an "alarm end":
• The system ensures a correlation between this notification and the corresponding
"alarm start" notification.
• The system destroys the corresponding alarm.
• The end of the alarm is propagated through SAM.
• The system acknowledges the alarm.
Alarm clearing mechanisms
An alarm is cleared when the OAM receives an end-of-fault message, that is the Fault
Management function considers that the fault is cleared and the defective element is now
operating correctly. Specific end-of-alarm conditions are defined in the configuration.
They must be consistent with the start-of-alarm conditions. For example, if a
start-of-alarm message is issued after an object state has changed to disabled, then an
end-of-alarm message is sent when the object state returns to enabled.
In certain conditions, the end of the fault is not detected and no corresponding message is
generated. The event that triggered end-of-fault messages cannot be delivered to the
OAM. For example, for repair, a faulty equipment is taken out of service and the object
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
on the level above, which describes the defective equipment, can also be taken out of
service. After the repairs, the equipment and the object on the level above are both
returned to service. However, certain information is no longer available and the
end-of-fault message is not generated.
To overcome this problem, alarms can be terminated automatically by the system. Alarms
are automatically terminated when the following events occur:
• End-of-fault message reception
All alarms activated on the same criteria and concerning the same object or equipment
are terminated.
• Object deletion or unlocking
All alarms related to the object are terminated (the OAM assumes that the problem is
solved). All alarms related to transceiver and channel objects depending on an
unlocked eNodeB objects are terminated.
Alarms are automatically terminated after re-synchronization between eNodeB and
SAM (after polling period).
For more information about alarm clearance, see “Maintenance principles” (p. 4-11).
Manual acknowledgment of alarms
Alarms can be terminated using one of the following ways:
• Cease selected alarms
• Cease selected object alarms
• Cease whole subtree alarms
For every acknowledgement action that an operator performs on an alarm, the date, the
time and the name of the user who performed the acknowledgement action are recorded.
The alarms are tagged with Acknowledge status.
For more information about alarms acknowledgment, see Alcatel-Lucent 5620 SAM |
Release 10.0 R6 - User Guide, 3HE 06993 AAAF TQZZA.
Notification messages and log files
Use the fault management function to manage unsolicited messages, which are sent by
Network Elements and OAM system.
Following the reception of the unsolicited messages sent by the OAM system, the NE
sends an unsolicited message in return. This message is translated into a notification and
managed by 5620 SAM.
• Notification message types are:
– Attribute value change is a message sent by NEs to the operator each time one or
more attribute states of a given object are modified.
– State change is a message sent by NEs to notify users of changes in object state
due to a change in internal system operating conditions or changes to another
object.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
For more information, see the Resource Browser description in Alcatel-Lucent 5620
SAM | Release 10.0 R6 - User Guide, 3HE 06993 AAAF TQZZA.
• Operator annotation on alarm type to:
– add additional custom information, tips and hints that can help during the
day-to-day supervision tasks.
– annotate alarm from the Alarm Manager.
– edit the entire annotation.
– record the user name, date, time, hostname and IP address of the location in the
annotation.
For more information, see Alcatel-Lucent 5620 SAM | Release 10.0 R6 - User Guide,
3HE 06993 AAAF TQZZA.
• Audible Alarms
– You can configure an audible alarm on the generation of alarm messages. .
3HE 06993 AAAF TQZZA
• Notification log
– The OAM system automatically saves alarms in a database. When the maximum
number of alarms allowed in the alarm history database is reached, the oldest
alarms are deleted. If the operator wants to save information about those alarms,
the file containing the alarm log information can be saved.
Maintenance principles
NE maintenance is based on the NE item on-site repairing or replacement (hardware
maintenance). The network supervision allows to identify a defect with raised alarms and
to remotely repair the faulty element item when permitted. The NE hardware maintenance
is required either to prevent network failures, or to correct them.
Maintenance activities comprise of the two following categories:
• Routine tasks, referred to as “Preventive maintenance” (p. 4-11)
• Corrective tasks, referred to as “Corrective maintenance process” (p. 4-12)
Preventive maintenance
The preventive maintenance includes the actions that are periodically required to prevent
a system or eNodeB malfunction. These actions are, for example, the test of items that do
not raise alarms, the replacement of filters, the cleaning of the eNodeB cabinet and
connectors. When not due to a failure, optional upgrades are also part of preventive
maintenance, since they improve the system operation. Preventive maintenance actions,
that do not require the onsite presence, can be performed from the 5620 SAM.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Note: Performing preventive maintenance procedures can generate alarms at the 5620
SAM side.
Corrective maintenance process
The corrective maintenance includes the recovery actions that are required to correct a
system or eNodeB malfunction.
One or both of the following reasons involve a corrective maintenance execution:
• An alarm is displayed at the OAM GUI
• A hardware defect is observed
Part of the corrective tasks, such as resetting an eNodeB module and running a software
update, can be performed using the 5620 SAM side. Other corrective tasks, such as
replacing an eNodeB module and restoring physical connections require operator
intervention.
The general corrective maintenance process is as follows, after a fault has occurred in an
eNodeB:
1. On 5620 SAM, the operator identifies the faulty object by viewing the generated
alarm description.
2. If the incident is resolved from the GUI, the alarm description indicates the required
remedial action to be executed.
If the issue requires an on-site recovery, the operator must refer to the eNodeB
maintenance procedures.
3. When the alarm is cleared and if the eNodeB runs without malfunction reported, the
recovery is done.
Note:
Reference documents:
• “Maintenance operations” (p. 4-13) refers to the documentation related to the
preventive and corrective maintenance tasks.
Fault management references

Overview
This section presents the fault management reference documents required for alarm
supervision and maintenance operations.
Alarm supervision
• To manage eNodeB alarms with the 5620 SAM GUI, see Alcatel-Lucent 5620 SAM |
Release 10.0 R6 - User Guide, 3HE 06993 AAAF TQZZA
• The eNodeB alarms can also be managed with specific tools. The Network Element
Manager (NEM) manages eNodeB alarms and performs basic maintenance tasks.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
eNodeB alarm management with the NEM consists of the following actions:
– Displaying active alarms
– Setting and viewing alarm histories
– Viewing and modifying alarm masks
For more information about the eNodeB alarm management with the NEM, see
Alcatel-Lucent 9412 eNodeB Network Element Manager (NEM) User Guide,
9YZ-03991-1001-PCZZA.
Maintenance operations
The reference documents are split according to the following aims:
• eNodeB hardware preventive maintenance tasks
• eNodeB alarms clearance procedures
• eNodeB hardware corrective maintenance tasks
• SAM maintenance tasks
Fault management references / Performing eNodeB hardware corrective
maintenance
The eNodeB preventive maintenance consists of the following activities, according to the
eNodeB type:
• Inspecting internal items in the cabinet and cables
• Testing batteries and replacing them if required
• Replacing filters
For more information about eNodeB preventive maintenance procedures, see the
appropriate document among the following eNodeB maintenance guides:
• 9926 Base Band Unit: Alcatel-Lucent 9926 Base Band Unit for FDD-LTE Hardware
Maintenance and Upgrade Guide, 9YZ-03991-2102-REZZA
• Alcatel-Lucent 9412 eNodeB Compact Smart Technical Description and Maintenance
Guide, 9YZ-03991-0110-DEZZA
• Alcatel-Lucent 9412 eNodeB Compact Hardware Maintenance and Upgrade Guide,
9YZ-03991-0107-REZZA
• Remote Radio Head: Alcatel-Lucent Remote Radio Head FDD Maintenance Guide,
9YZ-03991-0203-REZZA
Clearing network element alarms
This section indicates the required documents to correct NE faults after alarms are viewed
at the OAM GUI. NE alarms clearance process consists of the following tasks, depending
on the alarm type:
• Identifying the faulty equipment or module
• Enabling and disabling the maintenance mode
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• Remotely re-initializing the unit
• Performing an on-site corrective action
Note:
• For more information about the maintenance mode settings, see Alcatel-Lucent 5620
SAM | Release 10.0 R6 - User Guide, 3HE 06993 AAAF TQZZA
• For more information about the NE alarm clearance procedures, see Alcatel-Lucent
9412 eNodeB Alarms and Events Reference Guide, 9YZ-03991-0104-RKZZA..
Performing eNodeB hardware corrective maintenance
The following section indicates the required documents to perform eNodeB corrective
maintenance.
The eNodeB corrective maintenance consists of the following activities, according to the
eNodeB type:
• Replacing the cooling system equipment
• Replacing the power system equipment
• Replacing the RF block equipments
• Replacing the digital shelf modules
• Replacing the optional equipments
For more information about eNodeB corrective maintenance procedures, see the
appropriate document among the following eNodeB maintenance guides
• 9926 Base Band Unit: Alcatel-Lucent 9926 Base Band Unit for FDD-LTE Hardware
Maintenance and Upgrade Guide, 9YZ-03991-2102-REZZA
• Alcatel-Lucent 9412 eNodeB Compact Smart Technical Description and Maintenance
Guide, 9YZ-03991-0110-DEZZA
• Alcatel-Lucent 9412 eNodeB Compact Hardware Maintenance and Upgrade Guide,
9YZ-03991-0107-REZZA
• Remote Radio Head: Alcatel-Lucent Remote Radio Head FDD Maintenance Guide,
9YZ-03991-0203-REZZA
Performing 5620 SAM preventive maintenance
This section indicates the required documents to perform the 5620 SAM preventive
maintenance such as base measures, database backup and restore, and checking Solaris
platform. See Alcatel-Lucent 5620 SAM | Release 10.0 R6 - Maintenance Guide, 3HE
06984 AAAF TQZZA and Alcatel-Lucent 5620 SAM | Release 10.0 R6 - Troubleshooting
Guide, 3HE 06992 AAAF TQZZA.
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Configuration management
....................................................................................................................................................................................................................................
Configuration management
Overview
Configuration management refers to all the modifications that can be made in the
configuration of the network elements within the LTE Radio Access Network (RAN) to
handle traffic. This chapter describes the modifications that can be made to all the
parameters accessible from the network.
The following components are directly concerned with configuration management:
• Network hardware elements
• Network software applications
• Licensing requests
Network configuration is performed by the 5620 Service Aware Manager (SAM), mainly
when it receives workorders from the 9952 Wireless Provisioning System (WPS). The
workorders manipulate the RAN objects and attributes. For more information about the
objects, see “RAN model objects and configuration management” (p. 4-17).
Configuration parameter categories

LTE configuration parameters are categorized as follows:
• provisioning – standard parameters
• inventory – parameters related to hardware rollout but not part of provisioning
activities
• installation and commissioning – parameters related to installation and
commissioning activities (The initial value property is not applicable)
• states and status – parameters belonging to the OSI state or status category
• dynamic data – data managed at the network element level (not stored at the 5620
SAM server). The 5620 SAM requests the value of the parameter from the network
element to provide it to the OAM user, however, the parameter cannot be modified at
the OAM level.
Provisioning parameters are further categorized as follows:
• Customer-standard configuration parameters – parameters that the customer can set as
per their requirement.
• Customer-restricted configuration parameters – parameters that Alcatel-Lucent
strongly recommends the customer to set according to Alcatel-Lucent specification. A
warning in the 5620 SAM GUI and in the 9952 WPS editor highlights that modifying
these parameters can be dangerous.
• Manufacturer configuration parameters – parameters defined by Alcatel-Lucent.
Customers cannot modify manufacturer parameters.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
eNodeB parameters are also categorized as follows:
• alpha parameters are the transport-related parameters which need to be provisioned
before start-up.
• beta parameters are the eNodeB hardware and site parameters, that are set during
commissioning.
• gamma parameters are the telecommunication parameters.
Configuration parameter classes

LTE configuration parameters are also classified into one of the following classes
according to the requirements associated with their modification:
• RO – Read-only attributes.
• Class A (or Class 0) - The modification provokes a full eNodeB reset. The eNodeB
OAM interfaces will be unavailable during the reset. All telecommunications service
on the eNodeB is lost and is unavailable during the reset.
• Class B (or Class 2) - The modification provokes unavailability of internal resources
in the eNodeB, which leads to service impacts. The eNodeB OAM interfaces remain
available. The service impacts vary accordingly with the parameters that are being
modified. The service impact is either partial, full unavailability, some resources
impacted or impacts all eNodeB of telecommunication operations for the duration of
the modification.
• Class C (or Class 3) - Also referred to as the online parameter definition. The
modification is taken into account by the eNodeB without any impact on the services.
• NA – class is not applicable because:
– the parameter is an OAM parameter, not a network element parameter
– the parameter is a dynamic data parameter
Note:
• For more information on FDD parameters, see Alcatel-Lucent 9412 eNodeB
Parameters Reference Guide 9YZ-03991-0103-RKZZA
• For more information on TDD parameters, see Alcatel-Lucent 9412 eNodeB TDD
Parameters Reference Guide
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Snapshots and workorders
Snapshots and workorders are configuration data for network elements in eXtended
Mark-up Language (XML) format. They are produced by the CM XML interface, the
Alcatel-Lucent proprietary interface for configuration.
• Snapshot - A snapshot is an image of a configuration view taken at a given time.
• Snapshot file - A snapshot file is a flat XML description of the actual configuration of
the network. Snapshots can be filtered for a part of the network (whole network, one
or several network elements) or by the type of data (configuration parameters, states
and statuses) as desired. The XML file is dedicated to the exchange of configuration
views between applications, such as the 5620 SAM that exports snapshots to the 9952
WPS. The default extension of the file is <file name>.xcm.
• Workorder - A workorder defines the transition from an initial view to a target view
that fulfills an evolution request. It can be used as the tracking unit of the provisioning
process.
• Reverse workorder - A reverse workorder defines the opposite transition of the
workorder on which it is based. If a workorder defines a transition from state A to
state B, the reverse workorder defines the transition from state B to state A.
• Workorder file - A workorder file is an XML file which contains a sequence of
operations (create, delete, modify) to be applied on the network in order to implement
a new configuration. Workorders are generated by external applications, such as the
9952 WPS, and are activated through the 5620 SAM. The default extension of the file
is <file name>.xwo.
RAN model objects and configuration management

Configuration management involves the manipulation of RAN model objects and
attributes. This section describes how the objects are categorized and defined.
Object instances
An object is defined by the following characteristics:
• Generic attributes (parameters)
• Operations
• Notifications
• Relationship with other objects
A common information structure describes similar type of individual objects that can be
configured.
Attributes
All the objects included in the same class are described in a similar way by a set of
common parameters. The values of these parameters vary according to the object. The
parameter set is a list of attributes for the objects.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Object types
Object management entities are divided into the following subsets:
• Managed object - A managed object describes a graphical object that models an NE. A
managed object is available in the GUI and can be directly accessed by users.
Example of a managed object: ENBEquipment.
• Functional object - A functional object describes an object that conforms to a given
functionality. The functional object usually appears on the GUI, and if it does not
appear, the object is called a hidden object.
The users manage the functional objects as follows:
– A functional object is created based on the managed object to which it refers. The
functional object is created only when required by the system configuration.
– A functional object instance is defined by the managed object instance to which it
refers, and by a specific identifier.
Managed object ISO states
OAM software is responsible for management of the state of the managed objects in the
eNodeB.
The managed states are as follows:
• AdministrativeState
• OperationalState
• AvailabilityStatus
• OAMLinkAdministrativeState
AdministrativeState
AdministrativeState of a managed object indicates whether the managed object can be
accessed by the users or not. The AdministrativeState is a permanent attribute with the
following values:
• unlocked
• locked
The AdministrativeState is set to unlocked when the system administrator permits the
resource to perform services for its users. The AdministrativeState is set to locked when
the system administrator prohibits the resource from performing a service.
The AdministrativeState is not significant for all objects. Some objects have no
AdministrativeState as they are only significant to the OAM. The system manages the
operational state attribute, which is dependent on the AdministrativeState of higher-level
objects.
OperationalState
OperationalState of a managed object indicates whether the managed object is installed
and working or not.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The OperationalState of an object is a dynamic attribute that cannot be modified by the
user. The OperationalState is of two types and can be displayed on user request:
• enabled
• disabled
The internal system operating conditions can change the operational state of an object, or
when the AdministrativeState of the object or another network object changes. The
OperationalState is calculated by the OAM software based on the results of its fault
collection, filtering, and correlation functions.
AvailabilityStatus
AvailabilityStatus is used to qualify the operational state. The AvailabilityStatus of an
object is a dynamic attribute that cannot be modified by the user. It provides additional
information in association with the other state attributes.
Table 4-4, “AvailabilityStatus values and default states” (p. 4-19) shows the default
values and states.
The AvailabilityStatus is also presented as a combination of these possible values, if
several are applicable (for example, failed, intest,).
Table 4-4 AvailabilityStatus values and default states
AvailabilityStatus Value Default state

empty 0 enabled or disabled
powerOff 1 disabled
intest 2 enabled or disabled
faulty 4 enabled
degraded 8 enabled
dependency 16 disabled
logFull 21
notInstalled 22 disabled
offLine 23 23 disabled
offDuty 24 disabled
failed 32 disabled
initializing 64 disabled
combination of status is xx depends on status
possible
OAMLinkAdministrativeState
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The OAMLinkAdministrativeState indicates the supervision state of the NE. If
OAMLinkAdministrativeState is set to unlocked, then the eNodeB is supervised by 5620
SAM (SNMP connection established or under establishment if NE is not yet reachable). If
OAMLinkAdministrativeState is set to locked, then the eNodeB is not supervised by
5620 SAM (SNMP connection not established). The values are as follows:
• locked
• unlocked
Managed object relationships

Parent and child dependency
A dependency is created when the child object A depends on the parent object B.
Table 4-5, “Parent-child object” (p. 4-20) shows three examples of parent and child
dependencies. There can be other such dependencies.
The Object A column lists the associated children. The Object B column lists the parents.
Table 4-5 Parent-child object
Object A Object B
ENB ENBequipment
LTECell ENB
S1AccessGroup ENB
Functional dependency
If object B's operations influence object A's operations, object A is said to be functionally
dependent on object B. For example, LTECell object cannot operate if eNodeB object is
locked.
Creation order
The order in which managed objects are created is determined by their relationships.
If object A references object B, object B must be created before object A.
This relationship is highlighted in the tree structure of managed objects. The tree structure
shows the order in which the objects are created. For details about the managed objects
tree and the RAN model objects, see Alcatel-Lucent 9412 eNodeB Parameters Reference
Guide, 9YZ-03991-0103-RKZZA.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Managed object handling
Objects are managed in two Management Information Bases (MIB):
• The OAM MIB, which is stored on the OAM server system disks. The OAM MIB is
automatically updated after each operation, and contains all the LTE RAN objects.
• The application MIB, which is stored on the NE disks. The application MIB is built
from the OAM server (using snapshots and workorders) and the building operation of
the MIB is controlled by users.
The system runs correctly when the NE and OAM MIB files are consistent.
Operations
Operations are commands on objects that are sent from the GUI to the OAM server. The
operations are used to communicate with the OAM and update the NEs.
The OAM server includes two views:
• A provisioning view, which captures all the modifications before they are updated to
the NEs.
• A current view, which is in synchronization with the NE provisioning where the
changes are successfully activated.
The OAM checks the command before forwarding them to the NE to ensure that only
consistent commands are sent.
The same set of operations applies to all the objects in a given class. The principle
operations are:
• Creating an object
• Deleting an object
• Locking or unlocking an object
• Setting permanent attributes for an object
• Displaying permanent attributes for an object
• Displaying permanent and dynamic attributes for an object
• Reporting semantic checks to detect erroneous objects
Network configuration management architecture

This section describes the online configuration capabilities that are available from the
5620 SAM and the offline configuration from 9952 WPS for the LTE RAN. The section
details the interaction between the 5620 SAM and the 9952 WPS. The section also details
system configuration from both 5620 SAM and 9952 WPS.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
eNodeB configuration initialization
When commissioning eNodeB:
• either, the eNodeB is completely provisioned on site through the NEM GUI or
configured with a workorder imported from 9952 WPS on the NEM, and then the
eNodeB configuration is discovered by the 5620 SAM.
• OR
the eNodeB is installed on site with only a few parameters configured and then the
eNodeB configuration is performed from the pre-provisioned data by the 5620 SAM.
In such cases, the mechanism is called the self-configuration of the eNodeB.
Online and offline configurations
A large number of parameters related to equipment, neighboring, transmission, and so on,
must be configured to maintain a stable, optimized RAN network and parameter
consistency across the domains. 5620 SAM provides several configuration interfaces
suited to different types of operations.
Depending on requirements and urgency, two modes are used to configure the network:
• The online configuration for real-time modification of the LTE RAN configuration.
• The offline configuration for a programmed LTE RAN configuration.
Online configuration
Online configuration capabilities are available on the SAM GUI interface. The online
configuration capabilities are used to make real-time adjustments to the configuration of
NEs, either to tune the performance of specific NEs when required, or as a part of the
troubleshooting procedures.
Offline configuration
Offline configuration for the LTE RAN is in charge of filling network data to the access
network. The offline configuration is used for system upgrades or for global modification
of the Network Element (NE). The parameters are prepared by an external tool, the 9952
Wireless Provisioning System (WPS), and applied to the LTE RAN network by activating
a configuration session on the 5620 SAM. The offline configuration provides the
following features:
• Data import or export with the 5620 SAM server using a cmXML format
• Parameters consistency checks
• Configuration wizard for common network operations
• An open interface based on cmXML format
Figure 4-1, “Configuration extract view” (p. 4-23), Figure 4-2, “Configuration import
view” (p. 4-23), and Figure 4-3, “Offline configuration activation view” (p. 4-24) give a
general view of the offline configuration management.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-1 Configuration extract view
Figure 4-2 Configuration import view
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-3 Offline configuration activation view
cmXML interface
The cmXML interface is the main file import or export interface for the configuration
data of NEs provided by the 5620 SAM server and is based on the eXtended Markup
Language (XML) format. The cmXML is a generic framework for data exchange between
5620 SAM and external applications, covering multiple NEs, and multiple configuration
data. The interface is asymmetrical and two different formats are defined for the import
and export.
The cmXML interface is used by the 5620 SAM server for the following purposes:
• Exporting the RAN elements configuration, installation, and configuration
parameters.
• Exporting the parameter state and status.
• Importing the cmXML workorders. These cmXML workorders pertain to the
configuration parameters prepared offline and are prepared offline using the 9952
WPS.
The 9952 WPS – 5620 SAM/NEM interactions are shown in Figure 4-4, “cmXML
interface overview” (p. 4-25).
This interface is available between 5620 SAM, 9952 WPS, NEs, and other external
applications, such as planning applications or Operations Support Systems (OSS).
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-4 cmXML interface overview
Interaction between 5620 SAM and 9952 WPS

The 5620 SAM sends the data coming from the network to the 9952 WPS, after a
re-synchronization with the NEs. The data will be the initial view of the network or an
updated view in case of modifications.
The 5620 SAM retrieves the configuration data processed by the WPS team and sends it
to the network. The data can be the first resultant cmXML files or the delta configuration
in case of an evolution.
The 9952 WPS and 5620 SAM exchange cmXML files for configuration in the following
two ways:
• Snapshot export
• Workorder imports
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
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The workorder is a list of configuration changes, for example, create, delete, and modify.
The workorder is computed by the 9952 WPS to be applied on the 5620 SAM NE. The
9952 WPS loads a cmXML snapshot and creates workorders that contain actions. The
follow-up of these configuration changes is done only in 5620 SAM. No status report is
sent to the 9952 WPS.
Workorder exports are XML files that contain a sequence of operations (create, delete, or
modify) to be applied on the network to implement a new configuration. Workorders are
generated by external applications, such as the 9952 WPS tool suite, and they are
activated through the Activation Configuration session. Workorders contain information
fields such as title, originator, creation date, and comments for an efficient management.
For procedures associated with offline configuration on the 5620 SAM, see
Alcatel-Lucent 5620 Service Aware Manager | Release 10.0 R6– LTE RAN User Guide,
3HE 06983 AAAF TQZZA.
Interaction between 5620 SAM and eNodeB
The 5620 SAM user selects a single eNodeB or a set of eNodeBs and performs
modifications based on the configuration update requests.
The 5620 SAM checks for snapshot activations in progress and allows a single snapshot
activation to be in progress for the given eNodeB at any time. The 5620 SAM uses its
local database to verify that the version of the management information model used to
prepare the cmXML snapshot file is compatible with the software load running on the
target eNodeB. The 5620 SAM generates the snapshot file with the Edit-Config
command and Edit-Config operations.
To achieve an online configuration, 5620 SAM opens a Netconf session and sends an
edit-config command to the eNodeB. This command contains a few deltas and not the
full snapshot.
The Netconf protocol supports the following two actions:
• Reading of the full snapshot through a GET command.
• Creation, deletion, merge, or replacement of objects through the edit-config
command.
There are three scenarios:
• Command check failure
• Successful configuration
• Unsuccessful configuration
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The status messages for each scenario are sent by the eNodeB through OAM.
• Command check failure - When there is a command check failure, the following
events take place:
– The OAM does not update its persistent storage
– The OAM does not update its CM configuration last change counter
– The OAM sends a failure message back to 5620 SAM GUI
– Configuration changes are not affected
In this case, the operator troubleshoots to ascertain the cause.
• Successful configuration - An OK message from eNodeB means that the eNodeB has
completed the command checks and its database is successfully updated. The 5620
SAM then updates its database.
• Unsuccessful configuration - If the configuration fails after the command checks were
done successfully, the eNodeB raises an alarm to 5620 SAM, and notifies the failure
cause.
Configuration management with 5620 SAM
The 5620 SAM provides functions such as:
• display of eNodeB configuration
• discovery of eNodeB configuration
• self-configuration of eNodeB
• export of eNodeB configuration
• activate workorder imported from 9952 WPS
• adjustment of individual parameters of a eNodeB
For more information on the configuration management with the 5620 SAM, see
Alcatel-Lucent 5620 Service Aware Manager | Release 10.0 R6– LTE RAN User Guide.,
Configuration management with 9952 WPS
The 9952 WPS is an important tool in Configuration Management. Figure 4-5, “9952
WPS positioning within OAM” (p. 4-28) shows the position of 9952 WPS within OAM.
The 9952 WPS tools can be used for the following configuration activities:
• Engineering: planning and provisioning
• Operations: last-minute synchronization
9952 WPS supports the NE models. The 9952 WPS basic tool set contains the following
tools:
• Tabular editor
• cmXML import or export interface
• Workorder synchronization tool
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• Copy and paste template
• Model check tool
For procedures associated with offline configuration, see Alcatel-Lucent 9952 Wireless
Provisioning System Version 2.0 User Guide for LTE, 9YZ-05134-0203-PCZZA.
Figure 4-5 9952 WPS positioning within OAM
eNodeB Software Management

The eNodeB Software Configuration function allows an operator to:
• display the current software version that is running on the eNodeB
• download a new software from the 5620 SAM disk storage to the eNodeB, upon
request by the operator
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• monitor and report the progress and status of the download to the operator
• abort a download at any stage
• activate a new software version in the eNodeB
• accept or reject a new version of software after validation
The eNodeB software is managed from the 5620 SAM GUI or from the NEM. The 5620
SAM supports parallel downloads as well as single eNodeB download capabilities.
The software management process is made through the SNMP protocol. The failures are
reported to the operator.
The eNodeB is able to keep two versions of the software persistently; the running version
and the non-running version.
• The eNodeB downloads only the software files for those hardware units for which it
does not already have the correct software files.
• If the operator aborts a download, the eNodeB keeps the files completely downloaded
except the Software Descriptor File that is erased.
• If the activation fails, the eNodeB falls back to the previously running software
version.
• If the operator rejects the new version the eNodeB falls back to the previously running
software version.
In addition, NEM supports eNodeB data backup and restore capabilities.
Note:
• For more information on eNodeB Software Upgrade with the 5620 SAM, see
Alcatel-Lucent 5620 Service Aware Manager - LTE RAN user Guide.
• For more information on eNodeB Software Replacement with the NEM, see
Alcatel-Lucent 9412 eNodeB Reconfiguration Procedures, 9YZ-03991-0102-RJZZA
and Alcatel-Lucent 9412 eNodeB Network Element Manager (NEM) User Guide,
9YZ-03991-1001-PCZZA
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Performance management
....................................................................................................................................................................................................................................
Performance management
Overview
This section introduces the performance management concepts of the LTE RAN. It
describes the measurement scheduling and reporting principles, the counter types, the
various performance management models and the applications involved in performance
management (PM). Performance management includes the collection and storage of
performance measurements counters. The data collected is used to verify the physical and
logical configuration of the network, and locate potential problems as early as possible. It
also leads to reduction of call drops and provides better Quality of Service (QoS).
The performance management portfolio focuses on the following features:
• Access network performance monitoring
• Access network optimization
• Access network troubleshooting
Counter observation data

The data collected by a performance management system is used to evaluate the network
configuration, Quality of Service (QoS) and resource availability in a network
Network configuration
Once a network plan or changes to a network plan is implemented, it is important to
evaluate the effectiveness of the planned changes. Typically, the measurements required
to support this activity indicate the traffic levels with particular relevance to the way the
traffic uses the network.
Quality of Service
An end user views the provided service from outside the network. That perception can be
described in terms of observed QoS. QoS indicates the network performance that the user
experiences. The QoS parameters applied by the network to specific user services
determine the charges levied on the user for using these services.
Resource availability
The resource availability performance depends on the activities that are completed during
the different phases of the life cycle of the system, and on the physical and administrative
conditions.
The observation counters collected from different NEs are used to calculate the number of
occurrences of an event. The eNodeB generates the performance measurements. The
access network observation counters are eNodeB equipment counters. The observation
counters are divided into eNodeB counter families.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Note:
• For more information on counter families, see “Counter families” (p. 4-34)
• For more information on observation counter definitions, see the 3GPP TS 32.104
specifications.
• For more information on observation counters, see Alcatel-Lucent 9412 eNodeB
Counters Reference Guide9YZ-03991-0105-RKZZA. This document provides
reference pages for all LTE eNodeB observation counters, as well as descriptions
of counter types, object hierarchies, counter hierarchies, and other supporting
information.
Measurement scheduling and reporting

The measurement schedule specifies the time frames during which the measurement job
is active.
The following are the elements that determine the amount of data collected by a network
element:
• granularity period
• reporting period
• recording interval
• measurement schedule
Measurement scheduling and reporting diagram
The Figure 4-6, “Measurement scheduling and reporting” (p. 4-32) shows the relation
between the various measurement values:
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-6 Measurement scheduling and reporting
Granularity period
The granularity period is the time over which a measurement is measured. The
measurement result can be obtained at the end of this period.
Reporting period
The reporting period indicates how often the measured results are required to be
transferred from the Network Element (NE) to the Element Manager (EM), or appropriate
destination system. The reporting period must be no smaller than the granularity period
and must be a multiple of the granularity period.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Recording interval
The recording interval is an interval within the measurement schedule (during a single
day) when measurement collection is active. The interval is identified by a start time and
an end time which must lie between 00:00 h and 24:00 h and is aligned on granularity
period boundaries. Thus the length of a recording interval is a multiple of the granularity
period.
Measurement schedule
The measurement schedule defines the time during which a measurement job is active.
This is done by specifying a start time and an end time, or multiple start times and end
times.
Note: The start time can be immediate; this means measurement collection starts at
the next coherent granularity period boundary. The end time can be infinite; this
means that the measurement job has no end time.
Measurement counter types

The 3GPP standard defines types of measurement counters.
The eNodeB supports the following types of measurement counters:
• Cumulative counter
• Discrete event registration or Value counter
• Status inspection
Cumulative counter
The Cumulative counter maintains a running count of the events being counted. The
counter is reset to a defined value (usually 0) at the beginning of each granularity period.
Discrete event registration or Value counter
The Discrete event registration counter captures measurement data from the occurrences
of a given type of event detected during the granularity period. A measurement data is
extracted from each occurrence of the event. These individual measurements then
contribute toward the summary counter for the corresponding granularity period. Discrete
event registration counters are also known as Value counters. The Value counters provide
the minimum, maximum, and average values. Each event provides a value that is added to
the cumulated value.
Status inspection or Load counter
The Status inspection is derived from samplings of a specified measurement taken at
regular intervals during the granularity period. The individual samplings contribute
towards the summary counter for the corresponding granularity period. The summary
counter is useful for the analysis of averages, trends, or cycles. The Status inspection
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
counters are also known as load counters because they provide the minimum, maximum,
and average values. This counter type is based on a self-generated sampling method. It
offers the means of getting the rapidly changing data.
Counter families
The counters related to a given function are assigned to a corresponding family. The
family name is used as part of the hierarchic identity of the counter.
A counter name is as follows <family-name>.<counter-name>.<sub-counter-
name>:
Where:
• family-name refers to a collection of counters involved in performing a
telecommunication function or service.
• counter-name refers to different types of counter name as defined in 3GPP TS 32.401.
• sub-counter-name refers to a counter that a basic counter definition generates. The sub
counters are also called as screenings.
For example, a cumulative counter recording the number of occurrences of a given
type of event is observed during the granularity period and may be defined to record
the number of instances of the event that belong within a given defined subclass of the
event.
In case of a connection event, the establishment causes can define subclasses of the
event. For example, any DER or SI counter generates three sub counters. The sub
counters are the minimum, maximum, and the average values observed during the
granularity period. To determine the average measurement, two more counters are
implied. It includes the cumulative total of values observed and the number of
observations made.
Performance management models

This topic lists different performance management models.
The following are the performance management models:
• Native model
• Network Resource Model (NRM) oriented model
• Correspondence native model
Native model
The performance measurements are defined for the resource objects. The resource object
is a subset of the managed objects of an eNodeB native Managed Information Model
(MIM). This model is used for the interface of SAM with eNodeB. In the performance
monitoring object model, each object class has a unique set of defined counters that is
supported by each and every instance of the class. The subnetwork object is added as the
root of the containment tree and it reflects the LTE RAN topology.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Network Resource Model (NRM) oriented model
The performance monitoring data file, as generated by the eNodeB, identifies the
measured object instances according to the NRM-oriented model, which, in the absence
of a standardized Network Resource Model for the evolved UTRAN, is derived from the
3GPP EUTRAN Model. This NRM oriented model is used for the Northbound Interface
(NBI) with the SAM.
In the performance monitoring data file:
• The reporting NE is identified by the NE user name element (neun). It is populated
with the value of uniqueName.
• The subnetwork in the Performance monitoring data file has no identification.
• The measured object instance (moid) is identified by the following LDN:
– For a LteCell: ENBEquipment=”NE_uniqueName”, Enb=0,
LteCell=”LteCell_unique Name”; the complete identifier of a Eutran Cell is:
SubNet.NE uniqueName.0. LteCell_uniqueName
– For a MmeAccess: ENBEquipment=”NE_uniqueName”, Enb=0,
MmeAccess=”MmeAccess_uniqueName”; the complete identifier of a
MmeAccess is: SubNet. NE uniqueName.0. MmeAccess_uniqueName
– For a X2Access: ENBEquipment=”NE_uniqueName”, Enb=0,
X2Access=”X2Access_uniqueName”; the complete identifier of a X2Access is:
SubNet.NE_uniqueName.0. X2Access_uniqueName For a MbmsBearerService:
ENBEquipment=”NE_uniqueName”, Enb=0,
MBMSservice=”MbmsBearerService_uniqueName”; the complete identifier of a
MbmsBearerService is:
SubNet.NE_uniqueName.0.MbmsBearerService_uniqueName
Note: The object containment tree, as used in the NPO tool, may differ in minor
respects from the above model.
Correspondence native model/NRM model
The correspondence between the eNodeB native MIM-oriented model to the
NRM-oriented model is in the performance monitoring data file. This file is generated in
3GPP format and it requires no mediation.
Performance management applications

The access network performance management applications are responsible for the
following actions:
• Collecting the XML data that is generated by the eNodeB
• Post-processing the collected data for viewing and creating tables, graph reports, and
geographical information system views
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The 9412 eNodeB performs the data collection, the 5620 SAM retrieves the performance
data from the Alcatel-Lucent eNodeB and the Alcatel-Lucent 9959 NPO performs the
counter observation data post-processing on the data collected.
Counter system architecture

The counter system architecture involves entities that collect and store the performance
measurement counters. The following are the entities:
9412 eNodeB
The eNodeB generates the performance monitoring data and stores them in a file.
5620 Service Aware Manager (SAM)
The SAM collects the performance measurement data on all eNodeBs and generates the
performance measurement files.
9959 Network Performance Optimizer (NPO)
The NPO retrieves the Performance Management or Monitoring (PM) file from SAM and
stores the performance measurement data.
The main phases of the counter observation are:
• Configuration of performance management parameters
• Counter pegging in the NEs according to the performance management parameter
configuration
• Collection of performance measurement results
• Post-processing of performance measurement results
The Figure 4-7, “Functional view of the counter observation domain” (p. 4-37) shows the
functional split of the counter observation domain.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-7 Functional view of the counter observation domain
The results of the counter observations are the XML record files, which store the access
network observation data (counters). The Data Type Definition (DTD) of this XML
format is 3GPP-compliant (compliant with the 3GPP 32.401 V5.5.0 format) and each
record file contains the counters of a single collecting element.
Use Network Performance Optimizer (NPO) to report observations. NPO is an
Alcatel-Lucent performance reporting tool.
The NPO regularly polls the counter observation directory, uploads the XML counter
observation files, and post-processes them.
The post-processing mainly consists of:
• Mapping the NE counter observation object model onto the NPO topological model
• Loading the NE counter observation data into the NPO database
• Computing the indicators and generating QoS reports
eNodeB counter observation data

Each eNodeB observation counter is attached to managed object instances.
The eNodeB observation counter families available for this release are classified as
follows:
• Capacity counters
• E-RAB (E-UTRAN Radio Access Bearer) Management counters
• eNodeB synchronization counters
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
• Interface management counters
• IP Transport counters
• L1 Traffic and throughput
• L2 Traffic and throughput
• Mobility (handover procedures and redirections to other networks) counters
• Paging counters
• PDCP (Packet Data Convergence Protocol) SDU (Service Data Unit) counters
• Radio scheduler (uplink and downlink) counters
• RRC (Radio Resource Control) connection counters
• S1 dedicated connection counters
• S1 traffic and throughput counters
• SCTP (on S1 or X2) counters
• UE context management
• X2 traffic and throughput
For information on eNodeB observations, see Alcatel-Lucent 9412 eNodeB Counters
Reference Guide 9YZ-03991-0105-RKZZA.
Performance and service measurement reporting

The following data is obtained from the eNodeB in reply to a request from the SAM
pertaining to each performance measurement job.
The information available are:
• PM job ID
• PM job type
• Administrative state
• Operational state
• The number of objects that are elements of the range of measurements
• The number of activated threshold observations
• The number of activated measurement types
• An estimation of the size of the uncompressed measurement result file, if the file is
generated by the data upload command
• The size of all stored uncompressed measurements
• An estimation of the size of the uncompressed measurement result file that is created
during the subsequent 24 h with the current scanner configuration.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
eNodeB observation activation
The eNodeB observation session is automatically created after building the eNodeB. At
the eNodeB, the counter collection cannot be deactivated. The granularity period can be
modified through CLI. The eNodeB generates and stores one observation file per
granularity period with a maximum latency of one minute after the end of this granularity
period. The guaranteed storage duration is 72 h for all granularity period files. The
observation files are generated in XML format and the event is sent to the SAM.
Counter collection and mediation

This topic describes how the counter observation data is collected from the NEs for
post-processing.
Counter collection
The Figure 4-8, “Measurement files - schedule” (p. 4-40) depicts the schedule for the
generation and transfer of the performance measurements data in the eUTRAN.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Figure 4-8 Measurement files - schedule
with y + z +2.5 = Granularity period where y = the time for regular SNMP retrieval and z
= the time for exceptional SNMP retrieval.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The following is the functional split between subsystems (9412 eNodeB, 5620 SAM,
9959 NPO):
• The 9412 eNodeBs are responsible for generating counters and sub counters
depending on their activity. PM data collection starts on the eNodeB when the
eNodeB is started. At the end of a specified time frame, called the granularity period,
the eNodeB calculates PM results for the last granularity period and stores them in a
file in RAM. This file is generated in the first two minutes of the next granularity
period. The PM data file is compressed with gzip. If this compressed file exceeds a
certain size, the file is split into several parts and it is up to SAM to perform the
concatenation.
The files in RAM does not remain during a reset of the eNodeB.
The collected performance information is stored as a performance counter file. The
following are the two types of performance data:
– Value collected (accumulated) during the measurement cycle
– Value reported at a single point during the measurement interval
The counters are generated for every granularity period requested by the SAM.
The result is made available for SAM through Management Information Base
(MIB) data in Performance Manager Counter (PMC) results table for a minimum
of 72 h and deletes the PM files that exceed 72 h.
If eNodeB fails to ensure the right values of the counters, it sets a SuspectFlag to
True.
• The 5620 SAM ensures the retrieval of PM data for every supervised eNodeB through
Simple Network Management Protocol (SNMP) requests, at regular intervals. 5620
SAM does not perform any transformation of the data and makes the PM files
available in a public directory for external applications, especially NPO.
The PM files contain the defined counters for every PM objects. There is one
compressed file per eNodeB for a reporting period. SAM stores the PM files for a
minimum of 7 days and deletes the PM files that exceed 7 days.
The 5620 SAM implements a recovery mechanism for retrieving the missing PM data
in case of any failures. Within each granularity period, after the termination of the
regular retrieval window for PM Data and before the end of the granularity period,
5620 SAM attempts to recover PM data that were not successfully transferred from
the respective eNodeB's during earlier granularity periods.
If an SNMP request for an eNodeB fails during the Exceptional Retrieval, the 5620
SAM raises an alarm against the eNodeB, indicating the termination status of the
SNMP error.
If the eNodeB PM data retention period (72 h) has expired without any data being
retrieved by 5620 SAM, it raises and alarm against the eNodeB and returns the name
of the unretrieved data with a lost data status.
The 5620 SAM allows the operator to configure the granularity period for each
eNodeB through the pmcGranularityPeriod parameter under ENBEquipment.
The granularity period values are 5 min, 15 min by default, 30 min or 1 h.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The reported hour is always rounded to the nearest granularity period value. For
example, reported times for granularity period of 15 min are: 16:00 h, 16:15 h, 16:30
h, and so on.
• A network performance management application or OSS, such as the Alcatel-Lucent
9959 NPO automatically retrieves all available files from 5620 SAM using FTP, reads
them and stores them in its database. It consolidates the counter data every day for
further analysis. The NPO retrieves the suspectFlag to know the validity of the
counters value and generates Key Performance Indicators (KPI) based on PM data
retrieved on 5620 SAM.
Note: The collection method depends on the counter type.
eNodeB observation XML files

This topic describes the file tree structure, the data formats, and the file naming
conventions that the PM collector uses to store the eNodeB observation data.
The SAM periodically uploads the observation files stored on the eNodeB. The eNodeB
XML observation files are generated and stored in the following directory
/opt/5620sam/lte/stats/<Date>/<eNodeB>/<NeUserLabel>
Where:
• <Date> refers to the date of monitoring, according to the local time-zone of the
SAM, its format is <YYYYMMDD>
• <NeUserLabel> refers to the User Label of the eNodeB, as used in the file name of
the file retrieved from the eNodeB
Note: For more information on SAM behavior, see “Chapter: LTE RAN statistics” in
5620 SAM LTE RAN User Guide.
The XML format is compliant with the 3GPP DTD file: with the DTD-based XML
format, “MeasDataCollection.dtd version 2.0”, as per 3GPP TS 32.401 V5.5.0.
Note: For more information on the DTD file, see “Measurement FileFormat (from
3GPP TS 32.401)” in Alcatel-Lucent 9412 eNodeB Alarms and Events Reference
The generated eNodeB XML file name has the following format :
<Type><Date>.<StartTime>-<EndTime>_<eNodeB-NeUserLabel>.gz
Where
• <Type>
The default value is A, indicating the observation file contains data originated from a
single eNodeB
• <Date>
Refers to the date of monitoring, as in directory name, the format is YYYYMMDD
• <StartTime>
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Refers to the beginning time of the granularity period, the format is <hhmm[+]#GMT>
• <EndTime>
Refers to the end time of the granularity period, the format is <hhmm[-]#GMT>
Table 4-6 eNodeB XML file naming convention
Code Description
YYYY The four-digit year
MM The month of the year (01,02,...,12)
DD The day of the month (01,02,...,31)
hh The two digit hour (00,01,...,23)
mm The digit minute of the hour. Possible values are five-minute steps: 00, 05, 10,
15, 20, 25, 30, 35, 40, 45, 50, and 55.
#GMT Difference between local time and Greenwich Meridian Time {+/-hhmm). At
10:15:02 in Paris, the April 22, 2004, the #GMT is +0100 => the
<hhmm><#GMT> is 1015+0100.
At 18:12:11 in New York, the June 22, 2009, the #GMT is -0500=>the
<hhmm><#GMT> is 1812-0500.
Note:
• It is assumed that the 5620 SAM and all the eNodeBs are aligned to the same
time-zone.
• To generate LTE RAN access observation reports from NPO, see Alcatel-Lucent
NPO WCT - User Guide 3BK 17446 2111 TQZZA.
Counter data
Observation counter identification
Observation counters available on OAM GUI are of three types:
• Cumulative (or Total) counts the number of events. This counter increments by one
each time the counted event occurs and it provides the cumulated value for the
observation period.
• Value records the value accumulation. It offers the means of measuring minimum,
maximum, and the average values. The average value is a weighted average value of
an event.
• Load offers the means of sampling rapidly changing data and obtaining an average
minimum or maximum value of the sampled data. The average value is a time
weighted average.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Zero, one, or more screenings are associated with each counter. The screening mechanism
provides a further specialization of the counters. For example, the screening TimeOut of
the counter RadioLinkSetupUnsuccess counts the number of unsuccessful radio link setup
because of time-out.
A counter record refers to a counter screening value for a given measured object instance.
When a Cumulative counter screening is measured on an object instance, the result is
one-counter record (Cumulated Value). When a Value counter screening is measured on
an object instance, the result is four-counter record (Cumulated Value, Number of Events,
Maximum Value, Minimum Value). Similarly, when a Load counter screening is
measured on an object instance, the result is four-counter record (Cumulated Value,
Elapsed Time, Maximum Value, Minimum Value).
Observation counter name
Use the counter name to identify the type of counter.
The counter measurements include screening names or the following fields:
• Cumulated value
• Maximum value
• Minimum value
• Number of events or Elapsed Time
Note: The Cumulative counter has one value, while Value and Load counters have
five values.
The associated counters are identified using an underscore notation:
• VS_<CounterName>
Example:
VS_RadioLinkFailureSum
• VS_<CounterName>_Cum
Example:
VS_bUeScheduledPerDLTTI_Cum
• VS_<CounterName>_Max
Example:
VS_bUeScheduledPerDLTTI_Max
• VS_<CounterName>_Min
Example:
VS_bUeScheduledPerDLTTI_Min
• VS_<CounterName>_NbEvt
Example:
VS_bUeScheduledPerDLTTI_NbEvt
• VS_<CounterName>_ElapsedTime
Example:
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
VS_NbUeRrcConnected_ElapsedTime
• VSP_<CounterName>_<Screening>
Example:
VS_InitialERABSetupRequest_QCI1
Note: For more information about the screening meanings and observation
measurements, see Alcatel-Lucent 9412 eNodeB Counters Reference Guide,
9YZ-03991-0105-RKZZA.
Managed object format

The managed objects contained in the observation record files are identified according to
the Measurement File Format from 3GPP TS 32.401.
Note: For more information on observation record files, see “Measurement File
Format (from 3GPP TS 32.401)” in Alcatel-Lucent 9412 eNodeB Counters Reference
The following conventions are only used in the XML record file. For the NE identifiers
used in file naming conventions, refer to the file naming convention for observations
section. A Distinguished Name (DN) is built as a series of comma-separated name
components referred to as Relative Distinguished names (RDN). DN ::= RDN [',' RDN]*
The syntax of these name components is RDN ::= className '=' identifierValue
Note:
• There is no space between RDNs; the only possible separator is a comma (“,”).
• The className element is not the name of the naming attribute but the name of
the class. The <identifierValue> is processed as a string.
Observation file DTD versioning

The release of DTD used for the XML output is identified using the observation file. The
name of the DTD referred to in the XML document header includes the protocol name
and the release of this DTD as shown in the following example:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE mdc SYSTEM "/opt/oam/data/observation/32.401-02.dtd">
Performance management collector

Performance Management (PM) collection starts when the eNodeB is started. The PM
data collector manages the PM data and also introduces the performance management
framework to have enhanced PM capabilities. It retrieves the PM file from the eNodeB to
the 5620 SAM. At the end of every granularity period, the eNodeB calculates PM results
for the last granularity period and stores them in a file.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
The performance collector provides the following functionality:
• It allows the collection of counter files from the equipment managed by 5620 SAM.
• It allows the mediation of collected counter files to make them available on the
Northbound interface of the 5620 SAM system.
NPO overview
NPO is a GUI driven Alcatel-Lucent application with the flexibility for reporting (drag
and drop, markers) and creation of indicators.
It offers the following multi-standard QoS monitoring and radio network optimization
facilities:
• Powerful GUI that supports the efficient use of all the MS-NPO functions
• QoS analysis
• Customizing
This product includes a powerful Oracle™ database containing performance
measurements and calculated indicators.
Note: For more information, see the Alcatel-Lucent 9959 Network Performance
Optimizer eNodeB, MME, SGW and PGW Indicators Reference Guide,
9YZ-03991-3702-RKZZA. This document provides a list of Network Performance
Optimizer (NPO) indicators available in LTE Radio Access Network (RAN) and
describes the indicator type, structure information, and the availability domain for
each indicator.
File retrieval
The NPO tool automatically initiates the file transfers of the performance monitoring data
files, retrieved from the SAM system. The PM files are retrieved using FTP from the
specified 5620 SAM path name and file name. The NPO is configured to check the 5620
SAM repository periodically to determine the availability of the expected performance
monitoring data files. In case of file transfer failure, the NPO tool records the failure
event in an event log. The performance monitoring data held within a retrieved
performance monitoring data file is imported into the NPO database.
Note: The recommended approach is NPO polls the 5620 SAM repository at 5-min
intervals aligned with 1-min offset from the boundaries of the granularity periods
themselves.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
Post processing
The performance monitoring counters, in the data files on SAM is available for reporting
and analysis using the NPO tool. The NPO tool generates the reports on the collected
counter data. It is configured to derive Key Performance Indicators (KPIs). The reports
generated are either in tabular form (spreadsheet) or in graphical form. The report
highlights the instances of metrics that cross the user-specified threshold.
Security
Overview
IP Security (IPsec) encryption is an optional security feature that protects the
confidentiality and integrity of the OAM messaging service between the clients and the
servers. The IPsec solution is based on the deployment of an IPsec gateway between
eNodeBs and the EPC network. Implementation of IPsec protects the FTP, Telnet, FMIP,
and TP services. An IPsec tunnel is created between an eNodeB and the Security gateway
(SEG). The Security gateway routes the packets to the relevant nodes, such as, eNodeBs,
Mobility Management Entities (MME), or the Packet Data (PD) gateway.
The ciphering and data integrity protection is applied in the EUTRAN by the PDCP layer
between the eNodeB and the UE. Data integrity ensures that no unauthorized, third-party
network is able to send unnecessary signaling messages with the intention of causing any
undesired effect on an ongoing call. Integrity protection is performed by Layer 2 (PDCP)
based on the configuration provided by the upper layers. Ciphering encrypts all signaling
and data messages sent over the air interface, ensuring the confidentiality of the
transmitted data. Ciphering is performed by PDCP based on the configuration provided
by the upper layers.
Security IPsec with certificates

The eNodeB supports the Certificate X509 for IPsec. The digital certificates supported by
eNodeB are compliant with X509 v3 standard. The Certificate X509 supports only for the
standard field. Digital certificates are public key certificates using RSA algorithm. The
RSA private key is stored securely inside the eNodeB and never leaves the eNodeB. The
certificates contain the identity of the eNodeB. The eNodeB supports the certificate
validity period.
The eNodeB supports three hierarchical Certificates:
• Root certificate
• Sub certificate
• eNodeB certificate
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Security
....................................................................................................................................................................................................................................
The certificates are downloaded in the eNodeB by a CMS application (not PKI) remotely
or locally.
The following documents include additional information on security:
• For activation and deactivation, and for configuration procedures, see Alcatel-Lucent
9952 Wireless Provisioning System Version 2.0 User Guide for LTE,
9YZ-05134-0203-PCZZA.
• For information on security, see Alcatel-Lucent 5620 Service Aware Manager |
Release 10.0 R6 System Architecture Guide., 3HE 06991 AAAF TQZZA
Call Trace
Overview
Collection of call trace does not affect the performance of 5620 SAM Server because the
collection of call trace is done on the auxiliary server. Each call trace is equal to 80
Kbytes for 1 h. The UDP packets containing call trace or debug trace data can be of a
maximum size of 5500 bytes. The processing of UDP packets is not CPU intensive.
However, compressing each XML file is CPU intensive.
Figure 4-9 SAM Call Trace Architecture
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Call Trace
....................................................................................................................................................................................................................................
SAM configures call trace session on eNodeB:
• IMSI/Signaling or management based traces
• Trace all or event based trace collections
– Thresholds on Traffic, RRC connection retries, and IRAT connection redirects
• Supports three levels of trace in detail.
Self Optimizing Network (SON)

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 9412 eNodeB, 5620 SAM, 9952 WPS, 9959 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 neighbor’s 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 – 9412
eNodeB interactions.
The PCI value is calculated using the formula below:
PCIvalue = physicalLayerCellIdentityIndex + 3 * physicalLayerCellIdentityGroupIndex
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE RAN OAM functions Transport call admission control
....................................................................................................................................................................................................................................
Transport call admission control

Overview
For any call, the call admission control provides the UE bearer to the Radio CAC and to
the transport CAC. Based on the occupancy of each CAC, the call is accepted or rejected.
A transport CAC manages a CAC UL and a CAC DL.
Key functions of the transport CAC are the following:
• A transport CAC manages a CAC UL and a CAC DL
• Several Class of services are managed (Max is 16)
For each class of service:
– Bandwidth is defined
– Some QCIs are allocated
• Congestion management at call admission when congestion management is enabled
The 9412 eNB supports CAC Transport for DL and UL traffic that applies only on S1
traffic. Bandwidth reservation for X2 is based on static allocation.
It is possible to have several class of Services (1 to 9) which are defined by QCI. One
class of service can support one or several QCIs. Other types of traffic (S1c, X2c, 1588,
eMBMS, OAM, Call trace, ICMP, other) are defined by flow type or DSCP. The
bandwidth of the Transport Link is partitioned in pools.
The QCI allocation to a transport pool is configured from 5620 SAM. The 9412 eNB
supports a parameter of overbooking per QCI.
....................................................................................................................................................................................................................................
Issue 1 April 2013
5 LTE Services
5
Overview
Purpose
This chapter provides an overview of the LTE services.
Contents
Synchronization 5-1
Quality of Services (QoS) 5-3
Synchronization
Overview
Synchronization is a state of simultaneous occurrences of significant instances among two
or more signals. The synchronization signal delivery system is based on the physical layer
(PHY) of the transmission system providing a clock signal.
Two types of downlink synchronization signals (channels) in LTE are:
1. Primary synchronization channel (PSCH) - The primary synchronization signal is
used to synchronize timing during cell search.
2. Secondary synchronization channel (SSCH) - The secondary synchronization signal is
used to synchronize timing and to transmit cell group identification during cell search.
...................................................................................................................................................................................................................................
Issue 1 April 2013
LTE Services Synchronization
....................................................................................................................................................................................................................................
Features
The synchronization features in LTE are:
• Redundancy support
– Optional failover from one mechanism to another
– Prioritization is configurable from the OAM
• Network design
– Limits the number of hops from timing signal to slaves
– Ensures that the packets transmitting the synchronization have the highest priority
with pbit/DSCP. Phase synchronization supported by GPS & 1588V2
• Daisy chaining 9412 eNodeB
– Master 9412 eNodeB provides the timing signal to the slave
Synchronization schemes
Two mobile wireless network synchronization schemes are:
1. Frequency-division duplex (FDD) - Synchronization frequency-division duplex
(FDD) radio-based mobile wireless network synchronization signals for entry and exit
of data and accurate radio frequency. For example, WCDMA FDD is the method of
radio air interface used in GSM systems.
2. Time-division duplex (TDD) - Synchronization of time-division duplex (TDD)
radio-based mobile wireless network requires frequency accuracy, phase alignment,
and, in certain cases, time alignment between all base stations in the cell network. For
Example: CDMA, cdma2000, Mobile WiMAX 802.16e, and Long-Term Evolution
(LTE).
Synchronization distribution
The following synchronizations are available:
• IEEE1588v2
• GPS
• External timing port
• Synchronous Ethernet
• High stability internal clock: optional
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE Services Synchronization
....................................................................................................................................................................................................................................
Figure 5-1 Synchronization distribution
Quality of Services (QoS)

Overview
LTE architecture supports Quality of Services (QoS) with end-to-end quality of service.
The QoS of the bearer is assigned by the EPC.
Each EPS bearer is associated with the following QoS parameters:
• QCI (QoS Class Identifier) - QCI describes the bearer level packet forwarding
treatment that is expected from an access node. For example, from eNodeB which is
primarily in terms of latency and packet loss.
• ARP (Allocation and Retention Priority) - The ARP decides a bearer establishment or
modification request accepted or rejected in case of resource limitations.
Figure 5-2, “QoS” (p. 5-4) describes the QoS parameters.
....................................................................................................................................................................................................................................
Issue 1 April 2013
LTE Services Quality of Services (QoS)
....................................................................................................................................................................................................................................
Figure 5-2 QoS
QoS Traffic Shaping

The ethernet and internet have different types of QoS. For example, various levels of QoS
can be applied to LTE traffic for different applications, the LTE MAC layer function is
fully scheduled. Evolved Packet System (EPS) bearers provide one-to-one
correspondence with RLC radio bearers and provide support for Traffic Flow Templates
(TFT).
To optimize and guarantee performance, lower latency, and to increase usable bandwidth
by delaying packets that meet certain criteria are:
• Traffic Classification - the IP packets that are sent is classified according to their
respective QoS.
• Buffering - the IP packets are buffered in different queues according to their relative
priority.
• Scheduling - the IP packets is sent at the right time according to the bandwidth
allocated by the Service Layer Agreement (Carrier to Interference Ratio (CIR), Pilot
to Interference ratio (PIR), and so on) of the UL transport line.
UL MAC Scheduler
The UL MAC Scheduler notifies the congestion of the uplink transport interface and
considerates.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
UL Static
A deterministic value is transmitted to the UL MAC scheduler when a backhaul link
bandwidth limitation is deterministic, like E1. For example, backhaul pipe size.
Backhaul pipe size includes:
• Dynamic - unable to detect the UL congestion as the explicit Congestion Notification
(eCN) bit is not implemented across the network.
• Static - a deterministic value of the bandwidth of the UL backhaul is set at the 9412
eNodeB. A mechanism of token is applied to manage the traffic load and to limit the
radio in case of congestion.
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
Issue 1 April 2013
Appendix A: Abbreviations
Overview
Purpose
This appendix lists abbreviations including initialisms and acronyms used in this
document.
Contents
Initialisms A-1
Acronyms A-5
Initialisms
0-9
3G Third Generation
3GPP Third Generation Partnership Project.
3GPP2 Third Generation Partnership Project 2.
5620 SAM Alcatel-Lucent 5620 Service Aware Manager
B
BB Baseband
BS Base Station
BBU Base Band Unit
...................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary A-1
Issue 1 April 2013
Abbreviations Initialisms
....................................................................................................................................................................................................................................
C
CC Cumulative Counter
CM Configuration Management
CSCF Call Session Control Function
D
DER Discrete Event Registration
DHCP Dynamic Host Configuration Protocol
E
eCN explicit Congestion Notification
eNodeB (eNB) evolved NodeB
EPC Evolved Packet Core
F
FDD Frequency Division Duplex
FM Fault Management
G
GBR Guaranteed Bit Rate
H
HRPD High Rate Packet Data
HPCRF Home Policy Control and Charging Rules Function
I
IMS IP Multimedia Subsystem
L
LTE Long Term Evolution
LTE RAN (eUTRAN, E-UTRAN) Long Term Evolution radio access network
M
MBMS Multimedia Broadcast Multicast Service
MIMO Multi-Input-Multi-Output
....................................................................................................................................................................................................................................
A-2 Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013
....................................................................................................................................................................................................................................
ME Mobile Equipment
MO Managed Object
MME Mobile Management Entity
MM Mobility Management
N
NAS Non Access Stratum
NE Network Element
NPO Network Performance Optimizer
O
OLCS Online Customer Support
OFDMA Orthogonal Frequency Division Multiple Access
OAM Operations, Administration, and Maintenance
P
PCM Pulse Code Modulation
PCRF Policy Control and Charging Rules Function
PD Packet Data
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDN GW Packet Data Network Gateway
PDU Protocol Data Unit
PM Performance Management
Q
QoS Quality Of Service
QAM Quadrature Amplitude Modulation
R
RF Radio Frequency
RRC Radio Resource Control
RRH Remote Radio Head
....................................................................................................................................................................................................................................
Issue 1 April 2013
....................................................................................................................................................................................................................................
S
SAE System Architecture Evolution
SC-FDMA Single Carrier Frequency Division Multiple Access
SDR Software-Defined Radio
SDU Service Data Unit
SEG Security Gateway
SI Status Inspection
SON Self-Organizing Network
SIM Subscriber Identity Module
S-GW Serving Gateway
SM Session Management
T
TDD Time Division Duplex
TRDUs Transmit Receive Duplex Units
U
UE User Equipment
USIM UMTS Subscriber Identity Module
W
WPS Wireless Provisioning System
WTA Wireless Trace Analyzer
....................................................................................................................................................................................................................................
Issue 1 April 2013
Abbreviations Acronyms
....................................................................................................................................................................................................................................
Acronyms
M
MAC Media Access Control
R
RAN Radio Access Network
S
SAM Service Aware Manager
....................................................................................................................................................................................................................................
Issue 1 April 2013
Abbreviations Acronyms
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
Issue 1 April 2013
Index
Numerics .............................................................
5620 Service Aware Manager
N Network Element Manager
(SAM), 3-1
(NEM), 3-7
.............................................................
Non Access Stratum (NAS)
C Call Trace, 4-48 Sublayer, 1-10
Configuration management, 4-15 NPO architecture, 3-3
Control plane protocol stacks, 1-8 .............................................................
............................................................. P Packet Data Convergence Protocol

(PDCP) Sublayer, 1-8, 1-10
E Evolved packet core (EPC), 1-5
Packet Data Network Gateway
.............................................................
(PDN-GW), 1-5
F Fault management, 4-1 performance management, 4-30
functions, 1-3 Physical (PHY) Sublayer, 1-8, 1-9
9412 eNodeB, 1-3 Policy Control and Charging Rules
Mobile Management Entity Function (PCRF), 1-6
(MME), 1-3 .............................................................
System Architecture Evolution R Radio Link Control (RLC)

(SAE), 1-3 Sublayer, 1-8, 1-10
.............................................................
Radio Resource Control (RRC)
L Long Term Evolution, 1-1 Sublayer, 1-10
.............................................................
LTE interfaces, 1-6
LTE network components, 1-4, 1-4 S Serving Gateway (S-GW), 1-5
LTE RAN, 1-4 .............................................................
............................................................. U User equipment (UEs), 1-4
M Media Access Control (MAC) User plane protocol stacks, 1-7

Sublayer, 1-8, 1-9
....................................................................................................................................................................................................................................
Alcatel-Lucent 9400 LTE RAN Alcatel-Lucent – Proprietary IN-1
Issue 1 April 2013
Index
....................................................................................................................................................................................................................................
....................................................................................................................................................................................................................................
IN-2 Alcatel-Lucent – Proprietary Alcatel-Lucent 9400 LTE RAN
Issue 1 April 2013

9YZ039910004TQZZA - V1 - Alcatel-Lucent 9400 LTE Radio Access Network RAN Overview PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

9YZ039910004TQZZA - V1 - Alcatel-Lucent 9400 LTE Radio Access Network RAN Overview PDF

Caricato da

Copyright:

Formati disponibili

Use pursuant to applicable agreements

About this document

Intended audience .......................................................................................................................................................................... x

Supported systems ......................................................................................................................................................................... x

How to use this document ........................................................................................................................................................... xx

Conventions used ........................................................................................................................................................................... x

Related information ..................................................................................................................................................................... xi

Document support ........................................................................................................................................................................ xi

Technical support .......................................................................................................................................................................... xi

How to order ................................................................................................................................................................................... xi

How to comment ........................................................................................................................................................................... xi

1 Long Term Evolution System Overview

Overview ...................................................................................................................................................................................... 1-1

Long Term Evolution .............................................................................................................................................................. 1-1

LTE functions ............................................................................................................................................................................. 1-3

LTE network components ..................................................................................................................................................... 1-4

LTE interfaces ............................................................................................................................................................................ 1-6

LTE protocol stacks .................................................................................................................................................................. 1-7

2 LTE Radio Access Network

Overview ...................................................................................................................................................................................... 2-1

LTE RAN ..................................................................................................................................................................................... 2-1

LTE RAN interfaces ................................................................................................................................................................ 2-2

Overview ...................................................................................................................................................................................... 3-1

5620 Service Aware Manager (SAM) ............................................................................................................................... 3-1

9959 Network Performance Optimizer (NPO) .............................................................................................................. 3-3

9412 eNodeB .............................................................................................................................................................................. 3-5

Network Element Manager (NEM) .................................................................................................................................... 3-7

9958 Wireless Trace Analyzer (WTA) ............................................................................................................................. 3-7

Wireless Provisioning System (WPS) ............................................................................................................................... 3-7

4 LTE RAN OAM functions

Overview ...................................................................................................................................................................................... 4-1

Fault management ..................................................................................................................................................................... 4-1

Configuration management ................................................................................................................................................ 4-15

Performance management ................................................................................................................................................... 4-30

Security ...................................................................................................................................................................................... 4-47

Call Trace .................................................................................................................................................................................. 4-48

Self Optimizing Network (SON) ...................................................................................................................................... 4-49

Transport call admission control ....................................................................................................................................... 4-50

Overview ...................................................................................................................................................................................... 5-1

Synchronization ......................................................................................................................................................................... 5-1

Quality of Services (QoS) ...................................................................................................................................................... 5-3

Overview ..................................................................................................................................................................................... A-1

Initialisms ................................................................................................................................................................................... A-1

Acronyms .................................................................................................................................................................................... A-5

1-1 LTE interfaces ............................................................................................................................................................. 1-6

4-1 Fault types .................................................................................................................................................................... 4-2

4-2 State types .................................................................................................................................................................... 4-5

4-3 Alarm termination ..................................................................................................................................................... 4-8

4-4 AvailabilityStatus values and default states ................................................................................................... 4-19

4-5 Parent-child object .................................................................................................................................................. 4-20

4-6 eNodeB XML file naming convention ............................................................................................................ 4-43

1-1 LTE network components ..................................................................................................................................... 1-4

1-2 User-plane protocol stack ....................................................................................................................................... 1-8

1-3 Control plane protocol stack .................................................................................................................................. 1-9

2-1 LTE RAN interfaces ................................................................................................................................................. 2-2

2-2 S1 interface .................................................................................................................................................................. 2-3

2-3 X2 interface ................................................................................................................................................................. 2-4

2-4 LTE air interface ........................................................................................................................................................ 2-5

3-1 Standalone 5620 SAM system .............................................................................................................................. 3-2

3-2 9959 NPO with auxiliary server ........................................................................................................................... 3-4

3-4 9412 eNodeB architecture ...................................................................................................................................... 3-5

4-1 Configuration extract view .................................................................................................................................. 4-23

4-2 Configuration import view .................................................................................................................................. 4-23