Вы находитесь на странице: 1из 117

ZTE FDD LTE Radio

Optimization Guideline

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

Product Type Technical Description


Version

Date

Author

V1.3

2014-5-12

ZTE

Approved By

Remarks
Not open to the Third Party

2010 ZTE Corporation. All rights reserved.


ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be
disclosed or used without the prior written permission of ZTE.
Due to update and improvement of ZTE products and technologies, information in this document
is subjected to change without notice.

TABLE OF CONTENTS

Introduction ................................................................................................................ 8

2
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3

Network optimization preparation ............................................................................ 8


Organization Structure ................................................................................................. 9
Optimization Tools and Software ................................................................................. 9
CNT............................................................................................................................ 10
CNA ........................................................................................................................... 10
NETMAX .................................................................................................................... 11
CNP ........................................................................................................................... 11
Cluster Definition ....................................................................................................... 11

3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.4

Network Optimization Process ............................................................................... 12


Optimization Milestone .............................................................................................. 12
Pre-launch Optimization ............................................................................................ 13
Radio Frequency Verifying ........................................................................................ 13
Single Site Verification (SSV) .................................................................................... 13
Cluster Optimization workflow ................................................................................... 15
Soft Launch (Trial-running Period) Optimization ....................................................... 16
Launched Optimization .............................................................................................. 17

4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.6

Cluster Optimization ................................................................................................ 18


Single-Cell Coverage Analysis .................................................................................. 18
Checking the Antenna Connection Sequence ........................................................... 19
Checking the Overshooting ....................................................................................... 20
Checking the Coverage of Antenna Side Lobe and Back Lobe ................................ 22
Checking the Zero-Coverage Cell ............................................................................. 23
Cluster Coverage Analysis ........................................................................................ 25
Overview .................................................................................................................... 25
Work Scope of Coverage Optimization ..................................................................... 25
Weak-Coverage Optimization .................................................................................... 26
SINR Optimization ..................................................................................................... 32
Overlapped Coverage Optimization .......................................................................... 37
Pilot Frequency Pollution Analysis ............................................................................ 41
Handover Analysis ..................................................................................................... 45
Missed Matching of Neighboring Cells ...................................................................... 47
Wrong Matching of Neighboring Cells ....................................................................... 54
Ping-Pong Handover ................................................................................................. 54
Handover Latency ...................................................................................................... 58
Handover Failure ....................................................................................................... 60
Downloading Rate Analysis ....................................................................................... 65
Overview .................................................................................................................... 65
Analysis Methods ....................................................................................................... 65
Analyzing the Cell with the Maximum Downloading Rate Less than 5M .................. 67
Analyzing the Cell with the Average Downloading Rate Ranging from 5M to 10M... 70
Access Analysis ......................................................................................................... 75
Call Failures ............................................................................................................... 75
RRC Connection Establishment Failures .................................................................. 76
Authentication and Encryption Failures ..................................................................... 80
E-RAB Connection Establishment Failures ............................................................... 82
Call Drop Analysis ..................................................................................................... 85

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

4.6.1
4.6.2
4.6.3

Caused by coverage problems .................................................................................. 85


Caused by handover problems .................................................................................. 86
Caused by interference problem ............................................................................... 86

5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
5.3.8

OSS KPI Optimization .............................................................................................. 87


Network Access Performance Optimization .............................................................. 87
System Accessibility .................................................................................................. 87
System Availability ..................................................................................................... 87
Commonly Used Methods ......................................................................................... 88
System Accessibility KPI ........................................................................................... 90
System Availability KPI .............................................................................................. 98
Handover Performance Optimization ...................................................................... 101
Handover Flow ......................................................................................................... 101
Handover Performance KPI ..................................................................................... 106
Commonly Used Methods ....................................................................................... 106
Handover Optimization Process .............................................................................. 106
No Handover Command Received upon the Sent Measurement Report ............... 107
MSG1 Sending Exception at Destination Cell ......................................................... 109
RAR Reception Exception ....................................................................................... 110
E-RAB Drops Performance Optimization ................................................................ 112
Definition of E-RAB Drop Rate ................................................................................ 112
Formula of E-RAB Drop Rate .................................................................................. 112
E-RAB Drop sampling point ..................................................................................... 112
E-RAB Drop Counters ............................................................................................. 113
Release Reason definition in3GPP TS 36.413........................................................ 113
OMM-level performance statistics analysis ............................................................. 115
OMM-level performance statistics analysis ............................................................. 116
Conclusion ............................................................................................................... 116

FIGURES
Figure 2-1: LTE Radio Network Optimization Organization Structure ................................................ 9
Figure 3-1: LTE Radio Network Optimization Milestone ................................................................... 12
Figure 3-2: Cluster Optimization Work Flow ..................................................................................... 15
Figure 4-1 CNA LTE COVER LINE ................................................................................................ 18
Figure 4-2 CNA PCI RSRP ............................................................................................................ 19
Figure 4-3 Coverage Direction of Cell FE2 (PCI94) ....................................................................... 20
Figure 4-4: Cell with Overshot Signals ............................................................................................. 21
Figure 4-5 PCI Coverage Analysis in CNA .................................................................................... 21
Figure 4-6 Cell Coverage Before and After the Azimuth & RS Power Adjustment ........................ 22
Figure 4-7 Overlapped Coverage Caused by Reflection ............................................................... 23
Figure 4-8 PCI's RSRP Function.................................................................................................... 24
Figure 4-9 Weak Coverage Area Analysis -1 ................................................................................. 26
Figure 4-10 Weak Coverage Area Analysis -2 ............................................................................... 27
Figure 4-11 Weak Coverage Area Analysis -3 ............................................................................... 27
Figure 4-12 Weak Coverage Area Analysis -4 ............................................................................... 28
Figure 4-13 Weak Coverage Area Analysis -5 ............................................................................... 28
Figure 4-14 DT Test Results-1 ......................................................................................................... 29
Figure 4-15 Coverage Effect of Cell PCI48, PCI43 and PCI12 ..................................................... 30
Figure 4-16 DT Test Results-2 ....................................................................................................... 30
Figure 4-17 Weak Coverage Analysis in Cell PCI30 -1 ................................................................. 31
Figure 4-18 Weak Coverage Analysis in Cell PCI30 - 2 ................................................................ 31
Figure 4-19 DT Test Results after Adjustment of Antenna Tilting and Azimuth ............................ 32
Figure 4-20 Low SINR Cell Analysis -1 .......................................................................................... 33
Figure 4-21 Low SINR Cell Analysis -2 .......................................................................................... 33
Figure 4-22 Low SINR Cell Analysis -3 .......................................................................................... 34
Figure 4-23 Low SINR Cell Analysis -4 .......................................................................................... 34
Figure 4-24 Low SINR Cell Analysis - 5 ......................................................................................... 35
Figure 4-25 Low SINR Caused by Handover Failure ..................................................................... 36
Figure 4-26 Handover Failure Analysis .......................................................................................... 36
Figure 4-27 Handover Success after Adjustment .......................................................................... 37
Figure 4-28 Overlapped Coverage Analysis -1 .............................................................................. 38
Figure 4-29 Low SINR Cell Analysis -2 .......................................................................................... 38
Figure 4-30 Overlapped Coverage Analysis -3 .............................................................................. 39
Figure 4-31 Overlapped Coverage Analysis -4 .............................................................................. 39
Figure 4-32 Overlapped Coverage Analysis -5 .............................................................................. 40
Figure 4-33 Overlapped Coverage Analysis .................................................................................. 41
Figure 4-34 Pilot Frequency Pollution Analysis -1 ......................................................................... 42
Figure 4-35 Pilot Frequency Pollution Analysis -2 ......................................................................... 43
Figure 4-36 Pilot Frequency Pollution Analysis -3 ......................................................................... 43
Figure 4-37 Pilot Frequency Pollution Analysis -4 ......................................................................... 43
Figure 4-38 Pilot Frequency Pollution ............................................................................................ 44
Figure 4-39 Pilot Frequency Pollution Analysis ............................................................................. 45
Figure 4-40 Location Where the Handover Takes Place ............................................................... 46
Figure 4-41 Handover Results ....................................................................................................... 47
Figure 4-42 Signaling in Case of Missed Matching of Neighboring Cells ...................................... 48

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

Figure 4-43 Workflow of Analysis on Missed Matching of Neighboring Cells ................................ 49


Figure 4-44 Signaling in Case of No Response for Measurement Report..................................... 50
Figure 4-45 Analysis on Missed Matching of Neighboring Cells -1 ............................................... 51
Figure 4-46 Analysis on Missed Matching of Neighboring Cells -2 ............................................... 51
Figure 4-47 Analysis on Missed Matching of Neighboring Cells -3 ............................................... 52
Figure 4-48 Analysis on Missed Matching of Neighboring Cells -4 ............................................... 53
Figure 4-49 Handover Restores after Elimination of Missed Matching .......................................... 53
Figure 4-50 Ping-Pong Handover .................................................................................................. 55
Figure 4-51 Workflow of Elimination of Ping-Pong Handover Problem ......................................... 56
Figure 4-52 Analysis on Ping-Pong Handover Problem ................................................................ 57
Figure 4-53 Signaling Process of Handover on Control Plane ...................................................... 59
Figure 4-54 Overtime Handover ..................................................................................................... 61
Figure 4-55 Workflow of Solving the Handover Failure Problem ................................................... 62
Figure 4-56 Handover Failure ........................................................................................................ 63
Figure 4-57 Analysis of Handover Failure -1 ................................................................................. 63
Figure 4-58 Analysis of Handover Failure -2 ................................................................................. 64
Figure 4-59 SINR Value after Adjustment of Antenna Downtilt ..................................................... 65
Figure 4-60 Workflow of Analyzing Traffic Problem ....................................................................... 66
Figure 4-61 Cells Whose Maximum Traffic is Less than 5M.......................................................... 68
Figure 4-62 DT Test Data of Area 1 ............................................................................................... 68
Figure 4-63 DT Test Data of Area 2 ............................................................................................... 69
Figure 4-64 Cells Whose Average Traffic Ranges from 5M to 10M .............................................. 71
Figure 4-65 DT Test Data -1 .......................................................................................................... 71
Figure 4-66 DT Test Data -2 .......................................................................................................... 72
Figure 4-67 DT Test Data -3 .......................................................................................................... 73
Figure 4-68 DT Test Data -4 .......................................................................................................... 74
Figure 4-69 Cause Analysis Procedure for Call Failures ............................................................... 75
Figure 4-70 Procedure for Troubleshooting an RRC Connection Establishment Problem ............ 77
Figure 4-71 Authentication Failure Message (Cause Value: MAC Failure) ................................... 81
Figure 4-72 Authentication Failure Message (Cause Value: Synch Failure) ................................. 82
Figure 5-1 OMM-Level Performance Statistics Analysis Procedure .............................................. 89
Figure 5-2 Cell-Level Performance Statistics Analysis Procedure ................................................ 90
Figure 5-3 RRC Connection Establishment Procedure ................................................................. 91
Figure 5-4 Initial E-RAB Connection Establishment Procedure ..................................................... 94
Figure 5-5 Initial Context Setup Procedure .................................................................................... 99
Figure 5-6 E-RAB Setup Procedure ............................................................................................... 99
Figure 5-7 Handover Process Diagram .......................................................................................... 101
Figure 5-8 Signaling Process Diagram of Handover Inside the eNB ............................................. 103
Figure 5-9 X2 Handover Signaling Process Diagram ..................................................................... 104
Figure 5-10 S1 Handover Signaling Process Diagram ................................................................... 105
Figure 5-11 Process of Analyzing Handover Problem .................................................................... 107
Figure 5-12 Process Flow When No Handover Command Received upon the Sent Measurement
Report ........................................................................................................................ 109
Figure 5-13 Process of Analyzing Msg1 Problem .......................................................................... 110
Figure 5-14 Process of Analyzing RAR Problem ............................................................................ 110
Figure 5-15 LTE Call Drop Problem-Solving Workflow .................................................................. 116

Tables
Table 2-1: Drive Test and Post Processing Tools .............................................................................. 9
Table 3-1: Single Site Verification: .................................................................................................... 14
Table 4-1 Cells with Zero Coverage ............................................................................................... 24
Table 4-2 Handover KPIs Table ..................................................................................................... 45
Table 4-3 RSRP When the Handover Takes Place ....................................................................... 46
Table 4-4 SINR Statistics When the Handover Takes Place ......................................................... 47
Table 4-5 Solutions for Handover Latency Problem ...................................................................... 60
Table 4-6 Cells Whose Maximum Traffic is Less than 5M ............................................................. 67
Table 4-7 Parameter Table for Cells Whose Maximum Traffic is Less than 5M ........................... 67
Table 4-8 Cells Whose Average Traffic Ranges from 5M to 10M ................................................. 70
Table 5-1 System Accessibility Indicators and Recommended Values ......................................... 87
Table 5-2 System Availability Indicators and Recommended Values ............................................ 87
Table 5-3 Commonly Used Performance Statistics Analysis Methods .......................................... 88
Table 5-4 Major Sampling Points in the RRC Connection Establishment Procedure ................... 91
Table 5-5 RRC Connection Establishment Failure Counters ........................................................ 92
Table 5-4 Major Sampling Points in the Initial E-RAB Connection Establishment Procedure ....... 95
Table 5-7 Initial E-RAB Connection Establishment Failure Counters ............................................ 96

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

1 INTRODUCTION

The document presents the solution of FDD LTE radio network optimization for
Wireless Network.

The construction of the wireless communication network is a gradual, dynamic


process. After a period of operation, with the increase of subscribers,
environment transformation and some other uncontrollable factors, there would
be decrease of connection success ratio, fall of call quality and faded signals etc.
The formerly planned network can no longer keep pace with the rapid
development. To make adjustments and expansion of the systemic resources
and related parameters, that is scope of network optimization.

The objective of this document is to describe:

Network optimization preparation

Network Optimization process

Cluster Optimization

OSS KPI Optimization

2 NETWORK OPTIMIZATION PREPARATION

Before the network optimization, the RNO (Radio Network Optimization)


manager should assure that manpower and equipments are available. At the
same time the optimization schedule should be made and the following
information is collected:

Radio network planning report;

Latest site configuration table and radio parameter configuration table;

OMM statistic data;

Subscriber complaints of the existing network;

Requirements for network performance targets, including specific requirements for


the coverage, capacity and QoS of the network;

The responsibility matrix definition

The project acceptance criteria.

2.1 Organization Structure

The following picture shows the organization structure.

Figure 2-1: LTE Radio Network Optimization Organization Structure

RF Optimization
PM

Cluster
Optimization
Person In
Charge

SSV
Person In
Charge

Analysis
Engineer

Analysis
Engineer

Field Test
Engineer

Field Test
Engineer

SSV Team 1

SSV Team N

Analysis
Engineer

Analysis
Engineer

Drive Test
Engineer

