TMO18416 - V5.1 SG (T) LA5.0 Ed1 PDF

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

Copyright 2012 Alcatel-Lucent. All Rights Reserved.
TERMS OF USE AND LEGAL NOTICE

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

(T)LA5.0 Introduction to RADIO QoS and Traffic Monitoring
1. 9400 LTE (T)LA5.0 Introduction to RADIO QoS and Traffic Monitoring
1. Introduction
2. Service Accessibility
3. Retainability
4. Mobility
5. Traffic Monitoring
6. Quality Monitoring
9400 LTE
(T)LA5.0 Introduction to RADIO QoS and Traffic Monitoring
Upon completion of this course, you should be able to:
Introduce the Alcatel-Lucent Monitoring tool for Wireless Standards
Describe the 3GPP metric families for LTE FDD and TDD
Explain counter and indicator metrics, and how to use these metrics
Classify the available LTE eNodeB metrics to monitor the KPI issues according to the following radio
features (accessibility, retainability, mobility, Traffic, radio Quality)
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:
TMO18416_V5.1-SG Edition 1.0
Thank you!

TMO18416_V5.1-SG-(T)LA5.0-Ed1.0 Module 1.1 Edition 5.1
Section 1 Module 1 Page 1
This page is left blank intentionally
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
5.0
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition
5.1
2013-01-05
Pascal SCANDOLO
Some Slides bug modification.



Page
1 Introduction To QoS Monitoring Tool
1.1 QoS rationals
1.2 Network Performance Optimizer
1.3 NPO Functionalities For LTE
2 Counters
2.1 Counters Definition
2.1.1 Counter Properties
2.1.2 Counters Aggregation Rules
2.1.3 Counters Aggregation Rules: Cumulative Counter
2.1.4 Counters Aggregation Rules: Value Counter
2.1.5 Counters Aggregation Rules: Load Counter
2.1.6 Counters Reference Id Types
2.2 Resource Object Hierarchy for LA5.0
2.3 Resource Object Hierarchy for TLA5.0
2.4 3GPP Counters Families
3 Indicators
3.1 Indicator Definition
3.1.1 Indicator Properties
3.1.2 Indicators- Methodology: Formula
3.1.3 EXERCISE on Indicator :
3.1.4 NPO Counters And Indicator summary
3.1.5 Release Independant Indicators Strategy
3.2 NPO Indicator Consolidation
4 Courseware Modules summary
4.1 Counter Family & Identifiers range
4.2 QoS (global indicators) Families for KPI metrics
5 Exercises
5.1 Counter calculation
5.2 Indicator Temporal Aggregation
5.3 Reminders: What is measured by the UE?

7
8
9
11
13
14
15
16
17
18
19
20
21
22
23
25
26
27
28
29
30
31
33
35
36
37
39
40
41
42


NPO will use the QoS Counter and Indicators build from both Alcatel-Lucent & Customer KPI metrics for an
optimized Quality follow-up.
QoE definition from KQI/KPI End User experience and metrics usage in not in the scope of this Courseware.

The Alcatel-Lucent MS-NPO tool will be introduce in a later Training Module (refer to ALUniv Course
Navigator - LTE Level3 - TMO18048 - 9959 NPO Standard Operations )

Filed proven NPO tool supports GSM, UMTS, Wimax and LTE Standards for High Definition QoS analysis.
Counter & Parameters (raw measurements) are collected from Network Nodes while Indicator metrics
are defined in NPO in order to define a common set of QoS basic materials for Network Analysis &
Optimization.
Counters and indicators are defined through dictionaries plugs. The introduction of new counters or
indicators is done through the delivery of new dictionaries.
NPO includes a powerful Oracle database containing collected performance measurements and
calculated Indicators. Based on them, the detection of QoS degradation is done much faster, NPO also
proposing the appropriate correction tasks and an improved logical configuration for the radio network,
even in multi-standard environments.
NPO add-on are available to refine QoS analysis

NPO-PCMD includes LTE PCMD flexible counter editor allowing counter design at
OAM level. NPO PCMD counter are computed at NPO level. It is possible to create a
new scalar counter on field that can be exported/imported (to allow sharing counter
definitions across teams).
NPO-NUART (Network Unavailability Analysis and Reporting Tool) for End To End
global performance analysis.

eNode B (eNB) is the base station in the LTE network. Its main functions are:
Radio resource management (Scheduling and associated QoS handling)
IP header compression and encrypting of user data stream
Selection of an MME at UE attachment
Routing of user plane data towards Serving Gateway (S-GW)
Measurement and measurement reporting configuration for mobility and scheduling
LTE counters are collected from eNodeB nodes via the 5620 SAM (1) and from MME nodes (2) (Per
IMSI investigation with PCMD data) as the basis to compute metrics (a metric can use only one given
counter).
Some of the counters defined hereafter are refined into screenings:
This break down into detailed causes allows having synthetic information to be used in metrics
computation, detailed one to be used for instance for troubleshooting analysis.
In addition, this avoids useless sum to be computed to get from nodes, for example the total number of
events monitored, and it makes possible to manage situation where additional use cases are introduced
(total value should always be correct even if screenings are missing).

The NPO QoS analysis process collects measurements from network elements.
Based on the collected raw measurements, NPO manages the linked indicators that are calculated/stored,
consolidated temporally/spatially for:
network monitoring and reporting
problem detection
troubleshooting (to drill-down from the high-level problem detected to the detailed root cause)
corrective action
This indicators database is ready to be used for Network planning & optimization.
Indeed, NPO provides a powerful dynamic graphical user interface (GUI) that eases QoS report analysis:
Special functions allow identification of the worst or best cells related to a QoS indicator,
Customized indicators/reports/ can be created,
Alerters can be trigged based on QoS indicators,
The counting module will count and report the number of records that match the selected counting
criterion. Users will be able to create, save, modify and use their counting criteria (within NPO PCMD
and CFT).
Network Stability & Availability can be reported (within NPO NUART)
Predefined Customization for GSM/ WCDMA/ WIMAX/ LTE Standards integrates:

Reference values for parameters,
Basic Rules and diagnosis,
Configured Events,
Parameters Configuration,
Cartographic display.


Note that the wording counter and measurement terms are being used in this document to identify the
same concept. Usually,
Alcatel-Lucent uses the term counter to distinguish a counter from a (radio) measurement. A
counter is periodically elaborated on periods expressed in minutes or hours, for example, 15 min.,
while a measurement is elaborated on periods expressed in milliseconds such as 500 ms.
The Alcatel-Lucent defined counter families are not the same as the 3GPP measurement families
defined in 3GPP TS 32.425.
For counters specific to Alcatel-Lucent, the counter name (referred to as 3GPP Name) starts
with the prefix "VS". For example, VS.IncomingInterENodeBS1HOFailure.CACFailure.
3GPP Performance Management specifications preferably uses measurement. When the
context refers to 3GPP specifications, measurement is used, while counter is used in Alcatel-Lucent
specific part, but both wordings are equivalent.
For counters defined in 3GPP TS 32.425, the counter name (referred to as 3GPP Name) is
compliant to this specification and starts with a prefix corresponding to the 3GPP measurement
family. For example, S1SIG.ConnEstabAtt.
For each counter, description contains (see after):

Counter attributes (3GPP name, counter type, location),
Counter definition (triggering event),
Counters is gathered through families.
Data Flow Diagram to highlight counter peg (DFD is in some cases
shared by all counters from the same family).

Each Counter Window Head contains the counter name followed by the Counter Information:
Counter Code: This section contains the counter code.
Counter Type: This section contains the counter field, which is used to identify the counter type such as
cumulative, load and value in the result files.
Triggering Event: This section contains the condition that causes the measurement result data :
The condition is defined by identifying protocol related triggering events that either starts or stops the
measurement processes or by updating the current measurement result value. When a precise
condition cannot be provided, the conditional circumstances behind the update is stated.
Subcounter: This section contains a description of expected result values (e.g. single integer or screened
measurements with criteria if any).
Subfamily: This section states the Subfamily that the counter belongs to. (refer also to the Subfamily
grouping in NPO)
3GPP Name: The statement is "3GPP specified counter" if the Alcatel-Lucent implementation is fully
compliant with the 3GPP specification or "Alcatel-Lucent specified counter" if the counter is not
considered by the 3GPP specification. (thenVS stands for Vendor Specific)
Object Class: This section contains the object class and its instance. The measObjInstId field identifies
the measured object class and its instance.
Range: This section contains the counter range.
Unit: This section contains the counter unit.
Available Release : This section states the Alcatel-Lucent LTE RAN system releases in which the counter
is introduced.
Other sections are available such as Report Group, Notes and so.

Each GP (Granularity Period), NPO will process the PM XML files retrieved from the O&M server (SAM).
NPO has a predefined mapping of the counters (and associated reference identity) that must be
present in the PM XML file for the corresponding release.

Cumulative counters provide raw counts.

A Cumulative counter is a CUM (CC) type counter, as identified in 3GPP TS 32.104 specifications.
It captures the measurement data from the occurrences of a given type of event detected during the
granularity period (GP) .
It offers the means of counting measurement data related to predefined events. It is incremented by one
each time the counted Event occurs, and it generates the cumulative value.
One NE cumulative counter provides one counter at the OAM GUI level.

Each event provides a value that is added to the cumulated value. The average corresponds to the
cumulated value divided by the number of events and is not reported by the eNodeB but computed at the
NPO level.
A VALUE counter captures measurement data from the occurrences of a given type of event detected
during the granularity period. A measurement is extracted from each occurrence of the event. The
individual measurement is contributed towards the summary counter for the corresponding granularity
period.
Alcatel-Lucent provides the following values:

Cumulated value (.Cum in XML files),
Number of events (.NbEvt in XML files)
Maximum added value (.Max in XML files),
Minimum added value (.Min in XML files)

1. Load counter with periodic sampling (SI status inspection), is derived from samplings of a specified
measurement, taken at regular intervals during the granularity period. That is, the individual samplings
contribute toward the summary counter for the corresponding granularity period. The summary counter
is useful to analyze the averages, trends, or cycles. Load counters with periodic sampling are also known
as status inspection. Load counters with periodic sampling provides the minimum, maximum and
average values. This counter type is based on a self-generated sampling method at a defined tempo.
This counter offers the means of getting rapidly changing data.
2. Load counter with sampling on event occurrence, is a specified measurement done without sampling at
regular intervals, but with sampling triggered by predefined events occurring during the granularity
period. Each individual sampling contributes toward the summary counter for the corresponding
granularity period. The summary counter is useful to analyze the averages, trends, or cycles. This a
second type of load counter which does not refer to status inspection as defined in the standard.
However, both types of load counters, report same values and apply the same algorithm to calculate
these values. The average value is not reported by the eNodeB but computed at the NPO level.
Alcatel-Lucent provides the following values:

Cumulated value (.Cum in XML files),
Number of samplings (.NbEvt in XML files)
Maximum sampled value (.Max in XML files),
Minimum sampled value (.Min in XML files)
NOTE:
NPO application doesnt support the . so for all the counter names the . is automatically replaced by _.
Therefore, The NPO counters are displayed with _ instead of . on NPO AD(Analysis Desktop), you can
display the counters for a corresponding object. For that, you have to select the object then select the tab
Counter.
The display is done by family/subfamily (refer to the counter definition for a better understanding).

To ease the Counter filtering, there are reported on Objects container Resources that are located according
to a container hierarchy.
The resource objects are defined as a subset of the managed objects of eNodeB native Management
Information Model (MIM).
This model is used in the 5620 Service Aware Manager (SAM) interface with eNodeB for
Configuration Management (CM).
In the Performance Monitoring object model (PM), each object class has a unique set of defined
counters supported by each and every instance of the class. It presents a subset of the eNodeB MIM.
The figure depicts a potential future Measured Object containment tree of the eUTRAN FDD releases.
The following Measured Objects have PM Counters defined in Release LA5.0:
ENBEquipment object, CpriRadioEquipment object, LteCell object, MbmsBearerService object, X2Access
(X2Interface) object, MmeAccess (S1CInterface) object, CellPLMN object, Vlan object,
TransportCosConfPerPort object and TransportCosConf object.

The figure depicts a potential future Measured Object containment tree of the eUTRAN TDD releases.
The following Measured Objects have counters defined in Release TLA5.0:
CpriRadioEquipment object, LteCell object, MbmsBearerService object, X2Access object, MmeAccess
object, CellPLMN object, VLAN object, PortShaperQueue object and VLANShaperQueue object.

To ease the Counter retrieval, counters are grouped into counter families:
A counter family is attached to a given LTE feature.
For example, the UE Context Management family groups all the counters involved with UE Context
Management (set up, modification, deletion & release).
The Alcatel-Lucent defined counter families are not the same naming as the 3GPP measurement families
defined in 3GPP TS 32.425.
Counters specific to Alcatel-Lucent (referred to as 3GPP Name) starts with the prefix "VS for Vendor
Specific.
For example: VS.IncomingInterENodeBS1HOFailure.CACFailure.
Refer to eNodeB customer documentation:

FDD Counters Reference Guide 9YZ-03990-0105-RKZZA
TDD Counters Reference Guide 9YZ-04619-0105-RKZZA



When a new counter or basic indicator is introduced, NPO database is automatically updated without
intervention of the design Team.
The introduction of a new calculated indicator has no impact on the NPO database schema.
Alcatel-Lucent NPO also allows users to create their own

indicators using counters and indicators delivered through
dictionaries.

Theses Indicators Properties and the root Counter Properties will be displayed via the Alcatel-Lucent
9959 NPO Analysis Desktop GUI (Properties).

A basic or stored indicator contains a multi-release counter formula. This has the major advantage that
underlying calculated indicators are release independant, and therefore remain valid from release to release
upgrade.
Calculated indicator is a MIX , it means a formula of calculated and/or basic indicators.

This VS_UE_ctxt_modif_eNB_setup_fail Indicator (L12511_20_CI) has a formula based on other

indicators ...
CI : for Cell Indicator

NPO performes a Temporal aggregation every Night (or manual)


Customer can use this Indicators set to define robust Release Independent KPI metrics.

NPO Indicators are spatially aggregated into both the existing ObjectZones (such as a CellZone) and the
global eUTRAN managed network.
In a second step, Temporal aggregation computes the indicator values at Hourly / Daily / Weekly /
Monthly periods.
NOTES:
Basic indicator defines also how the indicator will be aggregated in the temporal and spatial dimensions:
As EXAMPLE for a calculated indicator f=a/b at cell and 15min level, NPO knows automatically how to
compute it at RNC and 2h GP levels as f= a / b.



(*) The following families are Not included in this courseware overview:
- IP Transport, Interface Management, eNodeB Synchronization, S1-c Ippa Traffic.
On NPO,
One Indicator can be associate in two different family /subFamily/subsub...
It allows to define filtering groups, such as main indicators group for customer
KPI purpose or special traffic services follow up.
KPI family example:
FAMILY: QoS (global indicators)

SUBFAMILY: Inter Operability
SUBSUBFAMILY: Network performance

Reminders :
Indicators can be on different families in order to allow filtering for reporting design
or identify / tag some key indicators that will be focused on QoS monitoring.
NPO tool can define extra Family/SubFamily/SubSubFamily to stick to specific
customer KPI definitions based on Indicators.




Same measurements in RRC_Connected mode as in RRC Idle mode


3GPP
AAC
AAR
A-CQI
AF
ALG
AMBR
AMR
WB
API
APN
ARP
AVP
BBERF
BCCH
BCH
BO
CBR
CCA
CCCH
CCE
CCO
CCR
CDMA
CIF
CNG
CODEC
CQI
CS
CSFB
CSoPS
D-BCH
DCCH
DL
DLS
DL-SCH
DPI
DSCP
DTCH
DTX
E2E
E-MCTA
EPC
E-RAB
E-UTRAN
EVRC
FPS
FR
FSS
FW
GBR
3rd Generation Partnership Project

Advanced Audio Codec
Authorization-Application-Request
Aperiodic - Channel Quality Indicator
Application Function
Application Layer Gateway
Aggregate Maximum Bit Rate
Adaptive Multi Rate WideBand
Application Programming Interface
Access Point Name
Allocation and Retention Priority
Attribute Value Pair
Binding Bearer and Event Reporting
Function
Broadcast Control CHannel
Broadcast Channel
Buffer Occupancy
Constant Bit Rate
Credit-Control-Answer
Common Control Channel
Control Channel Element
Cell Change Order
Credit-Control-Request
Code Division Multiple Access
Common Intermediate Format
Comfort Noise Generator
Coder/Decoder
Channel Quality Indicator
Circuit Switched
Circuit-Switched FallBack
Circuit Switch over Packet Switch
Dynamic Broadcast Channel
Dedicated Control Channel
DownLink
DownLink Scheduler
DownLink Synchronization CHannel
Deep Packet Inspection
Differentiated Code Point
Dedicated Traffic Channel
Discontinuous Transmission
End-to-End
Enhanced-Multi Carrier Traffic
Allocation
Enhanced Packet Core
Evolved Radio Access Bearer
Evolved UMTS Terrestrial Radio Access
Network
Enhanced Variable Rate Codec
Frames per Second
Full-Rate
Frequency Selective Scheduling
Firmware
Guaranteed Bit Rate
GERAN
GGSN
GOP
GPRS
GRE
GSM
GTP
GTP-C
GTP-U
GUMMEI
GUTI
GW
HARQ
HAS
HD
HPLMN
HR
HRPD
HSGW
HSS
HW
IE
IETF
IGMP
IMS
IMSI
IP
IP-CAN
IPv4
IPv6
ISR
ITU
IWF
KPI
LBI
LTE
MAC
MBR
MCS
MGCP
MIMO
MIP
MME
MNC
MOS
MSC
MSS
MT
NACC
GSM EDGE Radio Access Network

Gateway GPRS Support Node
Group of Pictures
General Packet Radio Service
Generic Routing Encapsulation
Global System for Mobile
Communications
GPRS Tunneling Protocol
GTP Control
GTP User
Global Unique MME Identity
Global Unique Temporary Identity
Gateway
Hybrid Automatic Repeat Request
HTTP Adaptive Streaming
High Definition
Home Public Land Mobile Network
Half-Rate
High Rate Packet Data
HRPD Serving Gateway
Home Subscriber server
Hardware
Information Element
Internet Engineering Task Force
Internet Group Management Protocol
IP Multimedia Subsystem
International Mobile Subscriber
Identity
Internet Protocol
IP Connectivity Access Network
Internet Protocol version 4
Internet Protocol version 6
Idle state Signaling Reduction
International Telecommunications
Union
InterWorking Function
Key Performance Indicators
Linked EPS Bearer ID
Long Term Evolution
Medium Access Control
Maximum Bit Rate
Mobile Coding Scheme
Media Gateway Control Protocol
(MGCP)
Multiple Inputs, Multiple Outputs
Mobile Internet Protocol
Mobility Management Entity
Mobile Network Code
Mean Opinion Score
Mobile Switching Center
ALU Multimedia Streaming Server
Mobile Terminating
Network Assisted Cell Change

NAI
NAS
NAT
O&M
OCS
OFCS
OSD
P CQI
P GW
PBCH
PCC
PCC
PCEF
PCRF
PDCCH
PDF
PDN
PESQ
P-GW
PHB
PLMN
PMIP
PoE
PRB
PSHO
PSQM
PTZ
PUCCH
PUSCH
pvNS
QCI
QCIF
QoS
QVGA
RAB
RACH
RADIUS
RAN
RAT
RAU
RB
RIM
RM
RNC
RR
RRC
RSSI
RTCP
RTP
Network Access Identifier

Non-Access-Stratum
Network Address Translation
Operations and Maintenance
Online Charging System
Offline Charging System
On Screen Display
Periodic Channel Quality Indicator
Packet Data Network Gateway

Physical Broadcast CHannel
Policy and Charging Control
PC Communicator
Policy & Charging Enforcement
Function
Policy and Charging Rules Function
Physical Downlink Control CHannel
Policy Decision Function
Packet/Public Data Network
Perceptual Evaluation of Speech
Quality
Packet Gateway
Per-Hop-Behavior
Public Land Mobile Network
Proxy Mobile IP
Power over Ethernet
Physical Resource Block
Packet Switched HandOver
Perceptual Speech Quality Measure
Pan, Tilt, Zoom
Physical Uplink Control CHannel
Physical Uplink Shared CHannel
Packet Video Network Streamer, old
product name of MSS
QoS Class Identifier
Quarter CIF: 176x144 pixels
Quality Of Service
Quarter VGA: 320x240 pixels
Radio Access Bearer
Random Access Channel
Remote Authentication Dial Up User
Service
Radio Access Network (BSS or
UTRAN)
Radio Access Technology
Routing Area Update
Resource Block / Radio Bearer
RAN Information Management
Real Media
Radio Network Controller
Resource Request
Radio Resource Control
Received Signal Strength Indication
Real Time Control Protocol
Real-Time Transport Protocol
RTSP
SAE
SBC
SD
SGSN
S-GW
SGWCI
SIM
SINR
SIP
SNR
SPR
SRB
STUN
SW
TA
TAC
TAI
TAU
TCP
TE
TEID
TFT
ToD
TTI
UDP
UE
UL
ULI
UMTS
URI
UTRAN
VBR
VGA
VoD
VoIMS
VoIP
VoLGA
VOLTE
VPLMN
VT
W-CDMA
WiMAX
WMV
Real Time Streaming Protocol

