UTRAN KPI

UTRAN KPI Analysis Guide

For Internal Use Only

UTRAN KPI Analysis GuideFor Internal Use Only

Huawei Technologies Co., LtdDocument nameConfidentiality level

UTRAN KPI Analysis GuideFor Internal Use Only

RAN Maintenance Dept.Total 38 Pages

UTRAN KPI Analysis GuidePrepared byRAN Maintenance Dept.DateAug. 10, 2005

Reviewed byDate

Reviewed byDate

Approved byDate

Huawei Technologies Co., Ltd.

All Rights ReservedRevision EditionDateVersionDescriptionAuthor

Aug. 10, 2005The first version is complete.Wang Wei

Table of Contents1.Overview41.1Intended Audience41.2Objectives42.Introduction to Nastar53.UTRAN KPI Analysis53.1Nastar Tasks54.Detailed UTRAN KPI Analysis74.1Call Completion Rate74.1.1RRC Setup Analysis74.1.2RAB Setup Analysis114.2Soft Handover Analysis184.2.1Overview194.2.2Cell SHO Prepare Failure Analysis204.2.3Cell SHO Failure Analysis224.3CS Inter-RAT Handover Analysis244.3.1Overview254.3.2CS Inter-RAT Handover Prepare Failure Analysis264.3.3CS Inter-RAT Handover Failure Analysis284.3.4Cell Inter-RAT Handover Analysis304.4PS Inter-RAT Handover Analysis304.4.1Overview304.4.2PS Inter-RAT Handover Failure Analysis314.4.3Cell Inter-RAT Handover Analysis334.5Cell Update Analysis334.5.1Overview334.5.2Cell Update Failure Analysis344.6Call Drop Analysis354.6.1Overview354.6.2CS Call Drop Analysis364.6.3PS Call Drop Analysis374.6.4Cell Call Drop Analysis394.7Traffic Load Analysis404.7.1Overview414.7.2Cell Traffic Analysis425.Analyzing Complicated Problems445.1Narrowing Down Area Range and Time Range445.2Analyzing Abnormal Logs445.3Analyzing Repeated Problems44

UTRAN KPI Analysis Guide1. OverviewIn a commercial network, the QoS and network operation are reflected through KPI. UTRAN KPI analysis is a major method used for monitoring and evaluating network operation. UTRAN KPI analysis is also served to track the network traffic, monitor the resource distribution, and facilitate the network expansion and optimization. Huawei UTRAN traffic statistics provides sufficient KPI for network operation, algorithm management, and resource distribution. These traffic statistics can be used to locate network problems and optimize network KPI.UTRAN KPI analysis is a major method for RAN maintenance engineers and network optimization engineers to evaluate network performance. Comparing with drive tests, call detail logs, and alarms, KPI analysis can be used to monitor network operation directly and conveniently. To better locate network problems and optimize network KPI, abnormal indices, call detail logs, tracked messages, and drive tests can be used together.Huawei provides a traffic statistics analysis tool Nastar for UTRAN KPI analysis. Nastar can be used to obtain and analyze UTRAN KPI. This guide introduces how to use Nastar to analyze UTRAN KPI. For more information, refer to GENEX Nastar V400R001C01 User Manual.1.1 Intended AudienceThis guide, intended for network maintenance engineers and site audit engineers, introduces Nastar V400R001, which supports the KPI analysis of RNC V100R002C03B092 and RNC V100R002C03B151.1.2 ObjectivesThis guide aims to provide guidance for network maintenance personnel to monitor network KPI on a timely basis, analyze abnormal indices, and find out practical solutions.2. Introduction to NastarNastar provides such functions as index defining, query defining, and report generating. For more information, refer to GENEX Nastar V400R001C01 User Manual.3. UTRAN KPI AnalysisThe QoS of communication network is defined in ITU-T E.800. Considering the features of wireless communication network, the following KPI must be considered for WCDMA RAN, as shown in Table 1-1.Network performanceKPI

Call completion rateRRC Setup Success Rate

RAB Setup Success Rate

Call drop rateVoice Call Drop Rate

VP Call Drop Rate

PS Call Drop Rate

Mobility managementSoft Handover Success Rate

Inter-Frequency HO Success Rate

Intra-Frequency HO Success Rate

CS Inter-RAT HO Success Rate

PS Inter-RAT HO Success Rate

Cell Update Success Rate

TrafficEquivalent User

Cell Throughput

Cell Resource Allocation

Table 1-1 WCDMA RAN KPI3.1 Nastar TasksFigure 1-1 shows a list of Nastar tasks.

Figure 1-1 Nastar tasks

Perf Daily Report and Perf Weekly Report can be generated in .xls file by Nastar. An object can be a self-defined clutter or RNC. Perf Daily Report is used to monitor network performance. By default, Perf Daily Report includes the following KPI, as shown in Table 1-2.

Table 1-2 Perf Daily ReportIf network performance cannot meet the previous KPI or the KPI is changed, refer to Section 4 UTRAN KPI Analysis.4. UTRAN KPI Analysis4.1 Call Completion RateThis section consists of the following parts: RRC Setup Analysis RAB Setup Analysis4.1.1 RRC Setup Analysis1. OverviewRRC Setup Analysis is included in Nastar, as shown in Figure 1-1. Double click RRC Setup Analysis to display the RRC setup details, as shown in Figure 1-3. RRC setup success rate is 97.3%. Most RRC setup failures result from RRC Setup Fail No Response while few RRC setup failures (seven times) result from RRC Setup Reject.