Drive Test
Engineer

DT Team 1

DT Team N

KPI Analysis
Engineer

KPI Analysis
Engineer

Cluster
Optimization
Team 2

Cluster
Optimization
Team M

2.2 Optimization Tools and Software

In this section, tools used to collect data, analyze data and improve the
performance of network during the various stages of the project are introduced.
The tools used in network optimization process are listed in following table:

Table 2-1: Drive Test and Post Processing Tools


No.
Equipments
Model
1

Data Collection Software

CNT(Communication Network Test) or NEMO

Post Processing Software

CNA (Communication Network Analysis) or


NEMO

3
4
5
6
7
8

Test User Equipment


Test Laptop
GPS
Test Vehicle
Digital map
Power inverter
PC Server (Hard disk
should be 500G at least)
USIM cards
Performance analysis
software

For Drive Test


Map used for drive test
Power supply at test vehicle
To store test data & post processing data
&analysis report

Planning software

CNP(Communication Network Planning) or


Atoll/Aircom

9
10
12
13

ZTE Confidential Proprietary

NETMAX (Performance analysis software)

2010 ZTE Corporation. All rights reserved.

2.2.1 CNT

ZXPOS CNT is an advanced wireless network air interface test tool. It is used
for trouble shooting, evaluation, optimization, and maintenance of the mobile
network. This tool integrates the professional and final-user senses and feelings,
completely tests and analyzes the self-network and that of the competitors, and
provides precise measurement means for various network KPIs.

ZXPOS CNT supports all standards of 2G (GSM/GPRS/EDGE, CDMA IS95/1X),


3G (TD-SCDMA, WCDMA, CDMA2000), and 4G (LTE) networks and various
frequency bands of 900/1800/2100/2600MHz, 850/1900MHz, and 450MHz.

Support LTE test services including Ping, FTP, HTTP, and TCP/UDP data service
test

Support LTE Qualcomm test terminal

Support CW, spectrum and TopN scan by PCTEL scanner

Support ms-level frame exporting function of key data

Support KPI real-time statistics

Support indoor and outdoor tests

Simple configuration, easy operation, stable and reliable for test

Support real-time statistics function to quickly obtain test results

Support tests of new techniques and new service quickly with continuous research
innovation capability to meet test requirements on new techniques of operators

2.2.2 CNA

ZXPOS CNA is an intelligent wireless network optimization analysis system. It


supports all 2G, 3G, and 4G networks such as
GSM/GPRS/EDGE/CDMA/EVDO/WCDMA/ HSDPA/HSUPA/TD-SCDMA/LTE.

ZXPOS CNA provides network oriented data processing and analysis report on
network optimization. ZXPOS CNA also provides multi-service QoS analysis for
multi-network quality evaluation.

The main function is as following:

Support LTE data analysis and processing

Support simultaneous loading and viewing of up to 108 test data

Support KPI analysis of PING/FTP/HTTP/TCP/UDP services

GIS analysis function

Support diverse advanced analysis functions to locate reasons of multiple abnormal


problems

2.2.3 NETMAX

ZXPOS NETMAX is an advanced tools and the first choice for analyzing and
locating the network faults based on large quantities of Measurement Report
(MR) and Call Detail Trace (CDT). The workload of drive test and analysis can
be largely reduced due to its call recurrence and intelligence analysis,

Analyze and optimize the coverage status of the whole network;

Analyze and optimize the worst cell.

Trace the VIP subscribers and ensure their QoS.

Locate the subscribers with complaint; trace and analyze the signaling during the
call.

Analyze and optimize the performance of the terminal.

2.2.4 CNP

CNP is main tool for LTE network planning and simulation, the main functions
include:

Support GIS

Support 3 types schedule method

Support PCI planning

Support adjacent neighbor list planning

Support Monte Carlo simulation

Support traffic simulation

2.3 Cluster Definition

LTE Optimization will be done cluster by cluster, and the number of eNodeBs in
one cluster from 20 to 30. The main rules of cluster definition are:

The geographical location

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

11

The service distribution

The same TAC region information

The sites in a cluster should not too many and the overlap between clusters is
needed. The definition of cluster should be confirmed by customer and ZTE
together.

3 NETWORK OPTIMIZATION PROCESS

In this section, three stages of optimization are introduced, and the high level
optimization plans are presented for each individual stage of network
implementation and performance acceptance. Items under consideration are
target of optimization, methods of optimization and output for optimization, etc.

3.1 Optimization Milestone


Figure 3-1: LTE Radio Network Optimization Milestone

Launched Optimization
Network Commercial
Soft Launch Optimization
Network Soft Launch
Pre-Launch Optimization
Cluster Optimization
Single Site Verification
Network Construction
Installation & Commissioning & Test
Network Design
Site Survey

Start

Network Design

Commissioning

PAC

FAC

LTE radio network optimizations include three major stages: Pre-launch


Optimization, Soft Launch Optimization and Launched Optimization.

The main objective of Pre-launch Optimization is to control RF network air


interference, assure network hardware functionality work normally, and ensure
the KPIs target of Preliminary Acceptance Test is achieved. Pre-launch
Optimization includes two steps:

Single Site Verification

Cluster Optimization

End

The objective of Soft Launch Optimization is to assure that no Punch List items
exists in the System. The Punch List is the list that consists of all defects
identified during the respective Preliminary Acceptance Test, during the period
prior to Final Acceptance. When all items on the respective Punch List have
been resolved in the System, a Final Acceptance Certificate will be issued.

The optimization after issuing FAC is named as Launched Optimization. The


network can be put into commercial services after FAC. The objective of
Launched Optimization is to assure the network performance stabilization when
subscribes are increasing. Launched Optimization is focused on customer
experiences, system load, capacity balance, resource utilization, etc.

3.2 Pre-launch Optimization


3.2.1 Radio Frequency Verifying

The network quality, capacity and coverage are related to the interference level
of the system. It is necessary to measure radio frequency and assess the
interference level in the given LTE band.

Radio frequency verification must get permission of the operator and local
Telecommunication Administration. Radio frequency verification contains two
phases. The first phase is before the network construction, during site survey to
verify if there is interference at the site location, which will be carried out in the
spectrum that operator has available for this carrier and measure the band
designated by the operator. The second phase is after the network is on-line,
and radio frequency verifying is used to locate interference source.

3.2.2 Single Site Verification (SSV)

The goal of single site verification is to eliminate potential errors introduced


during the site construction and configuration phases, so that following RF
optimization can be based on a reasonable basis, or else if any problems are
identified during optimization, it will be time-consuming to find out what factors
are responsible for the unexpected results. Normally during single site
verification, functional requirements are the main concerns; service performance
of the single site is not strictly required.

The check items involved in the SSV can be classified into several categories,
for example, the equipment related problems, the engineering related problems,
the configuration related problems, etc. Typical problems are presented in the
following table. These problems should be solved before the service related
SSV test can be performed, to be more specific, these tests include coverage
test, VoIP, FTP, Pingetc.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

13

Table 3-1: Single Site Verification:


Equipment related

Engineering related

Configuration related

Abnormal power alarm


PA alarm
Transmission broken
Board related alarms
Internal/external link alarms
Antenna VSWR alarm
Clock source/GPS alarm
Cell/eNodeB down alarm
SW version alarm

Feeder
Loose connection of
connectors
Unreasonable antenna
position
Signal obstacle by buildings
Wrong antenna tilt and
azimuth

Center frequency
PCI
TAC
Cell status
Transmission
bandwidth
PRACH Configuration

Above mentioned problems are to be solved by corresponding technical staffs.


Most of equipment related problems are to be solved by base station engineers,
engineering related problems are to be solved by RF optimization engineers and
installation engineers together, and configuration related problems are to be
solved by RF optimization engineers and OMC engineers. After site verification,
it should be free of obvious problems that might cause the site incapable of
being put on air.

The SSV process is mainly based on stationary check and drive test, and the
former means performing desktop check on items according to configuration
data, or walking around the site using test UEs. For the stationary check,
needed materials are as the following list:

Technical Site Survey (TSS) report

Planned Engineering Parameters

Planned Radio Parameters

Site Configuration Parameters.

These materials might also be used in drive test verification of the site.

Before Single Site Verification, the critical and major level alarms for sites should
be eliminated. Most part of configuration related items can be fulfilled by
stationary check, whether the transmission bandwidth and center frequency
configuration can match the design requirement, whether the cell is in state of
reserved or barred, etc. The verification of some other items can also be
stationary as compared to drive test method. For example, the UL/DL frequency
assignment, the Physical Cell Identifier, the TAC of cells can be identified by
using a test UE with engineering mode, but these items can also be verified by
drive test. The drive test can be used to identify problems related to coverage,
handover, service accessibility and data throughput, which in turn will drill down
to problems related to engineering and configuration faults, such as feeders,
insufficient transmission bandwidth configuration, etc.

As a result of Single Site Verification, SSV report is the main output. Besides,
adjustment suggestions for the site should be proposed by SSV engineers for
implementation.

3.2.3 Cluster Optimization workflow

Main objective of cluster optimization is coverage optimization, neighbor cell


optimization and solve service access failure, call drop, and handover failure,
throughput issues etc. It is analysis collected data from DT and stationary test
data to analyze and locate problems, optimize network and verify adjusted
schema, which is an iterative process to assure achieve cluster acceptance
standard.

Cluster Optimization work flow as following.

Figure 3-2: Cluster Optimization Work Flow

TSS/SSV Report

System Parameters

Engineer parameters

Digital Map

Preparation

Output
Engineer
Parameters

Initial Coverage Test

Adjusting Report

Radio Parameters
Adjusting Report

Problems Analysis
Cluster
Optimization
Report

Optimization Suggestion
No

If acceptable?
Executions

Yes

End
Verification

No

If problems
solved?
Yes

Submit Report

Before optimization of cluster, the work needed to be prepared is listed as


follows.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

15

Cluster Optimization Test Schedule

Test Route Planning

Before cluster optimization, the system parameters should be imported into the
OMC, such as eNodeB ID, Cell ID, TAC, Neighbor List, etc.

Optimization Method Definition

Before cluster optimization, it is necessary to definite test route. It is required to


keep the continuous coverage along test route when not all of sites are on air.

Network Parameters Checking

Generally the ratio of on-air eNodeB of one cluster is over 80%, the cluster
optimization can be executed. The prior cluster can be arranged to optimize first.
After the optimization suggestion is adopted, a new test schedule will be made
to do justify if it is effective.

The methods of optimization include two aspects. One is engineering


parameters adjustment, such as antenna azimuth, down tilt, height, etc. Another
is radio parameters adjustment, such as channel power allocation, handover
parameters, etc.

Document Preparation

The following documents are necessary to prepare before cluster optimization:

Technical Site Survey report (TSS)

Single Site Verification report (SSV)

Site Engineering Parameters Table

OMC Configuration Parameters

Optimization Equipments Preparation

Optimization equipments include: data collection software, post-processing


software, test handset, Scanner, laptop, digital map, GPS, test vehicles, etc.

3.3 Soft Launch (Trial-running Period) Optimization

When network construction and pre-launch optimization work are finished, the
network can be put into a soft-launch stage, which means friendly users with
special access right can begin to use services provided by network and
generate useful feedback for the enhancement of network performance. The
goal of soft-launch optimization is to further optimize the whole network in order

to provide a continuous service experience in the majority of desired coverage


area and assure that no Punch List items exists in the System. If any problems
are detected in the soft-launch optimization stage, they should be solved and
checked thoroughly in the whole network. These problems might cover diverse
areas such as the EPC, eNodeB, transmission, UE, etc. Improving the related
KPIs to be commercial launch ready is the main purpose.

The main target in Soft Launch Optimization stage is focused on coverage,


neighbor relationship, RRM parameters, and border area of clusters. Neighbor
relationship optimization mainly includes missing neighbor, unidirectional
neighbor, inter-frequency neighbor, and inter-RAT neighbor. Handover related
parameters should be optimized as well. Other RRM parameters such as access
control, power configuration, load control, etc., should also be tuned selectively
to meet the traffic requirements.

The soft-launch optimization is normally based on both drive test and friendly
user feedback. As a supplementary data source, the signaling tracing is needed
to help troubleshooting some inner system problems.

Although in this stage, traffic statistics from trial users are not too much, the
KPIs report generated from soft-launched network should still be helpful to
analyze the problems. At the same time, some optimization aiding tools based
on OMC statistics can be put into use too, which may also be helpful at the early
age of the commercial network.

The output from soft-launch stage optimization is the performance optimization


report for the whole network, and also the complete set of parameters that have
been tuned for the forthcoming commercial launch. Of course these parameters
are to be optimized further in a dynamic process, but they serve as a good
baseline for further improvement of system performance.

3.4 Launched Optimization

The target in Launched Optimization stage is both the coverage and system
performance from OMC statistics. Normally, after large subscribers register, the
optimization goal is straight forward, that is, to keep stable and satisfactory end
to end system performance, and enhance the system KPIs. The daily KPIs from
OMC statistics should be monitored and optimized to designed level.

As main inputs for this optimization stage, OMC statistics and customer
complaints are to be used with higher priority than drive test and walk test data,
because after the commercial launch, traffic in the network has become
sufficient for providing detailed statistics on each KPI. The end to end
performance monitoring result can also help in this stage of optimization, for
example, for problem drilling down, trouble shooting, KPIs comparison, and cell
traffic load.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

17

The optimization process in this stage is mainly driven by KPIs analysis result.
For selected KPIs, daily analysis is made to keep up-to-date view on the
dynamically changing network performance. If any problems are identified and
classified into specific domains, corresponding teams from different domains are
responsible for the trouble shooting work, and make possible adjustments and
verifications until the problematic KPIs fall into the acceptable level again.

The output from this optimization stage would be daily and weekly KPI reports,
and also monthly performance test report through drive test. Typical or critical
trouble shooting reports made in this stage are documented and reported as
well.

4 CLUSTER OPTIMIZATION
4.1

Single-Cell Coverage Analysis

After the thorough drive test of the network, you need to check the antenna
connection sequence, single-cell overshooting, antenna side/back lobe
coverage, and zero-coverage cell based on data obtained from this test so as to
work out the actual coverage of each cell.

During the single-cell coverage analysis, you will use the LTE COVER LINE and
PCI RSRP functions provided by CNA. (or other DT analysis tool)

Figure 4-1

CNA LTE COVER LINE

Figure 4-2

CNA PCI RSRP

4.1.1

Checking the Antenna Connection Sequence

Problem Description

You will find the following problems when you are checking the antenna
connection sequence:

Antenna connection to wrong cell cause that the terminal conducts handover
between two cells of the same schema, thus impacting SINR.

Antenna connection to wrong cell leads to no configuration for neighboring cell


relationship, thus leading to call drops.

During the test, you need to solve this kind of problem if any.

Problem Analysis