System Architecture Evolution
Session Border Controller
Standard Definition
Serving GPRS Support Node
Serving Gateway
Serving Gateway Change Indication
Subscriber Identity Module
Signal to Interference-plus-Noise
Ratio
Session Initial Protocol
Signal to Noise Ratio
Subscriber Policy Repository
Signaling Radio Bearer
Simple Traversal of UDP through
NATs (Network Address Translation)
Software
Tracking Area
Tracking Area Code
Tracking Area Identity
Tracking Area Update
Transport Control Protocol
Terminal Equipment
Tunnel Endpoint Identifier
Traffic Flow Template
Time of Day
Transmission Time Interval
User Datagram Protocol
User Equipment
UpLink
User Location Information
Universal Mobile
Telecommunications System
Uniform Resource Identifier
UMTS Terrestrial Radio Access
Network
Variable Bit Rate
Video Graphics Array (resolution):
640x480 pixels
Video on Demand
Voice over IMS
Voice over Internet Protocol
Voice over LTE via Generic Access
Voice Over LTE
Visited Public Land Mobile Network
Video Telephony
Wideband-Code Division Multiple
Access
Worldwide Interoperability for
Microwave Access
Windows Media Video



TMO18416_V5.1-SG-(T)LA5.0-Ed1.0 Module 1.2 Edition 5
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
05
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition



Page
1 Service Setup Scenarios
1.1 UE Initiated Service Request In Idle Mode
1.2 Dedicated Bearer Activation in RRC Active Mode
2 RRC Connection Monitoring
2.1 RRC Connection Establishment counters
2.1.1 RRC Connection Setup Success Rate indicators
2.2 RRC Connection Failure - CAC failure indicators
2.3 RRC Connection Failure: Timeout UE indicators
2.4 RRC Connection Failure: OAM intervention indicators
2.5 RRC Connection Failure: MME overload indicators
2.6 INDICATOR: RRC Connection Failure Rate per cause
2.7 RRC Connection Release due to MME Overload indicators
2.8 RRC Cnx Release Due To Inability To Preempt indicators
2.9 indicator: Cell Inactivity
3 S1AP Connection Establishment Monitoring
3.1 S1AP Cnx Establishment success
3.2 S1AP Connection Establishment Failure
3.3 INDICATOR: S1AP Cnx Establishment Success Rate
4 UE Context Setup Monitoring
4.1 UE Context Setup Success
4.2 indicator: UE Context Setup Success Rate
4.3 indicator: Global Network Accessibility Success Rate
4.4 UE Context Setup For CSFB
4.5 Initial Context Setup Failed
4.6 indicator: UE Context Setup Fail CAC Rate
5 Initial & Dedicated eRAB Set up Monitoring
5.1 Initial E-RAB Set Up success
5.2 Additional E-RAB Setup Success
5.3 indicator: Global Service Accessibility Success Rate
5.4 E-RAB Setup Failure
5.5 indicator: E-RAB All Setup Success Rate
5.6 E-RAB Modify procedures
5.7 INDICATOR: E-RAB All modify Success Rate
5.8 EXERCISE: E-RAB partial failure

7
8
9
11
12
13
14
15
16
17
18
19
20
21
23
24
26
27
29
30
32
33
34
36
42
43
44
45
46
47
50
51
54
56


To initiate the service, the terminal sends a Service Request NAS message to the MME using the Random
Access procedure. On the S1 interface, for the transmission between the eNodeB and the MME, this
message is encapsulated in the Initial UE Message. The Service Request message contains the users
temporary identity (or S-TMSI) as well as an indication about the requested service type (like data or
answer to a paging message).
When needed, the NAS authentication procedure takes place, based on the AKA procedure. Once the AKA
procedure is performed, the terminal and the MME are mutually authenticated and share a common (and
secret) session key system. The MME can therefore possibly set up or change NAS signaling integrity and
ciphering protection, using the NAS security Mode Command message. The KSIASME parameter identifies
the set of NAS keys to be used for those algorithms.
Once the NAS security is effective, the MME performs the Initial Context Setup procedure, which aims at
creating the EPS bearer(s) and terminal context within the eNodeB. In addition, this procedure also aims at
establishing the necessary resources on the Radio and S1 interface bearers. On this occasion, the Initial
Context Setup message contains NAS elements such as the Quality of Service attributes associated to the
EPS bearer(s) as well as integrity and ciphering algorithms chosen by the MME and KeNB* the set of keys
which will be used by the eNodeB at the PDCP level for integrity and encryption. Access Network-level
security is started as part of the Radio Bearer (RB) establishment procedure.
At the end of the this procedure, all the bearers (including the default EPS bearer and possibly other
Dedicated Bearers) which were active between the network and the terminal before the last transition to
IDLE mode are available and usable again.

The Dedicated Bearer activation procedure is used when the terminal or the network is activating a new
application service while in ACTIVE mode. Therefore, to activate a new bearer in this condition, there is no
need to set up a RRC connection or perform the AKA process.



RRC Connection Request includes the S-TMSI and the establishment cause. If accepted (radio resource
available in eNodeB), the eNodeB returns RRC Connection Setup including the initial radio resource
configuration with SRB1.
RRC Connection Setup Complete includes the NAS message (Service Request, Initial attachment, Tracking
Area Update, etc) to be transferred to the MME.
This NAS message triggers the establishment of the S1 connection, which normally initiates a subsequent
step during which E-UTRAN activates AS-security (integrity protection and ciphering) and establishes (RRC
Connection Reconfiguration message) SRB2 and one or more DRBs (corresponding to the default bearer
and optionally dedicated EPS bearers).

The screening of the VS_RRC_cnx_req message is related to the establishment cause:

Screening 0: emergency
Screening 1: highPriorityAccess
Screening 2: mt-Access (Page Response received)
Screening 3: mo-Signalling (mobile originated signalling)
Screening 4: mo-Data (mobile originated user bearer)
Screening 5: other (spare values in the 3GPP)
VS_RRC_cnx_req is the stored indicator L12301_00_SI (=L12311_0 + + L12311_5)





Screening 0: Rejection from the eUTRAN due to CAC failure (Maximum number of call of the eNodeB
exceeded, Maximum number of call per modem,...).
Screening 1: Failure due to RrcConnectionSetupComplete supervision timer expiration (message not
received from the UE).
Screening 2: All MMEs accesses are disabled and the cell is not barred.
Screening 3: Loss of the cell service due to customer OAM intervention barring the cell.
Screening 4: Reception of RRC Connection Request with a provided MME in overload state and overload
action set to reject all RRC Connection establishment for non-emergency mobile originated data transfer
(RRC Connection Establishment cause moData).
action set to reject all RRC Connection establishment for signalling (RRC Connection Establishment cause
moData or moSignalling).
action set to only permit RRC connection establishments for emergency sessions and mobile terminated
session (only RRC Connection Establishment causes emergency and mtAccess are accepted, other
causes are rejected).

The VS_RRC_cnx_rel_[cause]_rate indicator (L12312_21_CI) provides provides the failure rate of

the RRC connection Release due to MME overload causes (0 to 2).
VS_RRC_cnx_rel_[cause]_rate = VS_RRC_cnx_rel_[cause] / VS_RRC_cnx_req


Refer to NPO users documentation for NPO QoS Alerters.



The SIAP establishment procedure should happen before any RRC connection because this is done once the
eNB is powered on.
S1 connection can be established either for signaling only handling (in case of attach procedure for
example), or to provide service to an end-user (voice, streaming, mail). In addition, it is possible that the
connection is established for signaling and then is reused for service providing (could be for instance attach
followed by VoIP call).
The connection is considered successfully established as soon as it ensures the initial UE demand is
fulfilled : this means that the first S1 message received from the MME answering UE Initial Message
makes the connection established.
LC12401 counter monitors the sending of INITIAL UE message to the MME, triggering the dedicated S1
connection establishment procedure.
LC12402 counter provides the number of DL NAS TRANSPORT messages (for instance AKA
authentication messages) received just after UE INITIAL MESSAGE has been sent (only the first received
message is counted).
Remark: In this dataflow case1, S1 connection is successfully established for common signaling only (no
Initial UE Context Setup procedure is started). It is possible that Initial UE Context Setup Request
message follows, but even if the associated procedure fails, S1 connection is considered successfully
established.

Screening 0:
Description
No DL NAS TRANSPORT message received before INITIAL CONTEXT

SETUP REQUEST.
3GPP Suffix
WithoutPreviousDLNASTransport
Screening 1:
Description
DL NAS TRANSPORT message received before INITIAL CONTEXT SETUP

REQUEST.
3GPP Suffix
AfterDLNASTransport

See also next section for the UE_CTX_setup failure cases during S1AP Connection Establishment Failure:
VS_UE_ctxt_setup_fail_InitialCtxtSetupFailure: L12502
VS_UE_ctxt_setup_fail_[cause]: L12503_x

This metric allows monitoring the S1 dedicated connection establishment procedure.

Refer also to VS_UE_ctxt_setup_fail_CAC_rate (L12503_21_CI) in UE_CTX_setup






It has to be noticed that E-RAB establishment procedure is not considered here because the scope of this
metric is only network accessibility.

The figure shows the case Mobile Terminating Call.

CS fallback is a function that moves UE from LTE network to a different RAT (UTRAN, GERAN, CDMA) that
supports CS voice service when a CS voice call needs to be setup. UE may request CS fallback when a voice
call is to be set up and when CS voice call is preferred.
CS fallback utilizes the existing inter-RAT procedures including PS handover to UTRA, Cell Change Order
(CCO) to GERAN and measurement based/blind redirection to UTRA or GERAN to move UE from LTE to
different RAT/carriers for CS voice calls.
CS fallback starts when MME receives an Extended Service Request from the UE requesting CS fallback.
CS fallback will be triggered when eNB receives CSFallbackIndicator in:
-
Intitial Context Setup Request message at call setup
UE Context Modification Request during a data call


-

LongName
VS_UE_ctxt_setup_fail_CAC
VS_UE_ctxt_setup_fail_InternalFail
VS_UE_ctxt_setup_fail_TimeoutUE
VS_UE_ctxt_setup_fail_reestab
VS_UE_ctxt_setup_fail_SecurityActivationFailure
VS_UE_ctxt_setup_fail_integrity
VS_UE_ctxt_setup_fail_ERABCtxtAllocation
VS_UE_ctxt_setup_fail_CSFBNotPossible

Reference
L12503_0
L12503_1
L12503_2
L12503_3
L12503_4
L12503_5
L12503_7
L12503_8





LongName
VS_UE_ctxt_setup_fail_CAC
VS_UE_ctxt_setup_fail_CSFBNotPossible_OD
VS_UE_ctxt_setup_fail_ERABCtxtAllocation_OD
VS_UE_ctxt_setup_fail_integrity_OD
VS_UE_ctxt_setup_fail_InternalFail_OD
VS_UE_ctxt_setup_fail_reestab_OD
VS_UE_ctxt_setup_fail_SecurityActivationFailure_OD
VS_UE_ctxt_setup_fail_SecurityAlgoNotCompatible_OD
VS_UE_ctxt_setup_fail_TimeoutUE_OD