Figure 1-3 RRC SetupThere are two reasons for RRC Setup Fail No Response: Downlink FACH and RACH are covered unevenly.The networks, built during the early period, are covered poorly. In particular, inter-system reselection areas are covered poorly. A certain area has too many subscribers or any equipment in this area is faulty.2. RRC Setup Scenario AnalysisOne of the reasons for RRC Setup Fail No Response is poor coverage, so RRC setup reasons and RRC setup success rate can be used for further analysis. Start Scenario Analysis to display a pie or bar chart for presenting RNC indices.

Figure 1-4 RRC setup scenario (pie chart)Use Scenario Analysis to analyze RRC setup scenarios, as shown in Figure 1-5. Most RRC setup requests are caused by: RRC REQ CELL RESELIf network coverage is poor, inter-system reselection may occur. RRC REQ REGIf network coverage is poor, subscribers attempt to register for many times.

Figure 1-5 RRC setup scenario (bar chart)Figure 1-5 shows RRC setup success rates. RRC SETUP SUCC RATE ORG is very high while RRC SETUP SUCC RATE REG is very low. On Huawei networks, resident threshold Ec/Io is greater than -18 dB while inter-system reselection start threshold Ec/Io is less than -14 dB. Low RRC SETUP SUCC RATE REG indicates that many registrations are attempted within the area (Ec/Io falls between -14 dB and -18 dB), which has poor coverage. High RRC SETUP SUCC RATE ORG (99%) indicates that the network is covered by PCH and RRC SETUP SUCC RATE can be high in a well-covered network.3. RRC Setup Reject AnalysisRRC setup reject are caused by: Admission reject due to crowded subscribers Access failure due to equipment faultsRRC setup reject may occur no matter how poor network coverage is; however, RRC setup reject occurs in a small-scale network. Therefore, only the areas of RRC setup reject must be analyzed.In RRC Setup Analysis, start Cell RRC Analysis to query the TOPN. The queried results are outputted in three pages:(1) The top ten cells that have the highest RRC setup reject times.(2) The top ten cells that have the highest RRC setup success rates.(3) The top ten cells that have the highest RRC setup failure rates.For the top ten cells that have the maximum RRC setup fail rates, start Cell Scenario Analysis for further analysis. For the top ten cells that have the maximum RRC setup rejects, start Cell RRC Reject Analysis for further analysis.

Figure 1-6 RRC setup reject analysisFigure 1-6 shows the results of Cell RRC Reject Analysis. In this figure, two RRC setup rejects are caused by Power Congestion. RRC setup reject may be caused by the following reasons:(1) Power Congestion

RRM performs the admission algorithm decision but uplink or downlink admission decision is rejected, so RRC setup reject occurs. If network load is heavy, power congestion may occur. To locate the problem, start Cell Traffic Load Analysis to check whether uplink or downlink is congested by focusing on the maximum RTWP and the maximum TCP. If power congestion is confirmed, check whether the threshold is reasonable, check whether there is any interference, and check whether the network capacity is insufficient.(2) CE CongestionIf there are many subscribers, CE resources may become insufficient in RNC. To locate the problem, start Cell Traffic Load Analysis to check the DCH user number and forecast the required CE quantity in accordance with the traffic model.(3) RL FailDuring the RRC setup process, NodeB recognizes RRC setup fail because NodeB fails or NodeB resource is insufficient. To locate the problem start Cell Traffic Load Analysis to check the DCH user number. Analyze the data and logs of the boards or CEs in NodeB to check whether NodeB fails or NodeB resource is insufficient.(4) AAL2 FailIf transmission resource is insufficient or any transmission equipment is faulty, the AAL2 path setup of lub interface may fail. To locate the problem, start Cell Traffic Load Analysis to check the DCH user number and the bandwidth of AAL2 path. Check whether transmission resource is insufficient or any transmission equipment is faulty.(5) FP FailIf the transmission fails or an equipment is faulty, FP synchronization may fail. To locate the problem, check whether there is any BTS alarm.(6) Code CongestionIf there is high traffic in the indoor micro cell, code resource may be insufficient. To locate the problem, start Cell OVSF Code Allocation Analysis to analyze the code allocation and confirm major services.(7) OtherIf there is any problem in RNC, RRC setup reject may occur. To locate the problem, analyze call detail logs.4.1.2 RAB Setup Analysis1. Overview

Figure 1-7 Nastar tasksFigure 1-7 shows a list of Nastar tasks. RAB Setup Analysis is included in Nastar. Double click RAB Setup Analysis to display RAB setup details, as shown in Figure 1-8.

Figure 1-8 RAB setup analysisCheck such RAB setup rates as CS_RAB_REQ_SETUP_CONV_0_32 (AMR), CS_RAB_REQ_SETUP_CONV_32_64 (VP), 64 K (PS), 128 K (PS), and 384 K (PS) to confirm major services in the network.Click Produce a Bar Chart to display the RB and RAB setup success rates, as shown in Figure 1-9.

Figure 1-9 RB and RAB setup success rates2. RAB Setup Fail AnalysisIn RAB Setup Analysis, start Cell RAB Analysis to query the TOPN. The queried results are outputted in four pages:(1) The top ten cells that have the highest CS RAB setup failures.(2) The top ten cells that have the lowest CS RAB setup failures.(3) The top ten cells that have the highest PS RAB setup failures.(4) The top ten cells that have the lowest PS RAB setup failures.Low RAB setup success rate may occur in the cells that have lowest setup times. To locate the problem, focus on the cells that have the lowest setup failures because the KPI is affected mostly by these cells.If CS RAB setup fail rate is high in a cell, start Cell CS RAB Setup Fail Analysis to display the CS RAB setup fail rates, as shown in Figure 1-10.