Analyze the test data and check whether the main coverage direction of current
cell is also covered by another cell. If yes, there may exist wrong antenna
connection.

Also, check the accuracy of engineering parameters and PCI.

If the LTE system shares the same antenna & feeder system with other system,
you should analyze the problem by considering both the LTE and other system
test data.

Solution

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

19

Modify engineering connection for the cell where wrong antenna connection
exists.

Study Case

The antenna in Beiting Square of Guangzhou University campus should have


covered the cell FE2 (PCI94). Actually, it covers the cell FE1 (PCI93). In this
case, the engineering parameters and PCI are proved to be accurate, so the
antenna connection in this area is wrong.

Figure 4-3

Coverage Direction of Cell FE2 (PCI94)

4.1.2

Checking the Overshooting

Problem Description

Overshooting appears when signals of a cell are found in its non-neighboring


cells, and RSRP of this cell is larger than -100 dBm. Overshooting usually leads
to overlapped coverage, pilot frequency pollution and ping-pong handover.

Figure 4-4: Cell with Overshot Signals

Problem Analysis

Find out the cell with overshot signals based on the test data and by using the
PCI coverage analysis function provided by CNA.

Figure 4-5

PCI Coverage Analysis in CNA

Solution

To solve the overshooting problem, adjust the antenna azimuth and RS power.
At the same time, pay attention to the coverage of this cell on other roads, and
how the terminal conducts handover between current cell and other cell. This is
because the adjustment of antenna azimuth and RS power in current area may
impact the coverage and handover of other area.

If it is unable to solve the overshooting problem, increase the coverage effect of


the cell which is nearest to current cell, and make a proper neighboring cell
relationship configuration.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

21

Case

Overshooting problem is found in the cell FE3 (PCI 125) in the teaching building
of Guangzhou Medical University. The engineer adjusts the antenna azimuth
and RS power in this cell, and finally solve this problem.

Figure 4-6

Cell Coverage Before and After the Azimuth & RS Power Adjustment

4.1.3

Checking the Coverage of Antenna Side Lobe and Back Lobe

Problem Description

Strong coverage is found on the direction of antenna side lobe and back lobe. It
leads to pilot frequency pollution, poor SINR and abnormal handover.

Problem Analysis

Find out the cell which has strong coverage at the direction of antenna side lobe
and back lobe by analyzing the test data and using the PCI coverage analysis
function provided by CNA. This problem is usually caused by reflection, wrong
feeder connection, wrong version file and wrong antenna.

Solution

Troubleshoot this problem based on actual situation.

Case

In the Arts Building of Guangzhou Foreign Language College, the coverage area
of cell FE1 (PCI 138) is found overlapped with the cell FE3 (PCI 140). This is
due to reflection of cell FE3 (PCI 140).

Figure 4-7

Overlapped Coverage Caused by Reflection

4.1.4

Checking the Zero-Coverage Cell

Problem Description

Sometimes, no measurement value can be obtained for a cell in the test area.
On this occasion, you need to check all unused cells based on the test data and
try to find out whether this problem is caused by coverage or cell.

Problem Analysis

Find out the zero-coverage cell by analyzing the test data and using the PCI
RSRP function provided by CNA.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

23

Figure 4-8

PCI's RSRP Function

Alternatively, you can find out the zero-coverage area by exporting PCI and
RSRP of all main serving cells and their neighboring cells into an excel, and
check this parameters in the excel. Compare the PCIs in this excel with the PCIs
of the whole test area. The cell without PCI can be considered as the cell with
zero coverage.

Solution

Check the working status, parameter configuration, location and coverage of


current cell.

Case

The cells with zero coverage are listed in the table below:

Table 4-1
NE ID

Cells with Zero Coverage


PCI

Reason

6006_Guangzhou Traditional
Medical College, FE2

Broken link

2871_Western Inner Circle


Road, Guangzhou, FE4

Broken link

1008_Geigang, Guangzhou,
FE1

114

Wrong parameter
configuration

Solution

4.2

Cluster Coverage Analysis

4.2.1

Overview

4.2.2

The co-frequency networking technology is widely adopted in LTE network.


However, this technology will cause severe co-frequency interference. Therefore,
the network optimization engineers should work hard to reduce co-frequency
interference and provide good network coverage.

Engineers usually come across missed coverage, poor coverage, overshooting


and pilot frequency pollution. These problems appear when:

Inaccurate RAN planning

Inaccurate RAN planning may increase future network optimization workload.


Therefore, engineers should work hard to provide an accurate RAN planning.

Location deviation between sites defined in network planning and actual sites

Deviation between engineering parameters defined in network planning and


actual engineering parameters

The actual antenna height, azimuth, inclination, and type are different what is
specified in the network planning, and thus the actual network coverage cannot
meet customer's requirement. These problems can be solved by future network
optimization, but great project cost is also involved.

RAN environment

RAN environment may change where the network construction is different from
original construction plan, or overshooting/pilot frequency pollution appears due
to complicated road type and signal reflection. In this case, engineers should
adjust the antenna azimuth and inclination angle so as to avoid signal reflection
and reduce the transmission distance of signals.

New requirements on network coverage

Coverage area, new sites and site relocation will bring new requirements on
network coverage.

Work Scope of Coverage Optimization

Engineers usually come across missed coverage, poor coverage, overshooting,


pinhole coverage and pilot frequency pollution. The missed coverage problem
can be consider as poor coverage problem while overshooting and pilot
frequency pollution can be considered as overlapped coverage problem.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

25

Therefore, the main task of network optimization is to eliminate poor coverage


area and overlapped coverage area.

4.2.3

Weak-Coverage Optimization

4.2.3.1

Definition of Weak-Coverage

4.2.3.2

Weak coverage refers to the situation where signal is not strong enough to
guarantee a stable network and required network performance.

The area whose RSRP is less than -110dBm is considered as a weak coverage
area.

How to Find out Weak-Coverage Area

Perform the following steps to find out weak coverage area based on DT test
data:

In the CNA, find Server Cell RSRP under the sub-node Measurement of MS1
from navigation tree on the left, right-click Server Cell RSRP and select View In
Map from the short-cut menu, or click and drag Server Cell RSRP into the map
window on the right.

Figure 4-9

Weak Coverage Area Analysis -1

Find Dynamic Link under the MS1 node from the navigation tree on the left,
right-click it to select Add from the short-cut menu.

Figure 4-10

Weak Coverage Area Analysis -2

In the pop-up dialog box, select LTE-SC Link and click Apply. Wait until the
success message is displayed.

Figure 4-11

Weak Coverage Area Analysis -3

From the toolbar, click


and select LTE-SC Link from the drop-down list.
The GPS dotted line is selected.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

27

Figure 4-12

Weak Coverage Area Analysis -4

Check the line connection of server cell and RSRP legends, and you can find
signal intensity of your desired area.

Figure 4-13

Weak Coverage Area Analysis -5

4.2.3.3

How to Eliminate Weak-Coverage

Use the following methods to eliminate the weak coverage area:

Adjust the antenna height, azimuth and tilting.

Add new sites, RRU long-distance connection and cell long-distance connection.

Adjust the RS power.

Re-configure the neighboring cell relationship.

4.2.3.4

As for the coverage in residential buildings and campus, you can use various
coverage solutions, for example small-sized plate-shape antenna and smallsized omni-directional antenna.

It is suggested that you adjust engineering parameters ahead of adjusting RS


power and other parameters.

Study Cases

PCI148 Weak Coverage

Problem Description

In the cell PCI48, the RSRP of an area is found lower than -110dBm.

Figure 4-14 DT Test Results-1

Problem Analysis

As shown in the figure below, yellow arrow indicates the coverage effect of cell
PCI43, blue arrow indicates the coverage area effect of cell PCI48, and red
arrow indicates the cell PCI12. The coverage effect in PCI48 and PCI12 is not
so good because most signals are blocked by buildings, and poor coverage of
PCI43 is due to inner road coverage and green belt coverage.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

29

Figure 4-15

Coverage Effect of Cell PCI48, PCI43 and PCI12

Solution

Based on the site survey results, adjustment of engineering parameters is


proved to be invalid for weak coverage elimination. In this study case, new cells
are added to improve the coverage effect.

PCI30 Weak Coverage

Problem Description

Weak coverage is found in the cell PCI30.

Figure 4-16

DT Test Results-2

Problem Analysis

As shown in Figure 4-17, the section 1 is covered by the cell PCI30 and PCI18,
but the coverage effect in this section is quite weak.

Figure 4-17

Weak Coverage Analysis in Cell PCI30 -1

As shown in Figure 4-18, the antenna azimuth for the cell PCI30 is proper. If you
find that there is no obstacle between cell PCI30 and section 1, you can adjust
the antenna azimuth about 30 degrees so as to increase the coverage effect for
section 1.

Figure 4-18

Weak Coverage Analysis in Cell PCI30 - 2

Solution

Check whether there is any obstacle at 120 degree of cell PCI30. If not, adjust
the antenna azimuth about 30 degrees clockwise.

Lower the antenna tilting about 2 degrees for cell PCI18 so as to reduce its
interference on section 1. Afterwards, conduct drive test for the coverage area of
cell PCI18 so as to check whether this adjustment impacts the coveage area for
other sections.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

31

Figure 4-19

DT Test Results after Adjustment of Antenna Tilting and Azimuth

4.2.4

SINR Optimization

4.2.4.1

SINR Definition

4.2.4.2

SINR (signal to interference plus noise ratio) indicates the ratio between
strength of received transmission signals and strength of received interference
signals (including noises and interference).

PDCCH SINR = RS power of best serving cell / interference from the coverage
cell

SINR requirements vary with operators and network construction stages. China
Mobile requires that SINR of 95% cells should be larger than -3dB. In actual
projects, we will conduct network optimization to guarantee that SINR of 1%
cells in a project is less than -3dB, and SINR of 5% cells in a project is less than
0dB

Root cause of Low SINR : weak coverage/Interference

How to Find a Cell of Low SINR

Perform the following steps to find a cell of low SINR based on the DT test data:

In the CNA, find Server Cell RSRP under the sub-node Measurement of MS1
from navigation tree on the left, right-click Server Cell RSRP and select View In
Map from the short-cut menu, or click and drag Server Cell RSRP into the map
window on the right.

Figure 4-20

Low SINR Cell Analysis -1

Find Dynamic Link under the MS1 node from the navigation tree on the left,
right-click it to select Add from the short-cut menu.

Figure 4-21

Low SINR Cell Analysis -2

In the pop-up dialog box, select LTE-SC Link and click Apply. Wait until the
success message is displayed.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

33

Figure 4-22

Low SINR Cell Analysis -3

From the toolbar, click


and select LTE-SC Link from the drop-down list.
The GPS dotted line is selected.

Figure 4-23

Low SINR Cell Analysis -4

Check the line connection of server cell and RSRP legends, and you can find
out the signal intensity of your desired area.

Figure 4-24

Low SINR Cell Analysis - 5

4.2.4.3

4.2.4.4

How to Raise the SINR of a Cell

Use the following methods to raise the SINR of a cell:

Avoid handovers and overlapped coverage between cells of the same network
schema.

Reduce the occurrence possibility of pilot frequency pollution area.

Eliminate poor coverage area and overshooting area.

Solve the RRC re-establishment problem caused by delayed handover, no


handover and handover failure.

Study Cases

Low SINR in Cell PCI150 and Cell PCI144 Caused by Handover Failure

Problem Description

The test UE fails to finish the handover from cell PCI150 to cell PCI144.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

35

Figure 4-25

Low SINR Caused by Handover Failure

Problem Analysis

eNodeB does not make judgement after the test UE sends out the measurement
report for cell PCI150. Two seconds later the test UE triggers RRC reestablishment but is rejected. However, the neighboring cell relationship
configuraiton is proved to be correct.

On this occasion, you can make a conclusion that no judgement on


measurement report and refusal on RRC re-establishment appear because of
low-speed measurement.

Figure 4-26

Handover Failure Analysis

Solution

Make an offset of 3dB when the test UE conducts handover from cell PCI150 to
cell PCI144.

Figure 4-27

Handover Success after Adjustment

4.2.5

Overlapped Coverage Optimization

4.2.5.1

Overlapped Coverage Definition

4.2.5.2

At least two cells are found covering a continuous coverage area, and the
coverage effect from these cells meets network performance requirements. On
this occasion, this coverage area is regarded as an overlapped coverage area.

How to Find Overlapped Coverage

Perform the following steps to find a cell of low SINR based on the DT test data:

In the CNA, find Server Cell RSRP under the sub-node Measurement of MS1
from navigation tree on the left, right-click Server Cell RSRP and select View In
Map from the short-cut menu, or click and drag Server Cell RSRP into the map
window on the right.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

37

Figure 4-28

Overlapped Coverage Analysis -1

Find Dynamic Link under the MS1 node from the navigation tree on the left,
right-click it to select Add from the short-cut menu.

Figure 4-29

Low SINR Cell Analysis -2

In the pop-up dialog box, select LTE-SC Link and click Apply. Wait until the
success message is displayed.

Figure 4-30

Overlapped Coverage Analysis -3

From the toolbar, click


and choose LTE-Cover Link > LTE All Cover
from the drop-down list. The CNA will conduct coverage analysis for all cells.
If you choose LTE-Cover Link > LTE Cell Cover from the drop-down list and
select a cell, the CNA will conduct coverage analysis for this selected cell.

Figure 4-31

Overlapped Coverage Analysis -4

Check the coverage area of your desired cell based on RSRP analysis.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

39

Figure 4-32

Overlapped Coverage Analysis -5

4.2.5.3

4.2.5.4

How to Solve Overlapped Coverage

Use the following methods to eliminate overlapped coverage:

Adjust the antenna azimuth, tilting and antenna height.

Adjust RS power.

Combine two cells when the angle between antennas for these two cells is too
small.

Study Cases

Overlapped Coverage from Cell PCI160, PCI144 and PCI150

Problem Description

The SINR of sections shown in figure is lower than -3dB.

Problem Analysis

The coverage of cell PCI160 and that cell PCI150 is overlapped in section 1,
and ping-pong handover is also found in this section. The coverage of cell
PCI150 and that of cell PCI144 is also overlapped.

Figure 4-33

Overlapped Coverage Analysis

Solution

Adjust the tilting of cell PCI160 from 1 degree to 3 degrees.

4.2.6

Pilot Frequency Pollution Analysis

4.2.6.1

Definition of Pilot Frequency Pollution

In LTE system, it can be considered that pilot frequency interference is posed on


a point when many strong pilot frequencies are found on a point but no main
pilot frequency exists.

Before the definition of pilot frequency pollution is presented, you should be


familiar with three concepts: strong pilot frequency, main strong pilot frequency
and too many pilot frequencies.

Strong Pilot Frequency


RSRP > -100dbm

Main Strong Pilot Frequency


RSRP_number >= 4
Too Many Pilot Frequency
RSRP(strongest)RSRP(weakest) <= 6dB

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