Reference
L12503_0
L12503_1
L12503_2
L12503_3
L12503_4
L12503_5
L12503_6
L12503_7
L12503_8



VS_ERABs_all_setup_succ_rate counts the E-RAB initial setup + E-RAB additional setup successes (E-RAB
setup on intra LTE HO not counted)
See also VS_ERABs_all_IaLTE_setup_succ_rate . This indicator provides the success rate of Intra-LTE
E-RABs setup.
= VS_ERABs_all_IaLTE_setup_succ / VS_ERABs_all_IaLTE_setup_req
= L126a3_11_CI = L126a3_10_CI / L126a3_00_CI


CASE 4: differs from CASE 1 (VS_ERABs_proc_setup_fail_CAC: LC12603_0): This is not a CAC problem.


LC12604_(x-1)
LC12605_(x-1)
LC12606_(x-1)
LC12607_(x-1)
LC12610_(x-1)
LC12611_(x-1)
VS_ERABs_[QCIx]_initial_setup_req
VS_ERABs_[QCIx]_initial_setup_succ
VS_ERABs_[QCIx]_add_setup_req
VS_ERABs_[QCIx]_add_setup_succ
VS_ERABs_[QCIx]_IaLTE_HO_setup_req_tgt
VS_ERABs_[QCIx]_IaLTE_HO_setup_succ_tgt

Notes:
Two RRC connection reconfiguration are sent from the UE for E-RAB modify procedure


In Case 7:
If reconfiguration is not for intra-cell HO, or it is for intra-cell HO but short-MAC-I valid with old key:
Then E-RAB Modify Failed screening 5 counter is pegged, for each E-RAB in the E-RAB failed to
modify list.

See also available failure rates all (or per QCI) :

-VS_ERABs_all_modif_fail_rate (L12613_21_CI)
-VS_ERABs_all_modif_fail_CAC_rate (L12614_2_21_CI)






Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
05
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition



Page
1 Radio Link Failure Monitoring
1.1 Radio Link Failure detection
2 RRC Connection Release Monitoring
2.1 RRC Connection Release due to MME Overload
2.2 RRC Connection Release Due To Inability To Preempt
3 RRC Connection Reestablishment Monitoring
3.1 RRC Connection Re-Establishment Success
3.2 INDICATOR: RRC Conn. Re-Establishment Success rate
3.3 RRC Connection Re-Establishment Failed
3.4 Supervision Timer Expiry
3.5 Radio Link Failure
3.6 MAC-I Mismatch and OAM intervention
3.7 CAC failure and Integrity failure
3.8 INDICATOR: RRC Conn. Re-Establishment Failure rate
3.9 INDICATOR: RRC Reestablishment CAC Failure Rate
3.10 EXERCISE: RRC Connection
4 UE Context Release Monitoring
4.1 UE Context Release
4.2 INDICATOR: UE Ctxt Release By eNB
4.3 INDICATOR: UE Context Drop Rate
5 eRAB Release management Monitoring
5.1 Normal E-RAB Release
5.2 Abnormal E-RAB Release
5.3 E-RAB Release
5.4 INDICATOR: e-RAB Drop Rate (No Mobility)
5.5 INDICATOR: SAE ACCESS BEARER Drop Rates
5.6 EXERCISE: E-RAB monitoring

7
8
9
10
11
13
14
15
16
17
18
19
20
21
22
24
25
26
34
35
37
38
39
41
45
46
48


Counter L12305 provides the number of Radio Link failures detected by the eNodeB. Radio link failures
detected are not counted in case RRC
ConnectionReconfiguration (HO command) or RRCMobilityfromEUTRACommand has been previously
transmitted.
Trigger for L12306_x:
0 - Internal counter handling the number of RLC retransmissions for a given block has its value equal to
the maximum allowed value.
1 - Sounding Reference Signal SINR value computed by the eNodeB is below a configurable threshold,
indicating a loss of UL synchronization.






This procedure of RRC connection re-establishment is used in case of Radio Link failure detected in order to
re-establish the connection.

Re-establishment is successfully performed :

0: intra eNodeB handover procedure is ongoing
1: inter eNodeB over X2 handover procedure is ongoing
2: inter eNodeB over S1 handover procedure is ongoing
3: handover procedure is ongoing; the The cell on which the re-establishment is performed is not the
Target cell (of the HO procedure)
4: Re-establishment is successfully performed but there is no handover procedure ongoing when request
for re-establishment is received. The cell on which the re-establishment is requested is not the serving cell.
5: Re-establishment is successfully performed on serving cell and there is no handover procedure ongoing.
6: intra eNodeB inter-frequency handover procedure is ongoing. The cell on which the re-establishment is
requested is the Target cell.
7: inter eNodeB inter-frequency same frame structure (TDD or FDD) handover over X2 procedure is
ongoing. The cell on which the re-establishment is requested is the Target cell.
8: inter eNodeB inter-frequency same frame structure (TDD or FDD) handover over S1 procedure is
9: inter eNodeB inter-frequency other frame structure (TDD<>FDD) handover over X2 procedure is
10: inter eNodeB inter-frequency other frame (TDD<>FDD) structure handover over S1 procedure is
11: incoming PS handover from UTRAN procedure is ongoing. The cell on which the reestablishment is
requested is the target cell.




Short MAC-I= Message Authentication Code for Integrity

Integrity protection (at PDCP level) is realized by adding a field known as MAC-I to each RRC message
Recall:
A PDCP entity is associated with the Control Plane and the User Plane. Each radio bearer is associated with
one PDCP entity.
For the User Plane, PDCP ensures header compression/decompression of IP data flows (ROHC),
ciphering/deciphering of user data, in-sequence delivery of PDUs, buffering and forwarding PDU from
serving eNodeB to target eNodeB during HO, time-based discarding of SDUs in UL.
For the Control Plane, PDCP ensures ciphering/deciphering of control data, integrity protection and integrity
verification of control data, transfer of control data.
The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.
Integrity protection is provided by the field MAC-I (32 bits). At transmission, the value of MAC-I is
calculated based on keys provided by RRC layer, radio bearer ID, COUNT value and the direction of
transmission (COUNT is a 32bits counter, associated with a PDCP PDU, composed of HFN, Hyper Frame
Number, and PDCP Sequence Number; it is used for reordering the RLC packets). The receiver computes
the expected message authentication code per PDU using the same parameters and algos as the sender
and if it does not match MAC-I field, the PDCP PDU is discarded.


0: Re-establishment is successfully performed when intra eNodeB handover procedure is ongoing

1: Re-establishment is successfully performed when inter eNodeB over X2 handover procedure is
ongoing
2: Re-establishment is successfully performed when inter eNodeB over S1 handover procedure is
ongoing
3: Re-establishment is successfully performed when handover procedure is ongoing; the The cell on
which the re-establishment is performed is not the Target cell (of the HO procedure)
4: Re-establishment is successfully performed but there is no handover procedure ongoing when request
for re-establishment is received. The cell on which the re-establishment is requested is not the serving
cell.
5: Re-establishment is successfully performed on serving cell and there is no handover procedure
ongoing.
6: Re-establishment is successfully performed when intra eNodeB inter-frequency handover procedure is
7: Re-establishment is successfully performed when inter eNodeB inter-frequency same frame structure
(TDD or FDD) handover over X2 procedure is ongoing. The cell on which the re-establishment is
8: Re-establishment is successfully performed when inter eNodeB inter-frequency same frame structure
(TDD or FDD) handover over S1 procedure is ongoing. The cell on which the re-establishment is
9: Re-establishment is successfully performed when inter eNodeB inter-frequency other frame structure
(TDD<>FDD) handover over X2 procedure is ongoing. The cell on which the re-establishment is
10: Re-establishment is successfully performed when inter eNodeB inter-frequency other frame
(TDD<>FDD) structure handover over S1 procedure is ongoing. The cell on which the re-establishment
is requested is the Target cell.
11: Re-establishment is successfully performed when incoming PS handover from UTRAN procedure is
ongoing. The cell on which the reestablishment is requested is the target cell.



Refer also to VS_UE_ctxt_drop_rate_IaLTEorIrRAT for QoS Retainability indicators.











The denominator excludes the UE context released during context setup.

The numerator includes UE context released during setup procedure or after establishment.
The accuracy of the formula depends on the value of the success rate of the UE context setup (higher it is
better it is for the accuracy of the formula).



Counters dedicated to E-RAB management monitoring are E-RAB oriented counters: they are focused on
the number of E-RABs established/released and are then pegged as many times as the number of ERABs
considered.
As several E-RABs can be released through the same procedure, it is possible that several different
screenings are pegged at the same time (or one or several screenings can be pegged several times).
Note:
Neither normal E-RAB release counter nor abnormal E-RAB release counter are pegged
on outgoing intra-LTE handover and RRC Connection Re-Establishment procedures.
Consequently no link shall be done between the E-RAB setup counters and the E-RAB
release counter.







In order to avoid issues related to mobility (calls incoming on and outgoing from the cell), the indicator is
based on the releases of the E-RABs and not on the established E-RABs.

This is an example of one of the available metrics. Based on available Basic Counters.
AE ACCESS BEARER DROP RATE ALL QCIS (LA5.0 release)
This indicator provides the rate of E-RABs that have been dropped (associated to dropped calls). In order to
avoid issues related to mobility (calls incoming on and outgoing from the cell), the indicator is based on the
releases of the E-RABs and not on the established ERABs. Both E-RABs released through UE Context
Release procedure and the ones released through E-RAB Release procedure is considered.





Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
05
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition



Page
1 Common Mobility management
1.1 Mobility Scenarios
1.2 Evolved MTCA Overview
1.3 Off-loading Success / Failure
1.4 GAP-assisted HO COUNTERS and INDICATORS
1.5 GAP-Assisted HO: EXERCISE 1
2 Intra eNB Handover Mobility
2.1 Intra eNB Handover Principle
2.2 COUNTERS: Intra eNB Handover Success
2.3 INDICATOR: Out & In Intra eNB Mobility Success Rate
2.4 Intra eNB Handover Failures
2.5 Intra eNodeB Handover Abort cases
2.6 Counters: Troubleshooting List
2.7 Intra-eNodeB HandOver: EXERCISE 1
3 Inter eNB X2 Handover Mobility
3.1 Inter eNB-X2 Mobility principles
3.2 COUNTERS: Inter eNB-X2 Mobility with Success
3.3 INDICATOR: Out / In Inter-eNB X2 Mobility Success Rate
3.4 Inter eNB X2 Handover Failures
3.5 X2 HO Failure & Abort Counters List Source Cell
3.6 X2 HO Failure & Abort Counters List Target Cell
3.7 INDICATOR: HO interCell interENB X2 Mobility Fail Rate
3.8 Inter-eNodeB X2 HandOver: EXERCISE 1
4 Inter eNB S1 Handover Mobility
4.1 Inter eNB-S1 Mobility principles
4.2 Inter eNB-S1 Mobility steps
4.3 COUNTERS: Inter eNB S1 Handover with Success
4.4 INDICATOR: In & Out Inter eNB S1 HO Success Rate
4.5 Inter eNB S1 Handover Failure
4.6 Inter eNB S1 Handover Abort
4.7 S1 HO Failure Counters List - Src Cell
4.8 S1 HO Failure Counters List Target Cell
4.9 S1 Handover principles: EXERCISE 1
5 eRAB Setup During HO Mobility
5.1 Incoming E-RAB on Intra-LTE HO success
5.2 Incoming E-RAB To Be Setup On INTRA LTE HO
5.3 Incoming eRAB Setup On INTRA LTE HO
5.4 ERABs All IaLTE HO Setup Success Rate
5.5 Incoming Handovers Failure Rate
5.6 Intra-cell handover during e-RAB modify
5.7 E-RAB modify: exercise 1
6 LTE UTRAN Mobility
6.1 Outgoing LTE to UTRAN Mobility (Successful)
6.2 INDICATOR: LTE to UTRAN FDD PS Mobility Success Rate
6.3 Redirection To UTRAN With/Without Measurement
6.4 LTE to UTRAN Failure
6.5 INDICATORS for LTE to UTRAN FDD HO failure
6.6 Offload Redirection To UTRAN
6.7 LTE to UTRAN (FDD / TDD) Abort
6.8 UTRAN TDD to LTE PS HandOver
6.9 LTE - UTRAN mobility: exercise
7 LTE To GERAN Mobility
7.1 LTE to GERAN CCO principles
7.2 CCO to GERAN With/Out NACC Via Event B2/B1
7.3 INDICATORS: CCO To GERAN Success Rate

7
8
9
12
14
16
17
18
19
21
22
26
28
30
31
32
35
36
37
51
52
53
55
57
58
59
61
62
63
74
75
76
78
80
81
83
84
85
86
87
90
91
92
94
95
97
102
103
104
105
107
109
110
112
115
Page
7.4 CCO to GERAN Via Event B2/B1: Failure Case
7.5 Redirection To GERAN With Measurement
7.6 Redirection To GERAN Without Measurement
7.7 Offload Redirection To GERAN
7.8 LTE to GERAN: exercise 1
8 LTE to HDRP Mobility
8.1 LTE to HDRP mobility Redirection
9 Circuit Switch Fall Back Mobility
9.1 CSFB initiation by UE
9.2 CSFB Outgoing LTE to UTRAN Mobility (Successful case)
9.3 CSFB For Emergency Call Redirection To UTRAN
9.4 CSFB to UTRAN via Redirection Success
9.5 CSFB Redirection To GERAN
9.6 CSFB For Emergency Call Redirection To GERAN
9.7 CSFB CCO To GERAN Failure: RRC Reestablishment
9.8 CSFB CCO To GERAN Failure: Mobility From EUTRA CCO
9.9 CSFB To 1xRTT: Regular/Emergency Call Redirection
9.10 CSFallback procedure scope: exercise 1
9.11 CSFallBack requirements: exercise 2
10 Radio Link Failure during HO
10.1 RLF: Intra-ENB HO toWrongCell
10.2 RLF: Inter-ENB INTRA-FREQ. HO
10.3 RLF: Inter-ENB HO toWrongCell
10.4 RLF: Inter-ENB INTRA-FREQ. HO tooEarly
11 Detection Counters
11.1 Reported Cell Not Selected
12 Global Mobility Success
12.1 INDICATORS: In & Out Global Handover Success Rate

116
117
118
119
121
123
124
129
130
132
133
134
135
136
137
138
139
141
142
143
144
146
147
149
151
152
153
154

In order to limit the number of counters reported by the eNodeB, it was chosen not to define mobility
counters per couple of cells, but per single cell. Counters and associated metrics are then provided from
source cell point of view for outgoing mobility and from target cell point of view for incoming ones.
Mobility Restrictions
LTE/CDMA & CDMA/LTE Handover is not available in LA/TLA5.0. Still, ENHANCED NON-OPTIMIZED LTETO-HRPD INTER-RAT MOBILITY is possible since LA3.0.

Reminders:
Introduced in LA3.0, eMTCA is a proprietary Alcatel-Lucent mobility management framework on the eNB. It is used
for allocating the traffic efficiently for LTE sessions across multiple RAT and multiple LTE RF carriers based on
enhanced triggers.
eMTCA supports the mobility management of inter-frequency LTE neighboring carriers, inter RAT GERAN neighboring
carriers, inter-RAT UTRAN neighboring carriers, and inter RAT CDMA 2000 HRPD neighboring carriers.
eMTCA is invoked only in the RRC-connected mode.
The eMTCA algorithm is design to support the following criterias:
In LA3.0, eMTCA can be invoked either by serving radio monitoring via RRC Measurement, or CSFB via CSFB
indicator from the MME.
In LA4.0 is the service based carrier allocation.
In (T)LA5.0 is the load based carrier allocation.


The OffLoad algorithm is design as followed :

In LA4.0, OffLoad is design on service based criteria with trigs in reactive load mode only.
In (T)LA5.0, OffLoad is design on load based criteria with reactive and preventive load modes.

These counters provide the number of times an off-loading mobility of a call is successful, i.e UE leaves the
congested cell or the congested band or the congested eNodeB upon:
- completion of an inter-frequency or inter-RAT mobility procedure triggered for off-loading reason
- CSFB completion
- intra-frequency mobility triggered for radio reason
- UE context release.
Preventive offloading is on LTE (intra or interfreq) while reactive is on LTE and inter-RAT.

This counter provides the number of times an off-loading mobility of a call failed, i.e UE doesnt leave the
congested cell or the congested band or the congested eNodeB. The reasons may be: off-load
not started due to MIM, UE capabilities reasons, off-laod timer timeout, handover preparation failure (S1,
X2), handover preparation with partial failure, Interrupting procedure does not move the UE or doesnt
respect the congestion level.
This counter provides the number of times an off-loading mobility of a call failed, that is, UE doesnt leave
the congested cell or the congested band or the congested eNodeB. The reasons may be: off-load not
started due to MIM, UE capabilities reasons, off-laod timer timeout, handover preparation failure (S1, X2),
handover preparation with partial failure, Interrupting procedure does not move the UE or doesnt respect
the congestion level.

Reminders:
During RRC_CONNECTED mode, if the eNodeB decides that the UE needs to perform LTE inter-frequency
and inter-RAT monitoring activities, it will provide the UE with a measurement configuration which includes
a monitoring gap pattern sequence. During the monitoring gaps, UE reception and transmission activities
with the serving cell are interrupted. The main reason for using monitoring gap patterns is because the vast
majority of UEs are single receiver and can not therefore monitor two RATs simultaneously. Even if a UE
has multiple receivers to perform inter-RAT monitoring activity (e.g. one LTE receiver, one UMTS receiver
and one GSM receiver) there are some band configurations for which monitoring gaps are still required in
the uplink direction. LTE monitoring gap patterns contain gaps every N LTE frames (i.e. the gap periodicity
is a multiple of 10 ms) and these gaps have a 6 ms duration (3GPP standards).
A single monitoring gap pattern is used to monitor all possible RATs (inter-frequency LTE FDD and TDD,
UMTS FDD, GSM, TD-SCDMA, CDMA2000 1x and CDMA2000 HRPD).




An outgoing intra-eNodeB inter-PLMN handover procedure can be attempted from the cell when the
HANDOVER REQUEST message is sent to the target cell and the target PLMN is not the source PLMN
(different PLMN id).

RELATED INDICATORS
VS_HO_IrC_eNB_req_src this indicator provides the number of times that an intra-eNodeB
handover procedure is attempted from the source cell. L12745
VS_HO_IrC_eNB_req_tgt This indicator provides the number of times that an intra-eNodeB
handover procedure is attempted towards the target cell. L12702
VS_HO_IrF_IrC_eNB_IaFDDorIaTDD req_src This indicator provides the number of times an
inter-frequency intra-eNodeB handover procedure is attempted from the source cell. L12845_0
VS_HO_IrF_IrC_eNB_IaFDDorIaTDD_req_tgt This indicator provides the number of times an
inter-frequency intra-eNodeB handover procedure is attempted towards the target cell. L12802_0

RELATED INDICATORS
VS_HO_IrF_IrC_eNB_IaFDDorIaTDD_succ_src indicator provides the number of times an inter-frequency
intra-eNodeB handover procedure is successfully performed from the source cell. L12846_0
VS_HO_IrF_IrC_eNB_IaFDDorIaTDD_succ_tgt this indicator provides the number of times an interfrequency intra-eNodeB handover procedure is successfully performed towards the target cell. L12803_0




The RRC Connection Reestablishment is done on the serving cell (screen. 3) or on the target cell (screen.4)
or on another cell (screen.6).

For the Control Plane, PDCP ensures integrity protection and integrity verification of the control data


Event A1: The serving cell radio link quality becomes better than an absolute threshold
Event A1 is LTE technology specific (a measurement is triggered whenever there is a significant change in
radio quality going better). Example in multicell network: UE is moving toward an eNodeB in a direction
such that it is closer to the inter-sector boundary. In this case, even though the serving cell radio link
quality improves over time as the UE transitions the inter-sector boundary, the neighboring sector becomes
a candidate for handover.





An outgoing inter-eNodeB inter-PLMN X2 handover procedure can be attempted from the cell when the
HANDOVER REQUEST message is
sent to the target eNodeB and the target PLMN is not the source PLMN.



UTRAN FDD or TDD counters

Outgoing and Incoming Handover is pegged on the resp. Source and Target cell with more detailled
reporting counters pegged on the Target Cell.
Where:
VS.OutgoingInterENodeBX2HOSuccess is the number of outgoing X2handovers successfully performed
VS.OutgoingInterENodeBX2HOAttempt is the number of outgoing X2handovers attempts
VS.IncomingInterENodeBX2HOSuccess is the number of incoming X2 handovers successfully performed
VS.IncomingInterENodeBX2HOAttempt is the number of incoming X2 handovers attempts
VS.RrcConnectionReestablishmentSuccess.OnTargetCellDuringInterENodeBX2HO is the number of RRC
Connection Re-establishment successfully performed on the target cell during an Inter-eNodeB X2
handover.

This Data Flow Diagram does not include the followed Abort case 1 to 5:
1)
Abort Case 1 : Reception of S1AP Reset from the MME on source eNodeB
2)
Abort Case 2 : Reception of S1AP UE Context Release Command on source eNodeB
3)
Abort Case 3 : Reception of X2AP Handover Cancel from the source eNodeB on target eNodeB
4)
Abort Case 4 : Reception of X2AP Reset from the source eNodeB on target eNodeB
5)
Abort Case 5 : No VoIP admission by target cell
The following conuters are pegged according to the above Abort Case number behavior:
Total Outgoing inter-eNodeB X2 handover abort counter
Ingoing Inter-eNodeB handover abort (screen 0 or 1) counter
Total Inter-eNodeB handover abort counter



