Beruflich Dokumente
Kultur Dokumente
Product Version
Total 80 Pages
1.0
Revision History
Revision
Date Description Author
Version
August 28,
1.00 First draft is finished. Zuo Yanzhong
2006
October 28,
1.3 Alarm analysis is added. He Fengming
2006
Contents
1 Overview..........................................................................................................................................8
1.1 Purpose of the Document ......................................................................................................8
1.2 Users of the Document ..........................................................................................................9
Figures
Keywords
Performance analysis, quality early warning, KPI, Nastar tool
Abstract
Network performance analysis and quality early warning aim to accurately and
effectively find network performance and quality problems and give early warnings.
This document describes the general ideas, methods and procedures of UMTS
network performance analysis and quality early warning. It is intended to provide
reference for analysis operations and early warning actions of various regional
divisions and representative offices and to improve the efficiency of UMTS network
performance analysis and quality early warning.
CE Channel Element
CN Core Network
NodeB NodeB
PI Performance Index
RF Radio Frequency
1 Overview
4) For multiple abnormal KPIs, the Nastar tool offers the causes such as RF.RLCRst,
RF.ULSync and UuNoReply. How to make further analysis?
5) If the call drop rate of a network PS is 5%, is any early warning needed? What are
the early warning principles?
2
Necessary Conditions of
Performance Analysis and Quality Early
Warning
The necessary skills of performance analysis and quality early warning include being
familiar with signaling flow and basic principles, knowing about traffic statistics PIs of
product implementation, and mastering each function of the Nastar tool. The following
expounds these skills one by one, but the emphasis is laid on the extent of mastery
and the methods of a quick mastery.
Case: In several cells of a site, traffic statistics analysis shows that the success rate of
RRC connection establishment decreases and that the cause of RRC connection
failure is mainly RRC.Fail.ConnEstab.NoReply. In the performance analysis of this
problem, engineers wonder whether too small CCP bandwidth configuration of this site
makes RNC unable to receive any Complete response from UE. May I ask whether
the Complete message is related to restricted CCP bandwidth? How is an RRC
connection established based on the protocol stack of the Uu interface and the Iub
interface? When RRC is set up on dedicated channels and common channels
respectively, what are the differences in the signaling flow and protocol stack
implementation?
The Nastar tool provides the query of numerous indexes oriented to service process,
algorithm process and resource use. The counter implementation of these indexes in
a product is based on the following:
1) Signaling flows of the UTRAN, such as RRC connection establishment flow, RAB
establishment flow, and soft handover flow.
2) Specific statistics in protocol modules, such as counter statistics in
RLC/MAC/PDCP protocol modules and link measurement counter statistics in
SAAL/MTP3-B modules. We can achieve an accurate understanding of these
statistical points only if we have mastered the basic principles of WCDMA network
planning and got familiar with protocol stacks of standard interfaces.
A good knowledge of the protocol stacks and service flows of WCDMA enables
performance analysis to have a definite object in view. The Nastar template provides
the query functions oriented to basic PIs, but an analysis of these PIs alone cannot
easily help find network problems. If you are familiar enough with signaling flows and
basic principles, you can skillfully pick out other PIs from traffic statistics indexes and
make an auxiliary analysis. You can better understand the internal relations between
abnormal KPIs and coverage, uplink interference, load or transmission. This makes
your analysis go in a right direction.
Some engineers who have just come into contact with performance analysis say that
when they see some abnormal indexes from the daily report of the Nastar tool, they do
not know how to make an in-depth analysis. In this case, first ask yourself whether you
are familiar enough with basic signaling flows of the UTRAN and protocol stacks of
WCDMA. If no, you cannot but be at a loss and need to take this lesson as soon as
possible. If you have mastered related knowledge points, you may participate in the
discussion of performance analysis methodology. The prerequisite to Chapter 3 of this
document is engineers’ mastery of basic flows and principles.
To sum up, the mastery of signaling flows and basic principles is necessitated by the
following:
1) Abnormality location and analysis can have a definite object in view. We can
quickly search for other related indexes based on flows and basic principles and
make an auxiliary analysis.
2) Getting familiar with flows and principles helps associate abnormal PIs with
network problems (such as coverage and interference) and roughly determine the
nature of problems according to abnormal PIs, to select corresponding special
topic functions (coverage and interference) of the Nastar tool for an in-depth
analysis.
3) The mastery of signaling flows and basic principles helps analyze CHR. Although
CHR is the implementation of product internal modules, a good knowledge of
signaling and basic principles helps quickly get involved in CHR analysis.
Performance analysis requires that engineers should master basic signaling flows, get
familiar with protocol stacks of standard interfaces and know about related algorithms
for product implementation. For numerous RRM algorithms, engineers need to know
about their concepts even if they cannot acquire a good knowledge of them. If the
analyzed commercial networks contain some algorithms, engineers need to learn
them well.
Those engineers unfamiliar enough with flows and principles are suggested to learn
the following slides to acquire a quick knowledge of signaling flows of basic services
get familiar with protocol stacks of various WCDMA standard interfaces and know
about basic functions of various protocol modules.
1) Advanced Training for W Network Planning----Signaling Flow.ppt
2) Advanced Training for W Network Planning ----WCDMA Handover Principles.ppt
If a network to be analyzed involves DCCC, HSDPA or CMB, you need to obtain
related information to form a basic concept of these algorithms or services before
making any performance analysis.
measurement points. Only in this way can the second query of traffic statistics or
auxiliary query of PIs have a definite object. At present, the common analysis indexes
include “RNC integrated performance measurement” and “cell measurement” shown
in the following figure. Performance analysis engineers first need to get familiar with
the PIs of both. They also need to know as much about other PIs as possible to
broaden the vision of performance analysis.
1) Provide performance analysis results at the level of traffic statistics PIs. Make a
special topic analysis of each service flow based on the familiarization of
signaling flows and the UTRAN KPI, and find out abnormal observation points in
a network. Some abnormal observation points correspond to problem causes
such as Power.Cong while most cannot such as RLCRst, ULSync, UuNoReply,
and so on. Analysis examples are shown in 4.2 “Example of Analysis Based on
Observation Point”.
2) Analyze the relations between traffic statistics PIs and network problems. Define
the nature of such problems.
3) Analyze real network problems by combining the advanced functions of the
Nastar.
Through observation point analysis, we have been able to make a preliminary analysis
of network performance. According to observation point indexes such as power
resource congestion, restricted transmission resource, and insufficient code resource,
we can give a simple quality early warning. But there are still many other performance
problems from which we cannot conclude directly.
For example, call drop analysis shows that many causes of call drop are RLCRst,
ULSync, and UUNoReply. How can we make an in-depth analysis? As shown in the
following table, the learning of signaling flows and basic principles, and topical
analysis practice may help summarize and analyze possible causes of abnormal PIs.
Table 1 Relationship between traffic statistics PIs and causes of call drop
Uplink Interference
Abnormal Mobile
Actual Cause of
OM Operation
Transmission
Equipment
Abnormal
RF Cause
Call Drop
Overload
Phone
Flow
Traffic
Statistics PIs for Call Drop
VS.RAB.RelReqCS.OM √
VS.RAB.RelReqCS.RABPreempt √
VS.RAB.Loss.CS.RF.RLCRst √ √ √
VS.RAB.Loss.CS.RF.ULSync √ √ √
VS.RAB.Loss.CS.RF.DLSync √ √
VS.RAB.Loss.CS.RF.UuNoReply √ √ √ √ √ √
VS.RAB.Loss.CS.Aal2Loss √
VS.Call.Drop.CS.Other √ √ √
Other special topics, such as RRC access, soft handover, and CS foreign handover,
can also be summarized and analyzed similarly. Performance analysis itself is a
process of continuous experience summarization. We can directly find out the causes
of some PIs, but we can only define the scope of problems for some others and
determine the idea of subsequent analysis according to the scope. If you are not so
skilled in summarizing the relationship between traffic statistics PIs and network
problems, you may make a classified analysis as described in the above table. When
experience is accumulated to some extent, you can “govern by doing nothing that
goes against nature”. That is, upon seeing any abnormal PI, you can naturally
determine the scope of the problem, have a clear idea of next step and judge what
advanced function of the Nastar tool should be selected for an in-depth analysis (The
next section describes the advanced functions of the Nastar).
Problems: What functions does the Nastar for WCDMA tool have? Can you really
skillfully use the Nastar tool? Consultation to many performance analysis engineers
shows that not many of them can skillfully use each function of this tool. Many people
use the Nastar tool only for simple query of traffic statistics indexes and fast output of
reports.
The Nastar for WCDMA tool integrates years of Huawei’s experiences in network
optimization of WCDMA. It uses the method of data analysis and data mining by
discarding the dross and selecting the essential and eliminating the false and retaining
the true. Fast and effectively, it analyzes network performance and locates network
fault. The Nastar tool is the crystallization of the wisdom of the R&D, Performance
Dept., Maintenance Dept. and Network Planning and Optimization Dept. of Huawei.
Powerful enough, this tool is not used only for fast output of reports and customized
query of traffic statistics indexes. Performance analysts must master each function of
the Nastar tool.
In an in-depth analysis of network performance, we need to use various functions of
the Nastar tool flexibly. To sum up, performance analysis is how to determine the
scope of problems from the whole to the part, how to define the nature of problems
from traffic statistics PIs and how to properly select related functions of the Nastar for
an in-depth analysis. Chapter 3 describes how to determine the scope and nature of
problems, but a skillful use of various functions of this tool is the basis for performance
analysis.
In an in-depth performance analysis, the following functions of the Nastar tool need to
be used:
1) Customization and second query of PI
2) Optimization solution to Intra-frequency adjacent cell
2.5 Summary
Chapter 2 mainly describes the knowledge and skills required for performance
analysis and quality early warning. It includes the understanding of UTRAN signaling
flow and basic principles, the familiarization of the UTRAN KPI and the mastery of the
functions of the Nastar tool. These three parts are associated with each other.
Signaling flow and principles are the very basis. We can understand each PI of a
product only when we have mastered signaling flow and principles. Based on the
familiarization of each PI, we can gradually master each function of this tool through
special topic practice of the Nastar.
Having laid a solid foundation, we can effectively make network performance analysis
and quality early warning by combining the methodology described in Chapter 3.
In reality, performance analysis and quality early warning include three steps:
knowledge of network conditions, preparations for performance analysis, and methods
and flows of performance analysis. Among the steps, there is a definite sequential
relationship. Each step helps gradually determine the scope and nature of network
problems. Then, we analyze, conclude and judge whether an early warning to network
quality is needed.
VP DL Erlang
CS Erlang
Traffic PS UL Erlang
PS DL Erlang
PS UL Throughput
PS DL Throughput
Specific performance analysis means that this network has specific functions or
algorithms and that specific attention should be paid to these functions or algorithms.
For example, if network provides HSDPA, HSUPA, and MPMS services, records of
performance indexes must contain corresponding KPI.
For each normal or specific performance which requires continuous observation and
analysis, engineers must keep history. They had better archive them in the form of
visual figures or trend tables (also save corresponding DATA), and update them
anytime. Keeping a record of performance indexes helps an overall observation of the
running quality of a network within a period of time, and makes engineers more acute
to analyze network indexes and judge whether any in-depth location analysis is
needed.
The following trend figure shows the voice call drop rate and VP call drop rate of a
network in a period of time.
3.0%
2.5%
2.0%
1.5%
1.0%
0.5%
0.0%
2006-01-16
2006-01-21
2006-01-26
2006-01-31
2006-02-05
2006-02-10
2006-02-15
2006-02-20
2006-02-25
2006-03-02
2006-03-07
2006-03-12
2006-03-17
2006-03-22
2006-03-27
2006-04-01
2006-04-06
2006-04-11
2006-04-16
2006-04-21
2006-04-26
2006-05-01
2006-05-06
2006-05-11
2006-05-16
2006-05-21
2006-05-26
2006-05-31
2006-06-05
2006-06-10
2006-06-15
2006-06-20
2006-06-25
2006-06-30
2006-07-05
Figure 2 Trend figure of call drop rate
The trend figure clearly shows the call drop trend of this network in the past months.
When we get any new data of call drop rate, we need to compare it with the recent
indexes in this figure to judge whether the call drop rate is abnormal.
In the early days of network commercialization, when indexes were not stable enough,
more information should be recorded for comparison. For example, when analyzing
call drop rate, we may record top 10 cells of a certain day or week. In a subsequent
comparative analysis of call drop rate, we have more pertinent information.
The following table shows the PS call drop analysis of TOP10 cells in a network on a
certain day.
PS Call PS Call
CellId CellName CellId CellName
Drops Drops rate
PS Call PS Call
CellId CellName CellId CellName
Drops Drops rate
Parameter revision during network optimization requires clear records. The impact of
parameter revision on networks can be analyzed by combining revision history and
performance indexes of traffic statistics. If traffic is not heavy, the impact of regional
parameter revision on KPI may be unapparent, nor can it be easily observed. But
when traffic rises suddenly some day, if early parameters are unreasonable, the bad
impact of parameter revision on KPI will be clearly seen. A complete record of
parameter revision may contribute to network performance analysis.
For example, the following table shows the revision history of a network. When
creating a parameter revision history table, performance analysis engineers may give
flexible consideration, but the general principle is visual. Thus, query can be made in
the order of revision time. If the revision history involves any specific region, they must
be clearly marked.
2 2006.01.03 Adjust the maximum and the minimum downlink power of voice,
12 2006.04.13 T314 and T315 are set to 0. Disable Cell Update caused by
Change the minimum access quality to -20 dB. See the table
14 2006.04.15
“Cell_SelReselParas_CR”.
Baseline parameter records may as well indicate known defects and patches of the
current version. There is no product version without any defect. Sometimes there is a
product BUG. Sometimes there may be restricted algorithm function. The network
Network operation records include the cutover of NodeB, the upgrade of RNC and
NodeB, and transmission expansion. They aim to help a comparative analysis of traffic
statistics index and a quick analysis of network performance.
Refer to the following network operation records.
When engineers start performance analysis, they must get related network operation
records. Generally, customers or on-site customer service will maintain a related
record table.
In a stable commercial network, performance analysis and quality early warning are
periodic. It generally includes daily report analysis and weekly report analysis. Daily
report analysis ensures timely network monitoring. It helps quickly find and eliminate
any burst KPI deterioration. In daily report analysis, users’ distribution (workdays and
holidays) and their calling habits (commuter time and working time) may cause small
KPI fluctuation in the observed time period. For a region with small traffic, call drop
rate, call completion rate, and handover success rate are of no statistical significance.
We should not analyze network performance problems according to them alone.
With a week as the unit, weekly report analysis has more statistical sample points.
According to one-week statistics, we may give an accurate early warning to traffic
change, transmission, power, and code resource. Thus, we can more easily find
network problems such as coverage, interference, and pilot pollution.
Performance monitoring requires that the same emphasis should be laid upon daily
report analysis and weekly report analysis. Daily report analysis helps eliminate burst
influence, such as base station reset and intermittent transmission failures. Weekly
report analysis helps locate network coverage problems and interference problems.
Quality early warning actions include comparative check of whole-network parameters,
check of whole-network unidirectional adjacent cells, and check of whole-network
missing adjacent cells and pilot pollution. These actions are periodically executed. The
period can be flexibly set according to the frequency of network parameter
modifications or operations. Quality early warning actions may be fully executed once
a month or a quarter.
Normal performance monitoring period takes day as the minimum unit. Use the Nastar
tool to output Daily report to observe network KPI and judge whether an in-depth
analysis is needed. Several scenarios are triggered by events. When a corresponding
event happens, we need to get traffic statistics data and make a detailed analysis. The
granularity of traffic statistics data is generally less than 24 hours. We may need to
analyze the traffic statistics data for half a day (or a whole day) or several hours. In the
following cases, traffic statistics KPI needs our major concern.
1) Important holidays: During important holidays, such as the Spring Festival,
Christmas Day, Buddha’s Birthday, and Pilgrimage to Mekka, the network traffic
of this region will climb to a new high. As to whether product equipment and
network design can withstand large-scale traffic shock, we need to upload traffic
statistics data hour by hour and monitor network performance at any moment.
2) Equipment upgrade and major parameter modification: For general upgrade and
parameter modification, we may analyze the network KPI by observing Daily
report. For highly risky upgrade and parameter modification, we need to get traffic
statistics data quickly and make an analysis with the granularity of 12 or six
hours.
3) Natural disaster: Earthquakes or typhoon may have a direct impact on networks.
To avoid affecting network communication, we need to analyze traffic statistics
data as soon as possible and observe the extent of the damage to networks.
The master data of performance analysis must be accurate, timely and integral.
Accuracy means that Nastar engineering parameters must be very accurate and will
be updated along with RF adjustment of network. Timeliness means that traffic
statistics data of network needs to be uploaded as soon as possible. Data integrity
means that no traffic statistics data should be omitted. Otherwise, there may be
relatively fewer call attempts and call drop times of a network or a cell, which cannot
fully reflect network quality.
Specifically speaking, master data includes:
1) Nastar engineering parameters. Multiple analysis functions of the Nastar tool,
such as missing adjacent cell analysis, interference analysis, and coverage
analysis, are closely related to engineering parameters. The accuracy of
engineering parameters determines the credibility of related analysis results of
the Nastar tool.
2) Traffic statistics data
3) Configuration data
4) CHR data. It is not used only for CHR analysis of the Nastar tool. In missing
adjacent cell analysis and unidirectional adjacent cell analysis, CHR data is
needed. If CHR data is only used for abnormal flow location analysis, we may
selectively import CHR data according to the frame number of a cell to be
analyzed.
5) RTWP data (optional). It is chiefly used for interference analysis. It may be
omitted if interference analysis is definitely unnecessary.
6) IOS data (optional). It is used for an in-depth location analysis of many network
abnormality problems, such as coverage.
7) General schedule of engineering parameters (optional). It is required for
geographic analysis.
CHR data records the information generated during a call. It will be recorded in the call
logs of the system if some conditions are satisfied. It may record the signaling flow
status before the call drop of a mobile phone, measurement report information
reported by a mobile phone before call drop and signal condition when a mobile phone
is accessed. In summary, CHR is oriented to all users involved in 3G services and
records the context information of a mobile phone in a conversation. It is output when
preset conditions are satisfied.
IOS sampling tracing is to start measurement oriented to one or more users within a
cell according to preset conditions. Sample data can be set. IOS sampling tracing is
active data collection initiated by users. It may require that a mobile phone should
actively report the measurement reports on the mobile phone side, such as downlink
pilot RSCP and EcIo, or require that NodeB and RNC should report special
measurement information.
In contrast, CHR data traces all the users within a RNC that satisfies tracing conditions.
It covers a large scope. IOS traces one or more users within a specific cell. It covers a
small scope, but goes deeper.
As to the use of RTWP data and IOS data, we generally determine whether to start the
interference analysis and coverage analysis of the Nastar tool for an in-depth
For different network problems, there are different methods of performance analysis.
Acquire a good knowledge of the running status and problems of existing network, and
then select one or more proper analytical methods. The commonly used methods of
performance analysis are as follows:
3) Region location
The change of network performance index always takes place in some regions. Traffic
increase, traffic model change, radio environment change, base station faults or
uplink/downlink interference leads to the index variation of these regions. The index
variation affects performance indexes of the whole network. We may compare the
network performance indexes before and after the variation, mark the base station or
sector with the greatest network performance variation on an electronic map, and
make a detailed analysis of problematic regions.
4) Contrast
A traffic statistics index is always affected by multiple factors. Some factors change
while others may not. We may properly select comparison objects, confirm the
existence of problems and analyze the causes. When observing indexes, we should
not focus on only their absolute values, but on their relative values.
Besides a longitudinal comparison, we should, if necessary, make a latitudinal
comparison of networks in different regions, for example, upgrade. We may refer to
the index change and causes after similar network upgrade.
Performance analysis is made by using the Nastar tool while alarm analysis is made
by using the Omstar. In the course of performance analysis, whether at the RNC level
or at the cell level, it is recommended to analyze alarm data first and confirm whether
any related equipment alarm affects PI. If equipment and transmission are both normal,
an in-depth analysis of specific PIs may greatly improve efficiency.
Alarm analysis methods must be used together with KPI analysis. An independent
analysis is meaningless, nor can it solve network quality problems effectively.
Generally speaking, the KPIs in our daily concern are traffic, access performance,
RAB establishment success rate, handover, and call drop. What alarms can these
KPIs be related to? We have simply classified service-related alarms as follows:
Performance of traffic: transmission congestion alarm, broken link alarm, and CE
resource congestion (DSP abnormality alarm)
RRC access performance: related to congestion alarm, such as CN congestion, CPU
congestion, base station baseband congestion, and IUB interface transmission
congestion
RAB establishment success rate: related to transmission congestion and RF coverage
Handover performance: related to clock or resource congestion
Call drop rate: Call drop caused by RF and by unavailability of a cell or a base station
According to the above-mentioned characteristics, we associate KPIs with alarms
while analyzing problems. Then, we analyze traffic statistics indexes to determine
whether alarm is the root cause of the decrease in KPIs. If yes, recover alarm and
check whether performance indexes resume to normal.
In alarm analysis, there is no need to analyze the detailed cause of alarm generation.
We only need to analyze the extent of the impact of this alarm on network
performance. If this alarm does not affect network performance, analyze other
problems. If this alarm does affect network performance, we need to analyze how
alarm is associated with KPIs. If alarm is closely associated with KPIs, we need to
recover alarm to verify the correctness of analysis results. The general process is as
follows:
Deterioration of
network quality
Collect and
analyze alarm
information
No
Does the alarm
affect KPI?
Yes
Yes
No
Does KPI resume Analysis of
to normal?
other problems
Ye
s
End
Network quality is always affected by one major alarm. In alarm analysis, we will find
that multiple alarms may affect service. Some of them are only accompanying alarms.
We need to distinguish between major alarms and accompanying alarms. Otherwise,
we cannot locate the root cause. The following table shows the impact of commonly
seen alarms on performance and is for your reference in problem solving.
Processing error
Processing error alarm involves only RNC instead of NodeB.
alarm
5) After defining the nature of problems, properly use different functions of the
Nastar tool for an analysis.
Y
Traffic
(2) RNC equipment/IU statistics
transmission/parameter Alarm
Is there any Y
equipment Solve RNC equipment/IU
problem/transmission transmission problems.
fault?
N Cell traffic
statistics
(3) KPI analysis of TopN
cells
N
Traffic statistics: IUB
(5) Analysis of cell load bandwidth
problems CE resource
Equipment resource
Radio resource
Is there any Y
overload Solve overload problems
problem?
Y
Is there any
interference Solve cell interference
problem? problems
N
CHR:
Pilot pollution
Extraction of coverage
(7) Analysis of cell information
coverage problems IOS Trace:
Analysis of cell coverage
quality
Y
Is there any
coverage Solve cell coverage
problem? problems
N
CHR:
Optimization of
(8) Analysis of cell adjacent cells
parameter problems Configuration
verification
Parameter optimization
Y
Is there any
parameter Solve parameter problems
problem?
N
CHR:
Statistical
(9) CHR flow/terminal
analysis of
performance
mobile phone
problems
using the Omstar tool. We make an auxiliary analysis by using the cell
unavailability PI (VS.Cell.UnavailTime.OM) provided by the Nastar tool.
In the early performance analysis, many RAN equipment problems have been
found. In cell performance analysis, sometimes abnormal access or call drop still
occurs even if there is no high load, a cell has normal signal coverage and there
is correct parameter configuration. In this case, we need to enable the CHR
analysis function of the Nastar tool and use signaling process to make an
analysis. The dot information of CHR involves the implementation of a product
internal module. CHR analysis does not aim to accurately locate a problem, but to
determine the scope of the problem and failure location of abnormal processes.
Then, feedback the result to product R&D personnel to provide auxiliary
information about the location by the R&D personnel.
Besides RAN equipment problem, terminal problems cannot be excluded in
performance analysis. Many of them have been found in an actual network.
Sometimes, a terminal transmits at a fixed power and the conditions that a
terminal satisfies measurement reports fail to be reported in time. For the sake of
query, terminal problems found in existing network can be classified and included
in a list.
RAN equipment problems and terminal problems seldom appear, therefore they
are put at the end of performance analysis. In analyzing abnormal PIs, after
excluding multiple possible causes, we should dare to doubt equipment problems
and give reasonable evidence based on CHR.
The difference between [Query Function] and [Customization Query] is that the former
can be directly exported from the performance analysis template of the Nastar tool
while the latter is customized as required.
1. Performance analysis of RRC establishment success rate
Query TOPN cells with the most RRC establishment failures with the Nastar. Make the
following performance analysis in terms of each TOPN cell.
1. Query RRC
establishment by using the
network performance
analysis function
2. Do indexes Y
satisfy the
requirements?
1) [Daily Report Output] Use a network optimization tool to analyze RNC traffic
statistics data, output daily reports and get related indexes of RRC establishment
success rate, mainly including RRC establishment success rate of service and
non-service.
2) Judge whether the KPI satisfies network requirements according to the defined
threshold or a comparison of the history.
3) [TOPN Query] Subdivide RNC-level indexes into cell-level indexes and find out
10 cells with the worst indexes.
4) [Customization Query] and [Omstar query] Customize the unavailability indexes
of the queried cell or find equipment alarm information with the Omstar, and judge
whether the problem lies in equipment or transmission.
5) [Customization Query] Query results indicate that possible performance problems
include coverage problems, cell reselecting problems and admission problems
(We need to determine the type of problems according to the previous basic KPI
analysis. Then, we use the Nastar tool for a corresponding analysis.)
6) [Coverage Analysis] Enable cell coverage quality analysis to exclude coverage
problems.
7) [Overshoot Analysis] Enable overshoot analysis to exclude possible overshoot.
8) [Missing Configuration of Adjacent Cell] Enable the analysis of missing adjacent
cells to exclude the possibility of missing configuration of adjacent cells.
9) [Configuration Verification] Enable parameter analysis to exclude parameter
configuration problems.
10) [Coverage Analysis] Adjacent cell coverage quality analysis.
11) [Customization Query][Configuration Verification] Query the PIs with load
admission failure and check parameters to judge whether load admission is too
high.
12) [Customization Query][Interference Analysis] Query cell load PIs or enable the
interference analysis function to eliminate interference problems and overload
problems.
1. Query RAB
establishment success rate
by using the performance
analysis function
2. Do indexes Y
satisfy the
requirements?
1) [Query Function] First use the network performance analysis and query function
of a network optimization tool to query the RAB establishment success rate of
various RNC-level services, including AMR service, VP service, and PS service
with a typical rate.
2) Judge whether each RAB establishment KPI satisfies requirements based on the
history.
3) [TOPN Query] Subdivide RNC-level indexes into cell-level indexes and find out
10 cells with the worst indexes. Among cell-level indexes, some statistical points
of RAB establishment failure can be used for the isolation of equipment problems
or network performance problems.
4) [Customization Query] or [Omstar tool query] We can use the Omstar tool to
query equipment problems or transmission problems. We may customize PI
query, for example, query the index VS.Cell.UnavailTime.OM.
This document does not distinguish between performance analysis and quality early
warning. Quality early warning is defaulted to occur during performance analysis. We
confirm whether quality early warning is necessary according to performance analysis
results.
Quality early warning includes performance KPI deterioration early warning and
potential quality risk early warning. When any KPI deterioration is found during
performance analysis, we give a timely early warning, find network problems and
optimize network to avoid continuous deterioration of network performance. Potential
risk early warning is not driven by any KPI deterioration event. Therefore, we need to
make routine network check according to certain rules and give an early warning to
those that do not conform to rules.
Routine analysis and quality early warning include the following aspects:
1) Check unidirectional adjacent cells. Normally, the intra-frequency adjacent cell
relationship of the UMTS network is configured as bi-directional. If some cells are
only configured with unidirectional adjacent cell relationship, we need to give an
early warning to those scenarios that cannot give special reasons for their
particularity.
2) Check the adjacent cells that miss configuration. Using the missing adjacent cell
check function, regularly check whole-network adjacent cell relationship. We
need to give an early warning to the adjacent cells that apparently miss
configuration.
3) Check RTWP. Regularly check the average RTWP and the maximum RTWP of
whole-network cell. It is found from actual network that some cells have a
relatively high RTWP, but their call drop rate and call drop times are not
necessarily quite deteriorated. No matter what the KPI performance of a cell is,
we need to give an early warning to the cells with a relatively high RTWP and find
out corresponding causes.
4) Check pilot pollution. Actual measurement and theoretical analysis have given us
a conclusion. Pilot pollution is not necessarily linked to call drop, but we need to
optimize the regions with severe pilot pollution. We should regularly check
whole-network pilot pollution with the Nastar and give an early warning to the
regions with severe pilot pollution.
Routine check is also based on the basic query function and advanced special topic
function of the Nastar. Its period can be flexibly set according to existing network
conditions. For example, routine check can be made once a month or a quarter.
Another trigger factor of routine check and quality early warning is network cutover.
When large-scale relocation and cutover occur in a network, be sure to make routine
check by using the configuration verification function and missing adjacent cell check
function of the Nastar. The complexity of the UMTS network parameters determines
the fact that whole-network check is necessary in case of large-scale relocation. A
quality early warning should be given as soon as possible to parameter inconsistency
or parameter omission.
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
from associated traffic statistics index. If
the maximum uplink CE is less than 20,
then traffic is not high and the problem lies
in abnormal NodeB equipment.
Observation Possible
Condition Analysis Idea
Point Cause
quite possible that RNC judges CE to be
sufficient, but actual NodeB CE resource is
insufficient. In addition, inconsistent
capability of RNC and NodeB may also
lead to NodeB RL establishment failure.
Observation Possible
Condition Analysis Idea
Point Cause
failure rejection occurs.
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
need to query the maximum RTWP and the
maximum TCP of the cell to make sure of
uplink congestion or downlink congestion
and judge whether any expansion is
necessary. Meanwhile, we should check
whether related admission strategy
settings, such as DCCC, are proper.
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
synchronized, which leads to RB
establishment failure. This is mainly caused
by poor coverage.
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
Other RF
RF cause; due to poor coverage quality
causes
Observation Possible
Condition Analysis Idea
Point Cause
Observation Possible
Condition Analysis Idea
Point Cause
Observation
Condition Possible Cause Analysis Idea
Point
Preparation
failures (>=5) of
Radio link establishment failure occurs
hard handover
Hard during RL establishment. For details, see
into this cell and
handover the RL establishment process analysis of
preparation
preparation the IUB interface.
failure rate
failure For other causes, we need to make a
(>=10%) of hard
further analysis based on RNC logs.
handover into
this cell
Observation
Condition Possible Cause Analysis Idea
Point
Transition in the
Generally, RNC does not support some
target CN/RNC
hard handover parameters. We need to
or system not
make an analysis based on RNC logs.
supported
Observation
Condition Possible Cause Analysis Idea
Point
Observation
Condition Possible Cause Analysis Idea
Point
domain In this case, a BSC does not support some
intersystem Transition in the
parameters of intersystem handover
outgoing target CN/RNC
requests. We need to analyze the cause
handover. or system not
according to the signaling tracing of a core
supported
network and a BSS.
Observation
Condition Possible Cause Analysis Idea
Point
handover handover, Physical channel Possibly poor coverage or severe
execution failure failure interference
rate (>=10%) of
transition out of a UE gives the feedback that the hard
cell accompanied Synchronization handover process of RNC adding a link is
by hard handover reconfiguration incompatible with other concurrent
incompatible processes. The problem may lie in the
compatibility of a mobile phone itself.
Configuration
not finished
Observation
Condition Possible Cause Analysis Idea
Point
Observation
Condition Analysis Idea
Point
Observation
Condition Analysis Idea
Point
Observe whether the If the minimum RTWP is lower than -108 dBm, a
Minimum RTWP minimum RTWP is less channel fails to be corrected, or a base station
than -105.5 dBm. encounters power-down.
Observation
Condition Analysis Idea
Point
Excess
configuration of
adjacent cells
Observation Possible
Condition Analysis Idea
Point Cause
Network
optimization
Undefined
Observation Possible
Condition Analysis Idea
Point Cause
interface UE considers that the RL configuration
Configuration content of RNC establishment is not
not supported supported. The problem lies in the
compatibility of a mobile phone.
Observation Possible
Condition Analysis Idea
Point Cause
analysis based on RNC logs
RL reconfiguration failure caused by
abnormal factors. We need to make an
analysis based on RNC logs. The known
causes are that transmission congestion
(Received Iub AAL2 type1 setup
response message from AL but result is
5 not success!) and improper T314/T315
parameter setting make there not be any
opportunity of RL reconfiguration. RL
addition failure caused by abnormal
factors. We need to make an analysis
based on RNC logs. It is known that RL
addition failure caused by restricted IUB
transmission bandwidth will be classified
into this cause value.
The problem lies in the compatibility of a
mobile phone itself in some unknown
RB RB establishment
scenarios. For example, when a Huawei
establishment failure generally
mobile phone drops network abnormally,
failure corresponds to
it may not release any RB. When PS RB
RB poor air interface Configuration
is reestablished next time, this case may
reconfiguration coverage or a not supported
occur. This case also happens to SE
failure mobile phone
V800 mobile phone. Or when some UEs
RB deletion compatibility
implement VP and high-speed (greater
failure problem.
than or equal to 64K) PS service, failure
may also due to unsupported capability.
This generally occurs when FACH
migrates to DCH and establishes RB.
Physical
The downlink physical layer of a terminal
channel
is not synchronized, which leads to RB
failure
establishment failure. This is mainly
caused by poor coverage.
The Cell Update flow occurs during RB
Cell update establishment. This nested flow leads to
RB establishment failure.
Observation Possible
Condition Analysis Idea
Point Cause
occurs in the domain of CS, it is possible
that a user dials a wrong telephone
number and immediately goes onhook.
RB SETUP failure may also occur at this
time. The cause is illegal configuration.
Or when a 3 G terminal as the caller
implements VP service, the called party
resides in a GSM network and does not
support VP service. Thus, after RNC
receives an RAB assignment request, a
core network immediately delivers the
Disconnect command upon Call
Proceeding (the cause is Bearer
capability not authorized). But UE has
just received an RB_SETUP command
at this time and has no time to complete
RB establishment. Upon receiving this
Disconnect command, UE initiates a
response “RB establishment failure” and
RNC returns RAB establishment failure.
Generally poor coverage makes UE
unable to receive any RB command. In
Hong Kong, the balance mechanism of
IUB once made signaling established on
No response
one E1, but service was established on
from UE
another E1. Thus, there has been no
problem with signaling, but RB
establishment may fail. In this case, it is
this cause value that is returned.
Observe whether
PS has a large amount of 128k, 144k,
the number of
RB bearer and 384k RB bearer. This will consume a
various types of
distribution of large number of resources and there is
RB service bearer
uplink/downlink poor coverage. We need to verify
and the
service whether RB bearer is consistent with
proportion are
Uplink/downlink actual demands with first-line personnel.
abnormal. If there
RB bearer Observe whether the RB distribution of
is any
distribution of BE BE service is rational. According to the
abnormality, an
service distribution, DCCC strategy and related
early warning
system parameters can be adjusted.
needs to be given
RNC1.6 version supports the following KPI monitoring: HSDPA service establishment
success rate, HSDPA call drop rate, HSDPA cell throughput, H <-> H
intra-/inter-frequency serving cell update success rate and H <-> R99 intra-frequency
handover success rate. It does not support the following KPI monitoring: HSDPA
average uplink and downlink throughput for a single user, H <-> R99 inter-frequency
handover success rate, H -> GPRS intersystem handover success rate, statistics of
the causes for HSDPA service establishment failure, statistics of the causes for
HSDPA call drop failure, statistics of the causes for H <-> H intra-/inter-frequency
serving cell update failure, statistics of the causes for H <-> R99 intra-/inter-frequency
handover failure, statistics of the causes for H -> GPRS intersystem handover failure.
Therefore, we cannot use traffic statistics for HSDPA all-KPI monitoring and analysis,
but need to use other supplementary means. It is recommended to use driving test
and signaling tracing for routine monitoring of the indexes not supported by RNC1.6
version. Meanwhile, analyze and locate KPI abnormality.
RNC1.7 traffic statistics is being collated and remains to be supplemented.
The main cause of the exemplified RRC establishment failure is that there is no
response to RRC Setup command delivery. It is unbalanced coverage of downlink
FACH and uplink RACH. For an early network, coverage cannot be guaranteed, so
there are a large number of areas with poor coverage quality. These areas with poor
coverage always correspond to intersystem rerouting areas. On the other hand, where
there are many users or equipment problems within a cell, RRC establishment
rejection is also a major cause of RRC establishment failure.
2. Analysis of RRC establishment scenario
One important reason for RRC establishment failure is poor coverage. We may make
a further analysis by using the establishment cause distribution and success rate of
different RRCs establishment. Get results by starting related query and selecting
Scenario Analysis to present a selected RNC in the form of a pie chart and a bar chart.
As shown in Figure 13, the bar chart compares the RRC establishment success rates
of various main scenarios. It can be seen from the examples in the figure that the
called voice service has the highest RRC establishment success rate while the calling
voice has the lowest success rate (which corresponds to a large amount of UENoRsp
analyzed earlier). The RRC establishment success rate of registration is also relatively
low. In Huawei networks, the present resident threshold is Ec/Io greater than -18 dB.
The intersystem reselecting starting threshold is Ec/Io less than -14 dB. A low
registration success rate indicates that some terminals have attempted to register at a
network in the areas without good coverage (Ec/Io is between -14 dB and -18 dB). The
called RRC establishment success rate is as high as 99.3%. If the called party starts
RRC establishment, it indicates that he is covered by a PCH. From another point of
view, this indicates that the RRC establishment success rate of expected network
coverage area may be very high.
3. Analysis of RRC establishment rejection
Another cause of RRC establishment failure is RRC establishment rejection. In the
case of RRC establishment rejection, generally too many users lead to admission
rejection, or cell equipment fault leads to access failure. RRC establishment rejection
always corresponds to some areas instead of a large network area. RRC
establishment rejection is generally analyzed based on problematic areas. In the
query results of RRC Setup Analysis, start related query to make TOPN query of Cell
RRC Analysis. Query results cover two pages, which respectively list 10 cells with the
most VS.RRC.FailConnEstab.Cell and VS.RRC.SuccConnEstab.Rate.Cell. For the 10
cells with the most RRC establishment failures and the cells with the most Rej, start
Cell RRC Reject Analysis of related query to analyze the causes for rejection.
According to the results of Cell RRC Reject Analysis, draw a pie chart of cause
distribution for a selected cell. Figure 14 is an exemplified pie chart of cause
distribution of RRC rejection. In this example, two RRC rejections of a cell are
because of Power Congestion. The following shows the commonly seen causes of
rejection:
1) Power Congestion: RRM makes an admission algorithm decision. Downlink
admission decision occurs. Therefore, RRM starts RRC establishment rejection.
This often occurs when heavy network load leads to congestion. Further, we may
start Cell Traffic Load Analysis of related query, pay much attention to the
maximum RTWP and the maximum TCP of this cell and make sure whether there
is uplink congestion or downlink congestion. For congestion, we may check
whether a threshold is properly set and judge whether there is any radio
interference, whether expansion is necessary.
2) CE Congestion: This is mainly because RNC considers CE resource insufficient.
CE congestion always corresponds to many users. These users exceed CE
capacity and we need to expand the capacity of this area. Further, we may start
Cell Traffic Load Analysis of related query, know about the quantity of DCH User
and predict the required CEs according to the traffic model.
3) RL Fail: During RRC establishment, NodeB considers establishment fails. This
may be NodeB fault or insufficient NodeB resource. Further, we may start Cell
Traffic Load Analysis of related query and know about the quantity of DCH users.
Determine whether the problem lies in insufficient resource or equipment fault by
analyzing the board configuration, CE configuration and logs of a corresponding
NodeB.
4) AAL2 Fail: This is mainly the AAL2 Path establishment failure of an Iub interface.
It is generally caused by insufficient transmission resource or transmission
problems. Further, we may start Cell Traffic Load Analysis of related query, know
about the quantity of DCH users and compare it with the AAL2 Path bandwidth of
transmission configuration. Thus, we can determine whether the problem lies in
equipment or insufficient transmission resource.
5) Redir.Inter.Att: Inter-frequency redirection failure starts rejection.
6) Redir.Intrat: Foreign redirection failure starts rejection.
7) Code Congestion: This is mainly because of insufficient resource. Insufficient
code resource may be seen in high traffic scenarios with microcell coverage, and
expansion is necessary. Cell OVSF Code Allocation Analysis of related query
helps analyze the use of channel codes and clarify main services.
8) Other: This is mainly an RNC internal processing problem. Its cause needs to be
confirmed according to R&D logs.
4.3 Summary
Make a similar analysis of several other special topics according to the
above-mentioned idea of the RRC connection analysis. Keep summarizing
experiences in your analysis. Special topic analysis will help greatly improve basic
skills of performance analysis.
Basic special topic analysis practice contributes to the following aspects:
1) Consolidate signaling flow and deepen an understanding of each UTRAN PI.
Performance analysis has a more definite object in view.
2) Basic special topic analysis enables us to make a preliminary analysis of network
performance and locate simple problem causes.
3) Summarize the relationship between performance KPIs and network problems,
and lay a foundation for the use of other Nastar functions and an in-depth
analysis of network performance.
5.3 Summary
According to network performance analysis results, formulate optimization strategies,
implement optimization schemes, and compare the indexes before and after the
optimization to obtain optimization implementation effects. In this way, one
performance analysis is closed. But performance analysis and quality early warning
come full circle. The increase in network registration users, change in traffic model,
and equipment transmission abnormality require that engineers should show
continuous concern for network performance, summarize experiences and use proper
methods to improve the efficiency of performance analysis.
6 References