41

4.2.6.2

In LTE system, it is considered that pilot frequency pollution is posed on a point


when the following two conditions are met:

RSRP of more than four cells is larger than -100dB.

RSRP(strongest) RSRP(weakest) <= 6dB

How to Find an Area with Pilot Frequency Pollution

Perform the following steps to find a cell of low SINR based on the DT test data:

In the CNA, find Server Cell RSRP under the sub-node Measurement of MS1
from navigation tree on the left, right-click Server Cell RSRP and select View In
Map from the short-cut menu, or click and drag Server Cell RSRP into the map
window on the right.

Figure 4-34

Pilot Frequency Pollution Analysis -1

Select IE Label Select from the Map toolbar.

Figure 4-35

Pilot Frequency Pollution Analysis -2

In the Label Select dialog box, select Server Cell PCI and click OK.

Figure 4-36

Pilot Frequency Pollution Analysis -3

PCIs of all main server cells are displayed.

Figure 4-37

Pilot Frequency Pollution Analysis -4

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

43

4.2.6.3

4.2.6.4

If more than one PCI is found in an area, it means that pilot frequency pollution
is posed on this area.

You can also find the area with pilot frequency pollution by checking call drops
and handover failure through CNA/CNT.

How to Eliminate Pilot Frequency Pollution

To eliminate pilot frequency pollution, you need to determine a cell and use it to
provide main strong pilot frequency. To enable a cell to provide main strong pilot
frequency:

Adjust engineering parameters of antenna

Adjust RS power.

Study Cases

Pilot Frequency Pollution in Cell PCI113 and Cell PCI134

Problem Description

SINR of the section covered by cell PCI113 and cell PCI134 is quite low.

Figure 4-38

Pilot Frequency Pollution

Problem Analysis

As shown below, when the UE conducts handover from cell PCI113 to cell
PCI149, two measurement reports have not been judged. The section shown
below is covered by the third cell, and pilot frequency pollution is also found in
this section.

Figure 4-39

Pilot Frequency Pollution Analysis

4.3

Solution

Downtilt the antenna 3 degrees and pan azimuth 20 degrees counter-clockwise


in cell PCI 149.

Handover Analysis

You usually perform the handover analysis from the following perspectives:

Missed matching of neighboring cells

Wrong matching of neighboring cells

Ping-pong handover

Handover latency

Handover failure

Before conducting the handover analysis, you need to collect statistics of


handover KPIs as shown below:

Table 4-2
Index

Handover KPIs Table


Handover
Handover
Success Rate Start

Handover
Success

Handover
Failed

Date

1
2
3
4

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

45

After all required statistics in this table is complete, you need to work out the
following information accordingly:

Location where the handover takes place

Figure 4-40

Location Where the Handover Takes Place

RSRP when the handover takes place

Table 4-3 RSRP When the Handover Takes Place


RSRP Statistics
RSRP
Range

> -80dBm

Counts
Remarks

Handover results

> -90dBm

> -100dBm

> -110dBm

<= -110dBm

Figure 4-41

Handover Results

Red curve and circle shown in this figure indicates that the handover failed.

SINR when the handover takes place

Table 4-4 SINR Statistics When the Handover Takes Place


th
th
SN
SINR Range
July 5
July 7

th

<=-3dB

28

20

10

> -3dB

> 0dB

> 3dB

> 10dB

> =15dB

36

22

Total

4.3.1

Missed Matching of Neighboring Cells

4.3.1.1

Definition of Missed Matching of Neighboring Cells

4.3.1.2

July 16

Missed matching of neighboring cell refers to the situation that the target
handover cell in the measurement report sent out by the UE cannot be found in
the neighboring cell list configured for the system. Missed matching of
neighboring cells usually lead to low downloading traffic, low SINR, RRC reestablishment and call drops.

How to Find the Missed Matching of Neighboring Cells

In LTE system, the UE does not conduct measurement based on the


neighboring cell list but conduct measurement for all cells all through workable

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

47

frequencies. Later on, the UE reports the cells which enjoy strongest signal
intensity which is beyond the handover threshold.

When the missed matching of neighboring cells exists, you will find that:

The UE tries to send out measurement report for several times.

The UE does not receive any response from the system after it sends out the
measurement report.

Low SINR (< -3dB)

You need to analyze the handover failure and the measurement reports sent out
by the UE.

If the UE sends out the measurement report but does not receive response from
the system, you can find the signaling tracing statistics as shown below:

Figure 4-42

Signaling in Case of Missed Matching of Neighboring Cells

Comply with the workflow shown below to conduct the analysis on missed
matching of neighboring cells:

Figure 4-43

Workflow of Analysis on Missed Matching of Neighboring Cells

Find out the point where the UE sends out


measurement report but does no receive
response based on the DT test data

Find out the latest signalling of RRC


Connection Reconfiguration before the
measurement is reported

Check the neighboring cell list


for the cell in the RRC
Connection Reconfiguration
signalling for this cell

Obtain the neighboring cell list


from the signalling of RRC
Connection Reconfiguration

Check whether the PCIs


contained in the measurement
report can be found in the
neighboring cell list

Other reasons

N
Configure the
neighboring cell
relationship and
conduct the
verification test

As for this workflow, you should be clear of the following items:

You need to find out the signaling which indicates that no response is made for
the measurement report based on the DT test data.

You need to obtain the PCI of target handover cell based on the measurement
report.

You need to obtain the neighboring cell list for the serving cell based on the test
data.

If no PCI of the target handover cell can be found in the neighboring cell list, it
indicates that the missed matching of neighboring cell exists.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

49

4.3.1.3

How to Solve the Problem of Missed Matching of Neighboring Cells

4.3.1.4

If the PCI of the target handover cell can be found in the neighboring cell list, it
indicates the handover problem is caused by other factors but the missed
matching of neighboring cells.

Add new neighboring cell

Study Cases

Problem Description

In the signaling shown below, many measurement reports are sent out but no
response is received.

Figure 4-44

Signaling in Case of No Response for Measurement Report

Problem Analysis

As shown in the following handover takes place according to last measurement


report, it is another cell but not the target cell where the handover takes place.
This handover takes place one minute after the first measurement report.

The content of the first measurement report and that of the second
measurement report are the same:

Figure 4-45

Analysis on Missed Matching of Neighboring Cells -1

The content of the third measurement report is shown below:

Figure 4-46

Analysis on Missed Matching of Neighboring Cells -2

The neighboring cell list contained in the RRC Connection Reconfiguration


signaling for the serving cell is shown below:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

51

Figure 4-47

Analysis on Missed Matching of Neighboring Cells -3

In this neighboring cell list, you can find cell PCI19 but not the cell PCI20. It
indicates that cell PCI20 has not been configured as the neighboring cell for cell
PCI72, and thus handover between these two cells fails.

Figure 4-48

Analysis on Missed Matching of Neighboring Cells -4

Solution

Set the cell PCI20 as the neighboring cell of cell PCI71.

Verification Test Results

In the figure below, you can find that the UE can conduct handover when
moving through these two cells and SINR restores to normal value.

Figure 4-49

Handover Restores after Elimination of Missed Matching

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

53

4.3.2

Wrong Matching of Neighboring Cells

4.3.2.1

Definition of Wrong Matching of Neighboring Cells

4.3.2.2

4.3.2.3

Wrong matching of neighboring cells refers to the situation that two cells of the
same PCI are configured as neighboring cell for main serving cell, or PCI of
neighboring cell is the same as that of main serving cell.

How to Find Wrong Matching of Neighboring Cells

Wrong matching of neighboring cells exists when:

The handover fails frequently after the measurement report is sent out.

The UE is not handed over to the cell of strongest signal intensity.

SINR is quite low, usually lower than -3dB.

At least two cells in the measurement list are of the same PCI.

How to Eliminate Wrong Matching of Neighboring Cells

Modify the PIC of neighboring cell.

4.3.3

Ping-Pong Handover

4.3.3.1

Definition of Ping-Pong Handover

4.3.3.2

Ping-pong handover refers to the situation that the UE conducts handover


frequently in the handover belt between more than two cells.

How to Find Ping-Pong Handover

You can check the downloading rate and handover quantity through GIS. Pingpong handover exists when:

The downloading rate is quite low.

SINR is quite low.

The UE conducts handover for more than three times in the handover belt.

Figure 4-50

Ping-Pong Handover

4.3.3.3

How to Eliminate Ping-Pong Handover

Comply with the following workflow to solve the ping-pong handover problem:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

55

Figure 4-51

Workflow of Elimination of Ping-Pong Handover Problem

Process the DT test data


through CAN and then export
a file containing location
information of handover
points

Display handover points in


MAPINFO

Display traffic in MAP

Ping-pong handover
exists?

Solve this problem in the


same way of elimination of
pilot frequency pollution

4.3.3.4

Eliminate ping-pong
handover problem

Study Cases

Problem Description

In the area shown below, traffic is quite low and the UE conducts handover
frequently.

Figure 4-52

Analysis on Ping-Pong Handover Problem

Problem Analysis

More than 15 times of ping-pong handover take place when the UE moves
between cell PCI161 and cell PCI 150. Ping-pong handover leads to low SINR
and low traffic.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

57

Solution

Lower the antenna tilting 3 degrees in both cell PCI161 and cell PCI150.

Verification Test Results

After the adjustment of antenna downtilt, traffic and SINR in these two cells
restores, and ping-pong handover disappears.

4.3.4

Handover Latency

4.3.4.1

Definition of Handover Latency

4.3.4.2

4.3.4.3

Handover latency here refers to the handover latency on control plane. The
latency starts at the time the UE receives the RRC Connection Reconfiguration
message, and ends at the time when the UE reports the MSG3 message.

How to Find Handover Latency

The handover latency is considered to be quite large when it is larger than the
latency value set by the network operator.

The signaling on control plane during the handover goes through two stages:

Latency from the reception of RRC Connection Reconfiguration message to the


sending of MSG1 message

Latency from the sending of MSG1 message to the reception of MSG2.

How to Solve the Handover Latency Problem

Comply with the workflow shown below to solve the handover latency problem:

Figure 4-53

Signaling Process of Handover on Control Plane

Process the DT test data

Collect statistics of handover


latency on control plane CNA

Average handover latency is


larger than the latency set by
operator?

Is MSG1 re-sent
frequently?

There is something wrong with


PRACH

There is something wrong with


RRC connection reconfiguration

Is the latency from


MSG1 to MSG2 too
large?

End

You can try to solve the handover latency problem by using following methods.
However, methods listed here are applicable to frequent sending of MSG1
message but not the reception of downlink RAR.

Obtain your desired data by using proper test devices and test terminals which
can help to obtain the signaling.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

59

If the MSG1 is not re-transmitted but the interval between MSG1 retransmission
and RRC connection reconfiguration message is quite large, check the value of
PRACH Config Index, which indicates the interval of PRACH transmission (for
more details, see protocol 36211.5.7). If the value of PRACH Config Index is
quite large, please set it to a lower value.

If frequent MSG1 transmission is found, you need to collect statistics of packets


received on PRACH. Also, you need to the uplink interference information. If the
electrical level of interference is larger than -110dBm, please troubleshoot the
uplink interference problem or modify the value of expected PRACH reception
power. Also, you can adjust the detection threshold of absolution PRACH prefix.

If the UE has received MSG1 and the system has sent out MSG2, there may be
something wrong with the uplink. In this case, you can adjust engineering
parameters, RS power, PCI, initial CCE convergence degree.

For clear idea of troubleshooting methods for handover latency, see solutions
listed below:

Table 4-5 Solutions for Handover Latency Problem


Uplink or
SN
Solution
Downlink?
1

Adjust the PRACH Config Index

Troubleshoot the uplink interference


problem
Uplink

Raise the expected PRACH reception


power

Lower the detection threshold of the


absolute PRACH prefix

Adjust the engineering parameters

Downlink

7
8

Remarks

Adjust the RS power


Adjust the PCI settings
Raise the initial convergence degree

4.3.5

Handover Failure

4.3.5.1

Definition of Handover Failure

Handover failure starts from the time the RRC Connection Reconfiguration
message is sent out, and ends at the time the RRC reconnection is triggered.

You can analyze this problem by using different measurement indexes, such as
RSRP and SINR.

4.3.5.2

How to Find Handover Failure

As shown below, the UE fails to finish the handover usually due to overtime
handover.

Figure 4-54

Overtime Handover

4.3.5.3

How to Solve the Handover Failure Problem

Comply with the workflow shown below to solve the handover failure problem:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

61

Figure 4-55

Workflow of Solving the Handover Failure Problem


Process the DT test data

Check whether there is


any problem with RSRP,
SINR and MSG2
reception

Troubleshoot the
coverage problem

Troubleshoot the
neighboring cell
problem

Troubleshoot the
MSG1 problem

N
Check neighboring cells

N
Check whether there is
any problem with MGS1
transmission

N
Check whether the
threshold of synchronous
detection is too small

Modify the value of


related parameters

N
Check whether T304 works
overtime

Modify the value of


T304

End

If RSRP, SINR and RAR reception are abnormal, it indicates that the handover
failure is caused by poor downlink coverage and non-synchronization between
UE and target cell. On this occasion, you need to improve the network coverage
effect.

During the neighboring cell check, what you have to do is to check whether
there exist cells of the same PCI.

If the MSG1 transmission is abnormal, troubleshoot this problem by modifying


the value of handover latency.

If the value of synchronization detection threshold is too small, nonsynchronization may appear, thus leading to RRC re-establishment.

4.3.5.4

T304 overtime usually leads to handover overtime. In this case, reset the value
of T304 to a larger value.

Study Cases

Problem Description

Handover failure is found in the area shown below:

Figure 4-56

Handover Failure

Problem Analysis

Handover failure occurs in this area due to weak network coverage.

Figure 4-57

Analysis of Handover Failure -1

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

63

As shown in Figure 4-58, the UE conducts handover between cell PCI304 and
PCI161. At the same time, the value of SINR is quite low, as shown in Figure
4-58.

Figure 4-58

Analysis of Handover Failure -2

Solution

Lower the antenna tilting 3 degrees in cell PCI60.

Verification Test Results

After the adjustment of antenna tilting, the value of SINR restores and handover
failure problem disappear.

Figure 4-59

SINR Value after Adjustment of Antenna Downtilt

4.4

Downloading Rate Analysis

4.4.1

Overview

4.4.2

Different from traditional networks, LTE network is a data service-based network,


and thus traffic serves as an important KPI of network performance.

Main objectives of LTE network improvement include faster data rate, short
latency, lower cost and larger system capacity and coverage.

During the LTE network optimization period, you usually need to solve the
following problems:

Weak coverage, low SINR, inter-frequency interference and intra-frequency


interference

Analysis Methods

Comply with the following workflow to analyze the traffic problem:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

65

Check whether any alarm is reported for the fault site.

Check whether interference or weak coverage exists.