See also Radio link Failure counters.

=> X2 Handover Cancel may not be sent then LC12735_0 is not pegged !

The serving eNodeB is waiting for the message Release Resource coming from the target eNodeB (after
serving eNodeB has started X2 Release timer)
The target eNodeB increments counter L12310_5 (RRC connection reestablishment failure due to RLF)
The RRC reestablishment can also be done on the serving cell (screenings 4/10 for incoming HO) or on
another cell (6/12)

The serving eNodeB is waiting for the message Release Resource coming from the target eNodeB (after
serving eNodeB has started X2 Release timer)
The target eNodeB increments counter L12310_5 (RRC connection reestablishment failure due to RLF)
another cell (6/12)









Note: RRC Connection Reestablishment on any cell of the source eNodeB is considered as an handover
failure even if there is no call drop.
The LC12732 counter monitors outgoing inter-eNodeB X2 intra-frequency and inter-frequency handover
procedures from the cell that aborted. It provides only total number of aborts. It refers to screenings
associated counter 12733 (S1AP UE Context Release Command received from the MME, Reception of
RrcMeasurementReport (measId configured for mobility trigger) triggering a cascaded handover during
Inter-EnodeB outgoing X2 handover procedure, decision to perform a CS fallback, no voIP bearer admission
by target cell, S1AP Reset received from the MME or S1AP Reset eNodeB initiated).
Remark: handover abort counters and handover failure counters are exclusive

LC12713 Counter reporting (associated to L12713 Basic Indicator) for X2 HO failure Preparation &
execution on Target Cell.
This counter monitors incoming inter-eNodeB X2 intra-frequency and inter-frequency handover procedures
to the cell that has been failed. It is screened per failure cause. The screened failure causes are not
exhaustive (for instance protocol errors).
Note: in case of Incoming Inter-eNodeB X2 Handover partial failure, the Incoming Inter eNodeB X2
Handover procedure is considered as successful, this counter is not pegged.
Note: RRC Connection Reestablishment on any cell of the target eNodeB is considered as an handover
Note: ABORT counter is triggered when there is any event that interrupts the handover.
handover abort counters and handover failure counters are exclusive.

SI: Stored Indicator





An outgoing inter-eNodeB inter-PLMN X2 handover procedure can be attempted from the cell when the
HANDOVER REQUEST message is
sent to the target eNodeB and the target PLMN is not the source PLMN.







See also Radio Link Failure Counters

another cell (screenings 7/16)




This is still a HO faillure case even if the connection is reestablished on the Source Cell !

This is still a HO faillure case even if the connection is reestablished on the Source Cell !




The LC12723 counter monitors outgoing inter-eNodeB S1 intra-frequency and inter-frequency handover
procedures from the cell that has been failed. It is screened per failure cause. The screened failure causes
are not exhaustive (for instance protocol errors).
Note: RRC Connection Reestablishment on any cell of the source eNodeB is considered as an handover
On S1 handover abort, refer to screenings associated to counter LC12737 for screening details (S1AP
UE Context Release Command received from the MME (with cause other than Successful Handover),
Reception of RrcMeasurementReport (measId configured for mobility trigger) triggering a cascaded
handover during Inter-EnodeB outgoing S1 handover procedure, decision to perform a CS fallback S1AP
Reset received from the MME, no VoIP bearer admission by targe or S1AP Reset eNodeB initiated).
Remark: handover abort counters and handover failure counters are exclusive.

Counter reporting for HO failure Preparation & execution on Target Cell.

Remark: handover abort counters and handover failure counters are exclusive.





Reminders: one reporting per ERAB of the ERAB list.






CASE 2: Intra-cell handover failure during E-RAB modify counter is pegged (LC12795).





These measurements are provided per cell in the UE Measurement Report:

RSCP: Reference Signal Code Power is for UMTS
RSRP: Reference Signal Received Power is for LTE
RSRQ: Reference Signal Received Quality is for LTE
EcN0 is the ratio of received signal on the ambiant noise (for UMTS)
OffLoad

These measurements are provided per cell in the UE Measurement Report:

OffLoad

The similar metrics is available for UTRAN TDD Mobility and SRVCC Mobility for FDD/TDD.



These measurements are provided per cell in the UE Measurement Report.


The restablishment can also be attempted on the other cell (screening 4)

Similar failure for SRVCC to UTRA FDD/TDD




These measurements are provided per cell in the UE Measurement Report.










LTE to GERAN mobility is done in LA3.0/TLA3.0 through CCO. The PS HO is not supported. The HO
Command is not sent by the MME (as for PS HO) but by the eNB during the CCO procedure.
NACC procedure is optional during CCO. The eNB retrieves the System Information broadcasted in each of
the neighbor GERAN cell through MME. The information will be included in Cell Change Order sent to UE
when it is released from eNB and directed to GERAN. This procedure is to speed up the UE call setup in
GERAN.
CCO is triggered by eNB receives event B2 Measurement (or B1 for CS fallback) report with measurement
purpose set to Mobility-Inter-RAT-to-GERAN. If CCO is activated in serving cell and supported by UE, CCO
procedure is launched, otherwise redirection to GERAN is triggered.
eNB sends Mobility From EUTRAN Command (carrierFreq, phyCellId, SysInfo) to UE and starts timer
tMobilityFromEutraCCO
If UE Context Release Command is received, CCO procedure is completed. Otherwise eNB sends a UE
Context Release Request to MME (eNB considers the UE to have lost radio coverage)

RIM procedure is used to retrieve the System Information of a GERAN neighbor cell to be included in the
Mobility From EUTRAN Command message of CCO procedure. It includes GERAN SysInfo transfer
initiation/update/stop/end procedures.













LA3.0/TLA3.0 supports both:

- LTE to HRPD blind redirection and
- event B2 measurement based HRPD redirection (see after)
Blind redirection is used if UE does not support event B2 or if measurement based is not available in the
eNB.

Measurement based redirection is more reliable than blind redirection because the target frequency has
been measured by the UE before the redirection.






-


supports CS voice service when a CS voice call needs to be setup.
UE may request CS fallback when a voice call is to be set up and when CS voice call is preferred.
-

TDD HO counters available since TLA5


L12780 counter is triggered:

- either on reception of RrcMeasurementReport message containing a UTRA FDD cell
-or during an ongoing PS Handover, on reception of S1AP UE CONTEXT MODIFICATION REQUEST, CS
Fallback Indicator = CS Fallback Required, Carrier (UTRAN) targeted for CSFB equal ongoing PS HO
target.
L12781 counter is triggered on reception of an S1AP UE Context Release Command message from the
MME with cause Successful handover, after triggering a PS Handover to UTRA FDD for CS Fallback
purposes.





This counter provides the number of redirections including CS fallback to 1xRTT technology that are
performed due to a bad signal measured by the UE in the serving cell.
This screening Counter is triggered when the eNode B sends RRC ConnectionRelease to the UE due to its
decision to perform CS fallback to 1xRTT. The eNodeB receives an S1AP Initial Context Setup Request or
S1AP UE Context Modification Request containing the CsFallbackIndicator IE. Choice of 1xRTT as the target
technology for CS fallback is driven by feature activation. This screening is both regular and emergency CS
Fallback triggered.
This screening Counter is triggered when the eNode B ends RRC ConnectionRelease to the UE due to its
decision to perform the CS fallback to 1xRTT for emergency call. The eNodeB receives an S1AP Initial
Context Setup Request or S1AP UE Context Modification Request containing the CsFallbackIndicator IE,
where the IE is equal to CSFB High Priority or the preceding RRCconnection was setup with
establishmentCause = emergency. Choice of 1xRTT as the target technology for emergency CS fallback is
driven by feature activation.





This is the INTRA-ENB HANDOVER: RE-ESTABLISHMENT REJECT BY A NEIGHBOUR ENB During intrafrequency handover execution [HO to wrong cell]

This is the INTRA-ENB HANDOVER: RE-ESTABLISHMENT REJECT BY A NEIGHBOUR ENB After intrafrequency handover execution [HO to wrong cell]

This Flow Chart is Before inter-eNodeB intra-frequency handover preparation [tooLate or

toWrongCell] the same counter is used with screenning RLF monitoring :
(TooLateHO): 12775-0 for the Serving i.e. Failure cell. 12776-0 for the Serving cell. 12778-0 for the
Serving to Neighbour cell-relation.
(toWrongCell): 12775-2 for the Serving i.e. Failure cell. 12776-2 for the Serving cell. 12778-2 for the
Serving to Neighbour cell-relation.
See also After inter-eNodeB intra-frequency handover execution [HO to wrong cell]
The inter-ENB HO preparation from the source to target eNodeB succeeds and after receiving an
RRCConnectionReconfiguration, the UE detaches from the Source cell. Additional X2AP HANDOVER
REPORT message is sent from the Target eNB with Handover Report Type set to the value HO to Wrong
Source cell ECGI & Failure cell ECGI.

SAME AS : During intra-eNodeB intra-frequency handover execution [HO to wrong cell]:

The inter-ENB HO preparation from the source to target eNodeB succeeds and after receiving an
RRCConnectionReconfiguration, the UE detaches from the Source cell.
But intra counter not pegged : VS_HO_IaF_IrC_eNB_all_fail_prep_RLF_tgt_OD: LC12705_15

This is the INTRA-ENB HANDOVER: RE-ESTABLISHMENT REJECT BY A NEIGHBOUR ENB After intrafrequency handover execution [HO to wrong cell]

This Flow Chart is After inter-eNodeB intra-frequency handover execution [HO too early]
To early means the inter-Enb HO preparation from the source to target succeeds and alter receiving an
RRC Connection Reconfiguration, the UE detaches the source cell before the end of the HO..



Reason for not selecting the cell can be:

0. Mobility is not enabled in the current eNodeB according to configuration parameter or not allowed to
the known neighbor cell, due to blacklisted cell or HO restriction list.
1.
The Physical Cell Identity reported by the UE does not match any Cell Global Identity known by the
eNodeB.
2.
Such reported Cell can be disabled (locked, barred or failed).
3.
Cell reported by the UE is hosted by an eNodeB to which the X2 link is disabled (locked or failed), or
the target eNodeB has no access on source MME, and S1 Handover is disabled. This applies in case
the reported cell is managed by a distant eNodeB.
Notes:
During the ANR active phase, UnknownPCI counter value is normal and this screening may report a high
number.
Remark:
We get the total number of neighbor cell detections reported by the UEs in the cell by summing:
The number of neighbor cell detections not followed by a handover procedure
The number of intra-eNodeB attempts
The number of inter-eNodeB attempts