Figure 1-10 Cell CS RAB setup fail analysisCell CS RAB setup failures may be caused by the following reasons:(1) PARAM_CELLRNC regards the parameters transmitted by core network as invalid parameters. This reason seldom occurs. To locate the problem, track the signaling and check the RAB setup messages in specific cells.(2) RELOC_CELLWhen initializing the migration process, RNC receives the RAB setup request messages but RNC does not process the request. This reason is mainly caused by the process integration related to subscriber action sequence, so this reason seldom occurs. In a core network, this situation is always avoided.(3) TNL_CELLRAB setup fails because IU transmission setup fails. To locate the problem, check the transmission capacity and operation stability.(4) CONG_CELLThis may be caused by RNC resource allocation failure. To locate the problem, analyze the RNC logs and obtain the detailed resource failure information.(5) POWER_CONG_CELLAccording to RRM admission decision, new RAN cannot be set up because cell load is too heavy. To locate the problem, check whether the parameters of admission algorithm are reasonable. If yes, consider to optimize the coverage and expand the capacity.(6) CE_CONG_CELLCE resource admission fails in RNC. CE must be expanded.(7) CODE_CONG_CELLDuring the RAB setup process, code resource allocation fails because too many subscribers are crowded on the network or code resource allocation fails. To locate the problem, analyze the code resource of cell traffic to check whether code resource is restricted due to cell overload.(8) OTHER_CELLThis may caused by RB setup failure or other reasons. To locate the problem, analyze RB setup success rates.If PS RAB setup fail rate is high, start Cell PS RAB Setup Fail Analysis to display the PS RAB setup fail rates, as shown in Figure 1-11.

Figure 1-11 Cell PS RAB setup fail analysisCell CS RAB setup failure may be caused by the following reasons:(1) PARAM_CELLRNC regards the parameters transmitted by core network as invalid parameters. This reason seldom occurs. To locate the problem, track the signaling and check the RAB setup messages in specific cells.(2) RELOC_CELLWhen initializing the migration process, RNC receives the RAB setup request messages but RNC does not process the request. This reason is mainly caused by the process integration related to subscriber action sequence, so this reason seldom occurs. In a core network, this situation is always avoided.(3) TNL_CELLRAB setup fails because IU transmission setup fails. To locate the problem, check the transmission capacity and operation stability.(4) CONG_CELLThis may be caused by RNC resource allocation failure. To locate the problem, analyze the RNC logs and obtain the detailed resource failure information.(5) POWER_CONG_CELLAccording to RRM admission decision, new RAN cannot be set up because cell load is too heavy. To locate the problem, check whether the parameters of admission algorithm are reasonable. If yes, consider to optimize the coverage and expand the capacity.(6) CE_CONG_CELLCE resource admission fails in RNC. CE must be expanded.(7) CODE_CONG_CELLDuring the RAB setup process, code resource allocation fails because too many subscribers are crowded on the network or code resource allocation fails. To locate the problem, analyze the code resource of cell traffic to check whether code resource is restricted due to cell overload.(8) UNSUP_CELLDuring the RAB setup process, the QoS is not supported by RNC or RRM admission fails in RAB.(9) OTHER_CELLThis may caused by RB setup failure or other reasons. To locate the problem, analyze RB setup success rates.In a commercial network, RAB setup is mainly caused by admission failure and RB setup failure. To analyze the RB setup failure, start Cell RB Setup Fail Analysis to display the RB setup fail rates, as shown in Figure 1-12.

Figure 1-12 Cell RB setup fail analysisCell RB setup failure may be caused by the following reasons:(1) CFG_UNSUPPUE acknowledges the RB setup failure because of configuration unsupported. This reason seldom occurs in the network. It is mainly caused by compatibility problem of UE in some unknown scenarios.(2) PHYCH_FAILThe RB setup failure may occur if FACH is migrated to DCH but downlink physical layers are not synchronized during the RB setup process. The rooted reason is poor coverage.(3) SIMU_RECFG_INCOMPUE regards that the RB setup process and other processes simultaneously occur and they are incompatible. RNC processing ensures RRC processes nesting. This reason seldom occurs. It is mainly caused by UE defects.(4) CELL_UPDTDuring the RB setup process, the Cell Update process occurs. The RB setup failure is caused by process nesting.(5) CFG_INVALIDUE regards the configured parameters are invalid ones. This reason seldom occurs. It is mainly caused by inconsistent understanding of network and UE.(6) NO_RESPONSEUE does not acknowledge the RB setup request. This reason frequently occurs. It is mainly caused by poor coverage, so UE cannot receive the RB setup request message.(7) OTHERCell RB setup failure is caused by other reasons. To locate the problem, analyze call detail logs.4.2 Soft Handover AnalysisThis section consists of the following parts:

Overview Cell SHO Prepare Failure Analysis Cell SHO Failure Analysis4.2.1 Overview

Figure 1-13 Nastar TasksSoft Handover Analysis is included in Nastar tasks, as shown in Figure 1-13. Double click Soft Handover Analysis to display the RNC soft handover details (including soft handover success rate, softer handover success rate, and soft handover prepare success rate), as shown in Figure 1-14.