Check engineering parameters and transmission.

Write down problem description and check results and send this problem report
to R&D engineers.

Figure 4-60

Workflow of Analyzing Traffic Problem

Find out the area of low service rate


based on DT test data

Any alarm is reported for the


fault cell

Clear the alarm

Does the rate meet


requirements of radio
environment

Y
Improve the coverage effect for the
area of low rate

Are the parameters of serving


cell meet requirements

Modify the value of abnormal


parameter

Y
Is the transmission abnormal

There may be something wrong with


the Version file. Report the problem
and problem location, track the
progress and verify the network
performance after adjustment

Submit problem report to the


customer and ask help for solving
transmission problem

4.4.3

Analyzing the Cell with the Maximum Downloading Rate Less than
5M

Export traffic data from the DT test data, and filter out all cells whose maximum
traffic is less than 5M.

Table 4-6
Index

Cells Whose Maximum Traffic is Less than 5M


Max PDCP Downlink PDU
ServerCell PCI
Traffic (Mbit/s)

Date

1
2
Table 4-7
Index

Parameter Table for Cells Whose Maximum Traffic is Less than 5M


PDCP DL PDU Traffic
PCI
RSRP
SINR
(Mbit/s)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

67

Figure 4-61

Cells Whose Maximum Traffic is Less than 5M

4.4.3.1

Area 1
Figure 4-62

DT Test Data of Area 1

Problem Description

When the UE is conducting handover from cell PCI149 to cell PCI134, it sends
out measurement report but does not receive any response. It triggers RRC
connection re-establishment in target handover cell but is refused. Therefore, it
triggers the re-establishment of a new service.

Problem Analysis

4.4.3.2

After the check of neighboring cell configuration, no wrong configuration is found.


However, cell PCI147 and cell PCI149 pose pilot frequency pollution over area 1,
thus leading to low SINR, handover failure and low bitrate.

Solution

Lower the power of cell PCI147 and cell PCI149 from 12 to 9, and increase the
power of cell PCI134 from 9 to 12.

Verification Test Results

After the adjustment, when the UE moves through this area, it conducts
handover between cell PCI 86<> cell PCI 134<> cell PCI 133<> cell PCI
113. Cell PCI147 and cell PCI149 pose no coverage on this area. Also, SINR is
raised to 10dB, and handover and rate restore to normal status.

Area 2
Figure 4-63

DT Test Data of Area 2

Problem Description

As shown in figure below, when the UE moves through area 2, it conducts


handover between cell PCI32<> cell PCI 64<> cell PCI 4<> cell PCI 64.
Ping-pong handover can be found when the UE moves between cell PCI41 and
cell PCI64, thus leading to call drops, service re-establishment and low rate.

Problem Analysis

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

69

4.4.4

The cell PCI64 poses network coverage on a campus, and the coverage radius
here is quite small. When the UE conducts handover between cell PCI41 and
cell PCI64, signals from cell PCI64 fade away quickly, thus leading to low SINR,
call drops and no service traffic.

Solution

To solve the ping-pong handover problem, you need to eliminate cell PCI64's
coverage on this area. Therefore, lower the antenna inclination angle in this cell
3 degrees, or reduce the RS power in this cell.

Verification Test Results

After the adjustment, ping-pong handover and call drops disappear, and traffic
also restores.

Analyzing the Cell with the Average Downloading Rate Ranging from
5M to 10M
Table 4-8
SN

Cells Whose Average Traffic Ranges from 5M to 10M


PCI
Average PDCP Traffic (Mbps)

Date

64

0.07

2012/7/16

149

0.51

2012/7/16

61

3.65

2012/7/16

139

3.67

2012/7/16

134

4.56

2012/7/16

82

5.85

2012/7/16

114

5.91

2012/7/16

88

6.26

2012/7/16

8.47

2012/7/16

10

37

8.94

2012/7/16

11

94

9.11

2012/7/16

12

140

9.42

2012/7/16

13

121

9.42

2012/7/16

Figure 4-64

Cells Whose Average Traffic Ranges from 5M to 10M

4.4.4.1

Area 1

4.4.4.2

See 4.4.3.1.

Area 2
Figure 4-65

DT Test Data -1

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

71

4.4.4.3

Problem Description

As shown above, when the UE conducts handover between cell PCI11 and cell
PCI21, it sends out measurement report but eNodeB does not receive this report,
or UE does not receive the handover judgment sent by eNodeB, thus leading to
handover failure, service re-establishment and low rate.

Problem Analysis

Area 2 is covered by cell PCI11, cell PCI21, cell PCI28 and cell PCI69, and
RSRP here is about -101dB. The cell PCI is about one kilometer away from this
area, namely its signal overshoot to this area. Also, cell PCI11 and cell PCI21
are not neighboring cells. Therefore, when the UE moves through cell PCI11, it
cannot receive handover judgment for handover to cell PCI21 from eNodeB
although it has sent the measurement report.

Solution

Lower the tilting in cell PCI11, or configure neighboring cell relationship for cell
PCI11 and cell PCI21.

Area 3
Figure 4-66

DT Test Data -2

Problem Description

When the UE is making phone calls or using data service in cell PCI25, it
detects strong RSRP from cell PCI68, so it triggers handover from PCI25 to

PCI68. However, the handover fails, service re-establishment is refused and no


traffic can be found in this area for a period of time.

4.4.4.4

Problem Analysis

After the UE receives measurement judgment from eNodeB, it sends back the
Handover Reconfiguration Completion message. RS power in cell PCI68
disappear suddenly and the handover fails. The problem may be caused by cell
breakdown.

Solution

Troubleshoot problem in cell PCI68.

Area 4
Figure 4-67

DT Test Data -3

Problem Description

When the UE conducts handover from PCI27 to PCI39, handover fails. Call
drops, service re-establishment and low rate are also found in this area.

Problem Analysis

The cell PCI29 covers the Information Building 3. However, the antenna of this
cell is installed in the center of building roof, thus leading to weak coverage over
this area.

Solution

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

73

4.4.4.5

Configure neighbour cell relationship for cell PCI27 and cell PCI37.

Area 5
Figure 4-68

DT Test Data -4

Problem Description

When the UE moves from cell PCI53 to PCI61, the UE sends out a lot of
handover requests to eNodeB, but does not receive any handover judgment.

Problem Analysis

There are residential buildings between cell PCI53 and PCI61, and there is a
high-rise crossroad in area 5. On this occasion, signals from PCI53 fade away
quickly at the turning corner.

Solution

Lower the RS power of cell PCI53 from 12dBm to 9dBm, and raise the RS
power of cell PCI61 from 6dBm to 9dBm. Moreover, increase neighboring cell
offset by 3dB.

Verification Test Results

After the adjustment, handover and rate in area 5 restore.

4.5 Access Analysis


4.5.1

Call Failures

Figure 4-69 shows the cause analysis procedure for call failures.

Figure 4-69

Cause Analysis Procedure for Call Failures


Start

Identify a radio access problem


using a data analyzer

Drive test
data

Radio access failure

RRC connection
establishment failure

Troubleshoot an RRC
connection
establishment problem

Authentication and
encryption failure

Troubleshoot an
authentication and
encryption problem

E-RAB setup failure

Troubleshoot an E-RAB
setup problem

Troubleshoot an
abnormal problem

End

The call failure cause analysis procedure can be explained as follows:

1.

Using such drive test data analyzers as TEMS Discovery or ZXPOS CNA-FDD LTE,
determine the exact time when a radio access failure occurs, and then retrieve the
pilot information and signaling procedure before and after this failure occurs.

2.

Align the time of the UE collected signaling with that of the STS signaling trace, and
then find the exact time of problem occurrence using the STS signaling trace tool.

3.

Check whether any hardware alarm or notification is raised for the problematic cell
through the OMC, when a radio access failure occurs.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

75

4.

Using the STS signaling trace tool and UE signaling procedure, locate the radio
access failure problem by following this cause analysis procedure.

5.

Analyze and solve the radio access problem by following the specific
troubleshooting procedure, including RRC connection establishment, authentication
and encryption, E-RAB connection establishment, and equipment fault.

4.5.2

RRC Connection Establishment Failures

4.5.2.1

Procedure for Troubleshooting an RRC Connection Establishment Problem

An RRC connection establishment failure can be processed by using the UE


signaling procedure and STS signaling trace tool, as shown in Figure 4-70.

Figure 4-70
Problem

Procedure for Troubleshooting an RRC Connection Establishment

RRC setup problem

UE sent
Preamble?

No

UE abnormal
?
problem

No

Adjust PRACH
parameters

No

Adjust PDCCH
parameters

No

UE abnormal
problem

Yes
eNodeB received
?
Preamble
Yes
UE received RA
?
reasons
Yes
UE sent RRC
?
request
Yes
eNodeB received
?
RRC request

Adjust UL open
loop power control
parameters

No

Yes
eNodeB sent setup No
?
message
Yes

Congestion or other
problem
No

UE received setup No
?
message
Yes

Cell reselection
Yes

No
UE sent setup
?
complete message

Adjust PDCCH
parameters

Optimize cell
reselection
Radom Access
contention

Yes
eNodeB received
setup complete
message
?

No

Adjust UL open
loop power control
parameters

Yes

End

4.5.2.2

Cause Analysis

An RRC connection establishment failure may be caused by one of the following


factors:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

77

Call signaling interruption because the call is originated from a poorly covered cell
with weak signals

Uplink RACH problem

Paging failure during the TAU

Cell reselection parameter misconfiguration: The call is not originated from the best
cell due to cell reselection time delay.

RS power and power allocation parameter misconfiguration

Traffic congestion

Equipment fault

4.5.2.3

It is highly likely that an RRC connection establishment failure may occur due to
the following factors:

Weak signals in the downlink

Uplink RACH problem

Cell reselection parameter misconfiguration

Equipment fault

Solutions to Highly Probable RRC Connection Establishment Problems

To solve these highly probable problems, ZTE recommends the following


solutions:

Perform the RF optimization to solve an undershooting or overshooting problem.

Optimize the TA edges to reduce unnecessary location update. If possible, it is best


to include the TA edges in a sparsely populated area.

To ensure that the UE can reselect a preferable cell for originating the call, optimize
the cell reselection parameters of the problematic cell.

Modify such random access and power allocation parameters as PRACH, PCCH,
PDCCH, PDSCH, and Msg3 power offset, whenever necessary.

Modify the RS power to cover the cell radius as expected.

4.5.2.4

Failing to Receive the RRC Connection Request Message

If the RSRP is relatively low in the downlink, you can infer that it may be caused by
a coverage problem.

If the RSRP is not too low (-105 dBm or more) in the downlink, you can infer that it
may be caused by an RACH problem.

4.5.2.5

Can you explain why the eNodeB fails to receive the RRC Connection Request
message that is sent from the UE?

This problem may usually be caused by these potential factors:

Insufficient power ramping level

Too low output power (UE)

eNodeB fault (too high VWSR)

Improper cell radius configuration

Failing to Receive the RRC Connection Setup Message

After receiving the RRC Connection Request message from the UE, the
eNodeB sends the RRC Connection Setup message, but the UE fails to
receive the RRC Connection Setup message. This problem may usually be
caused by these potential factors:

Poor coverage

Inappropriate cell selection and reselection parameters

To solve this problem, ZTE recommends the following solutions:

If this problem is caused by poor coverage, ZTE recommends you enhance the
coverage if conditions permit. For example, you can add certain sites or optimize
the antenna and feeder system. If conditions do not permit, ZTE recommends you
improve the RS power and adjust the corresponding power allocation parameters.

If this problem is caused by inappropriate cell selection and reselection parameters,


ZTE recommends you adjust the corresponding cell selection and reselection
parameters to speed up the cell selection and reselection procedure.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

79

4.5.2.6

Delivering the RRC Connection Reject Message

4.5.3

Congestion: In this case, you need to check the network usage.

Unspecified: In this case, you need to check the log information.

When receiving the RRC Connection Setup message, the UE fails to deliver
the RRC Connection Setup Complete message. If the signals in the downlink
are normal, you can infer that this problem may be caused by a handset fault.

When the UE delivers the RRC Connection Setup Complete message, the
eNodeB fails to receive the RRC Connection Setup Complete message. There
is a very small probability that this problem will occur because the transmit
power of the UE will be increased through the initial uplink power control.
Temporarily, no good solution is readily available to this problem.

Authentication and Encryption Failures

4.5.3.1

After receiving RRC Connection Request message, the eNodeB delivers the
RRC Connection Reject message to the UE. When finding the RRC
Connection Reject message, you need to check the specific cause value:

When an authentication failure occurs, you need to analyze potential factors,


depending on the cause value (MAC Failure or Synch Failure) carried in the
Authentication Failure message that is sent from the UE to the MME.

MAC Failure

During the authentication procedure, the UE checks the AUTN parameter


carried in the Authentication Request message that is sent from the MME.
When finding incorrect MAC information, the UE delivers the Authentication
Failure message that carries the cause value (MAC Failure) to the MME, as
shown in Figure 4-71.

Figure 4-71

Authentication Failure Message (Cause Value: MAC Failure)

UE

MME

AUTHENTICATION REQUEST
Start T3460
AUTHENTICATION FAILURE (cause = "MAC failure")
Stop T3460

Start T3418
IDENTITY REQUEST

Start T3470
IDENTITY RESPONSE (IMSI)
Stop T3470
AUTHENTICATION REQUEST
Stop T3418

Start T3460
AUTHENTICATION RESPONSE
Stop T3460

4.5.3.2

This problem may usually be caused by these potential factors:

Illegal subscriber

Ki or OPc configuration inconsistency between the USIM and the HLR

Synch Failure

During the authentication procedure, the UE checks the SQN parameter carried
in the Authentication Request message that is sent from the MME. When
finding incorrect SQN information, the UE delivers the Authentication Failure
message that carries the cause value (Synch Failure) to the MME, as shown in
Figure 4-72.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

81

Figure 4-72

Authentication Failure Message (Cause Value: Synch Failure)

UE

MME

AUTHENTICATION REQUEST
Start T3460
AUTHENTICATION FAILURE (cause = "synch failure")
Stop T3460

Start T3420

Perform
re-synch
with HSS
AUTHENTICATION REQUEST
Start T3460

Stop T3420
AUTHENTICATION RESPONSE

Stop T3460

4.5.4

This problem may usually be caused by these potential factors:

Illegal subscriber

Equipment fault

E-RAB Connection Establishment Failures

Based on the drive test data, the initial E-RAB connection establishment
success rate is measured from the time when the UE sends out the PDN
Connectivity Request message to the time when the UE returns the Activate
Default EPS Bearer Context Accept message.

An E-RAB connection establishment failure may usually be caused by these


potential factors:

Weak signals

UE/MME rejects

Parameter misconfiguration

Corner effect

Equipment faults

4.5.4.1

Weak Signals