Please refer also to the Module Quality Monitoring for Global QoS indicators for Mobility Monitoring.




Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
5.0
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition
5.1
2013-01-05
Pascal SCANDOLO
Some Slides bug modification (L1/L2)

The following Trafic counter families are not included in this Module:
SCTP Association establishment (success/ failure/ Traffic on S1-MME/ Traffic on X2)
M1 Traffic for a eMBMS service (M1 GTP / MBMS SYNC delay / MBMS user packets dropped & received ).
S1-C LPPa Traffic (Control) ,


Page
1 PDCP SDU Traffic & Throughput
1.1 PDCP SDU Traffic & Throughput counters
1.2 INDICATORS: PDCP SDU Traffic & Throughput
2 X2 traffic and throughput
2.1 INDICATOR: Average Traffic & Throughput on X2
3 S1 Traffic and Throughput
3.1 INDICATOR: average S1 Traffic & Throughput
4 L2 Traffic and Throughput
4.1 COUNTERS: Non GBR ERAB RLC UL/DL Throughput
4.2 INDICATOR: Non GBR ERAB RLC UL/DL Throughput
4.3 INDICATOR: Non GBR L2 UL/DL Throughput
5 L1 Traffic and Throughput
5.1 Cell DL/UL Throughput
5.2 INDICATOR: Cell DL/UL Throughput
5.3 DL/UL PRB Used per scheduler mode
5.4 INDICATOR: DL PRB Usage
5.5 UL PRB Usage For Freq Diverse & Freq Selective Users
5.6 INDICATORS: Semi-persistent Scheduling
5.7 DL PRB Used Per Cell
5.8 UL PRB Used Per Cell
5.9 TTI usage for PUSCH per PRB group
6 Exercises on Traffic &Thrpt Monitoring
6.1 KPI for Traffic and Throughput Monitoring: EXO1
6.2 KPI definition for Traffic Monitoring : EX0 2
6.3 KPI definition for Throughput Monitoring : EX0 3
7 Capacity Monitoring
7.1 Number of UE in RRC_Connected State
7.2 INDICATOR: Number Of UE RRC Connected Per Cell
7.3 Number Of Active Users Per eNB
7.4 Number of VoIP Bearers per Cell per PLMN
7.5 Number of GBR Bearers per Cell per PLMN
7.6 Number of Non-GBR Bearers Per Cell per PLMN
7.7 Number of Bearers (All Types) per Cell
7.8 Number of bearers per cell per QCI per PLMN
7.9 Number of Voice emergency Bearers
7.10 RLC DL Retransmission Rate
7.11 GBR E-RAB Satisfied
7.12 UL Noise Per PRB Group
7.13 DL Residual MAC BLER
7.14 UL Residual MAC BLER
7.15 initial MAC BLER Block Error Rate Counters
7.16 UL Power Headroom
7.17 DL MIMO Eligibility Decision
7.18 EXERCISE: KPI definition

7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
35
36
38
39
40
41
42
43
45
46
47
48
49
50
52
54
55
56
57


These counters monitor the user plane traffic and the control plane traffic through the eNodeB (via X2 or
S1).
These counters are reported per eUtranCell.
Separate screenings are defined per QCI group (VoIP, OtherGBR, NonGBR)

This counter provides the average, minimum and maximum ingress bitrate of user plane traffic to the
eNodeB via S1 excluding PDCP SDUs
forwarded over S1 and received from another eNodeB..
This measurement is obtained by sampling at pre-defined intervals the DL cell PDCP SDU bit-rate summed
across all QCIs.

Granularity Period is the granularity period in seconds.


L12909_cum indicator provides the received volume traffic in kilo-bits over X2 interface. Ethernet headers
are included. 12909 counter is triggered (in the NodeB) every sampling period of 10 sec.
The Max and Min are provided for one sampling period within the GP (Granularity Period).
L12909_NbEvt indicator provides the total elapsed time of X2 activity within the GP. The times of reset
during which the link is not available are not counted.
L12910 provides the total number of packets received on the X2 interfaces of the eNodeB.
L12911 uses the same mechanisms as L1209 but for the sent traffic (vs received) over X2.
L12912 provides the total number of packets sent on the X2 interfaces of the eNodeB.


L13109_cum indicator provides the received volume traffic in kilo-bits over S1 interface. Ethernet headers
are included. 13109 counter is triggered (in the NodeB) every sampling period of 10sec.
The Max and Min are provided for one sampling period within the GP (Granularity Period).
L13109_NbEvt indicator provides the total elapsed time of S1 activity within the GP. The times of reset
during which the link is not available are not counted.
L13110 provides the total number of packets received on the S1 interfaces of the eNodeB.
L13111 uses the same mechanisms as L13109 but for the sent traffic (vs received) over S1.
L13110 provides the total number of packets sent on the S1 interfaces of the eNodeB.
See also average S1 Traffic & Throughput for all eNodeB:
- VS_traf_eNB_S1_thpt_rcvd_avg_ForAllENBs (L13109_40_CI in kbit/s)
- VS_traf_eNB_S1_thpt_sent_avg_ForAllENBs (L13111_40_CI in kbit/s)


LC12101: This counter provides the distribution of the RLC downlink throughput experienced by non-GBR
E-RABs on a cell. Throughput is computed over the periods of time during which RLC SDU buffers are still
filled with data to be sent. RLC ARQ and MAC HARQ procedures are involved. The 5 screenings define
different ranges of throughput.
LC12102: This counter provides the distribution of the RLC uplink throughput experienced by Non-GBR ERABs on a cell. Throughput is computed by dividing the RLC payload received from the MAC entity by the
interval of time between the reception of the first PDU and the time the RLC SDU buffer is emptied. The 5
screenings define different ranges of throughput.
LC12105,106,113,114 are counted at RLC PDU level. For those counters, screening 0 is for VoIP, 1 for
GBR and 2 for Non GBR.
The values of the Range are hardcoded in the eNodeB

(*)NOTE:
Customers need to have counters on RLC throughput max, min, average. Counters 12120 and 12121 are
now supported from LA5, counters 12101 and 12102 are still available.

New screenings are planned to be introduced after LA5.0 to further analyze the traffic composition of
nonGBR
Category (e.g. QCI5 to QCI9 E-RAB).



(*)NOTE:
Customers need to have counters on physical layer cell throughput max, min, average. Counters 12030
and 12031 are now supported from LA5, counters 12003 and 12004 are still available.


---- Downlink number of PRBs for Frequency Diverse users.

---- NOTES: KiB is 1024 bytes



For PRB LICENSE AND POOLING IN ENB

See also the LA5 counter 12037 VS.DLPRBAllocated (3GPP name)
And associated Indicators:
- VS_ERABs_NonGBR_RLC_thpt_DL_avg_PerCell: L12120_30_CI
- VS_ERABs_NonGBR_RLC_thpt_DL_avg_ForAllCells: L12120_40_CI

For PRB LICENSE AND POOLING IN ENB

See also the LA5 counter 12038 VS.ULPRBAllocated (3GPP name)
And associated Indicators:
- VS_ERABs_NonGBR_RLC_thpt_UL_avg_PerCell : L12121_30_CI
- VS_ERABs_NonGBR_RLC_thpt_UL_avg_ForAllCells L12121_40_CI









This counter monitors the number of UEs that are simultaneously in or transitioning (FDD only) into
RRC_CONNECTED state in the cell.
Current implementation is based on the number of UE Context established at eNodeB level:
- In stable states this number is aligned with the number of RRC Connected Users.
- In transient periods this two values might differ due to the implementation strategy. There is agreement
that this difference during transient period is acceptable.


The counter (and indicator) current implementation is based on the number of UE Context established at
eNodeB level.
- In stable states, this number is aligned with the number of RRC Connected Users.
- In transient periods, this two values might differ due to the implementation strategy due to hardcoded
timer for RRC Connection Release.


This counter monitors the number of VoIP bearers established for the concerned PLMN on the cell.
This counter is a load counter with sampling on event occurence.
It reports a 4-tuple of values:
the cumulative value which has the unit of the counter multiplied by time. Its the Sum over the
granularity period of the number bearers in the cell multiplied by the time elapsed between two
successive events.
the elapsed time in second (equal to the granularity period, except in case of reset)
the maximum and the minimum values during granularity period. They have the unit of the counter.
LongName
Reference
VS_ERAB_VoIP_nb_OnCell_avg_PerCell
VS_ERAB_VoIP_nb_erlang_PerCell
VS_ERAB_VoIP_nb_OnCell_avg_ForAllCells
VS_ERAB_VoIP_nb_erlang_ForAllCells
VS_ERAB_VoIP_ongoing_duration
L13204_30_CI
L13204_40_CI
L13204_50_CI
L13204_60_CI
L13204_70_CI

This counter monitors the number of GBR bearers established for the concerned PLMN on the cell
(excluding VoIP bearers).
LongName
Reference
VS_ERABs_GBR_WithoutVoIP_nb_OnCell_avg_PerCell
L13205_30_CI
VS_ERABs_GBR_WithoutVoIP_nb_OnCell_avg_ForAllCells
L13205_40_CI
VS_ERABs_GBR_WithoutVoIP_nb_erlang_PerCell
L13205_50_CI
VS_ERABs_GBR_WithoutVoIP_nb_erlang_ForAllCells
L13205_60_CI
VS_ERABs_GBR_WithoutVoIP_ongoing_duration
L13205_70_CI

This counter monitors the number of non-GBR bearers established for the concerned PLMN on the cell.
LongName
VS_ERABs_NonGBR_nb_OnCell_avg_PerCell
VS_ERABs_NonGBR_nb_OnCell_avg_ForAllCells
VS_ERABs_NonGBR_nb_erlang_PerCell
VS_ERABs_NonGBR_nb_erlang_ForAllCells
VS_ERABs_NonGBR_ongoing_duration

Reference
L13206_30_CI
L13206_40_CI
L13206_50_CI
L13206_60_CI
L13206_70_CI
This counter monitors the number of bearers on the cell (all).
LongName
VS_ERABs_all_nb_OnCell_avg_PerCell
VS_ERABs_all_nb_OnCell_avg_ForAllCells
VS_ERABs_all_nb_erlang_PerCell
VS_ERABs_all_nb_erlang_ForAllCells
VS_ERABs_all_ongoing_duration

Reference
L13207_30_CI
L13207_40_CI
L13207_50_CI
L13207_60_CI
L13207_70_CI
Note:
VS_ERABs_all_nb_OnCell_NbEvt_Savg_Tsum is a stored indicator for the SUM based on the counter
VS_NbBearersPerCell_NbEvt (LC13207_NbEvt)
For voice traffic, this is the nb of Bearers for erlang traffic.
INDICATORS NAMING
is based on VS_ERABs_all_nb_OnCell_PerCell
VS_ERABs_all_nb_erlang_ForAllCells is based on VS_ERABs_all_nb_OnCell_ForAllCells