Figure 1-14 Soft Handover AnalysisIn the previous figure, soft handover factor is used to measure the proportion and cost of soft handover. SHO_FACTOR_RL and SHO_FACTOR_UE are defined as follows: SHO_FACTOR_RLSHO_FACTOR_RL is used to measure average link number. SHO_FACTOR-RL can be calculated as follows:(Subscriber number of link 1 of active set*1 + Subscriber number of link 2 of active set*2 + Subscriber number of link 3 of active set*3)/Total subscriber number 1SHO_FACTOR_RL is used to indicate the influence of soft handover exerted on NodeB CE and to evaluate the subscriber resource utililization. SHO_FACTOR_UESHO_FACTOR_UE is used to measure the proportion of soft handover subscribers. SHO_FACTOR_UE can be calculated as follows:(Subscriber number of link 2 of active set + Subscriber number of link 3 of active set)/Total subscriber numberSHO_FACTOR_UE is used to indicate the subscribers in the soft handover area, which is similar to the proportion of soft handover area by making drive tests. SHO_FACTOR_UE is used to measure the reasonable relationship between soft handover area and soft handover distribution.SHO_FACTOR_UE is greater than SHO_FACTOR_UE. The greater the difference between them is, the greater the subscriber number of link 3 of active set is. If the subscriber number of link 3 of active set is very great, SHO_FACTOR_RL is greater than 1 while SHO_FACTOR_UE is less than 1.4.2.2 Cell SHO Prepare Failure AnalysisIn the Soft Handover Analysis, start Cell SHO Analysis to query the TOPN. The queried results are outputted in four pages:(1) The top ten cells that have the highest soft handover failure times

(2) The top ten cells that have the lowest soft handover success rates(3) The top ten cells that have the highest soft handover prepare failure times(4) The top ten cells that have the lowest soft handover prepare success ratesDuring the early period, low soft handover success rates may exist in the cells that have less soft handover times. Attention must be paid to the cells that have the highest soft handover failure times and the highest soft handover prepare failure times because they affect the KPI of soft handover greatly.To query the cells that have the highest soft handover prepare failure times, start Cell SHO Prepare Failure Analysis to display the soft handover prepare failure details, as shown in Figure 1-15.

Figure 1-15 Cell SHO Prepare Failure AnalysisCell SHO prepare failure may be caused by the following reasons:(1) SHO_PREP_RL_SETUP_FAILThe links cannot be added during the soft handover because NodeB CE resource is insufficient or NodeB is faulty. Internal NodeB logs, Cell Traffic Load Analysis, and data configuration of NodeB boards can be used to locate the problems. If NodeB CE resource is insufficient, one or more boards must be added for expansion.(2) SHO_PREP_AAL2_SETUP_FAILWhen the links are added during the soft handover, the AAL2 setup of lub interface fails because the transmission bandwidth is insufficient. If the transmission bandwidth is insufficient, transmission equipments must be expanded.(3) SHO_PREP_FP_SYNC_FAILWhen the links are added during the soft handover, the synchronization of AAL2 and FP of lub interface fails. To locate the problem, check whether the intermittent transmission interruption occurs or the IMA group transmission is incorrectly configured.(4) SHO_PREP_ FAIL_OTHER_CELLSoft handover prepare failure is caused by other reasons, such as insufficient RNC resource, radio resource admission reject, and RNC link state reject. To locate the problem, RNC logs must be used for further analysis.4.2.3 Cell SHO Failure AnalysisIn the Soft Handover Analysis, start Cell SHO Analysis to query the TOPN. The queried results are outputted in four pages:(1) The top ten cells that have the highest soft handover failure times(2) The top ten cells that have the lowest soft handover success rates(3) The top ten cells that have the highest soft handover prepare failure times(4) The top ten cells that have the lowest soft handover prepare success ratesDuring the early period, low soft handover success rates may exist in the cells that have less soft handover times. Attention must be paid to the cells that have the highest soft handover failure times and the highest soft handover prepare failure times because they affect the KPI of soft handover greatly.In the Cell SHO Analysis, start Cell SHO Failure Analysis to display the soft handover failure details, as shown in Figure 1-16.

Figure 1-16 Cell SHO Failure AnalysisSoft handover failure may be caused by the following reasons:(1) SHO_RL_ADD_FAIL_CFG_UNSUPPUE does not support to add radio links in RNC during the active set update. This reason seldom exists in a commercial network.(2) SHO_RL_ADD_FAIL_SIMU_RECFG_INCOMPUE feeds back that the soft handover process is incompatible with other concurrent processes when radio links are added in RNC. When handling the processes, RNC performs the serial connection. The problem is mainly caused by some handsets.(3) SHO_RL_ADD_FAIL_CFG_INVALIDUE regards active set update of adding radio links in RNC as invalid configuration. This reason seldom occurs in a commercial network.(4) SHO_RL_ADD_FAIL_NO_RSPRNC does not receive the acknowledgement of active set update of adding radio links. Soft handover failure is mainly caused by this reason. If network coverage is poor or soft handover area is small, soft handover failure easily occurs. Thus, the RF optimization is required.(5) SHO_RL_DEL_FAIL_CFG_UNSUPPUE does not support to delete radio links in RNC during the active set update. This reason seldom occurs in a commercial network.(6) SHO_RL_ADD_FAIL_SIMU_RECFG_INCOMPUE feeds back that the soft handover is incompatible with other concurrent processes when radio links are deleted in RNC. When handling the processes, RNC performs the serial connection. The problem is mainly caused by some handsets.(7) SHO_RL_ADD_FAIL_CFG_INVALIDUE regards the active set update of deleting radio links in RNC as invalid configuration. This reason seldom occurs in a commercial network.(8) SHO_RL_ADD_FAIL_NO_RSPRNC does not receive the acknowledgement of active set update of deleting radio links. Soft handover failure is mainly caused by this reason. If network coverage is poor or soft handover area is small, soft handover failure easily occurs. Thus, the RF optimization is required.(9) SHO_FAIL_OTHER_CELLSoft handover failure is caused by other reasons; however, soft handover failure is seldom caused by other reasons. If soft handover failure is caused by other reasons, analyze the logs to locate the problems.4.3 CS Inter-RAT Handover AnalysisThis section consists of the following parts:

Overview CS Inter-RAT Handover Prepare Failure Analysis CS Inter-RAT Handover Failure Analysis Cell Inter-RAT Handover Analysis4.3.1 Overview

Figure 1-17 Nastar tasksCS Inter-RAT Handover Analysis is included in Nastar tasks, as shown in Figure 1-17. Double click CS Inter-RAT Handover Analysis to display the CS inter-RAT handover details between a 2G network and a 3G network (including CS inter-RAT handover success rate, CS inter-RAT handover prepare failure rate, and CS inter-RAT handover failure rate), as shown in Figure 1-18. In a commercial network, CS inter-RAT handover between a 2G network and a 3G network seldom occurs.

Figure 1-18 CS Inter-RAT Handover Analysis4.3.2 CS Inter-RAT Handover Prepare Failure AnalysisIn the CS Inter-RAT Handover Analysis, start CS Inter-RAT Handover Prepare Failure Analysis to display the CS inter-RAT handover details, as shown in Figure 1-19.

Figure 1-19 CS inter-RAT handover prepare failure analysisCS inter-RAT handover prepare failure may be caused by the following reasons:

(1) CS_INTERRAT_HO_PREP_FAIL_TARGET_FAILCS inter-RAT handover prepare failure is caused by Relocation Failure Target CN/RNC or Target System (cause value) because the data configuration of core network is incorrect or BSS does not support the handover. To locate the problem, track the signaling of core network and BSS for further analysis.(2) CS_INTERRAT_HO_PREP_FAIL_TALLOC_EXPIRCS inter-RAT handover prepare failure is caused by TRELOCalloc Expiry (cause value) because the data configuration or link connection of core network is incorrect. To locate the problem, track the signaling of core network and BSS for further analysis.(3) CS_INTERRAT_HO_PREP_FAIL_TARGET_UNSUPPCS inter-RAT handover prepare failure is caused by Relocation Not Supported in Target RNC or Target System (cause value) because BSC does not support some parameters of handover requests. To locate the problem, track the signaling of core network and BSS for further analysis.(4) CS_INTERRAT_HO_PREP_FAIL_RELOC_ABORTAfter sending the handover prepare request, RNC receives the release message from core network. This may be caused by two reasons:(1) Inter-RAT handover is requested during the signaling processes, such as location update. Location update process is complete before inter-RAT handover process is complete. Thus, core network initializes the release.(2) When inter-RAT handover prepare process is performed, an MS hangs up the call. Thus, core network initializes the release.Although the previous inter-RAT handover processes are incomplete, they are normal nested processes.(5) CS_INTERRAT_HO_PREP_FAIL_NO_RSRC_AVAILCS inter-RAT handover prepare failure is caused by No Resource Available (cause value) because the data configuration of MSC is incorrect or there is no available resource in BSC. To locate the problem, track the signaling of core network and BSS for further analysis.(6) CS_INTERRAT_HO_PREP_FAIL_UNKNOWTARGETCS inter-RAT handover prepare failure is caused by Unknown Target RNC (cause value) because the data configuration of MSC is incorrect or the LAC of target cell is not configured. To locate the problem, check whether any data is incorrectly configured in the core network. This problem frequently occurs if a 2G network is adjusted.(7) CS_INTERRAT_HO_PREP_FAIL_ REQINFNOTAVAICS inter-RAT handover prepare failure is caused by Requested Information Not Available because the data configuration is incorrect or target BSC does not support the handover. To locate the problem, track the signaling of core network and BSS for further analysis.(8) CS_INTERRAT_HO_PREP_FAIL_NO_RSPCS inter-RAT handover prepare failure occurs because core network does not respond to the handover prepare request. This may be caused by incorrect data configuration or link connection of core network. To locate the problem, track the signaling of core network and BSS for further analysis.4.3.3 CS Inter-RAT Handover Failure AnalysisIn the CS Inter-RAT Handover Analysis, start CS Inter-RAT Handover Failure Analysis to display the CS inter-RAT handover details (including CS inter-RAT handover success and failure rates), as shown in Figure 1-20.