A weak signal or blind spot can become a very critical factor for the UE to get
access to the E-UTRAN, especially when the UE is put in mobility or the radio
environment is sharply changed. When the UE is put in mobility, especially the
RSRP is smaller than -110 dBm or the SINR is smaller than -3 dB (meaning that
the UE is stationed in a high path loss or low SNR coverage area), the Samsung
UE fails to demodulate signals and thereby experiences a radio access failure.
When the UE is motionlessly stationed in an isolated area (meaning that the
RSRP is smaller than -120 dBm), the UE can successfully get access to the LTE
network.

This problem may usually be caused by these potential factors:

Poor coverage

A poor coverage problem may occur in the uplink or downlink:

If a poor coverage problem occurs in the uplink, the eNodeB cannot receive or
demodulate the response message received from the UE. In this case, you
can check the RSSI to see if it is caused by radio interference in the uplink.

If a poor coverage problem occurs in the downlink, the demodulation function


of the UE does not work very well. In this case, you need to optimize the RF.

To achieve optimum coverage, ZTE recommends the following solutions:

If a poor coverage problem occurs in the uplink, you need to check whether
radio interference is present in the uplink.

If a poor coverage problem occurs in the downlink, you need to eliminate the
malfunctioning demodulation factors:

Adding a new eNodeB

Optimizing the RF

Adjusting the antenna and feeder system

Optimize the RS power

The UE is not stationed in an optimum cell.

In the case of a quick signal change, the location update of the stationed cell cannot
be implemented until the E-RAB connection is already established. As a result, the
E-RAB connection establishment can only be completed in a weak-signal cell, and
thereby causing a devastating failure.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

83

4.5.4.2

In this case, you need to increase the intra-frequency cell reselection threshold and
speed. This can force the UE to quickly station in an optimum cell.

UE/MME Rejects

The reject is resulted from the activated EPS bearer context.

The reject is resulted from the security mode of the NAS layer.

4.5.4.3

The UE rejects may usually be caused by these potential factors:

When the MME delivers the Attach Reject message, the cause value may
include:

Network failure

EPS services not allowed in this PLMN

ESM failure

No EPS bearer context activated

For more information about the UE/MME rejects during the radio access
procedure, please refer to the corresponding message description guide.

To solve this problem, ZTE recommends the following solutions:

If a UE reject problem occurs because the UE is mal-functioning, you need to


upgrade the HW/SW version or replace the UE.

If an MME reject problem occurs, you need to check the STS signaling trace data
on the eNodeB side to see if it is caused by a poor coverage or S1 link failure
problem. If not, you need to hand this problem to the core network technical
support team.

Parameter Misconfiguration

When a radio access failure occurs, we need to first compare the parameters of
a well-functioning cell to those of a mal-functioning cell to see if they are
consistently configured. If not, check whether such a failure is caused by
parameter misconfiguration. In normal cases, it is recommended to enable the
intra-frequency measurement and cell reselection. To solve this problem, ZTE
recommends you configure scenario-specific parameters as required.

4.5.4.4

Corner Effect

The corner effect is present when the original cell experiences a fast signal
decrease but the target cell experiences a fast signal increase. For example, the
signal of the original cell may be sharply decreased by 10 dB within one second.
On the contrary, the signal of the target cell may be sharply increased by 10 dB
within one second.

This corner effect may be accompanied by a call drop problem or a call


origination, especially in a densely-populated urban area. However, we now
have very limited ways to tackle this issue.

To solve this problem, it is recommended to optimize the RF as below:

Adjusting the antenna or RS power to make the target cell bypass the corner effect,
meaning that the cell reselection should be completed prior to the corner effect

Adjusting the antenna of the serving cell to avoid a fast signal change caused by
the corner effect, and thus decreasing the call failure rate

4.6 Call Drop Analysis

The call drop rate reflects the system sustainability for different services; its the
most important performance indicator that users can directly experience.
Generalized call drop rate definition should include both the EPC and eNodeB
call drop, in this section; radio related call drops are emphasized. From high
level point of view, most call drops are caused by the following three types of
radio problems, that is, coverage, handover, and interference. They are
described below, respectively.

4.6.1 Caused by coverage problems

According to optimization experience, the following coverage problems may


result in call drops:

Due to the isolated island effect, the UE in the isolated cell cannot make outgoing
handover;

Coverage holes exist at the intersected area of two adjacent cells, UE loses
coverage during the call;

Shadow fading effect caused by high buildings, this results in weak coverage area
or areas with rapid signal fluctuation.

Possible solutions are given below:

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

85

Find the weak coverage area and try to optimize by RF adjustments. If the weak
coverage area exists in shopping malls, tunnels, underground parking lands,
subway entrance, or high buildings, etc., the coverage can be enhanced by adding
indoor coverage system.

Check the hardware problems, especially the power output of serving cell and
neighbor cells, make sure that there is no cell shrink caused by PA problems.

4.6.2 Caused by handover problems

According to optimization experience, the following handover problems may


result in call drops:

Hardware problems result in abnormal process

Isolated island problem result in handover failure

Source cell in seriously interfered in downlink or uplink results in handover failure;

Handover parameters are not properly set;

Ping pong handover failure result in call drop;

Signal sudden drop in corner or shadow area, which results in handover failure and
call drop.

Possible solutions are given below:

Check hardware faults, make sure theres no hardware alarm;

Make RF adjustments to control interference in network;

Control cell load at stable level;

Modify handover related radio parameters according to radio environments;

Control and eliminate the internal and external interference in network.

4.6.3 Caused by interference problem

According to optimization experience, the following interference problems may


result call drops:

Intra-frequency multiple access interference;

Other RAT system interference;

Interference caused by microwave, satellite receiver, radar, TV receiver, etc.

Possible solutions are given below:

Control cell load;

Make RF adjustments to control the overshooting;

Add space isolation or Tx/Rx filter to reduce interference from other systems.

5 OSS KPI OPTIMIZATION


5.1 Network Access Performance Optimization

In the LTE network, the UE in Inactive state or IDLE state triggers the initial
random access by sending the attach request or Service Request message. The
RRC connection is thus established. The signaling connection for NAS
information transmission is established through the initial transport before the ERAB is established. To evaluate radio access performance, we are going to
focus on system availability and system accessibility

5.1.1 System Accessibility

Table 5-1 summarizes the system accessibility indicators and recommended


values.

Table 5-1 System Accessibility Indicators and Recommended Values


Initial E-RAB establishment success rate
PS
DT/CQT

97%

RRC establishment success rate

PS

Stat.

96%

E-RAB establishment success rate

PS

Stat.

97%

These recommended values are shown for reference only. The values of all
system accessibility indicators should be dependent on the agreed-upon
project/contract configuration information.

5.1.2 System Availability

Table 5-2 summarizes the system availability indicators and recommended


values.

Table 5-2 System Availability Indicators and Recommended Values


Cell availability
PS
Stat.

99%

E-RAB block rate

PS

Stat.

1%

Paging congestion rate

PS

Stat.

1%

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

87

These recommended values are shown for reference only. The values of all
system availability indicators should be dependent on the agreed-upon
project/contract configuration information.

5.1.3 Commonly Used Methods

Based on the understanding of network situations and potential problems, we


need to tackle different network problems by adopting appropriate performance
statistics analysis methods, as summarized in Table 5-3.

Table 5-3 Commonly Used Performance Statistics Analysis Methods


No. Method
Description

Ranking the
worst TOP N
cells

Firstly, identify the worst TOP N cells based on the average


values of the involved performance statistics indicators in a
busy hour or whole day.
Secondly, analyze and optimize the worst TOP N cells.
Finally, prioritize these optimization tasks.

Time-based
change trend
chart

Firstly, produce a change trend chart of a network, cluster, or


cell on an hourly, daily, or weekly basis
Then, analyze how the involved performance statistics
indicators are changed over the time

Problem
location

Performance statistics indicators are often changed in certain


areas due to the following factors:
- Increased traffic load
- Varied traffic model
- Ever-changing radio environment
- eNodeB fault
- Radio interference in the uplink or downlink
These factors will have an adverse impact on network
performance.
By comparing the changed performance statistics indicators to
the unchanged ones, highlight the most sharply changed
eNodeBs or sectors in an electronic map, and then concentrate
on them for further analysis.

Comparison

A performance statistics indicator can be influenced by a


number of factors. Some factors may be changed; others may
remain unchanged. To verify a problem, you need to choose
the appropriate objects to be compared.
When observing a performance statistics indicator, you cannot
focus on whether the absolute value is high or low, but focus
on whether the relative value is high or low.

Depending on different performance statistics objects, performance statistics


analysis methods can be roughly divided into the following types:

OMM-level performance statistics analysis: It focuses on evaluating and analyzing


performance statistics indicators on a network basis.

Cell-level performance statistics analysis: It focuses on locating a problem on a cell


basis.

5.1.3.1

It should be noted that the cell-level performance statistics analysis is


considered as part of the OMM-level performance statistics analysis. In real
situations, OMM-level performance statistics analysis is generally followed by
the cell-level performance statistics analysis. However, the failure counters in
the OMM are primarily based on a cell basis. The subsequent sections will also
concentrate on the cell-level performance statistics analysis.

OMM-Level Performance Statistics Analysis Procedure

Figure 5-1 shows the OMM-level performance statistics analysis procedure.

Figure 5-1

OMM-Level Performance Statistics Analysis Procedure


Start

Performing the
OMM-level traffic
statistics analysis

Checking whether
performance statistics
indicators can meet the
requirements
N
Identifying the worst
TOP N cells

Analyzing the
problematic
cells

Locating and solving


the problem

End

The OMM-level performance statistics analysis procedure is explained in detail


as below:

1.

Check whether the OMM-level performance statistics indicators can meet the
requirements. If yes, this procedure is closed.

2.

If not, identify the worst TOP N cells for further analysis.

3.

Locate and solve the problem.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

89

5.1.3.2

4.

Check the new results of OMM-level performance statistics indicators to see if they
can meet the requirements. If yes, this procedure is closed.

5.

If the problem still persists, follow the cycle until you can verify that OMM-level
performance statistics indicators can meet the requirements.

Cell-Level Performance Statistics Analysis Procedure

Figure 5-2 shows the cell-level performance statistics analysis procedure.

Figure 5-2

Cell-Level Performance Statistics Analysis Procedure


Start

Performing cell-level
traffic statistics
analysis

Checking whether traffic


statistics indicators
cannot meet the
requirements in any cell
Y

Analyzing the specified cause


value t identify the root cause

Working out a
solution and
implementing it

End

The cell-level performance statistics analysis procedure is explained in detail as


below:

1.

Check whether the cell-level performance statistics indicators cannot meet the
requirements. If not, this procedure is closed.

2.

If yes, analyze the specified cause value to identify the root cause of the problem.

3.

Work out a solution, and then implement it.

4.

Check the new results of cell-level performance statistics indicators to see if they
can meet the requirements. If yes, this procedure is closed.

5.

If the problem still persists, follow the cycle until you can verify that cell-level
performance statistics indicators can meet the requirements.

5.1.4 System Accessibility KPI


5.1.4.1

RRC Connection Establishment Success Rate

The RRC connection establishment success rate is the ratio of the RRC
connection establishment successes to the RRC connection establishment
attempts. This indicator represents the service acceptability of the eNodeB or
the UE, which is essential for measuring the call connectivity.

Figure 5-3 shows the RRC connection establishment procedure.

Figure 5-3

RRC Connection Establishment Procedure

UE

EUTRAN

RRCConnectionRequest
1

RRCConnectionSetup
2

RRCConnectionSetupComplete
3

RRCConnectionReject
4

RRCConnectionSetupComplete
5

The RRC connection establishment procedure primarily contains the following


steps:

RRC connection establishment completion

RRC connection establishment rejection

RRC connection establishment failure

The major sampling points are summarized in Table 5-4.

Table 5-4 Major Sampling Points in the RRC Connection Establishment Procedure
Sampling
Description
Point
1

The eNodeB receives the RRC Connection Request message from the
UE.

The eNodeB sends the RRC Connection Setup message to the UE.

The eNodeB receives the RRC Connection Setup Complete message


from the UE.

The eNodeB sends the RRC Connection Reject message to the UE.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

91

The timer is timing out when the eNodeB waits for the RRC Connection
Setup Complete message from the UE.

The RRC connection establishment procedure is started when the eNodeB


receives the RRC Connection Request message from the UE, and terminated
when the eNodeB receives the RRC Connection Setup Complete message
from the UE.

By counting the RRC Connection Request messages and the RRC Connection
Setup Complete messages, the RRC connection establishment Success Rate
indicator can be calculated as follows:

RRC Connection Establishment Success Rate = RRC Connection


Establishment Successes/RRC Connection Establishment Attempts

RRC connection establishment failures are primarily caused by the following


factors:

ENB Admission Failure

Timeout

Other Reason

Table 5-5 summarizes the RRC connection establishment failure counters.

Table 5-5 RRC Connection Establishment Failure Counters


Counter
Description
C373200001
C373200002
C373200003
C373200005
C373200006
C373200007
C373200009
C373200010
C373200011
C373200013
C373200014
C373200015

Number of Mt-Access RRC Establishment Failure due to Timeout


Number of Mt-Access RRC Establishment Failure due to ENB
Admission Failure
Number of Mt-Access RRC Establishment Failure due to Other
Reason
Number of Mo-Signaling RRC Establishment Failure due to
Timeout
Number of Mo-Signaling RRC Establishment Failure due to ENB
Admission Failure
Number of Mo-Signaling RRC Establishment Failure due to Other
Reason
Number of Mo-Data RRC Establishment Failure due to Timeout
Number of Mo-Data RRC Establishment Failure due to ENB
Admission Failure
Number of Mo-Data RRC Establishment Failure due to Other
Reason
Number of High Priority Access RRC Establishment Failure due
to Timeout
Number of High Priority Access RRC Establishment Failure due
to ENB Admission Failure
Number of High Priority Access RRC Establishment Failure due
to Other Reason

C373200017
C373200018
C373200019

Number of Emergency RRC Establishment Failure due to


Timeout
Number of Emergency RRC Establishment Failure due to ENB
Admission Failure
Number of Emergency RRC Establishment Failure due to Other
Reason

On the eNodeB side, RRC connection establishment failures include:

ENB Admission Failure

After receiving the RRC Connection Request message from the UE, the eNodeB
sends the RRC Connection Reject message.

Timeout

After delivering the RRC Connection Setup message, the eNodeB does not
receive the RRC Connection Setup Complete message from the UE.

5.1.4.1.1 ENB Admission Failure

The potential causes of an eNodeB acceptance failure include:

eNodeB hardware fault, such as too hot power amplifier (occasional)

Equipment alarm (air conditioner and power amplifier)

5.1.4.1.2 RRC Connection Reject Due to Traffic Congestion

If an RRC connection establishment failure is caused by traffic congestion, you


