WCDMA Network Performance Analysis Guide
WCDMA Network Performance Analysis Guide
1.0
Brainstorming Group
and
Revision History
Date August 28, 2006 Revision Version 1.00 Description Author
Zuo Yanzhong
1.1
optimization parts are simplified according to review comments. The emphasis is to find problems. He Fengming Analysis based on observation points and subsequent analysis data requirements are added.
1.2
The document is revised according to the review comments of the CCB. Alarm analysis is added. Review yearly
He Fengming
1.3 1.31
2008-11-29
Page 2 of 80
Contents
1 Overview..........................................................................................................................................8 1.1 Purpose of the Document ......................................................................................................8 1.2 Users of the Document ..........................................................................................................9 2 Necessary Conditions of Performance Analysis and Quality Early Warning ........................10 2.1 Creating Network Planning and Network Optimization Parameter Archives .......................10 2.2 Signaling Flows of UTRAN and Basic Principles of WCDMA .............................................11 2.2.1 Mastery of Signaling Flows and Basic Principles......................................................11 2.2.2 Fast Makeup of Knowledge Points ...........................................................................12 2.3 Familiarization of UTRAN PIs ..............................................................................................12 2.4 Use of the Nastar Tool .........................................................................................................13 2.4.1 Relations between Traffic Statistics PIs and Network Problems...............................14 2.4.2 Mastery of Advanced Functions of the Nastar Tool...................................................15 2.5 Summary..............................................................................................................................16 3 Three Steps of Performance Analysis and Quality Early Warning ..........................................17 3.1 Step 1: Knowledge of Network Conditions ..........................................................................17 3.1.1 Historic Performance Index of Network ....................................................................18 3.1.2 Parameter Revision History ......................................................................................21 3.1.3 Network Operation History ........................................................................................24 3.2 Step 2: Preparations for Performance Analysis ...................................................................24 3.2.1 Starting Time of Performance Analysis and Quality Early Warning ..........................24 3.2.2 Preparation of Master Data .......................................................................................25 3.3 Step 3: Ideas and Methods of Performance Analysis and Quality Early Warning ...............27 3.3.1 Conventional Methods of Performance Analysis ......................................................27 3.3.2 Analysis Method of Alarm Data .................................................................................28 3.3.3 Quick Analysis of Some PIs ......................................................................................34 3.3.4 Commonly Seen PIs and Corresponding Analysis Idea ...........................................34 3.3.5 General Idea of Performance Analysis and Quality Early Warning ..........................35 3.3.6 Procedures and Methods of Performance Analysis and Quality Early Warning .......36 4 Observation Point and Analysis Examples of Typical Problems ............................................50 4.1 Observation Points of Typical Problems ..............................................................................51 4.1.1 RRC Establishment Analysis Observation Point.......................................................51 4.1.2 RAB Establishment Analysis Observation Point .......................................................54 4.1.3 Call Drop Analysis Observation Point .......................................................................57
2008-11-29
Page 3 of 80
4.1.4 Soft Handover Analysis Observation Point ...............................................................60 4.1.5 CS/PS Intersystem Handover Analysis Observation Point .......................................61 4.1.6 Traffic Analysis Observation Point.............................................................................66 4.1.7 Key Interface Flow Analysis Observation Point ........................................................68 4.1.8 HSDPA Analysis Observation Point ..........................................................................72 4.2 Example of Analysis Based on Observation Point...............................................................72 4.3 Summary..............................................................................................................................77 5 Closing of Performance Analysis and Quality Early Warning .................................................78 5.1 Basic Requirements for Analysis Conclusion ......................................................................78 5.2 Output Analysis Report ........................................................................................................79 5.3 Summary..............................................................................................................................79 6 References ....................................................................................................................................80
2008-11-29
Page 4 of 80
Figures
Figure 1 Measurement of performance index......................................................................... 13 Figure 2 Trend figure of call drop rate..................................................................................... 20 Figure 3 Revision history of baseline parameters................................................................... 23 Figure 4 History of network operations ................................................................................... 24 Figure 5 Alarm analysis processing flow................................................................................. 29 Figure 6 Performance analysis flow........................................................................................ 37 Figure 7 Performance analysis flow (Continued).................................................................... 38 Figure 8 Performance analysis of RRC establishment success rate...................................... 45 Figure 9 Performance analysis of RAB establishment success ............................................. 47 Figure 10 Special topic analysis.............................................................................................. 51 Figure 11 General information about RRC setup.................................................................... 73 Figure 12 Distribution of RRC setup scenario ........................................................................ 74 Figure 13 Comparison of RRC setup scenario success rate.................................................. 74 Figure 14 Analyzing the cause of RRC rejection .................................................................... 75
2008-11-29
Page 5 of 80
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.
Acronyms and Abbreviations Abbreviation ALCAP APS CCP CDL CDR CE CHR CHR CN GPS IOS KPI MSP MTP3B NCP Full Spelling Access Link Control Application Part ATM Protection Switching Communication Control Port Call Detail Log Call Drop Rate Channel Element Call History Record Calling History Record Core Network Global Positioning System Intelligent Optimization System Key Performance Index Multiplex Section Protection Message Transfer Part NodeB Control Port
2008-11-29
Page 6 of 80
Abbreviation NEMU NMON NodeB PI RAB RF RNC RRC RRU SAAL SCCP
Full Spelling NodeB Environment Monitor Unit NodeB Monitor Unit NodeB Performance Index Radio Access Bearer Radio Frequency Radio Network Controller Radio Resource Control Radio Remote Unit Signaling ATM Adaptation Layer Signaling Connection Control Part
2008-11-29
Page 7 of 80
Overview
A commercial network requires regular performance analysis and observation of QoS and running status, together with a timely early warning of abnormal or potential risks. Network performance analysis and quality early warning offer direct guidance to network optimization and expansion. Performance analysis and quality early warning aim to accurately and effectively find network performance and quality problems and give early warnings. What skills must network optimization engineers and network maintenance engineers master to monitor a network effectively? What principles, flows and procedures must be followed in performance analysis and quality early warning to ensure the accuracy and timeliness of analysis results? Based on Huawei's performance analysis practice in multiple commercial UMTS networks and the analysis experiences of the Performance Dept. and the Tool Dept., this document expounds the flows and procedures of performance analysis and quality early warning, together with other related precautions. In this document: Version of the performance analysis tool: NastarV400R001C03B020 RNC version: BSC6800V100R006C01B071 NodeB version: BTS3812EV100R006C02B040
3)
2008-11-29
Page 8 of 80
4) 5)
For multiple abnormal KPIs, the Nastar tool offers the causes such as RF.RLCRst, RF.ULSync and UuNoReply. How to make further analysis? If the call drop rate of a network PS is 5%, is any early warning needed? What are the early warning principles?
Some other questions are not listed here. In the first performance analysis, engineers tend to make a mistake: They expect to find the one-to-one correspondence between traffic statistics PIs and causes of problems. They first export a large quantity of traffic statistics indexes in analysis. For example, they export WCDMA Performance Monitoring Report from the Nastar tool once every week and pick out abnormal PIs. Then, they expect to find out the causes of those abnormal PIs from an encyclopedia. The causes of some problems, such as cell power resource congestion (Power.Cong) and IUB bandwidth restricted (IUB.Band), can be directly found from the PIs of the Nastar tool. But it is very hard to find out the causes of many network problems simply by querying PIs. The complexity of a UMTS network determines that performance analysis and quality early warning are comprehensive and systematic. These jobs require that analysts should master necessary skills and use normalized methods to analyze network performance while getting familiar with current network conditions. This document does not aim to provide a valuable book, through which performance analysts can easily analyze the running quality and performance of a network simply by querying traffic statistics KPIs. Instead, by expounding the general ideas and necessary procedures of performance analysis, the document normalizes network analysis and early warning actions and corrects network monitoring mistakes, to improve the efficiency of performance analysis and quality early warning.
2008-11-29
Page 9 of 80
2008-11-29
Page 10 of 80
2008-11-29
Page 11 of 80
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. 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. 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.
2)
3)
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.
2008-11-29
Page 12 of 80
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.
2008-11-29
Page 13 of 80
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. Analyze the relations between traffic statistics PIs and network problems. Define the nature of such problems. Analyze real network problems by combining the advanced functions of the Nastar.
2) 3)
Equipment
Abnormal
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
2008-11-29
Page 14 of 80
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).
2008-11-29
Page 15 of 80
3)
Pilot pollution solution. In pilot pollution analysis, no IOS data needs to be imported, but CHR, PERF/engineering parameters and configuration files should be imported. Coverage analysis solutions. When traffic statistics analysis shows that there is the problem of coverage within a cell, we need to make IOS tracing and import the traced IOS data to Nastar for coverage analysis. This coverage analysis includes common downlink pilot channel coverage analysis, link quality analysis, and overshoot analysis. Interference analysis solutions. Interference analysis helps effectively find out external interference or internal problems of equipment. By means of main-diversity signal strength analysis and according to certain algorithms, we can locate multiple possible causes of radio interference or abnormal signal. Interference analysis is a small but practical function. It helps on-site engineers find problems. The master data of interference analysis includes RTWP data, configuration data, and engineering parameters. Configuration verification CHR analysis means
4)
5)
6) 7)
The advanced functions of the Nastar will not be described further in this document. If you need them, please query the Help of the Nastar tool and master each function through repeated practices.
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.
2008-11-29
Page 16 of 80
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.
2008-11-29
Page 17 of 80
Before making performance analysis, we need to acquire a good knowledge of present network conditions, including early network performance indexes, modification records of network parameters, and operation history of networks.
AMR RAB Assignment Success Rate (>98%) Video Call RAB Assignment Success Rate (>98%) PS RAB Assignment Success Rate (>97%) Soft Handover Factor based on Radio Link Number (<50%) Soft Handover Success Rate (>99%) Inter-Freq Hard Handover Success Rate (>95%) CS Inter-RAT Handover Success Rate (from UTRAN to GSM) (>96%) PS Inter-RAT Handover Success Rate (from UTRAN to GSM) (>92%) CS AMR Call Drop Rate (<1.5%) VP Call Drop Rate (<3%)
Page 18 of 80
PS Service Drop Rate (<5%) HSDPA RLC Traffic Volume (MBytes) Traffic HSDPA Mean UE HSDPA RLC Throughput (Mbps) Access HSDPA RAB Setup Success Rate (>97%) HS-DSCH Service Cell Change Success Rate (with SHO)(>99%) HSDPA: HO CDR
2008-11-29
HS-DSCH Service Cell Change Success Rate (with Intra HHO)(>95%) HS-DSCH Service Cell Change Success Rate (with Inter HHO)(>95%) HS-DSCH to DCH Handover Success Rate (>95%) DCH to HS-DSCH Handover Success Rate (>95%) HSDPA Service Drop Rate (<5%)
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.
Page 19 of 80
2006-05-31
2006-06-05
2006-06-10
2006-06-15
2006-06-20
2006-06-25
2006-06-30
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. Table 3 PS call drop analysis of top 10 cells PS Call Drop(2006-08-18) CellId 22192 58681 14282 16351 16352 22191 16181 CellName PS Call Drops PS Call Drop Rate(2006-08-18) CellId 58681 16181 16351 16352 22191 22192 44441 CellName MKK_A Ellen_AB ManHong_ABE ManHong_CD KingNamH_AB KingNamH_CDE TsLokEst_AD PS Call Drops rate 90.27% 35.39% 40.96% 35.68% 61.54% 18.38% 36.59%
2008-11-29
Page 20 of 80
2006-07-05
PS Call Drop(2006-08-18) CellId 44461 58111 44441 CellName UWTSEst_A DyPlzCi_A TsLokEst_AD PS Call Drops 56 40 30
PS Call Drop Rate(2006-08-18) CellId 44461 58111 14282 CellName UWTSEst_A DyPlzCi_A EHTunnl_B PS Call Drops rate 30.11% 90.91% 41.50%
In subsequent analysis of PS call drop rate, we may make a comparative analysis of top ten cells and observe whether any change has taken place, whether the PS call drop indexes of these cells rise abnormally. Based on recent network parameter modifications and network operations, we judge whether any in-depth performance analysis is needed. Other KPIs that need a careful observation, such as call completion rate and foreign handover success rate, need to be similarly recorded as described above.
2006.01.03
2008-11-29
Page 21 of 80
Revision of On-Site Baseline Parameters NO Date Problem Description VP, PS64, PS144, and PS384 according to on-site optimization to improve network quality and call drop. See the table Cell_TrafficPower_CR. 3 2006.02.04 Change the intra-frequency rerouting starting threshold to -4 dBm. See the table Cell_SelReselParas_CR. Change the admission and congestion parameter settings of Hong Kong Island. For details, see CELL_CACPara and CELL_LCCPara. Change intra-frequency measurement parameters including Layer 3 filtering coefficient, 1A1B relative threshold, and delay trigger time and so on. See the table Cell_IntraFreqHOMrParas_CR. For some cells to tunnels and underground 3G-2G handover and change of inter-RAT measurement starting threshold and decision threshold, see the table Cell_IntraFreqHOMrParas_CR. Turn on the common channel flow control switch of the IUR 7 2006.02.08 interface because an IUR interface is configured between the RNC1 and RNC2 of the current SUNDAY. Adjust the inter-frequency power of some cells from 33 dBm to a smaller value. The reasons are as follows: NodeB is a 10 W base station and its inter-frequency power is 8 2006.03.09 30 dB. Share indoor distribution system and RF requirements with other operators. In network optimization, the inter-frequency power of some cells is adjusted to 30 or 28 dBm. 9 2006.03.10 Turn on the UE state transition switch. The static transition switch is turned off to avoid the possible call drop caused by some mobile phones not supporting static transition. The downlink blind detection switch is turned off to avoid one-way audio caused by some mobile phones not supporting blind detection. T314 and T315 are set to 0. Disable Cell Update caused by
2006.02.05
2006.02.06
2006.02.07
10
2006.03.11
11
2006.03.12
12
2006.04.13
2008-11-29
Page 22 of 80
Revision of On-Site Baseline Parameters NO Date RLFAILURE. 13 2006.04.14 Change the number of continuous synchronization indication to 1. See the table CellBasicInfo. Change the minimum access quality to -20 dB. See the table Cell_SelReselParas_CR. Change times of random access preamble retransmission to 20 times. See the table CellPrachParas. To avoid poor streaming quality caused by code transmit power limit, the maximum service code transmit power of PS 144 is increased by 2 dB and is the pilot channel power +2 dB. See the table Celltrafficpower. To check the adjacent cells that miss configuration or potential adjacent cells, turn on the monitoring set reporting switch. See the table SWITCH. The uplink BE service rate negotiation threshold is 8K and the downlink BE service rate negotiation threshold is 64K. See the table SWITCH. Add cell location configuration information. The maximum coverage distance of a cell antenna is 500 m. Activate the AGPS location activation identifier. See CellSMLCParas. The maximum retransmission times of location measurement can be set to 0. See the table SWITCH. The hard handover hysteresis is 6 (3 dB). 2D trigger time is 640 ms. NBMULCACALGOSELSWITCH uplink admission switch is turned off. See the table SWITCH. Change inter-RAT cell reselecting starting threshold (Ssearchrat) to 3, inter-frequency cell reselecting starting threshold (Sintersearch) to 5 and intra-frequency cell reselecting starting threshold (Sintrasearch) to 8. Figure 3 Revision history of baseline parameters 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 Problem Description
14
2006.04.15
15
2006.04.16
16
2006.05.17
17
2006.05.18
18
2006.05.19
19
2006.06.20
20
2006.06.21
21
2006.07.22
22
2006.07.23
23
2006.07.24
2008-11-29
Page 23 of 80
analysis of a certain version demands a good knowledge of the known defects of a product.
Figure 4 History of network operations 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.
2008-11-29
Page 24 of 80
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.
2)
3)
2008-11-29
Page 25 of 80
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. Traffic statistics data Configuration data 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. RTWP data (optional). It is chiefly used for interference analysis. It may be omitted if interference analysis is definitely unnecessary. IOS data (optional). It is used for an in-depth location analysis of many network abnormality problems, such as coverage. General schedule of engineering parameters (optional). It is required for geographic analysis.
2) 3) 4)
5) 6) 7)
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
2008-11-29
Page 26 of 80
performance analysis according to early performance analysis. If it is really necessary, we need to start tracing to get RTWP data and IOS data.
3.3 Step 3: Ideas and Methods of Performance Analysis and Quality Early Warning
This part summarizes the early experiences of multiple commercial networks in performance analysis, and educes section 3.3.2 General Idea of Performance Analysis and Quality Early Warning from historical experiences. According to the general idea, section 3.3.3 Quick Analysis of Some PIs systematically describes the methods and procedures of performance analysis.
According to traffic statistics indexes such as call drop rate, connection success rate, and soft handover failure rate, get the busy-hour average or all-day average as required, find out the worst N cells, and make them as the emphasis of fault analysis and optimization. Or you may determine the priority order of optimization based on this. 2) Time trend figure
Trend figure of traffic statistics index is a commonly used method of traffic analysis. Analysis engineers may draw the change trend figure of one or more indexes of the whole network, Cluster or a single cell by hour, day or week and find the change law of traffic statistics indexes. 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
2008-11-29
Page 27 of 80
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.
2008-11-29
Page 28 of 80
No
No
No
End
Ye s
Figure 5 Alarm analysis processing flow 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.
2008-11-29
Page 29 of 80
Table 4 Alarm influence Alarm Type Performance Impact Trunk alarm has a fatal impact on network quality. If network quality is worsened and there is any trunk alarm, it is generally believed that it is trunk fault that causes worsening of the network quality. There are a variety of trunk alarms. Trunk alarm does not necessarily lead to the worsening of network quality. This type of alarm always has numerous accompanying alarms. We need to combine associated alarms and make an analysis for accurate location. Some alarms will make a base station unavailable, thus causing coverage hole. This may not be found from KPIs, but will cause the cell of the base station adjacent to this base station to have a greater probability of RF call drop. In the case of a large-scale network, the impact is concealed. From the perspective of KPIs, it can only be considered that this falls within the normal fluctuation range. But the unavailability caused by this type of alarm will have a bad impact on users feelings. Maybe some customers will make complaints. In this case, we should not make an analysis only from the association of KPIs with alarm. We need to focus on whether alarm makes a cell unavailable. The impact of this alarm on KPI is implicit. Loopback alarm, configuration alarm, and mismatch alarm do not appear in network operation, so they do not deserve our attention. Slip frame overrun alarm and high bit error alarm depend on specific conditions. If they appear often, they will have an impact on network quality. If they are seldom generated, it can be believed that they have no impact on network quality. Among the RNC alarms, the alarms about APS and MSP have no impact on service. These are the alarms of additional functions. If they are not used, this type of alarm does not appear in network operation. Other alarms, more or less, affect service. They affect capacity, access, handover, and call drop caused by RF.
Trunk alarm
2008-11-29
Page 30 of 80
Alarm Type
Performance Impact Most alarms may be signaling link alarms caused by trunk alarm. In analyzing this type of alarm, we need to make clear whether there is any trunk alarm. If there is any trunk alarm, we need to analyze them by associating signaling link alarms with trunk alarms. Note that NodeB categorizes AAL2PATH alarm as a signaling alarm while RNC categorizes AAL2PATH alarm as a trunk alarm. Signaling alarm will unexceptionally have a certain impact upon service, sometime a fatal impact. For example, NCP/ALCAP alarm directly causes the unavailability of a base station, so a coverage hole appears. The alarms of MTP3B link, SCCP and SAAL link will have a direct impact on service availability. If the link with a core network is interrupted, the link will also be interrupted between UE and the core network. All related services become unavailable. Configuration error alarm, syntactical error alarm, unknown message, and packet boundary-crossing may appear in interconnecting partners equipment. But they will not affect existing network quality if other processes are normal. The system information 11 limiting adjacent cell data is an event alarm. Handover is not affected either. Among RNC alarms, there are some event alarms. If these event alarms are often generated, they will affect network quality. If they seldom occur, it can be believed that they do not affect network quality. QoS alarm directly affects service communication quality and KPIs. For the alarms of NodeB, generally cell blocking appears in network operation only when this cell is not needed. Therefore, we need not pay any attention to this type of alarm. Simulated load starting alarm is used for testing and does not appear in network operation either. Cell unavailability will directly cause a coverage hole. Call drop caused by RF will also appear. Too small output power of a cell will also cause coverage problems and there will be poor coverage in some places. This causes call drop due to RF. From the perspective of KPIs, call drop rate rises slightly. The service alarm of RNC is an event alarm and affects service slightly. But the loss of a large number of measurement results may cause some algorithm problems, for example, power control failure. If event alarms are often generated, they may affect KPIs, but the impact is limited.
Signaling alarm
QoS alarm
2008-11-29
Page 31 of 80
Alarm Type
Performance Impact The alarms which involve a service board and a main control board may affect service. The alarm of a board other than a service board does not affect any network quality. Among the hardware boards of NodeB, all the boards except the NMON board are related to service. The alarms of these boards may lead to deterioration of network quality. But the extent of impact depends on alarm type. A RF board is also related to service and directly affects quality of the air interface of networks. All boards of RNC products are basically related to service. Board hardware fault of the WRSS frame and WRBS frame may deteriorate network quality. Power alarm and fan alarm do not affect service. A faulty WGRU board affects location service, but does not affect any other service or KPIs. Therefore, no consideration should be given to this for the time being. Software alarm is generated by the running software part of a product. It is unrelated to hardware structure, but closely related to the software structure of the system. Among the software parts of NodeB and RNC, some involve service while others are not related to service, but related to equipment maintenance. Software function alarms related to service need our attention. Those alarms unrelated to service function do not need our attention. In analyzing the software alarm of NodeB, we need not pay any attention to the alarms of the operation and maintenance part. Other software alarms are generally unrelated to service and do
Hardware alarm
Software alarm
not appear in normal network operation. These alarms will be involved only when there is any operation of system software upgrade. But generally, the software upgrade of NodeB will interrupt service. In the software parts of RNC, the switching subsystem and the service processing subsystem are related to service, but the operation and maintenance subsystem is unrelated to service and may not be considered. The software alarms of RNC are mostly the alarms of the operation and maintenance subsystem. That is, they are associated with BAM database system. Host software alarm is seldom seen and some are generated during network construction. The alarms generated during network operation are the KPIs which only affect network capacity and network access.
2008-11-29
Page 32 of 80
Alarm Type
Performance Impact This type of alarm is generated when the software system runs abnormally. Most of them are system abnormality caused by software design defects after long-term running. They may also be generated when system running exceeds software design specifications. We need to know about product specifications and functions before we analyze network quality well. Most alarms are unrelated to service. The running alarms of NodeB will mostly be seen during the early days of network construction. This is because some configuration has not been fixed yet. These running alarms are seldom seen during normal operation. LICENSE alarm and DSP/CPU alarm will affect the capacity, access and handover of the system. The running alarms of RNC are mostly generated during network construction because some configuration or parameter settings are not fully frozen during network construction. These alarms helps effectively analyze and solve some problems existing during network construction. They will be eliminated in formal network optimization to avoid affecting network quality. Communication alarms are mainly internal communication alarms of a product, especially the maintenance channel communication between boards. Generally speaking, maintenance channel fault does not affect any service, but service channel fault is bound to affect service. When a communication link generates any alarm, link fault will lead to corresponding communication interruption.
Running alarm
Communication alarm
The internal communication alarm of NodeB does not affect normal service running. The communication link of RNC is related to service, so the interruption of internal links between corresponding boards will have a certain impact as a trunk alarm does. Among the communication alarms of RNC, BAM-related link fault will not affect service, but the alarms which involve a board may affect service. The impact is fatal and generally leads to the unavailability of a cell or a base station. Thus, some coverage hole problems appear.
2008-11-29
Page 33 of 80
Alarm Type
Performance Impact An environment alarm generally does not affect the service and
Environment alarm
KPI of the system. But some environment alarms deteriorate product performance or functions of some products. They will be analyzed accordingly. Among the environment alarms of RNC, GPS antenna alarm affects only location service instead of any other service. Generally, power alarm does not affect service at all, but hardware alarm caused by power alarm may make service abnormal. This case will be analyzed accordingly.
Power alarm
Processing error Processing error alarm involves only RNC instead of NodeB. alarm
2)
2008-11-29
Page 34 of 80
VS.MinTCP, and VS.MaxTCP, or starting the downlink transmit power measurement of this cell), start load problem analysis. 3) If call drop rate of the whole network suddenly becomes relatively high, generally the following factors may lead to this and we need to make the following check: (1) Iu interface transmission analysis: analyze alarms to see whether there is any problem with the transmission for the Iu CS interface and the Iu PS interface. (2) RNC equipment analysis: analyze alarms to see whether RNC boards reset and whether there is any equipment fault. (3) whole-network traffic analysis: Find out whether sudden increase in registered users and traffic leads to the increase in call drop rate and check whether the system is upgraded or patched. In dealing with special topic exercises, Chapter 2 points out that there is need to summarize the relationship between traffic statistics PIs and network problems (section 2.4.1). This section summarizes commonly used experiences in analysis of commercial networks. It also expounds the analysis idea of commonly seen PIs. The abstraction of this experience forms the following parts:
2)
3)
4)
2008-11-29
Page 35 of 80
5)
After defining the nature of problems, properly use different functions of the Nastar tool for an analysis.
3.3.6 Procedures and Methods of Performance Analysis and Quality Early Warning
3.3.6.1 Flowchart of Performance Analysis Procedures
According to the general idea, we may determine the specific procedures of performance analysis and quality early warning. It is mentioned in 3.2.2 Preparation of Master Data that RTWP data and IOS data can be obtained only if there is specific tracing, and is needed only at a specific stage of performance analysis. The following flowchart shows the main procedures of performance analysis, but the performance analysis flow is not completely a one-way process. From the perspective of time, performance analysis is also a day-after-day process of gradual analysis, repeated optimization and continuous observation. After a problem is analyzed, possibly there is need to adjust parameters, increase transmission and solve equipment problems. Upon finishing network optimization and network maintenance, continue observing network indexes, contrastively adjust traffic statistics performance, and confirm the effects after the change. From the perspective of flow, we may omit some procedures or lay an emphasis upon the observation of a certain part according to on-site scenarios.
2008-11-29
Page 36 of 80
END
N (5) Analysis of cell load problems Traffic statistics: IUB bandwidth CE resource Equipment resource Radio resource Y
2008-11-29
Page 37 of 80
CHR: NodeB RTWP Cell load information Special interference analysis Y Solve cell interference problems
CHR: Pilot pollution Extraction of coverage information IOS Trace: Analysis of cell coverage quality Y
N (9) CHR flow/terminal performance CHR: Statistical analysis of mobile phone problems Y Terminal defect list
N B
2008-11-29
Page 38 of 80
1)
Overall analysis of network KPI Step 1 of performance analysis and quality early warning is to make an overall analysis of network KPIs. The KPIs include, but are not limited to traffic, call completion rate, handover success rate, and call drop rate, shown as follows. For those which contain specific services, such as HSDPA and CMB, or specific algorithms, we also need to observe the integral indexes of corresponding KPIs. Analyze the KPI of daily report or weekly report as required. From WCDMA Performance Monitoring Report output by the Nastar tool, we can also obtain a visual overall analysis. The judgment of whether the KPI is abnormal must be based on the comparison with early history. We may observe the extent of relative change instead of the absolute value of the KPI. When there is no apparent change in the KPI, there are two processing modes: End the current performance analysis and analyze TOPN cell. When there are a large number of network cells, the performance deterioration of very few base stations may not apparently affect the overall network KPI. These abnormal cells can be found out by contrasting TOPN analysis. When the relative value of the KPI is not apparently changed but its absolute value always cannot reach standards and no analysis conclusion has been drawn, we need to analyze specific causes according to traffic statistics data and conduct quality early warning.
Table 5 Overall analysis of network KPIs AMR DL12.2 Erlang VP DL Erlang CS Erlang Traffic PS UL Erlang PS DL Erlang PS UL Throughput PS DL Throughput Access RRC Connection Setup Success Rate (service) (>98%) RRC Connection Setup Success Rate (other) (>95%) AMR RAB Assignment Success Rate (>98%) R99
2008-11-29
13.08 (11:0012:00) 0.39 (17:0018:00) 15.86 (18:00 19:00) 167.19 (21:0022:00) 554.03 (21:0022:00) 2675.06 (21:0022:00) 8864.55 (21:0022:00) 99.78% (135343/135638)
99.31% (170930/172122)
99.66% (18595/18659)
Page 39 of 80
Video Call RAB Assignment Success Rate (>98%) PS RAB Assignment Success Rate (>97%) Soft Handover Factor based on Radio Link Number (<50%) Soft Handover Success Rate (>99%) Inter-Freq Hard Handover Success Rate (>95%) CS Inter-RAT Handover Success Rate (from UTRAN to GSM) (>96%) PS Inter-RAT Handover Success Rate (from UTRAN to GSM) (>92%) CS AMR Call Drop Rate (<1.5%) CDR VP Call Drop Rate (<3%) PS Service Drop Rate (<5%) HSDPA RLC Traffic Volume (MBytes) Traffic HSDPA Mean UE HSDPA RLC Throughput (Mbps) Access HSDPA RAB Setup Success Rate (>97%) HS-DSCH Service Cell Change Success Rate (with SHO) (>99%) HSDPA HO CDR
2008-11-29
99.57% (230/231)
99.59% (95524/95918)
HO
98.76% (6198/6276)
96.10% (44834/46653) 0.35% (66/18595) 0.87% (2/230) 5.08% (4854/95524) 19373 68.18 (18:0019:00)
98.24% (14360/14617)
99.73% (10391/10419)
HS-DSCH Service Cell Change Success Rate (with Intra HHO) (>95%)
N/A
HS-DSCH Service Cell Change N/A Success Rate (with Inter HHO) (>95%) HS-DSCH to DCH Handover Success Rate (>95%) DCH to HS-DSCH Handover Success Rate (>95%) HSDPA Service Drop Rate (<5%) 99.38% (961/967)
Page 40 of 80
2)
Analysis of RNC equipment problem/IU transmission problem/parameter RNC equipment problem and IUR interface transmission problem may affect the whole-network KPI. IU interface transmission problem and core network problem will affect the whole-network KPI directly. If the performance indexes of network cells are universally deteriorated, basic causes are related to the RNC board reset and restricted IU interface transmission. Equipment problems and intermittent transmission failure can be checked by the Omstar tool. Transmission bandwidth restricted can be checked by observing transmission-related PIs from traffic statistics. Another case of affecting the overall KPI of RNC: RNC-level parameter change. If the whole-network KPI becomes apparently abnormal, we need to make sure whether any RNC-level parameter change has been made recently and carefully check the impact of this parameter on the network.
3)
KPI analysis of TOPN cell The number of TOPN cells can be increased according to the network scale. The number of the Nastar tools is 10 by default. If there are too few TOPN cells, some cells with abnormal performance may be ignored. The WCDMA Performance Monitoring Report output by the Nastar tool lists the TOPN with normal KPIs. According to this report, we may pick out important cells from TOPN cells and make an in-depth analysis. A comparison of the indexes of TOPN cells with those of history TOPN cells helps judge whether cell performance indexes are normal. It is recommended to use the above-mentioned trend analysis figure for comparison. Make sure whether TOPN cell Id changes and what the amplitude of change in TOPN cell KPI is. This is simple but visual. TOPN cell problems must be analyzed together with cell traffic. For example, a pure observation of the call drop rate of a cell is meaningless. If a cell has one call drop, but there is only one call attempt, the call drop rate is 100%.
4)
Cell equipment analysis: Cell equipment analysis means analyzing the equipment of TOPN cells of last step. Likewise, subsequent load problem analysis and interference problem analysis are oriented to TOPN cells. The equipment that affects cell performance KPI includes the antenna feeder equipment and the uplink/downlink processing board of a base station. Generally, related equipment alarms can be observed either on the NodeB side or on the RNC side. The transmission restricted and intermittent transmission failure of a base station will affect related cell indexes. Intermittent transmission failure is observed by
2008-11-29
Page 41 of 80
using the Omstar tool. We make an auxiliary analysis by using the cell unavailability PI (VS.Cell.UnavailTime.OM) provided by the Nastar tool. 5) Analysis of cell load problems The indexes directly related to cell load include average uplink/downlink occupied CE of a cell (VS.LC.ULCreditUsed.CELL/2, VS.LC.DLCreditUsed.CELL) and the maximum uplink/downlink occupied CE (VS.LC.ULCreditUsed.CELL.Max/2, VS.LC.DLCreditUsed.CELL.Max). When the maximum uplink/downlink occupied CE approaches 128 or the average occupied CE is around 60, expansion should be considered. Causes for cell load problems include: change of traffic model; the main coverage service of this cell is designed to be VP64, but actually there are a large number of 384k services. During holidays, relatively concentrated population leads to the increase in traffic. High load may cause CE congestion, power congestion, code congestion, and transmission congestion. We should make an analysis by observing corresponding PI. In load problem analysis, when much power congestion occurs, actual load is not necessarily very high. In this case, we need to analyze admission strategy and judge whether admission parameters are properly set. 6) Analysis of cell interference problems Causes of interference: UE self-correlation interference. If there are many UEs in a conversation within a cell, interference will increase. Interference is also caused by external interference source and by pilot pollution. Whether there is any uplink interference within a cell can be judged by observing the RTWP indexes in traffic statistics, that is, the average RTWP of a cell and the maximum RTWP of a cell. If the average RTWP of a cell is as high as -95 dBm or higher, it is possible that there is uplink interference. Observe the maximum RTWP. If RTWP peak, such as -70 dBm, is often seen, the cause may be the power of access process or handover process. An in-depth interference analysis requires that the interference analysis function of the Nastar should be started. If a cell has severe interference, we need to trace its RTWP data. Import the RTWP data, configuration data and engineering parameter to the Nastar tool, and start the interference analysis function. In this way, we can effectively find external interference or internal equipment problems. This function locates multiple possible causes of radio interference or abnormal signals by analyzing main-diversity signal strength and according to certain algorithm categorization.
2008-11-29
Page 42 of 80
7)
Analysis of cell coverage problems Coverage problems include poor coverage, excessive coverage, pilot pollution, and missing configuration of adjacent cells. Poor coverage leads to poor performance of an air interface. In traffic statistics, a large number of PIs, such as RF.RLCRst, RF.ULSync and UuNoReply, are related to poor coverage. For an in-depth analysis of poor coverage and excessive coverage, we need to provide the IOS data of the analyzed cell and enable the coverage analysis function of the Nastar to make a statistical analysis of the coverage strength of the pilot and the link quality of service. Pilot pollution analysis does not need any IOS data. The pilot pollution analysis function of the Nastar tool needs CHR data, engineering parameter, configuration data, and traffic statistics data. The principles of pilot pollution analysis are to make statistics according to 1C measurement reports and signal quality of active set and monitoring set when 1C reports are reported, together with the number of branches of cell power splitting output in engineering configuration parameters. The intra-frequency adjacent cell check of the Nastar tool can be fully used to find those adjacent cells that miss configuration. In using this function, we need to turn on the detection set reporting switch. The principles of this function are to judge whether any adjacent cell misses configuration by making statistics of detection set reports and cell signal strength reported.
8)
Analysis of parameter problems: (What factors lead to parameter change? Insufficient bandwidth, missing configuration of adjacent cells, comparison of cutover tool with the Nastar tool) If the KPI deterioration of a cell is not closely related to equipment, load, interference or coverage, we need to check cell parameters carefully. We need to make sure whether the history (see 3.1.3 Network Operation History) of network operations contains any parameter adjustment related to this cell, including adjustment of adjacent cell relationship and RF parameter adjustment. If cell parameter adjustment has been made recently, we need to make a careful analysis. Meanwhile, the impact of early parameter adjustment on the recent KPI should not be eliminated. We also need to check whether there is a big increase in the traffic of this cell. If traffic increases sharply, the unreasonableness of cell parameters will be easily found. The configuration verification function of the Nastar tool can help quickly check the parameter changes of the same version made on a different day.
9)
Analysis of CHR process and terminal performance problems The prerequisite to network planning performance analysis is stable product performance and normal equipment. But the bug of actual networks and products always exists. We need to define whether the problem lies in product implementation through performance analysis.
2008-11-29
Page 43 of 80
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.
2008-11-29
Page 44 of 80
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
6. Ec/Io analysis
7. Overshoot analysis
Figure 8 Performance analysis of RRC establishment success rate 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. Judge whether the KPI satisfies network requirements according to the defined threshold or a comparison of the history.
2)
2008-11-29
Page 45 of 80
3) 4)
[TOPN Query] Subdivide RNC-level indexes into cell-level indexes and find out 10 cells with the worst indexes. [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. [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.) [Coverage Analysis] Enable cell coverage quality analysis to exclude coverage problems. [Overshoot Analysis] Enable overshoot analysis to exclude possible overshoot. [Missing Configuration of Adjacent Cell] Enable the analysis of missing adjacent cells to exclude the possibility of missing configuration of adjacent cells.
5)
6) 7) 8) 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.
2. Performance analysis of RAB establishment success rate Query TOPN cells with the most RAB establishment failures by using Nastar. Make the following performance analysis in terms of each TOPN cell.
2008-11-29
Page 46 of 80
1. Query RAB establishment success rate by using the performance analysis function
6. Ec/Io analysis
Figure 9 Performance analysis of RAB establishment success 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. Judge whether each RAB establishment KPI satisfies requirements based on the history. [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. [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.
2) 3)
4)
2008-11-29
Page 47 of 80
5)
[Customization Query] RAB failure causes can be categorized as coverage problems, handover problems and overload rejection problems. For the standard for the categorization, refer to Table 1 in section 2.4.1. [Coverage Analysis] Enable cell coverage quality analysis to exclude coverage problems. [Missing Configuration of Adjacent Cell] Enable the analysis of missing adjacent cells to exclude the problem of missing configuration of adjacent cells. [Customization Query] Query related PIs to make sure whether the problem lies
6) 7) 8) 9)
in handover. [Configuration Verification] Enable parameter optimization analysis to exclude handover parameter configuration problems. 10) [Customization Query] Query related PIs to make sure whether there is any overload. 11) [Customization Query] and [Interference Analysis] Query load-related PIs and enable interference analysis to exclude interference problems and overload problems.
2)
3)
2008-11-29
Page 48 of 80
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.
2008-11-29
Page 49 of 80
4
1) 2) 3) 4) 5) 6) 7) 8)
An observation point is a PI which reflects a specific performance problem. The analysis based on an observation point is a process that goes deeper based on the familiarization of the UTRAN PI. Observation point analysis associates signaling process with performance index. Observation points are categorized as follows: RRC establishment analysis observation point RAB establishment analysis observation point Soft handover analysis observation point Call drop analysis observation point CS/PS intersystem handover analysis observation point Traffic analysis observation point Key interface process analysis observation point HSDPA analysis observation point
An in-depth performance analysis can be made only after you have gained a mastery of observation points. The Nastar tool provides special topic query of most observation points. We may also make special topic query of other observation points by means of customization. Special topic drilling analysis of basic observation point helps deepen the understanding of signaling processes and various PIs and strengthen the mastery of the Nastar tool.
2008-11-29
Page 50 of 80
Categories of
RRC establishment their proportional requests distribution. If any abnormality, we need to give an early warning.
Number of RRC connection RRC establishment establishment failures (>=5); failure RRC connection establishment failure rate (>=10%)
RL establishment failure
2008-11-29
It may be caused by NodeB fault or insufficient NodeB resource. You may query the maximum downlink CE of a cell
Page 51 of 80
Observation Point
Condition
Possible Cause
Analysis Idea 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. RRM admission decision cannot establish any new RRC connection due to too high radio load within a cell. In this case, you need to query the maximum RTWP and the
Power congestion
maximum TCP of the cell to confirm 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. Uplink CE resource admission congestion within an RNC. You need to query the number of uplink CEs of a cell from relevant parameters and judge whether to expand CE. If the number of uplink CEs is less than 20, then traffic is not high and the problem may lie in abnormal NodeB equipment. At present, RNC does not make an accurate estimate of CE resource. It is 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.
Uplink CE congestion
Downlink CE congestion
Downlink CE resource admission congestion within an RNC. You need to query the number of downlink CEs of a cell
2008-11-29
from relevant parameters and judge whether to expand CE. If the number of uplink CEs is less than 40, traffic is not high and the problem may lie in abnormal All Rights Reserved Page 52 of 80 NodeB equipment. At present, RNC does not make an accurate estimate of CE resource. It is
Observation Point
Condition
Possible Cause
Analysis Idea 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. Code resource fails to be allocated during RRC connection establishment. Code congestion is generally caused by too
Code congestion
many network users. It may be seen in high traffic scenarios with microcell coverage. You may query the effective utilization of codes from associated traffic statistics indexes. If the effective utilization of codes is lower than 30%, it is possible that the code distribution algorithm is abnormal. Generally the congestion caused by
unknown insufficient resources. For example, license resource and high CPU utilization make flow control and FMR processing capacity insufficient. In addition, E1 fault also appears. This cause value is dotted. Transmission congestion is mainly caused by insufficient transmission resource. You may query the downlink cell throughput from associated traffic statistics indexes. If the downlink cell throughput is lower than 200 kbps, it is possible that there is abnormal equipment. The power-down of a base station once led to transmission interruption, but the cause in traffic statistics is transmission congestion.
Transmission congestion
Abnormal causes. We need to make in-depth location based on RNC logs. The known problem is that the system
2008-11-29
redirection function of the network is enabled. During redirection, a mobile phone does not support GSM and thus of 80 All Rights Reserved Page 53
Observation Point
Condition
Possible Cause
No response from UE
This is generally caused by poor coverage. The downlink FACH and RACH have unbalanced coverage. This is generally caused by an RNC fault. At present, there is a problem with traffic statistics mode, which may lead to some wrong dotting of this cause.
There was a problem with the designated access DSP of node B. The RRC CONNECTION SETUP REQUEST message fails to be sent to RNC. The RACH packet decoding of this cell fails. We may make a judgment by checking whether the index VS.MAC.CRNCIubBytesRACH.Tx is abnormal.
Number of CS/PS RAB CS/PS RAB establishment establishment failure failures (>=5); CS/PS RAB establishment failure rate (>=10%)
Power congestion
2008-11-29
RRM admission decision cannot establish any new RRC connection due to too high radio load within a cell. In this case, you
Page 54 of 80
Observation Point
Condition
Possible Cause
Analysis Idea 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. Uplink CE resource admission congestion within an RNC. You need to query the number of uplink CEs of a cell from relevant parameters and judge whether to expand CE. If the number of uplink CEs is less than 20, then traffic is not high and the
Uplink CE congestion
problem may lie in abnormal NodeB equipment. At present, RNC does not make an accurate estimate of CE resource. It is 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. Downlink CE resource admission congestion within an RNC. You need to query the number of downlink CEs of a cell from relevant parameters and judge whether to expand CE. If the number of uplink CEs is less than 40, then traffic is not high and the problem may lie in abnormal NodeB equipment. At present, RNC does not make an accurate estimate of CE resource. It is 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.
Downlink CE congestion
2008-11-29
Page 55 of 80
Observation Point
Condition
Possible Cause
Analysis Idea Code resource fails to be allocated during RRC connection establishment. Code congestion is generally caused by too many network users. It may be seen in high
Code congestion
traffic scenarios with microcell coverage. You may query the effective utilization of codes from associated traffic statistics indexes. If the effective utilization of codes is lower than 30%, it is possible that the code distribution algorithm is abnormal. Transmission congestion is mainly caused by insufficient transmission resource. You may query the downlink cell throughput from associated traffic statistics indexes. If the downlink cell throughput is lower than 200 kbps, it is possible that there is abnormal equipment. The power failure of a base station once led to transmission interruption, but the cause in traffic statistics is transmission congestion.
Transmission congestion
Others
Abnormal causes. We need to make an in-depth location based on RNC logs. The air interface failure occurring during
RB establishment is generally caused by poor coverage or mobile phone compatibility. The compatibility of a mobile phone itself becomes faulty in some unknown scenarios. For example, when a Huawei
mobile phone drops network abnormally, it may not release any RB. When PS RB is set up next time, this case may occur. This case also happens to the SE V800 mobile phone.
This generally occurs when FACH migrates to DCH and sets up RB. The downlink physical layer of a terminal is not
Page 56 of 80
2008-11-29
Observation Point
Condition
Possible Cause
Analysis Idea synchronized, which leads to RB establishment failure. This is mainly caused by poor coverage. The Cell Update flow occurs during RB establishment. This nested flow leads to RB establishment failure. UE considers parameter configuration illegal. Network and terminals have an inconsistent understanding of parameter processing. If RB establishment failure occurs in the domain of CS, it is possible that a user dials a wrong telephone number and at once goes onhook. RB SETUP failure may also occur at this time. The cause is illegal configuration.
Cell update
Illegal configuration
No response from UE
RNC considers the parameter delivered by a core network invalid. You need further cell signaling tracing to determine the cause. Among the known causes is that the uplink subscription and activation Parameter error application information of user PS service exceeds the capacity of a mobile phone, or that the network negotiation rate in PDP activation acceptance messages is less than the minimum guaranteed rate.
2008-11-29
Page 57 of 80
Observation Point
Condition
Possible Cause
Analysis Idea High-priority users preempt low-priority users when admission is rejected. This causes a link to be released. This kind of call drop occurs in the case of load and insufficient resource. Determine whether expansion is necessary according to the number of occurrences. Within a cell, UTRAN leads to abnormal link release. This case generally corresponds to processing abnormality. We need to make a further analysis by means of CDL. Uplink or downlink signaling RB reaches the maximum retransmission times and resets. This causes a link to be released. This case is mainly caused by poor coverage quality (including missing configuration of adjacent cells and small handover area). RNC receives RL Failure reported by NodeB, which causes a link to be abnormally released. In this case, poor coverage quality (including missing configuration of adjacent cells and small handover area) makes UE abnormally shut down the transmitter, or uplink demodulation out-of-sync. Receive the Cell Update message reported by a mobile phone. The cause is downlink
RAB preemption
UTRAN
RL Failure, which makes a link abnormally released. In this case, poor coverage quality (including missing configuration of adjacent cells and small handover area) makes UE abnormally shut down the transmitter, or uplink demodulation out-of-sync.
2008-11-29
Page 58 of 80
Observation Point
Condition
Possible Cause
Analysis Idea
RNC delivers a message and waits for the response from a mobile phone, but timeout The UU occurs. For example, waiting for RB interface makes reconfiguration completion message times no response. out and waiting for active set update completion times out. This case is generally caused by poor coverage. Other RF causes RF cause; due to poor coverage quality
RNC finds that the AAL2 Path of the IU CS interface is abnormal and starts abnormal release. It is possible that the transmission Abnormal AAL2 equipment of the Iu interface is abnormal. link The known problem is that immediate normal release during RB establishment is classified by traffic statistics into abnormal release. RNC finds that the GTPU of the IU PS Abnormal GTPU interface is abnormal and starts abnormal release. The cause may be equipment fault or defect. Possibly the call drop (but traffic statistics does not dot) occurring during flow interaction or cell update, or abnormal call drop and cell blocking caused by the transmission fault of the Iub interface, RNC internal cause, and Bug. There may be call drop for abnormal causes. We need to make an analysis based on RNC logs. The call drop caused by violent change (corner effect or driving out from the shadow area of a building) of uplink signal is known to be classified into this cause.
Others
2008-11-29
Page 59 of 80
Number of soft/softer Configuration handover failures not supported (>=5) and soft/softer handover failure rate (>=10%)
UE considers that the content of the active set update of RNC adding/deleting a link is not supported. Generally, this scenario will not appear in commercial use. UE gives the feedback that the softer/soft handover process of RNC adding/deleting a link is incompatible with other concurrent processes. RNC has guaranteed serial flow processing. Soft handover execution failure is mainly caused by the problematic processing of some mobile phones. UE considers that the content of the active
Illegal configuration
set update of RNC adding/deleting a link is illegal. Generally, this scenario will not appear in commercial use..
2008-11-29
Page 60 of 80
Observation Point
Condition
Possible Cause
Analysis Idea RNC does not receive the active set update command response for adding/deleting a link. This is the main cause of softer/soft handover failure. This happens in the region with poor coverage or a small handover area. It needs RF optimization.
No response from UE
Radio link establishment failure occurs during RL establishment. For details, see the RL establishment process analysis of the IUB interface. For other causes, we need to make a further analysis based on RNC logs.
A target cell has no resource available, or there is some RNC parameter configuration error. We need to make an analysis based on RNC logs. The problem often lies in CN parameter configuration or a related link connection. We need to make an analysis based on RNC logs.
Transition failure in the target It generally corresponds to core network CN/RNC or configuration error. system
2008-11-29
Page 61 of 80
Observation Point
Condition
Possible Cause Transition in the target CN/RNC or system not supported Transition objective not allowed OM intervention
Analysis Idea
Generally, RNC does not support some hard handover parameters. We need to make an analysis based on RNC logs. Often an MSC parameter configuration error. We need to check the parameter configuration of a core network. Failure caused by operation and maintenance Often an MSC parameter is configured incorrectly, or a target RNC has no resource available. Failure causes are not defined in traffic statistics. We need to make an analysis based on RNC logs. A core network does not return a
No available resource
Undefined
Others Preparation Preparation failure of RNC-level foreign outgoing handover failures (>=5) of RNC-level CS/PS domain intersystem outgoing handover, preparation failure rate (>=10%)of CS domain intersystem outgoing handover Waiting for transition command timeout
corresponding command of handover preparation request. In this case, there is some problem with the parameter configuration or related link connection of a core network. We need to analyze the cause according to the signaling trace of the core network and BSS. Upon requesting handover preparation, RNC receives the release command from a core network. Two cases: intersystem handover request occurs during signaling process like location update. The location
Transition cancelled
update flow has been finished before one flow is finished. The core network starts release; the user who sets up a call goes onhook during handover preparation, and the core network starts release. No handover is finished in either case, but either is normal flow nesting.
2008-11-29
Page 62 of 80
Observation Point
Condition
Possible Cause
Analysis Idea It generally corresponds to core network configuration error. We need to analyze the cause according to the signaling tracing of a core network and a BSS. The problem often lies in the parameter configuration or related link connection of a core network. We need to analyze the cause according to the signaling tracing of a core network and a BSS. The problem often lies in an MSC parameter configuration error. That is, the LAC of the target cell fails to be configured. We need to check the parameter configuration of a core network. This case is often seen after the adjustment of 2 G network. The problem often lies in an MSC parameter configuration error, or BSC has no resource available. We need to analyze the cause according to the signaling tracing of a core network and a BSS. We need to analyze the cause according
Transition timeout
No available resource
Others
to the signaling tracing of a core network and a BSS. The problem often lies in the parameter configuration or related link connection of a core network. We need to analyze the cause according to the signaling tracing of a core network and a BSS. It generally corresponds to core network configuration error or BSS not supporting. We need to analyze the cause according to the signaling tracing of a core network and a BSS.
Preparation failures (>=5) of CELL-level CS domain intersystem outgoing handover and preparation failure rate (>=10%) of CS
Transition timeout
2008-11-29
Page 63 of 80
Observation Point
Possible Cause
Analysis Idea In this case, a BSC does not support some parameters of intersystem handover requests. We need to analyze the cause according to the signaling tracing of a core network and a BSS. We need to analyze the cause according
Others
to the signaling tracing of a core network and a BSS. UE considers that the command for hard handover out of a cell is not supported. The problem generally lies in the compatibility of a mobile phone.
Physical channel Possibly poor coverage or severe failure Outgoing hard handover Failures (>=5) of failures within hard handover out of a cell, NODE B, failure rate between different NodeBs within RNC, and between RNCs Illegal configuration interference UE gives the feedback that hard handover process is incompatible with other concurrent processes. The problem may lie in the compatibility of a mobile phone itself. Cell update happens during hard handover out of a cell. This flow nesting leads to the failure of hard handover out of a cell. UE considers that the command for hard handover out of a cell is illegal. The problem generally lies in the compatibility of a mobile phone. We need to make a further analysis based on RNC logs. UE considers that the command for transition out of a cell accompanied by hard handover is not supported. The problem generally lies in the compatibility of a mobile phone.
Others Failure of transition out of a cell accompanied by hard Execution failures (>=5) of Configuration transition out of a not supported cell accompanied by hard
2008-11-29
Page 64 of 80
Condition handover, execution failure rate (>=10%) of transition out of a cell accompanied by hard handover
Possible Cause
Analysis Idea
Physical channel Possibly poor coverage or severe failure interference UE gives the feedback that the hard handover process of RNC adding a link is incompatible with other concurrent processes. The problem may lie in the compatibility of a mobile phone itself. UE considers that the command for transition out of a cell accompanied by hard handover is illegal. This case seldom occurs.
Illegal configuration
Configuration not finished Others CS/PS foreign handover failure CS/PS domain Configuration intersystem handover failures not supported (>=5), CS/PS domain intersystem handover failure rate (>=10%) We need to make a further analysis based on RNC logs. The handover command terminal in a network does not provide support. The problem generally lies in the compatibility of a mobile phone. 1) 2) Poor 2 G signal or severe interference leads to UE access failure. The channel parameters, including the encryption mode sent from network to UE, are inconsistent with those of a BSC. We need to compare and confirm the parameters of a terminal and those of a BSC. Physical channel failure generally occurs in a network with partners equipment as the CN. We need to check the encryption algorithm configuration of an MSC and an SGSN.
2008-11-29
Page 65 of 80
Observation Point
Condition
Possible Cause
Analysis Idea We need to make a further analysis according to RNC logs, together with the signaling tracing of a core network and a BSS. Improper service capability configuration of 2 G cell makes high-rate service unable to start a pressing mould, which leads to system PS handover failure.
Others
Uplink CE
Lay an emphasis upon the analysis of average uplink CE resource occupied and the maximum uplink CE resource occupied.
Lay an emphasis upon the analysis of average downlink CE resource occupied and the maximum downlink CE resource occupied List the average TCP, Average transmit the maximum TCP and power of cell the minimum TCP of a cell. List the average TCP, Maximum the maximum TCP and transmit power of the minimum TCP of a cell cell.
Downlink CE
If the maximum transmit power of a cell is large and there is small traffic, it indicates that power peak shock may lead to power congestion.
2008-11-29
Page 66 of 80
Analysis Idea If the minimum transmit power of a cell is abnormal, the transmit channel may become faulty.
transmit power of minimum transmit power cell of a cell is abnormal. List the average RTWP, the maximum RTWP, and the minimum RTWP of a cell. Observe whether there are many peaks. Observe whether the minimum RTWP is less than -105.5 dBm. Observe whether the code utilization is abnormal.
Average RTWP
If the average RTWP of a cell is higher than -95 dBm, there may be downlink interference.
Among various items, RTWP peaks, for example, -70 dBm, often appear. This may be caused by the power of access process or handover process. If the minimum RTWP is lower than -108 dBm, a channel fails to be corrected, or a base station encounters power-down. If the effective utilization of codes is not high (<= 30%), but code congestion leads to access failure, it is possible that the code distribution algorithm is abnormal. Observe whether the uplink throughput of a cell is
Maximum RTWP
Minimum RTWP
Uplink
great. If it amounts to 75% of the transmission capability of a base station, transmission expansion needs to be considered. Observe whether the downlink throughput of a cell is great. If it amounts to 75% of the transmission capability of a base station, transmission expansion needs to be considered.. This is generally caused by transmission
interruption or intermittent transmission failure. Some offices are greatly influenced by weather due to the use of microwave transmission. Thunder storm always leads to intermittent transmission failure.
If 1A events often happen within many consecutive days, there may be missing configuration of adjacent cells.
2008-11-29
Page 67 of 80
Condition
Analysis Idea
If 1C events often happen within many consecutive days, there may be pilot pollution.
Radio network layer Security mode flow failure IU security mode failures, IU security mode failure rate
RL establishment failure of the IUR interface RL synchronization configuration failure of the IUR interface RL addition failure of the IUR
List the number of OM RL establishment intervention failures (>= 5) of the Iur interface of Hardware the SRNC, RL failure establishment failure rate (>= 10%) of the Iur interface of the SRNC, and main failure causes.
RL failure of IUR interface caused by operation and maintenance This generally corresponds to equipment abnormality. We should first query related equipment alarm.
This is caused by insufficient RNC internal resource. You need to query the RNC resource quantity of related users to judge unavailable whether there is any equipment abnormality.
2008-11-29
Page 68 of 80
Condition
Possible Cause
content of RNC establishment is not supported. The problem lies in the compatibility of a mobile phone. Abnormal causes. We need to make an analysis based on RNC logs. This generally corresponds to equipment
Others
No response
abnormality. We need to query whether there is any power-down. The problem lies in the compatibility of a mobile phone itself in some unknown scenarios. Insufficient RNC internal resource or abnormal RNC equipment. You need to query cell CE resource from relevant parameters to judge whether there is any equipment abnormality. Equipment is known to encounter repeated power failure and air-conditioner fault due to thunder storm. As a result, high temperature leads to abnormality of various kinds. Besides, the NLPA board encounters shutdown. This generally corresponds to equipment abnormality. We should first query related equipment alarm. RL establishment failure caused by operation and maintenance (for example, cell blocking) The problem may lie in cell unavailability
RL establishment failure of the IUB interface RL reconfiguration failure of the IUB interface RL addition failure of the IUB interface
No available resource List the number of RL establishment failures of the IUB interface, RL establishment failure rate of the Iub interface, and main failure causes. Equipment fault
OM intervention
or equipment fault. You need to query the cell unavailability duration from relevant parameters to judge whether there is any equipment fault. RL establishment failure caused by abnormal factors. We need to make an
Others
2008-11-29
Page 69 of 80
Observation Point
Condition
Possible Cause
Analysis Idea 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 scenarios. For example, when a Huawei mobile phone drops network abnormally, it may not release any RB. When PS RB is reestablished next time, this case may occur. This case also happens to SE V800 mobile phone. Or when some UEs implement VP and high-speed (greater 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. The downlink physical layer of a terminal is not synchronized, which leads to RB establishment failure. This is mainly caused by poor coverage. The Cell Update flow occurs during RB establishment. This nested flow leads to RB establishment failure.
RB establishment failure generally corresponds to poor air interface coverage or a mobile phone compatibility problem.
Cell update
Illegal configuration
UE considers parameter configuration illegal. Network and terminals have an inconsistent understanding of parameter processing. If RB establishment failure
2008-11-29
Page 70 of 80
Observation Point
Condition
Possible Cause
Analysis Idea 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 one E1, but service was established on 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. PS has a large amount of 128k, 144k, and 384k RB bearer. This will consume a large number of resources and there is poor coverage. We need to verify whether RB bearer is consistent with actual demands with first-line personnel. Observe whether the RB distribution of BE service is rational. According to the distribution, DCCC strategy and related system parameters can be adjusted.
No response from UE
RB bearer distribution of
various types of RB service bearer uplink/downlink and the service proportion are Uplink/downlink abnormal. If there RB bearer is any distribution of BE abnormality, an service early warning needs to be given
2008-11-29
Page 71 of 80
2008-11-29
Page 72 of 80
Figure 11 General information about RRC setup 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.
2008-11-29
Page 73 of 80
Figure 13 Comparison of RRC setup scenario success rate Scenario Analysis makes a comparative analysis of several commonly used scenarios. The pie chart shows the RRC establishment distribution of a main scenario. The example in the chart indicates that RRC establishment requests mainly exist in network registration with REG as the cause. When an LAC area is not well planned or there is poor coverage (the margin of LAC division is in a prosperous area), there may be a lot of registration. On the other hand, the cause of RRC establishment during intersystem reselecting of this mobile phone is registration. A large number of mobile phones fail to be registered due to poor coverage and will try again and again. Thus, the cause of RRC establishment is registration in many cases. This indicates that there is poor network coverage in some areas.
2008-11-29
Page 74 of 80
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.
2008-11-29
Page 75 of 80
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 2) interference, whether expansion is necessary. 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. 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. 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. Redir.Inter.Att: Inter-frequency redirection failure starts rejection. Redir.Intrat: Foreign redirection failure starts rejection. 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. Other: This is mainly an RNC internal processing problem. Its cause needs to be confirmed according to R&D logs.
3)
4)
5) 6) 7)
8)
2008-11-29
Page 76 of 80
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) 2) 3) Consolidate signaling flow and deepen an understanding of each UTRAN PI. Performance analysis has a more definite object in view. Basic special topic analysis enables us to make a preliminary analysis of network performance and locate simple problem causes. 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.
2008-11-29
Page 77 of 80
2008-11-29
Page 78 of 80
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.
2008-11-29
Page 79 of 80
6
Optimization_Call Drop Rate Optimization (V1.0) Alarm Analysis Guide
References
UTRAN KPI Analysis Guide-20051010-A-1.0 UMTS Performance DepartmentRAN Performance Optimization Idea GENEX Nastar WCDMA User Manual (CHN) Guide to Analysis of UMTS Network Planning Remote Network Performance -20060524 UMTS Radio Performance Department Commercial Network Index
2008-11-29
Page 80 of 80