Figure 1-20 CS inter-RAT handover failure analysisCS inter-RAT handover failure may be caused by the following reasons:(1) CS_INTERRAT_HO_ FAIL_UNSPECCS inter-RAT handover failure is caused by Unspecified (cause value). This reason seldom occurs in a network.(2) CS_INTERRAT_HO_ FAIL_PHYCN_FAILCS inter-RAT handover failure is caused by Physical Channel Failure (cause value). CS inter-RAT handover failure is mainly caused by: The signals of 2G network are weak or UE fails to access the network due to serious interference. Some parameters (such as ciphering mode) transmitted to UE are inconsistent with that of BSC.To locate the problem, compare the parameters of UE with that of BSC.(3) CS_INTERRAT_HO_ FAIL_ CFG_UNSUPPCS inter-RAT handover failure is caused by Configuration Unsupported (cause value) because UE does not support the handover request. This reason may be mainly caused by abnormal UE.(4) CS_INTERRAT_HO_ FAIL_ RELOC_ABORTAfter sending the handover request message to UE, RNC receives the release message from core network. However, the cause is not Normal Release because the link is released abnormally due to other reasons. This reason is caused by the nesting of handover process and release process.(5) CS_INTERRAT_HO_ FAIL_NO_RSPAfter RNC sends the handover request message to UE, UE does not acknowledge the request because network coverage is poor.(6) CS_INTERRAT_HO_ FAIL_OTHERCS inter-RAT handover failure is caused by other reasons. To locate the problem, analyze the RNC logs.4.3.4 Cell Inter-RAT Handover AnalysisIn the CS inter-RAT Handover Analysis, start Cell inter-RAT Handover Analysis to query the TOPN. The queried results are outputted to list:(1) The cell that have the lowest CS inter-RAT handover success rate(2) The cell that have the greatest CS inter-RAT handover prepare failure times(3) The cell that have the greatest CS inter-RAT handover failure times(4) The cell that have the greatest CS inter-RAT handover timesThrough the previous results, you can find the cell that has the greatest CS inter-RAT handover times. Thus, the network coverage must be improved. In addition, you can find the cell that has the greatest CS inter-RAT handover failure times. Thus, the data configuration must be checked.4.4 PS Inter-RAT Handover AnalysisThis section consists of the following parts:

Overview PS Inter-RAT Handover Failure Analysis

Cell Inter-RAT Handover Analysis4.4.1 OverviewPS inter-RAT Handover Analysis is included in Nastar tasks. Double click PS Inter-RAT Handover Analysis to display the PS inter-RAT handover details between a 2G network and a 3G network, as shown in Figure 1-21. PS inter-RAT handover from a 2G network to a 3G network need not be analyzed because PS inter-RAT handover from a 2G network to a 3G network cannot be identified in access network.

Figure 1-21 PS inter-RAT handover analysisFigure 1-22 shows PS_INTRAT_HO_OUT_UTRAN_REQ and PS_INTRAT_HO_OUT_UTRAN_UE. PS_INTRAT_HO_OUT_UTRAN_REQ indicates that the PS inter-RAT handover is initialized by the UE in a dedicated channel. PS_INTRAT_HO_OUT_UTRAN_UE indicates that the PS inter-RAT handover is initialized by combined services or the PS inter-RAT reselection is initialized by the UE that is not in a dedicated channel.

Figure 1-22 PS inter-RAT handover success rate4.4.2 PS Inter-RAT Handover Failure AnalysisIn the PS inter-RAT Handover Analysis, start PS inter-RAT Handover Failure Analysis to display the PS inter-RAT handover success and failure rates, as shown in Figure 1-23.

Figure 1-23 PS inter-RAT handover failure analysisPS inter-RAT handover failure may be caused by the following reasons:

(1) PS_INTERRAT_HO_ FAIL_UNSPECPS inter-RAT handover failure is caused by Unspecified (cause value). This reason seldom occurs in a network.(2) PS_INTERRAT_HO_ FAIL_PHYCN_FAILPS inter-RAT handover failure is caused by Physical Channel Failure (cause value) because the signals of 2G network are weak or UE fails to access the network due to serious interference.(3) PS_INTERRAT_HO_ FAIL_ CFG_UNSUPPPS inter-RAT handover failure is caused by Configuration Unsupported (cause value) because UE does not support the handover request. This reason may be mainly caused by abnormal UE.(4) PS_INTERRAT_HO_ FAIL_NO_RSPAfter RNC sends the handover request message to UE, UE does not acknowledge the request because network coverage is poor or UE does not support the handover.(5) PS_INTERRAT_HO_ FAIL_OTHERPS inter-RAT handover failure is caused by other reasons. To locate the problem, analyze the RNC logs.4.4.3 Cell Inter-RAT Handover AnalysisIn the PS Inter-RAT Handover Analysis, start Cell Inter-RAT Handover Analysis to query the TOPN. The queried results are outputted to list:(1) The cell that have the lowest PS inter-RAT handover success rate

(2) The cell that have the greatest PS inter-RAT handover prepare failure times

(3) The cell that have the greatest PS inter-RAT handover failure times

(4) The cell that have the greatest PS inter-RAT handover timesThrough the previous results, you can find the cell that has the greatest PS inter-RAT handover times. Thus, the network coverage must be improved.4.5 Cell Update AnalysisThis section consists of the following parts:

Overview

Cell Update Failure Analysis4.5.1 OverviewCell Update Analysis is included in Nastar tasks. Double click Cell Update Analysis to display the cell update details (including cell update times and cell update success rate). Cell update process is initialized because the links of UE are abnormal or RLC is reset. Cell update process is mainly caused by poor network coverage. This cell update process is different from that of cell reselection, so you must be familiar with diverse cell update processes. In the Cell Update Analysis, start Cell Update Scenario Analysis to display different cell update scenarios, as shown in Figure 1-24. If the state transition is disabled in a network, the cell update is caused by abnormal links or RLC reset if UE is not in CELL_FACH or CELL_PCH state.