need to check which type of resources is insufficient. For example, when the
eNodeB is experiencing a power resource application failure, you need to check
whether the radio access parameters are consistent with the default values. If all
the parameters are correctly configured, you need to check such counters as
resource utilization and activated subscribers to see if the network is overloaded.

5.1.4.1.3 Timeout

The potential causes of a timer timeout failure include:

The UE fails to receive the RRC Connection Setup message from the eNodeB.

Certain coverage, cell selection and reselection parameters are improperly


configured.

For more information on how to solve this problem, see section 4.5.2 "RRC
Connection Establishment Failures.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

93

5.1.4.2

The eNodeB fails to receive the RRC Connection Setup Complete message from
the UE probably because the initial transmit power in the uplink is set to a too low
value.

Initial E-RAB Connection Establishment Success Rate

The initial E-RAB connection establishment success rate is the sum of all QCIbased service success rates. This indicator represents the service acceptability
of the eNodeB or the UE.

Figure 5-4 shows the initial E-RAB connection establishment procedure.


Figure 5-4

Initial E-RAB Connection Establishment Procedure

UE

EUTRAN

MME

InitialContextSetupRequest
1

RRCConnectionReconfigration
2

RRCConnectionReconfigrationComplete
3

InitialContextSetupResponse
4

RRCConnectionReconfigrationComplete
5

InitialContextSetupFailure

InitialContextSetupRequest

InitialContextSetupFailure

The initial E-RAB connection establishment procedure primarily contains the


following steps:

Initial E-RAB connection establishment completion

Initial E-RAB connection establishment timeout

Initial E-RAB connection establishment security failure

The major sampling points are summarized in Table 5-6.

Table 5-6 Major Sampling Points in the Initial E-RAB Connection


Establishment Procedure

Sampling
Point

Description

The eNodeB receives the Initial Context Setup Request message from
the MME.

The eNodeB sends the RRC Connection Reconfiguration message to


the UE.

The eNodeB receives the RRC Connection Reconfiguration Complete


message from the UE.

The eNodeB sends the Initial Context Setup Response message to the
MME.

The timer is timing out when the eNodeB waits for the RRC Connection
Reconfiguration Complete message from the UE.

The eNodeB sends the Initial Context Setup Failure message to the
MME because of a security failure or other UE interaction failure.

The eNodeB sends the Initial Context Setup Failure message to the
MME because it cannot find the ID of the context.

The initial E-RAB connection establishment procedure is started when the


eNodeB receives the Initial Context Setup Request message from the UE, and
terminated when the eNodeB receives the Initial Context Setup Response
message from the MME.

By counting the number of successfully and unsuccessfully received E-RABs in


the Initial Context Setup Request and Initial Context Setup Response
messages, the Initial E-RAB Connection Establishment Success Rate
indicator can be calculated as follows:

Initial E-RAB Connection Establishment Success Rate = Initial E-RAB


Connection Establishment Successes/Initial E-RAB Connection Establishment
Attempts

Initial E-RAB connection establishment failures are primarily caused by the


following factors:

ENB Admission Failure

Uu Interface Failure

Security Failure

Parameter Error

Other Reason

Table 5-7 summarizes the initial E-RAB connection establishment failure


counters.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

95

Table 5-7 Initial E-RAB Connection Establishment Failure Counters


Counter
Description
C373210201

Number of Initial QCI1 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210202

Number of Initial QCI1 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210203

Number of Initial QCI1 SAE Bearers Establishment Failures due


to Security Failure

C373210204

Number of Initial QCI1 SAE Bearers Establishment Failures due


to Parameter Error

C373210205

Number of Initial QCI1 SAE Bearers Establishment Failures due


to Other Reason

C373210207

Number of Initial QCI2 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210208

Number of Initial QCI2 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210209

Number of Initial QCI2 SAE Bearers Establishment Failures due


to Security Failure

C373210210

Number of Initial QCI2 SAE Bearers Establishment Failures due


to Parameter Error

C373210211

Number of Initial QCI2 SAE Bearers Establishment Failures due


to Other Reason

C373210213

Number of Initial QCI3 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210214

Number of Initial QCI3 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210215

Number of Initial QCI3 SAE Bearers Establishment Failures due


to Security Failure

C373210216

Number of Initial QCI3 SAE Bearers Establishment Failures due


to Parameter Error

C373210217

Number of Initial QCI3 SAE Bearers Establishment Failures due


to Other Reason

C373210219

Number of Initial QCI4 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210220

Number of Initial QCI4 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210221

Number of Initial QCI4 SAE Bearers Establishment Failures due


to Security Failure

C373210222

Number of Initial QCI4 SAE Bearers Establishment Failures due


to Parameter Error

C373210223

Number of Initial QCI4 SAE Bearers Establishment Failures due


to Other Reason

C373210225

Number of Initial QCI5 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210226

Number of Initial QCI5 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210227

Number of Initial QCI5 SAE Bearers Establishment Failures due


to Security Failure

C373210228

Number of Initial QCI5 SAE Bearers Establishment Failures due


to Parameter Error

C373210229

Number of Initial QCI5 SAE Bearers Establishment Failures due


to Other Reason

C373210231

Number of Initial QCI6 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210232

Number of Initial QCI6 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210233

Number of Initial QCI6 SAE Bearers Establishment Failures due


to Security Failure

C373210234

Number of Initial QCI6 SAE Bearers Establishment Failures due


to Parameter Error

C373210235

Number of Initial QCI6 SAE Bearers Establishment Failures due


to Other Reason

C373210237

Number of Initial QCI7 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210238

Number of Initial QCI7 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210239

Number of Initial QCI7 SAE Bearers Establishment Failures due


to Security Failure

C373210240

Number of Initial QCI7 SAE Bearers Establishment Failures due


to Parameter Error

C373210241

Number of Initial QCI7 SAE Bearers Establishment Failures due


to Other Reason

C373210243

Number of Initial QCI8 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210244

Number of Initial QCI8 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210245

Number of Initial QCI8 SAE Bearers Establishment Failures due


to Security Failure

C373210246

Number of Initial QCI8 SAE Bearers Establishment Failures due


to Parameter Error

C373210247

Number of Initial QCI8 SAE Bearers Establishment Failures due


to Other Reason

C373210249

Number of Initial QCI9 SAE Bearers Establishment Failures due


to ENB Admission Failure

C373210250

Number of Initial QCI9 SAE Bearers Establishment Failures due


to Uu Interface Failure

C373210251

Number of Initial QCI9 SAE Bearers Establishment Failures due


to Security Failure

C373210252

Number of Initial QCI9 SAE Bearers Establishment Failures due


to Parameter Error

C373210253

Number of Initial QCI9 SAE Bearers Establishment Failures due


to Other Reason

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

97

These failures can be resolved as follows:

ENB Admission Failure

Uu Interface Failure

This failure occurs because the timer is timing out when the eNodeB waits for the
RRC Connection Reconfiguration Complete message from the UE.

Security Failure

This failure occurs because of an encryption or security activation problem.

Parameter Error

This failure occurs because of an incorrect or non-standard-compliant parameter


configuration.

Other Reason

Other reasons must be analyzed and located through a drive test or a similar test
because you cannot obtain any specific cause value based on performance
statistics results.

5.1.5 System Availability KPI


5.1.5.1

5.1.5.2

Cell Availability

The cell availability is the ratio of the in-service time to the counted time. The inservice time refers to the timer interval between the cell setup success and the
cell deletion. This indicator represents how well the cells work under the eNodeB,
which can provide a solid foundation for analyzing system failure or performance.

By counting the in-service time of the cell on the eNodeB side, the cell
availability indicator can be calculated as follows:

Cell Availability = In-Service Time/Granularity Time

E-RAB Block Rate

The E-RAB block rate is the sum of all QCI-based service failure rates due to
limited resources. This indicator represents the service acceptability of the
eNodeB or the UE, in terms of resource usage.

Figure 5-5 shows the initial context setup procedure.

Figure 5-5

Initial Context Setup Procedure

eNB

MME

INITIAL CONTEXT SETUP REQUEST

INITIAL CONTEXT SETUP RESPONSE

Figure 5-6 shows the E-RAB setup procedure.

Figure 5-6

E-RAB Setup Procedure


eNB

MME

E-RAB SETUP REQUEST

E-RAB SETUP RESPONSE

By counting the number of successfully and unsuccessfully received E-RABs in


the E-RAB Setup Request and E-RAB Setup Response messages, the ERAB Block Rate indicator can be calculated as follows:

= (C373210201 + C373210207 + C373210213 + C373210219 + C373210225 +


C373210231 + C373210237 + C373210243 + C373210249 + C373210255 +
C373210261 + C373210267 + C373210273 + C373210279 + C373210285 +
C373210291 + C373210297 + C373210303)/(C373210200 + C373210201 +
C373210202 + C373210203 + C373210204 + C373210205 + C373210206 +
C373210207 + C373210208 + C373210209 + C373210210 + C373210211 +
C373210212 + C373210213 + C373210214 + C373210215 + C373210216 +
C373210217 + C373210218 + C373210219 + C373210220 + C373210221 +
C373210222 + C373210223 + C373210224 + C373210225 + C373210226 +
C373210227 + C373210228 + C373210229 + C373210230 + C373210231 +
C373210232 + C373210233 + C373210234 + C373210235 + C373210236 +
C373210237 + C373210238 + C373210239 + C373210240 + C373210241 +
C373210242 + C373210243 + C373210244 + C373210245 + C373210246 +
C373210247 + C373210248 + C373210249 + C373210250 + C373210251 +
C373210252 + C373210253 + C373210254 + C373210255 + C373210256 +
C373210257 + C373210258 + C373210259 + C373210260 + C373210261 +
C373210262 + C373210263 + C373210264 + C373210265 + C373210266 +
C373210267 + C373210268 + C373210269 + C373210270 + C373210271 +
C373210272 + C373210273 + C373210274 + C373210275 + C373210276 +
C373210277 + C373210278 + C373210279 + C373210280 + C373210281 +

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

99

C373210282 + C373210283 + C373210284 + C373210285 + C373210286 +


C373210287 + C373210288 + C373210289 + C373210290 + C373210291 +
C373210292 + C373210293 + C373210294 + C373210295 + C373210296 +
C373210297 + C373210298 + C373210299 + C373210300 + C373210301 +
C373210302 + C373210303 + C373210304 + C373210305 + C373210306 +
C373210307) x 100%

5.2 Handover Performance Optimization


5.2.1 Handover Flow
5.2.1.1

Handover Flow Diagram


Figure 5-7 Handover Process Diagram
UE
1.

MeasurementControl
( RRCConnection
Reconfiguration
)

Source
eNB

Destination
eNB

Packet data
UL allocation

EPC

Packet data

PDCCH

2 . Measurement Report

3 . HO Request

4 . HO Request Ack
5.

RRC Connection Reconfiguration


( HO Command
)
Deliver buffered
packets to _eNB
T
6 . SN Status Transfer
Buffer packets
from S
_eNB
7.
8.
9.

Random Access Preamble


Random Access Response
RRC Connection Reconfiguration
Complete ( HO Confirm)

Path Switch
10 . Release Resource

Flush DL Buffer
Release
Resource
s

Measurement Control
Measure Control, generally carried in the reconfiguration message in the initial
connection or last handover command.
Measurement Report

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

101

Measure Report, the UE reports the cells falling within the handover margin
according to the measure control messages.
HO Request
At the receipt of the measurement report, the source eNB requests to the
destination eNB for resources and configuration information. Please note that,
interaction within the eNB is enough for handover within an eNB. For handover
between eNBs, X2 or S1 interface should be used, with X2 preferred.
HO Request Ack
The destination eNB feeds the acknowledgement message and other
configuration information back to the source eNB.
RRC Connection Reconfiguration
The source eNB sends the acknowledgement message of the destination eNB
and reconfiguration message which contains the measurement control of the
destination eNB to the UE, and notify the UE that the destination eNB is ready
for connection.
SN Status Transfer
The Source eNB delivers the buffered packets of the UE service to the
destination eNB.
Random Access Preamble
Upon the receipt of the reconfiguration message in step 5 (handover command),
the UE uses the access information in the reconfiguration information to connect.
Random Access Response
The destination eNB access response, with this command received, it is
deemed as access completed. Then the UE sends the reconfiguration complete
message on RRC layer (step 9).
RRC Connect Reconfiguration Complete (HO Confirm)
The UE Reports the reconfirmation complete message to the destination eNB,
now the handover process is complete.
Release Resource
When the UE connected successfully, the destination eNB notifies the source
eNB to delete the context information (flush DL buffer) on the UE.

5.2.1.2

Classification of Handover

Based on the actual application situations, handover can be done within one
eNB, over the X2 interface or the S1 interface. The section below introduces
these handover modes separately. All of the handover methods below are
introduced given that the UE is already connected and measurement
configuration is acquired.

5.2.1.2.1 Handover Within an eNB

The Handover within an eNB is relatively simple. Since the handover source and
destination are in a same eNB, then it is determined just inside the eNB and
does not have to request to EPC for data path switch.

Figure 5-8 Signaling Process Diagram of Handover Inside the eNB


UE

eNB

Measurement Report

RRC Connection Reconfiguration


(HO Command)

RRC Connection Reconfiguration


Complete(HO Confirm)
MSG1
(Random Access Preamble)
RAR
(Random Access Response)

5.2.1.2.2 Handover over the X2 Interface

This is used for establishing handover between neighbor cells that are
connected with the X2 interface. Upon receiving the measurement report, the
source eNB delivers handover request to the target eNB through the X2
interface (step 3 in Figure below), sends handover command to the UE after
getting the acknowledgement from target eNB (step 4 in Figure below)and
meanwhile it sends SNStatus Transfer the message which contains the data
packet buffer and buffer number and other information to target eNB. After the
UE connected to the target eNB, the target eNB will send path switch request to

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

103

EPC with the purpose of notifying the EPC to transfer the UE service to the
target eNB. X2 handover is in preference to S1 handover.
Figure 5-9 X2 Handover Signaling Process Diagram
UE

Source eNB

Destination
eNB

EPC

Measurement Report
X2AP HandoverRequest
X2AP
HandoverRequestAcknowled
ge
RRCConnectionReconfigurati
on
(HO Command)

X2AP SNStatusTransfer

RRCConnectionReconfigurationComplete
(HO Confirm)
MSG1
(Random Access Preamble)
RAR
(Random Access Response)
S1AP PathSwitchRequest

X2AP UEContextRelease

S1AP
PathSwitchRequestAcknowled
ge

5.2.1.2.3 Handover over the S1 Interface

The handover over S1 interface takes places between neighbor cells when there
is not X2 link and not in the case of handover inside eNB. The basic flow is
identical to that of the X2 handover, with the only difference that all interactive
signaling are transferred over the S2 interface in EPC, which has a slightly
longer delay than X2 handover.

Figure 5-10 S1 Handover Signaling Process Diagram