Number of voice emergency bearers per VLAN for CoS VoIP on S1U: 13239
This Load counter provides the average, maximum and minimum number of Emergency bearers per CoS in
a VLAN. The average value is obtained by dividing the cumulative value of the bearers by the elapsed time.
Number of voice emergency bearers per port for CoS VoIP on S1U: 13240
This Load counter provides the average, maximum and minimum number of Emergency bearers per CoS in
a VLAN. The average value is obtained by dividing the cumulative value of the bearers by the elapsed time.
LongName
VS_ERABs_all_nb_OnCell_avg_PerCell
VS_ERABs_all_nb_OnCell_avg_ForAllCells
VS_ERABs_all_nb_erlang_ForAllCells
VS_ERABs_all_ongoing_duration

Reference
L13207_30_CI
L13207_40_CI
L13207_50_CI
L13207_60_CI
L13207_70_CI


Uplink noise per PRB group counter gives the distribution per 4 PRBs group of Uplink noise monitored on
the cell. It means that for each PRB of the group, the measure is done and the corresponding counter
range is incremented.
This counter will be duplicated for each 4 PRBs Group of the cell.
This counter is pegged based on the long term period (period duration configurable and set to 100ms by
default) averaged NoisePower metric
computed by the eNodeB for each PRB. The counter is updated every 1000 radio frames with the latest
computed noise value for the corresponding 4 PRBs group (the screening (subcounter) that corresponds to
the NoisePower value is incremented by 1).

LongName
VS_BLER_DL_all
VS_BLER_DL_Hi_ratio
VS_BLER_DL_LoMed_OrBest_ratio
VS_BLER_DL_Hi_HiMed_HiLo_ratio
VS_BLER_DL_Lo_OrBest_ratio

Reference
L12707_30_CI
L12007_71_CI
L12707_31_CI
L12707_41_CI
L12707_61_CI
This counter provides a distribution of residual Semi-Persistent Scheduling MAC BLER values measured in
downlink direction. In order to
avoid pegging the counter with non-representative values, BLER values is only taken into account if at least
dlBlerMinPdu PDUs have been sent.

LongName
Reference
VS_BLER_DL_all
VS_BLER_DL_Hi_ratio
VS_BLER_DL_LoMed_OrBest_ratio
VS_BLER_DL_Hi_HiMed_HiLo_ratio
VS_BLER_DL_Lo_OrBest_ratio
L12707_30_CI
L12007_71_CI
L12707_31_CI
L12707_41_CI
L12707_61_CI

LongName
Reference
VS_BLER_UL_all
VS_BLER_UL_LoMed_OrBest_ratio
VS_BLER_UL_Lo_OrBest_ratio
L12709_30_CI
L12709_31_CI
L12709_61_CI

LongName
Reference
VS_BLER_UL_all
VS_BLER_UL_LoMed_OrBest_ratio
VS_BLER_UL_Lo_OrBest_ratio
L12709_30_CI
L12709_31_CI
L12709_61_CI

The Dynamic Scheduler counters includes packets with first HARQ transmission scheduled by Dynamic
Scheduler of VoIP SPS bearer. This does not include packets with first HARQ transmission scheduled by
Semi-Persistent Scheduler of VoIP SPS bearer.

The normalized Power Headroom is the sum of all Power Headroom reported by all Ues in the cell.
The Power Headroom is the difference between the nominal UE maximum transmit power and the
estimated power of the current UL-SCH transmission [40 to -23dB]


CAPACITY KPI should be monitored using:

1.
Nb max connected Ue
2.
DL TTI scheduled
3.
UL TTI scheduled
4.
UE schedul - Avg Nb of UE scheduled per TTI DL
5.
UE schedul - Avg Nb of UE scheduled per TTI UL
6.
PRB - Avg Used DL
7.
PRB - Avg Used UL
8.
Duration of eRAB
In addition to the Exercise, the following eNodeB INDICATORS can be used :

UE capacity per Cell (previous slides): VS_UE_RRC_connected_avg_PerCell for average number of UE in or
transitioning into RRC_Connected state per cell.
VS_UE_nb_PerTTI_DL_avg_PerCell: This indicator provides the average number per cell of UE scheduled on
downlink on a cell.
VS_PRB_used_all_DL_avg_ForAllCells: This indicator provides the "average" number of downlink PRBs aggregated on all cells - that have been assigned by the downlink scheduler in the cell. The counter is sampled
every time frame and updated based on the number of downlink PRBs computed globally for every mobiles
scheduled on the cell during this sampling period.
VS_ERABs_all_nb_erlang_ForAllCells: This indicator provides the Erlang capacity of all bearers over all
aggregated cells.
See also UL Capacity possible KPI: VS_UE_nb_PerTTI_UL_avg_PerCell and
VS_PRB_used_all_UL_avg_ForAllCells



Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition
04
2012-01-25
Ikram ANDONIAN
Jean-Philippe KINE
Fourth edition
5.0
2012-11-15
Pascal SCANDOLO
LTE LE5.0 edition
5.1
2013-01-05
Pascal SCANDOLO
Some Slides bug modification.

The following Trafic counter families are not included in this Module:
SCTP, eNodeB Synchronization, IP Transport,


Page
1 Radio Frequency Measurements
1.1 signal strength indicator measurement
2 Radio Scheduler Monitoring
2.1 Number of UE Scheduled in DL/UL per TTI
3 Paging Monitoring
3.1 S1 Paging Monitoring
4 CAC Monitoring
4.1 CAC Overview
4.2 CAC procedure Monitoring
4.3 INDICATOR: CAC Request & Failures rate
5 Global Indicators for QoS
5.1 Global Counter for QoS reporting configuration
5.2 Global Indicators for QoS
5.2.1 Bearer session management SubFamily
5.2.2 Capacity SubFamily
5.2.3 E-RAB management SubFamily
5.2.4 E-RAB management per VLAN SubFamily
5.2.5 E-RAB management per PLMN SubFamily
5.2.6 Handover SubFamily
5.2.7 Inter Operability SubFamily
5.2.8 L2 traffic and throughput SubFamily
5.2.9 Mobility management SubFamily
5.2.10 UE context management SubFamily
6 Examples on QUALITY Monitoring
6.1 LTE Quality Of Experience principles
6.2 DATA Web Browsing service monitoring
6.3 DATA Gaming service monitoring
6.4 VoIP service monitoring
6.5 VIDEO Streaming service monitoring
6.6 KPI for VoIP: EXERCISE 1

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
37
39




This counter provides the average, maximum and minimum number of UEs scheduled on downlink per TTI
in the cell. The average value is obtained by dividing the cumulative value of the UEs by the number of
events.
Use Numbered List tag and list the trigger information:
1.Trigger: Beginning/End of the observation period.
Actions: If (nbUeDlTtiEvt NE 0) then Peg counter according to nbUeDlTtiMax, nbUeDlTtiMin, nbUeDlTtiCum
and bUeDlTtiEvtnbUeDlTtiMax = 0,
nbUeDlTtiMin = Maximum number of UE schedulable per TTI,
nbUeDlTtiCum = 0,
nbUeDlTtiEvt = 0.
2.Trigger: Every TTI.
Actions: If at least one UE has been scheduled in downlink during this TTI then nbUeDlTtiEvt++,
nbUeDlTtiCum += number of UE scheduled on this TTI.
if (number of UE scheduled on this TTI GT nbUeDlTtiMax) then nbUeDlTtiMax = number of UE scheduled
on this TTI.
if (number of UE scheduled on this TTI LT nbUeDlTtiMin) then nbUeDlTtiMin = number of UE scheduled
on this TTI.


The L13502_30_CI indicator provides the number of times page attempts from MMEs have been
discarded by eNodeB.
The L13502_31_CI indicator provides the ratio of page attempts from MMEs that have been discarded by
eNodeB.
The L13501 indicator provides the raw number (Basic Counter) of S1 page attempts received by the
eNodeB (all cells) from MMEs.



Overload Control is processed before CAC.

However there is interaction between CAC and Overload in case preemption is rejected due to overload
condition. Up to now, no counter is defined to cover preemption. Consequently there is no need to count
preemption in overload. It is the reason why no specific screening is defined in this counter in case of
preemption rejected in overload condition.

Remarque:
VS_CAC_user_VoIP_... Indicators not available on LA5.0.2 release.


(*)In case of Network Performance Optimizer (NPO) usage, there is a need to provide a Range of Usefull QoS Counters to be
reported at the northbound interface between eNodeB and NPO:
FeatureSelection linked counters are automatically selected when enabling the Feature if optional (when disabled, the linked
Counters & indicators return NULL or NA value types).
UserSelection QoS reporting information related to the Customer configuration of the relevant performance counter are defined
at the 5620 SAM interface (refer to SAM Users Guide)


















Reminder on R Factor :
Transmission Rating Factor indicates the relative quality of a call, measured or predicted by the E model
(Electro-acoustic model also known as E-model) , on a scale of 0-100.
The rating factor R is composed of: R = Ro Is Id Ie-eff + A,
where Ro represents the signal-to-noise ratio, including noise sources such as circuit noise and room noise,
Is is a combination of all impairments which occur simultaneously with the voice signal, Id are impairments
caused by delay, Ie-eff are the effective equipment impairments caused by the codes. It also includes
impairment due to packet-losses of random distribution. A is the advantage factor, used for compensation
of impairment factors when there are other advantages of access to the user. These values can be further
subdivided into more specific impairment values.

Note:
The Video Streaming service is optimized using the Multimedia Broadcast Multicast Service (MBMS),
a point-to-multipoint interface specification for existing and upcoming 3GPP cellular networks, is available
since the TLA3.0 and LA5.0 releases.




All Rights Reserved Alcatel-Lucent @@YEAR

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

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

TMO18416 - V5.1 SG (T) LA5.0 Ed1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TMO18416 - V5.1 SG (T) LA5.0 Ed1 PDF

Uploaded by

Copyright:

Available Formats

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

contents not permitted without written authorization from Alcatel-Lucent

TERMS OF USE AND LEGAL NOTICE

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Welcome to 9400 LTE

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Your feedback is appreciated!

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Last name, first name

LTE LE5.0 edition

Some Slides bug modification.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Navigator - LTE Level3 - TMO18048 - 9959 NPO Standard Operations )

NPO add-on are available to refine QoS analysis

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Predefined Customization for GSM/ WCDMA/ WIMAX/ LTE Standards integrates:

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

For each counter, description contains (see after):

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Cumulative counters provide raw counts.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Alcatel-Lucent provides the following values:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Alcatel-Lucent provides the following values:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Refer to eNodeB customer documentation:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Alcatel-Lucent NPO also allows users to create their own

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

This VS_UE_ctxt_modif_eNB_setup_fail Indicator (L12511_20_CI) has a formula based on other

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

NPO performes a Temporal aggregation every Night (or manual)

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

KPI family example:

FAMILY: QoS (global indicators)

Copyright 2012 Alcatel-Lucent. All Rights Reserved.