Figure 1-24 Cell update scenariosIn the Cell Update Scenario Analysis, click Create a Bar Chart to display the cell update success rates, as shown in Figure 1-25. In general, the cell updates are caused by abnormal links (RL) or RLC reset (RLC_ERR), thus low cell update success rate may be caused by poor network coverage. If cell update is caused by other reasons, cell update success rate must be greater than 85%.

Figure 1-25 Cell update success rates4.5.2 Cell Update Failure AnalysisIn the Cell Update Analysis, start Cell Update Analysis to query the TOPN. The queried results are outputted to list:(1) The cell that has the lowest cell update success rate(2) The cell that has the greatest cell update failure timesIf a cell has the lowest cell update success rate, cell update times are less. Attention must be paid to the cell that has the greatest cell update failure times.In the queried results of Cell Update Analysis, start Cell Update Scenario Analysis for Cell to analyze the cell update failure and summarize the cell update failure scenarios.4.6 Call Drop AnalysisThis section consists of the following parts:

Overview

CS Call Drop Analysis PS Call Drop Analysis Cell Call Drop Analysis4.6.1 OverviewCall Drop Analysis is included in Nastar tasks. Double click Call Drop Analysis to display the RNC call drop details. Then, click Create a Pie Chart to display the call drop details for different services (including voice, VP, CS, and PS), as shown in Figure 1-27.

Figure 1-26 Call drop analysisIn the Cell Drop Analysis, click Create a Bar Chart to display the call drop rates for different services (including voice, VP, CS, and PS), as shown in Figure 1-27. In general, the call drop rate of CS service is less than that of VP service or PS service because of their different service coverage capabilities and service process complexities, especially in the poor-covered areas.

Figure 1-27 Call drop rates4.6.2 CS Call Drop AnalysisIn the CS Call Drop Analysis, click Create a Pie Chart to display the CS call drop reasons, as shown in Figure 1-28.