UE

Source eNB

Destination
eNB

EPC

Measurement Report
S1AP HandoverRequest

RrcConnectionReconfiguratio
n
(HO Command)

S1AP
HandoverRequestAcknowled
ge

S1AP HandoverRequest
S1AP
HandoverRequestAcknowled
ge

S1AP_EnbStatusTransferMs
g
RrcConnectionReconfigurationComplete
(HO Confirm)
MSG1
(Random Access Preamble)
RAR
(Random Access Response)
S1AP MMEStatusTransfer
S1AP HandoverNotify
S1AP
UEContextReleaseCommand
S1AP
UEContextReleaseComplete

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

105

5.2.2 Handover Performance KPI


ZTE LTE system supports the following types of handover KPIs :
Intra-eNB intra-frequency Handover
Inter-eNB intra-frequency Handover (X2)
Inter-eNB intra-frequency Handover (S1)
Please refer to ZXSDR UniRAN (V3.10.20) Performance Counter Reference and ZXSDR
UniRAN (V3.10.20) Performance Index Reference for the detail formulas and counters

5.2.3 Commonly Used Methods


5.2.3.1.1 Neighbor Optimization
Based on DT data to check the neighbor configuration
Based on OMC static data to check the neighbor configuration

5.2.3.1.2 RF Optimization
Please refer to the coverage optimization part

5.2.3.1.3 SON functioin


Please refer to ZTE LTE FDD ANR Feature Guide_V1.0

5.2.4 Handover Optimization Process

When any exception occurs, we should check whether the eNB and the
transmission work properly. If positive, analyze the handover process.

During the handover process, perform the following steps to analyze the
exceptions:

Is the handover command received after the sending of measurement report?

Is MSG1 sent successfully at the destination side after receiving the


reconfiguration command?

Is MSG2 received after MSG1 is delivered successfully?

The following figure shows the overall process flow diagram of the handover
problem analysis. When a certain process has problem, we can check the
corresponding process step to solve it out.

Figure 5-11 Process of Analyzing Handover Problem

Measurement
Report

No

Is handover
command
received?

Flow 1
Yes

No

Is MSG1 sent
sucessfully?

Flow 2
Yes

No

Is RAR
received?

Flow 3
Yes
Send
reconfiguration
complete
MSG3

End

5.2.5 No Handover Command Received upon the Sent Measurement Report

This problem often occurs at field and it is relatively difficult to be located and
solved. Check the following figure for the analysis process of it.

The eNB has not received the measurement report (can be checked through the
background signaling tracing):

Check whether the coverage point is reasonable. This can be determined by


checking several factors, including checking whether the coverage of RSRP and
SINR in the measurement report is good, if the UE is at cell edge or limited
uplink power exists (determined by the path loss estimated at the downlink EU).
If any of these problems exists, adjust the coverage and handover parameter to
solve it.

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

107

For field test, it is suggest that the coverage of RSRP at handover point is
greater than -120dBm and SINR no less than -5dB.

The eNB has received the measurement report:

i.

ii.

1. No handover command sent to the UE:


Confirm if the destination cell is missing neighbor cell, which is relatively easy
to be checked out from the background, just by checking the background
signaling tracing information to see if the eNB sends handover request to the
destination cell after receiving the measurement report. It can also be
determined from the foreground. When access to or handover to the source
eNB, there should be a PCI carried by the UE measurement report in the
neighbor list in the field MeasObjectToAddModList of the reconfiguration
command. If negative, it is the problem of neighbor missing. If it is confirmed
that the problem is caused by neighbor list missing, add neighbor cell.
If the measurement report is received after neighbor cell is configured, the
source eNB will send the handover request to the destination eNB over the
X2 or S1 interface (if no X2 association is configured). Now it is necessary to
check whether the destination eNB has not sent HO request
acknowledgement to the source eNB, or HANDOVER PREPARATION
FAILURE signaling is returned. In this case, the source eNB will not send the
handover command to the UE either.
Now we need to locate the problem from the following three aspects:
Several factors including the destination eNB preparation failure, RNTI
preparation failure, and PHY/MAC parameter configuration exception and so
on may lead to returning a HANDOVER PREPARATION FAILURE

message from the destination eNB.

Transmission link exception may result in no response from the destination


eNB;

Destination eNB status exception may cause no response from the destination
eNB.

2. Handover command sent to the UE:

The coverage of the reported point on the measurement report should be


checked. If it is checked as a weak field or a strong interfered area, it is
recommended to solve the coverage problem by adjusting engineering
parameters first. If coverage cannot be adjusted easily, adjust handover
parameters.

Figure 5-12 Process Flow When No Handover Command Received upon the Sent
Measurement Report
Flow 1

No

Has the serving


cell received the
measurement
report?
Yes
Is it neighbor
missing?

No

Solve the problem


of target eNB
abnormality and Yes
transmission

Is the coverage of the


tested point
reasonable?

Check if any
problem in target
eNB status,
admission
parameter and
transmission?

No
Optimize coverage
and handover
parameter

Yes

Yes
Is there uplink
interference ?

No

Optimize neighbor
cell

Yes
Check and
remove the
interference

No

Is the problem
solved?
Yes

End

5.2.6 MSG1 Sending Exception at Destination Cell

In normal condition, the coverage of the reported cell on the measurement


report is better than that of the source cell. Whereas the possibility of the
destination cells coverage changes abruptly cannot be ruled out. So the
handover problem caused by the coverage of the testing environment can be
excluded. For this kind of problem, it is suggested to adjust coverage

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

109

preferentially. If coverage cannot be adjusted easily, adjust handover


parameters.

If the coverage is stable and sending cannot be done normally, then it is


required to check whether there is uplink interference at the eNB.

Figure 5-13 Process of Analyzing Msg1 Problem


Flow 2

Is the coverage of
testing point
reasonable?
Yes

No

Is there
interference in
uplink of cell?
Yes

Optimize the
coverage and/or
handover
parameters
No

Check and
remove the
interference

Is the problem
solved?
Yes

End

5.2.7 RAR Reception Exception

For the exceptional RAR received the wireless environment of the testing point
need to be checked. The process to solve this kind of problem is similar as
optimizing coverage first. If coverage optimization is not feasible, adjust
handover parameter.

Figure 5-14 Process of Analyzing RAR Problem

Flow 3

Optimize coverage
and handover
parameter
No
Is the problem
solved?

Yes

End

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

111

5.3 E-RAB Drops Performance Optimization


5.3.1

Definition of E-RAB Drop Rate

5.3.2

5.3.3

E-RAB drop rate= number of E-RAB abnormal release/number of E-RAB setup


successful* 100%

Formula of E-RAB Drop Rate

E-RAB Drop Call Rate=

(C373210381+C373210391+C373210431+C373210441+C373210451+C37321
0511+C373210521+C373505354)/(C373210200+C373210206+C373210212+C
373210218+C373210224+C373210230+C373210236+C373210242+C3732102
48+C373210254+C373210260+C373210266+C373210272+C373210278+C37
3210284+C373210290+C373210296+C373210302+C373210461+C373240809
+C373240810+C373240811+C373240812+C373240813+C373240814+C3732
40815+C373240816+C373240817)*100%

E-RAB Drop sampling point

5.3.4

E-RAB Drop Counters

Please refer to ZXSDR UniRAN (V3.10.20) Performance Counter Reference


and ZXSDR UniRAN (V3.10.20) Performance Index Reference

5.3.5 Release Reason definition in3GPP TS 36.413

Release reason in 3GPP for your reference

Radio Network Layer cause


Unspecified
TX2RELOCOverall Expiry
Successful Handover
Release due to E-UTRAN
generated reason
Handover Cancelled
Partial Handover

Handover Failure In Target


EPC/eNB Or Target System
Handover Target not allowed
TS1RELOCoverall Expiry
TS1RELOCprep Expiry
Cell not available
Unknown Target ID
No radio resources available in
target cell
Unknown or already allocated MME
UE S1AP ID
Unknown or already allocated eNB
UE S1AP ID
Unknown or inconsistent pair of UE
S1AP ID
Handover Desirable for Radio
Reasons
Time Critical Handover

Resource Optimisation Handover


Reduce Load in Serving Cell

ZTE Confidential Proprietary

Meaning
Sent for radio network layer cause when none of the specified cause
values applies
The timer guarding the handover that takes place over X2 has
abnormally expired.
Successful handover.
Release is initiated due to E-UTRAN generated reason.
The reason for the action is cancellation of Handover
Provides a reason for the handover cancellation. The HANDOVER
COMMAND message from MME contained E-RABs to Release List
IE and the source eNB estimated service continuity for the UE would
be better by not proceeding with handover towards this particular
target eNB.
The handover failed due to a failure in target EPC/eNB or target
system.
Handover to the indicated target cell is not allowed for the UE in
question.
The reason for the action is expiry of timer TS1 RELOCoverall.
Handover Preparation procedure is cancelled when timer
TS1RELOCprep expires.
The concerned cell is not available.
Handover rejected because the target ID is not known to the EPC.
Load on target cell is too high.
The action failed because the MME UE S1AP ID is either unknown,
or (for a first message received at the eNB) is known and already
allocated to an existing context.
The action failed because the eNB UE S1AP ID is either unknown,
or (for a first message received at the MME) is known and already
allocated to an existing context.
The action failed because both UE S1AP IDs are unknown, or are
known but do not define a single UE context.
The reason for requesting handover is radio related.
handover is requested for time critical reason i.e. this cause value is
reserved to represent all critical cases where the connection is likely
to be dropped if handover is not performed.
The reason for requesting handover is to improve the load
distribution with the neighbour cells.
Load on serving cell needs to be reduced.

2010 ZTE Corporation. All rights reserved.

113

User Inactivity
Radio Connection With UE Lost
Load Balancing TAU Required
CS Fallback triggered
UE Not Available for PS Service

Radio resources not available


Invalid QoS combination
Inter-RAT Redirection
Failure in the Radio Interface
Procedure
Interaction with other procedure
Unknown E-RAB ID
Multiple E-RAB ID Instances
Encryption and/or integrity
protection algorithms not supported
S1 Intra system Handover triggered
S1 Inter system Handover triggered
X2 Handover triggered
Redirection towards 1xRTT
Not supported QCI Value
Invalid CSG Id

The action is requested due to user inactivity on all E-RABs e.g. S1


is requested to be released in order to optimise the radio resources.
The action is requested due to loosing the radio connection to the
UE.
The action is requested for all load balancing and offload cases in
the MME.
The action is due to a CS fallback that has been triggered
The action is requested due to a Cell Change Order that has been
triggered.
In case of CS fallback to GERAN, it indicates that either the target
GERAN cell or the UE has no DTM capability.
No requested radio resources are available
The action was failed because of invalid QoS combination.
The release is requested due to inter-RAT redirection.
Radio interface procedure has failed
The action is due to an ongoing interaction with another procedure
The action failed because the E-RAB ID is unknown in the eNB
The action failed because multiple instance of the same E-RAB had
been provided to the eNB
The eNB is unable to support any of the encryption and/or integrity
protection algorithms supported by the UE.
The action is due to a S1 intra system handover that has been
triggered.
The action is due to a S1 inter system handover that has been
triggered.
The action is due to an X2 handover that has been triggered.
The release is requested due to redirection towards a 1xRTT
system.
The E-RAB setup failed because the requested QCI is not
supported.
The CSG ID provided to the target eNB was found invalid.

Transport Layer cause


Transport Resource Unavailable
Unspecified

Meaning
The required transport resources are not available
Sent when none of the above cause values applies but still the
cause is Transport Network Layer related

NAS cause
Normal Release
Authentication Failure
Detach
Unspecified

Meaning
The release is normal
The action is due to authentication failure.
The action is due to detach.
Sent when none of the above cause values applies but still the
cause is NAS related
The action is due to the UE becoming a non-member of the
currently used CSG.

CSG Subscription Expiry

Protocol cause
Transfer Syntax Error
Abstract Syntax Error (Reject)
Abstract Syntax Error (Ignore And
Notify)
Message Not Compatible With
Receiver State
Semantic Error
Abstract Syntax Error (Falsely
Constructed Message)
Unspecified

Miscellaneous cause
Control Processing Overload
Not Enough User Plane Processing
Resources Available
Hardware Failure
O&M Intervention
Unspecified Failure

Unknown PLMN

Meaning
The received message included a transfer syntax error.
The received message included an abstract syntax error and the
concerning criticality indicated reject.
The received message included an abstract syntax error and the
concerning criticality indicated ignore and notify.
The received message was not compatible with the receiver state.
The received message included a semantic error.
The received message contained IEs or IE groups in wrong order or
with too many occurrences.
Sent when none of the above cause values applies but still the
cause is Protocol related
Meaning
Control processing overload
No enough resources are available related to user plane processing.
Action related to hardware failure
The action is due to O&M intervention.
Sent when none of the above cause values applies and the cause is
not related to any of the categories Radio Network Layer, Transport
Network Layer, NAS or Protocol.
The MME does not identify any PLMN provided by the eNB

5.3.6 OMM-level performance statistics analysis


Description

The E-RAB drop rate high usually happens at the initial stage of the network
construction or after swap/upgrade/cutover

1.

Whole network/big area of sites E-RAB drop rate are high

2.

Usually at the same time the HO SR and E-RAB setup SR are also poor

Analysis

Reason of E-RAB Drop rate is high

1.

Weak coverage

2.

Neighbor missing

3.

HO parameter configuration is wrong

4.

X2 parameter configuration is wrong

5.

DL/UL Interference

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

115

Analysis step of OMC KPI:

1Collect HO/Drop/setup statistics for whole network

Select TopN cell

3TopN cell analysis

5.3.7 OMM-level performance statistics analysis


Description

In a stable network ,the high drop rate will not in whole network, usually just for
certain sites

1.

Certain sites(cells) drop rate is high

2.

Usually at the same time the HO SR is also poor

Analysis
1.

Is the site a new on-air site? Or there are new on-air site near this site?(parameter
check)

2.

Alarm checkany alarm? power is ok or not?

3.

Antenna system is ok or not?Azimuth/tilt are same with planning?

4.

Check the radio environmentConner? interference?

5.

Handover/ Power control parameter check

5.3.8 Conclusion

The call drop problem-solving workflow is illustrated as follow

Figure 5-15 LTE Call Drop Problem-Solving Workflow

Call Drops

Check alarms

Large-scale or BBUbased call drops?

Whether the power


level is too low?

Adjust the RSRP, for


example, the power or
roofing parameters

N
Transmission
faults

BBU hardware
faults

Whether interference
exists?

The SINR is too low

Whether all the


neighboring cell
parameters are
configured and whether
the parameters are

Check the neighboring


cells

proper?

N
Perform multi-terminal
checking

Use different UEs to


replicate problems

Locate the problems by


blocking the cells

ZTE Confidential Proprietary

2010 ZTE Corporation. All rights reserved.

117