Figure 1-28 CS call drop reasonsCS call drops may be caused by the following reasons:(1) RAB_CS_REL_RF_LOSSCS call drop may be caused by abnormal release caused by the lost synchronization of links because of poor network coverage (including adjacent cell missing, small handover area. As a result, UE closes the transmitter abnormally or uplink demodulation is asynchronous. To solve the problem, network coverage must be improved. In the early network, call drops are mainly caused by this reason.(2) RNC_CS_RAB_REL_TRIG_BY_RNC_SRB_RESETCS call drops may be caused by link releasing due to downlink SRB reset. This reason is mainly caused by poor network coverage (including adjacent cell missing and small handover area). To solve the problem, the network coverage must be improved. In the early network, call drops are mainly caused by this reason.(3) RNC_CS_RAB_REL_TRIG_BY_RNC_AAL2_LOSSIf IU CS interface (AAL2 path) is abnormal, RNC initializes the release. In practice, this reason seldom occurs. If this reason occurs, the problem may be caused by any faulty or defective equipment. In some versions of RNC, normal release is recorded as abnormal release during the RB setup process.(4) CS_RAB_DROP_OTHERCS call drops may be caused by other reasons. There are few call drop statistics in RNC (Version 12). Such reasons as process interaction timeout and cell update failure are recorded in CS_RAB_DROP_OTHER. In practice, many call drops are caused by process interaction timeout and cell update failure. Therefore, these call drops are recorded in CS_RAB_DROP_OTHER.4.6.3 PS Call Drop AnalysisIn the Call Drop Analysis, start PS Call Drop Analysis. Then, click Create a Pie Chart to display the PS call drops, as shown in Figure 1-29.

Figure 1-29 PS call drop reasonsPS call drop may be caused by the following reasons:(1) RAB_PS_REL_RF_LOSSPS call drops may be caused by abnormal release because the links are asynchronous. This reason is mainly caused by poor network coverage (including adjacent cell missing and small handover area). As a result, UE closes the transmitter abnormally or uplink demodulation is asynchronous. To solve the problem, network coverage must be improved. In the early network, call drops are mainly caused by this reason.(2) RNC_PS_RAB_REL_TRIG_BY_RNC_SRB_RESETPS call drops may be caused by link releasing due to downlink SRB reset. This reason is mainly caused by poor network coverage (including adjacent cell missing and small handover area). To solve the problem, the network coverage must be improved. In the early network, call drops are mainly caused by this reason.(3) RNC_PS_RAB_REL_TRIG_BY_RNC_TRB_RESETPS call drops may be caused by link releasing due to downlink TRB reset. This reason is mainly caused by poor network coverage (including adjacent cell missing and small handover area). To solve the problem, the network coverage must be improved. In the early network, call drops are mainly caused by this reason.(4) RNC_PS_RAB_REL_TRIG_BY_RNC_GTPU_LOSSIf IU CS interface (AAL2 path) is abnormal, RNC initializes the release. In practice, this reason seldom occurs. If this reason occurs, the problem may be caused by any faulty or defective equipment.(5) PS_RAB_DROP_OTHERPS call drops may be caused by other reasons. There are few call drop statistics in RNC (Version 12). Such reasons as process interaction timeout and cell update failure are recorded in PS_RAB_DROP_OTHER. In practice, many call drops are caused by process interaction timeout and cell update failure. Therefore, these call drops are recorded in PS_RAB_DROP_OTHER.4.6.4 Cell Call Drop AnalysisIn the Cell Drop Call Analysis, query the TOPN to find the cell that has the greatest CS call drop rate, start Cell Call Drop Analysis, and then click Create a Pie Chart to display the cell drop reasons, as shown in Figure 1-30.

Figure 1-30 CS cell drop reasonsCS Cell call drops may be caused by the following reasons:(1) RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_OMCell call drops may be caused by CS link releasing due to operation and maintenance (for example, cell block). Actually, cell call drops caused by this reason are normal.(2) RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_SRB_RESETCell call drops may be caused by link releasing due to downlink SRB reset. This reason is mainly caused by poor network coverage (including adjacent cell missing and small handover area). To solve the problem, the network coverage must be improved. In the early network, call drops are mainly caused by this reason.(3) RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_UTRANCell call drops may be caused by abnormal link releasing due to UTRAN. To solve the problem, use CDL for further analysis.(4) RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_AAL2_LOSSIf IU CS interface (AAL2 path) is abnormal, RNC initializes the release. In practice, this reason seldom occurs. If this reason occurs, the problem may be caused by any faulty or defective equipment.(5) RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_RAB_PREMCell call drops may be caused by CS link releasing due to high priority preemption. If load or resource is insufficient, cell call drop may occur. Check whether the expansion is required according to cell call drop times.(6) CS_RAB_DROP_CELL_OTHERCell call drops may be caused by other reasons. There are few call drop statistics in RNC (Version 12). Such reasons as process interaction timeout and cell update failure are recorded in CS_RAB_DROP_CELL_OTHER. In practice, many call drops are caused by process interaction timeout and cell update failure. Therefore, these call drops are recorded in CS_RAB_DROP_CELL_OTHER.4.7 Traffic Load AnalysisThis section consists of the following parts:

Overview Cell Traffic Analysis4.7.1 OverviewTraffic Load Analysis is included in Nastar tasks. Double click Traffic Load Analysis to display the RNC traffic load details. You can choose Time Range or Query Object to query the RNC traffic load, as shown in Figure 1-32.

Figure 1-32 Query traffic loadChoose Busy Time (Busy Time can be Automatic Querying or Designated Time). In the Traffic Load Analysis, click Create a Pie Chart to display the traffic load details. Assume that the subscribers for different services are equivalent, traffic load proportions are displayed in Figure 1-33. UNKNOWN_USER indicates that the subscribers are from other RNC and service type is unknown. The unit of traffic load is Erl.

Figure 1-33 Traffic Load4.7.2 Cell Traffic AnalysisIf a cell has the highest traffic, it is the most important cell in a network. In addition, the cell is easily congested and need to be expanded. In the Traffic Load Analysis, start Cell Traffic Analysis to query the TOPN. The queried results are outputted as follows:(1) The cell that has the greatest RTWP(2) The cell that has the greatest TCP

(3) The cell that has the greatest DCH UE

(4) The cell that has the greatest downlink admission rejectsThe cell that has the greatest RTWP represents the cell that has the greatest uplink radio load. In practice, this queried result can be used to find the cell that is seriously interfered. If the RTWP of a cell is greater than -100 dBm, the cell must be analyzed. Check whether it is the burst interference or continuous interference. The burst interference exerts little influence on the system but the continuous interference must be eliminated on a timely basis. If the cells have large RTWP_MAX_CELL_DBM values, start Cell RTWP Analysis, as shown in Figure 1-34.

Figure 1-34 Cell RTWP analysisThe cell that has the greatest TCP represents the cell that has the greatest downlink radio load. In practice, if the cell has the greatest downlink radio load, the cell also has the greatest downlink admission rejects. For such cell, check whether the cross coverage is serious and check whether the indoor coverage of high traffic area must be improved to decrease large power consumption.The cell that has the greatest DCH UE is used to measure the subscriber number of a cell. Combined with the utilization of OVSF codes, the average CE and transmission can be estimated to further check whether the resources are sufficient.The cell that has the greatest DL ADMSN DENY is used to measure the cell that has the greatest downlink radio load. In practice, downlink radio load is a bottleneck because the uplink is asymmetric to the downlink and the downlink is of interference. If a cell has the greatest DL ADMSN DENY, check whether the cross coverage is serious, the handover area is unreasonable, or the indoor coverage for high traffic area must be improved.For the cell that has the greatest DL ADMSN DENY, start Cell Resource Analysis to display the admission reject proportions of call setup, incoming handover, and re-configuration. In this way, you can further understand the influence exerted on the subscribers.5. Analyzing Complicated ProblemsFurther analysis is necessary because the KPI of traffic statistics does not represent the processes, but the results. Some reasons may not be found through the KPI analysis. Therefore, it is necessary for us to use further analysis to locate complicated problems. To analyze complicated problems, use the following methods: Narrowing down area range and time range

Analyzing abnormal logs Analyzing repeated problems5.1 Narrowing Down Area Range and Time RangeThe area range of abnormal traffic statistics can be determined by querying the TOPN. After determining the area range, query the time range of problem (The time range falls within 30 minutes).5.2 Analyzing Abnormal LogsExecute the command LST CELL in MML on the RNC maintenance console to find the service subrack. Then, send the CDL of service subrack from BAM to a service engineer for further analyzing abnormal processes, reasons, and involved subscribers.5.3 Analyzing Repeated ProblemsIf time range or area range falls within a fixed scope after the KPI analysis is performed for several days, use Sample Trace on the RNC maintenance console in a given time to obtain the detailed call procedure for further analyzing problem causes and involved subscribers.

Aug. 10, 2005Confidential Information of Huawei

No Spreading Without PermissionPage 5 of 44