Anda di halaman 1dari 134
RAN10 KPI Troubleshooting Guide INTERNAL BOM Code Product Name RAN10 KPI Troubleshooting Guide Intended Product Version

RAN10 KPI Troubleshooting Guide

INTERNAL

BOM Code

Product Name

RAN10 KPI Troubleshooting Guide

Intended

Product Version

V100R010

audience

Department

UMTS Maintenance and Development Department

Document Version

V1.0

 

RAN10 KPI Troubleshooting Guide

Prepared by

KPI Team of the UMTS Maintenance Department

Date

2009-3-6

Reviewed by

Date

Reviewed by

Date

Approved by

Date

RAN10 KPI Troubleshooting Guide INTERNAL BOM Code Product Name RAN10 KPI Troubleshooting Guide Intended Product Version

Huawei Technologies Co., Ltd.

All rights reserved

2009-03-06

RAN10 KPI Troubleshooting Guide Revision History INTERNAL Version Date Description Author V1.0 2009-1-20 The draft was

RAN10 KPI Troubleshooting Guide

Revision History

INTERNAL

Version

Date

Description

Author

V1.0

2009-1-20

The draft was complete.

Shen Yueping, Qian Jin, and Wu Yanwen

V1.0

2009-3-6

The document was revised.

Shen Yueping, Qian Jin, and Wu Yanwen

 
 
RAN10 KPI Troubleshooting Guide Figures Contents 1.1 Problem Discussion.............................................................................................................................................11 1.2 Narrowing the Scope...........................................................................................................................................11 1.3 Locking the

RAN10 KPI Troubleshooting Guide

Figures

Contents

  • 1.1 Problem Discussion.............................................................................................................................................11

  • 1.2 Narrowing the Scope...........................................................................................................................................11

  • 1.3 Locking the Scenario..........................................................................................................................................12

  • 1.4 Drive Test On Site...............................................................................................................................................12

  • 1.5 Reproducing the Mirroring Environment...........................................................................................................12

  • 1.6 Problem Analysis and Summary.........................................................................................................................13

  • 2.1 KPI Definition.....................................................................................................................................................14

  • 2.2 Influence Factors.................................................................................................................................................14

  • 2.3 Analysis Process..................................................................................................................................................15

  • 2.4 List of Problem Information ..............................................................................................................................41

  • 3.1 KPI Definition.....................................................................................................................................................42

  • 3.2 Influence Factors.................................................................................................................................................42

  • 3.3 Analysis Process..................................................................................................................................................43

  • 3.4 List of Problem Information...............................................................................................................................50

  • 4.1 Problems Related to Soft Handover Success Rate..............................................................................................51

    • 4.1.1 KPI Definition...............................................................................................................................................51

    • 4.1.2 Influence Factors...........................................................................................................................................52

    • 4.1.3 Analysis Process............................................................................................................................................54

    • 4.1.4 Cases of Soft Handover Failure ...................................................................................................................57

  • 4.2 Problems Related to Hard Handover Success Rate............................................................................................59

    • 4.2.1 KPI Definition...............................................................................................................................................59

    • 4.2.2 Influence Factors...........................................................................................................................................60

    • 4.2.3 Analysis Process............................................................................................................................................61

    • 4.2.4 Cases of Inter-Frequency Hard Handover Failure .......................................................................................64

  • 4.3 List of Problem Information ..............................................................................................................................67

  • 5.1 KPI Definition.....................................................................................................................................................68

  • 5.2 Influence Factors.................................................................................................................................................68

  • 5.3 Analysis Process..................................................................................................................................................71

  • 5.4 Cases of Call Drop..............................................................................................................................................77

  • 5.5 List of Problem Information...............................................................................................................................80

  • 6.1 Inter-RAT Handover from WCDMA to GSM (CS Domain)..............................................................................81

    • 6.1.1 KPI Definition...............................................................................................................................................81

    • 6.1.2 Influence Factors...........................................................................................................................................82

    • 6.1.3 Analysis Process............................................................................................................................................83

  • RAN10 KPI Troubleshooting Guide Figures 6.2 Inter-RAT Handover from GSM to WCDMA (CS Domain)..............................................................................88 6.2.1 KPI

    RAN10 KPI Troubleshooting Guide

    Figures

    • 6.2 Inter-RAT Handover from GSM to WCDMA (CS Domain)..............................................................................88

      • 6.2.1 KPI Definition...............................................................................................................................................88

      • 6.2.2 Influence Factors...........................................................................................................................................89

      • 6.2.3 Analysis Process............................................................................................................................................90

  • 6.3 Inter-RAT Handover from WCDMA to GPRS (PS Domain).............................................................................92

    • 6.3.1 KPI Definition...............................................................................................................................................92

    • 6.3.2 Influence Factors...........................................................................................................................................93

    • 6.3.3 Analysis Process............................................................................................................................................93

  • 6.4 Inter-RAT Handover from GPRS to WCDMA (PS Domain).............................................................................95

    • 6.4.1 KPI Definition...............................................................................................................................................95

    • 6.4.2 Analysis Process............................................................................................................................................95

  • 6.5 List of Problem Information...............................................................................................................................96

  • 7.1 Performance data of RNC...................................................................................................................................97

    • 7.1.1 Purpose..........................................................................................................................................................97

    • 7.1.2 Information to Be Collected..........................................................................................................................97

    • 7.1.3 Method..........................................................................................................................................................97

  • 7.2 RNC CHR/PCHR................................................................................................................................................98

    • 7.2.1 Purpose..........................................................................................................................................................98

    • 7.2.2 Information to Be Collected..........................................................................................................................98

    • 7.2.3 Method..........................................................................................................................................................99

  • 7.3 RNC IOS Tracing................................................................................................................................................99

    • 7.3.1 Purpose..........................................................................................................................................................99

    • 7.3.2 Information to Be Collected..........................................................................................................................99

    • 7.3.3 Method..........................................................................................................................................................99

  • 7.4 RNC IFTS/CDT (User Plane) Tracing .............................................................................................................102

    • 7.4.1 Purpose........................................................................................................................................................102

    • 7.4.2 Information to Be Collected........................................................................................................................102

    • 7.4.3 Method........................................................................................................................................................102

  • 7.5 Standard Signaling Tracing on the RNC ..........................................................................................................107

    • 7.5.1 Purpose........................................................................................................................................................107

    • 7.5.2 Information to Be Collected........................................................................................................................107

    • 7.5.3 Method........................................................................................................................................................107

  • 7.6 UE QXDM LOG...............................................................................................................................................111

    • 7.6.1 Purpose........................................................................................................................................................111

    • 7.6.2 Information to Be Collected........................................................................................................................111

    • 7.6.3 Method........................................................................................................................................................111

  • 7.7 Real-Time Performance Monitoring of RNC...................................................................................................113

    • 7.7.1 Purpose........................................................................................................................................................113

    • 7.7.2 Information to Be Collected........................................................................................................................113

    • 7.7.3 Method........................................................................................................................................................113

  • 7.8 RNC Script Configuration ...............................................................................................................................114

    • 7.8.1 Purpose........................................................................................................................................................114

  • RAN10 KPI Troubleshooting Guide Figures 7.8.2 Information to Be Collected........................................................................................................................114 7.8.3 Method........................................................................................................................................................114 7.9 Operation Log of

    RAN10 KPI Troubleshooting Guide

    Figures

    • 7.8.2 Information to Be Collected........................................................................................................................114

    • 7.8.3 Method........................................................................................................................................................114

    7.9 Operation Log of RNC......................................................................................................................................115

    • 7.9.1 Purpose........................................................................................................................................................115

    • 7.9.2 Information to Be Collected........................................................................................................................115

    • 7.9.3 Method........................................................................................................................................................115

    • 7.10 Alarm Information on RNC............................................................................................................................116

      • 7.10.1 Purpose......................................................................................................................................................116

      • 7.10.2 Information to Be Collected......................................................................................................................116

      • 7.10.3 Method......................................................................................................................................................116

  • 7.11 Node B Configuration Script..........................................................................................................................117

    • 7.11.1 Purpose......................................................................................................................................................117

    • 7.11.2 Information to Be Collected......................................................................................................................117

    • 7.11.3 Method......................................................................................................................................................117

  • 7.12 Node B CHR...................................................................................................................................................119

    • 7.12.1 Purpose......................................................................................................................................................119

    • 7.12.2 Information to Be Collected......................................................................................................................119

    • 7.12.3 Method......................................................................................................................................................119

  • 7.13 Node B Alarm.................................................................................................................................................120

    • 7.13.1 Purpose......................................................................................................................................................120

    • 7.13.2 Information to Be Collected......................................................................................................................120

    • 7.13.3 Method......................................................................................................................................................120

  • 7.14 Node B CDT...................................................................................................................................................122

    • 7.14.1 Purpose......................................................................................................................................................122

    • 7.14.2 Information to Be Collected......................................................................................................................122

    • 7.14.3 Method......................................................................................................................................................122

  • 7.15 Checking Whether Any Neighboring Cells are not Configured ....................................................................125

    • 7.15.1 Enabling Call Trace for Missing Neighboring Cell Detection Tracing ...................................................125

    • 7.15.2 Stopping the MNCDT...............................................................................................................................129

    • 7.15.3 Reporting the Missing Neighboring Cell Message...................................................................................129

  • 7.16 Soft Failure of DSP.........................................................................................................................................132

  • 7.17 Terminal Troubleshooting...............................................................................................................................134

  • RAN10 KPI Troubleshooting Guide Figures Figures Impact of the PS service upon the RTWP when some

    RAN10 KPI Troubleshooting Guide

    Figures

    Figures

    Impact of the PS service upon the RTWP when some neighboring cells are not configured................................................................20

    Impact of the CS service upon the RTWP when the neighboring cell is not configured.............................................................................21

    Satellite map of the BTS...............................................................23 Traced RTWP waveform................................................................23 Change in the number of subscribers of the cell............................24 Signal quality of neighboring cells................................................25

    Impact of the burst of a large number of RRC connection requests upon the RTWP............................................................................26

    Cell audit message.......................................................................28 Cell signal quality........................................................................58 Measurement report....................................................................58 CIO offset parameter....................................................................59 Relation between RSCP fading and Ec/N0 fading............................61 Comparison of handover parameters.............................................66 Flow on CS inter-RAT handover out of 3G......................................82 Relocation Required message.......................................................85 Relocation Command message......................................................86 Handover Request ACK message...................................................87 Flow on CS handover-in................................................................89 Signaling of CS inter-RAT handover-in...........................................91 Relocation_Request message........................................................92 Flow on PS inter-RAT handover out of...........................................93 Flow on LAU/RAU after the UE accesses the 2G cell........................95

    RAN10 KPI Troubleshooting Guide Figures Querying the workarea of the BAM ...............................................98 Exporting the CHR log

    RAN10 KPI Troubleshooting Guide

    Figures

    Querying the workarea of the BAM ...............................................98 Exporting the CHR log (by running the COL LOG command)............99 Types of objects to be traced......................................................100 IOS Tracing dialog box................................................................101 MoreInfo dialog box...................................................................102 Type of trace object....................................................................103 Configuration page of CDT parameters........................................104 Configuration page of IFTS parameters.......................................105 Configuration page of user-plane tracing.....................................106 Configuration page of performance monitoring............................107 Uu interface tracing ..................................................................108 Iub interface tracing...................................................................109 Iur interface tracing...................................................................110 Querying the DSP code of the CN................................................111 Configuring the QPST port..........................................................112 Connecting the equipment ports.................................................112 Enabling log tracing...................................................................113 Real-time performance monitoring..............................................114 NC script configuration...............................................................114 Exporting the operation log by running the EXP LOG command.....115 Alarm box of the LMT.................................................................116 Exporting the alarms..................................................................117 Exporting the NodeB configuration file through the M2000...........118 Data Config File Transfer............................................................118 FTP upload................................................................................119 Setting the CHR level of the NodeB.............................................120 NodeB CHR reporting switch.......................................................120 Querying the alarm information..................................................121 Saving the alarm information......................................................121 Alarm box of the NodeB LMT.......................................................122

    RAN10 KPI Troubleshooting Guide Figures Modifying the properties of the monitor items of the NodeB CDT.

    RAN10 KPI Troubleshooting Guide

    Figures

    Modifying the properties of the monitor items of the NodeB

    CDT.

    .123

    Enabling CDT tracing of the NodeB cells......................................123

    Basic setting..............................................................................124 Setting other monitor items........................................................124

    Enabling call trace to check whether any neighboring cells are not

    configured.................................................................................126

    Configuration interface of intra-frequency MNCDT.......................126 MNCDT window..........................................................................127 Intra-frequency measurement control after the intra-frequency MNCDT is enabled......................................................................127 Configuration interface of inter-frequency MNCDT.......................128 Configuration interface of inter-RAT MNCDT................................129 Message tracing for the missing intra-frequency neighboring cells

    .................................................................................................130

    Reported message about the missing intra-frequency neighboring

    cells..........................................................................................130

    Message tracing for the missing inter-frequency neighboring cells

    .................................................................................................131

    Reported message about the missing inter-frequency neighboring

    cells..........................................................................................131

    Message about the missing inter-RAT neighboring cell.................132 Analyzing the soft failure of the DSP through the CHR log............133 Resetting the DSP......................................................................133 Analyzing the special UEID through the CHR log..........................134

    RAN10 KPI Troubleshooting Guide Tables Tables Indicators related to RRC setup failure .........................................15 Cell traffic count—Analysis

    RAN10 KPI Troubleshooting Guide

    Tables

    Tables

    Indicators related to RRC setup failure .........................................15 Cell traffic count—Analysis of power congestion............................16 Number of top congested cells .....................................................22 Indicator of cell CE congestion......................................................29 Number of CEs consumed by the DCH service................................30 Number of CEs consumed by the HSUPA service.............................31 Analysis of cell code congestion indicators ...................................34 Analysis of transmission congestion indicators .............................35 Indicators of CS RAB setup failure.................................................43 Indicators of PS RAB setup failure.................................................44 Indicators of PS RB setup failure...................................................47 Flow on RB setup failure because of invalid configuration .............48 Models of the known UEs that have invalid configuration...............48 Indicators related to soft handover failure ....................................55 Indicators related to inter-frequency hard handover failure ...........62 Inter-frequency handover failure .................................................64 CS call drop rate .........................................................................64 Requirements for the EcIo and Ec threshold ..................................69 Requirements of IP-based networking for the transmission quality 71 Indicators related to CS call drop..................................................72 Indicators related to PS call drop..................................................73 Indicators related to CS inter-RAT handover-out failure .................83 Indicators related to CS inter-RAT handover-in failure ...................90 Indicators related to PS inter-RAT handover-out failure .................94

    RAN10 KPI Troubleshooting Guide Tables 2013-8-7 Huawei Confidential Page 10 of 134

    RAN10 KPI Troubleshooting Guide

    Tables

    RAN10 KPI Troubleshooting Guide INTERNAL The document describes the troubleshooting methods for the KPI-related problems in

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    The document describes the troubleshooting methods for the KPI-related problems in the commercial WCDMA networks, thus providing reference for the network maintenance personnel.

    • 1 Analysis Methodology of KPI- Related Problems

    • 1.1 Problem Discussion

    If the customer, network planning personnel, or customer service personnel report some KPI-related problems, you need to collect the related information and understand the problems and needs of the field personnel.

    It is important to know the background of the problems, especially the KPI-related problems that occur in commercial networks. You need to collect more information about the problems by phone and by Email. Firstly, you need to ascertain the urgency and importance of the problems, thus helping you lay down appropriate measures.

    Determine whether the problems are known problems according to the collected information (for example, problem description and version).

    For the KPI-related problems, you need to obtain the version information first. Some problems are known problems or related to known bugs, which have been analyzed and solved.

    Therefore, the troubleshooting personnel can first obtain the bug information or release notes of the version to eliminate the impacts of known problems upon the KPIs.

    According to the time of KPI changes, determine whether the problems are caused by network operations or parameter modifications, and analyze the impacts of network adjustment upon the KPIs emphatically.

    • 1.2 Narrowing the Scope

    After understanding the problems clearly, you can analyze the general KPI data and the KPI data of the top N cells, compare the normal KPI data with the abnormal KPI data, and thus find out the main causes that affect the KPIs (performance counter).

    For example, if the call drop rate increases, you can analyze the call drop rate of the Top N cells and compare the normal KPIs of the Top N cells with the abnormal KPIs of the Top N

    RAN10 KPI Troubleshooting Guide INTERNAL cells. You may find that a cell is abnormal and its

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    cells. You may find that a cell is abnormal and its call drop rate increases. By analyzing the abnormal data of the cell and comparing the normal KPIs with the abnormal KPIs, you can determine whether the symptom is the primary cause of the problem. If yes, the KPI-related problems of the network can be focused on the abnormal cells.

    • 1.3 Locking the Scenario

    Know the main scenarios that affect the KPIs by analyzing the PCHR log.

    Compared with the performance data, the PCHR log records more detailed information and can record the 15 pieces of key signaling before the call is released. By analyzing the PCHR log, you can collect and analyze the exceptional information about the KPI-related problems and know the common features of signaling flow.

    Based on the PCHR log, you can obtain the subscriber information and terminal information, and thus judge whether the problems are caused by the poor performance of the terminal of a specific subscriber or a specific UE type.

    If having the preliminary analysis principles and results, you can request the field personnel to enable the IOS tracing of the TOP cells, thus knowing the scenarios and details of the problems.

    IOS tracing is an effective troubleshooting means. As a kind of cell-level tracing, it can trace the subscriber information about a cell and provide massive amounts of information. However, it can only trace several cells and a limited number of subscribers. To achieve an optical effect, you need to have a preliminary understanding of the problem before enabling IOS tracing.

    Deeply analyze the causes for the KPI-related problems through the CHR, as well as the IOS and PCHR.

    Normally, you can find some abnormalities through IOS tracing and obtain more detailed internal print information about the RNC by analyzing the CHR in the corresponding time range. In addition, you can associate the CHR with the PCHR bills and thus analyze the internal abnormal process, for example, whether the problem is Soft Failure of DSP.

    RAN10 KPI Troubleshooting Guide INTERNAL cells. You may find that a cell is abnormal and its

    The analyzed problem scenarios are determined as the main scenarios that affect the KPIs.

    • 1.4 Drive Test On Site

    Normally, you can determine the causes that affect the KPIs through the preceding steps. If failing to determine such causes, you need to request the field personnel to arrange drive test. The expense of drive test is high. Before conducting the drive test, therefore, you need to have a considerable analysis of the problems and determine the main cells or scenarios where the problems occur.

    Through drive test, you can know the behaviors and signaling of the UE, which are vital to analyzing some UE-related problems.

    • 1.5 Reproducing the Mirroring Environment

    Both field drive test and mirroring in the HQ are the means to reproduce the problems. If the problems can be reproduced in the HQ, the expense is lower and the problems can be

    RAN10 KPI Troubleshooting Guide INTERNAL analyzed more clearly. However, it is difficult to simulate the field

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    analyzed more clearly. However, it is difficult to simulate the field scenarios (transmission status and signal status) in the HQ. To verify the problems caused by the modification parameters, therefore, it is necessary to reproduce the problems in the HQ. If the problems occur in the existing network, field drive test can be required usually.

    Note that you must have a preliminary analysis of the problems before reproducing the problems (unless the problems are extremely urgent). Otherwise, the reproduction is blind.

    1.6 Problem Analysis and Summary

    Firstly, you need to determine whether the analyzed problem is the main influence factor of the KPIs. This point is important, because lots of factors affect the KPIs of the network. You need to clearly analyze the major factors that cause the KPI changes or affect the KPIs.

    Secondly, it is also important to summarize the problems and share the related experience timely.

    RAN10 KPI Troubleshooting Guide INTERNAL 2 RRC Access Success Rate (Service/Non-Service) 2.1 KPI Definition RRC setup

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    • 2 RRC Access Success Rate (Service/Non-Service)

    • 2.1 KPI Definition

    RRC setup success rate = (Number of Successful RRC Setups)/ (Number of RRC Connection Attempts)

    VS.RRC.SuccConnEstab.Rate = < RRC.SuccConnEstab.sum > / < VS.RRC.AttConnEstab.Cell >

    • 2.2 Influence Factors

    The process of RRC connection setup includes the following steps:

    • 1. The UE sends the RRC Connection Request message through the RACH.

    • 2. The RNC sends the RRC Connection Setup message through the FACH.

    • 3. If the RRC is established on the DCH, the UE sends the RRC Connection Setup

    CMP message through the uplink dedicated channel after the downlink dedicated

    channel is set up and synchronized.

    • 4. If the RRC is established on the CCH, the UE directly sends the RRC Connection

    Setup CMP message through the RACH. The RRC connection setup fails in the following scenarios:

    The UE sends the RRC Connection Request message, but the RNC does not receive the message.

    The RNC receives the RRC Connection Request message sent by the UE and delivers the RRC Connection Setup message, but the UE does not receive the RRC Connection Setup message.

    The RNC receives the RRC Connection Request message sent by the UE, and delivers the RRC Connection Reject message.

    The UE receives the RRC Connection Setup message, but does not send the RRC Setup Complete message.

    The UE sends the RRC Setup Complete message, but the RNC does not receive the message.

    RAN10 KPI Troubleshooting Guide INTERNAL Usually, the problems related to RRC setup success rate are found

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Usually, the problems related to RRC setup success rate are found through the performance counter of the RNC or users’ complaints (or drive test). In the scenario where the UE sends the RRC Connection Request message but the RNC does not receive the message, the problem can be found only through users’ complaints or drive test. In other scenarios, the problem can be found through the performance counter.

    Usually, RRC setup failure is caused by the following factors:

    Uplink RACH

    Downlink coverage

    Cell reselection parameter

    Downlink synchronization

    Uplink synchronization

    Resource congestion

    The equipment is abnormal.

    Resource congestion includes power resource congestion, CE resource congestion, code resource congestion, and transmission resource congestion. For the problem caused by resource congestion, you need to first check the actual utilization of resources and analyze the correctness of congestion threshold and configurations.

    For the problem caused by other factors, the air interface of RRC setup does not make any response. Generally, UU Noreply is the main problem that causes RRC connection setup failure.

    2.3 Analysis Process

    • 1. Discussing the Problem, Ascertaining the Problem Background and Product

    Version, and Excluding the Impacts of Known Bugs

    Determine the time at which the RRC setup success rate decreases severely, analyze whether the problem is caused by network adjustment, and focus on the impacts of network adjustment. Obtain the known bug information about the corresponding version (you can inquire of the related contact person of the product or inquire about the information about similar problems of other sites), and determine whether the problem is a known problem.

    • 2. Analyzing the Main Scenarios in Which RRC Setup Fails

    Analyze the change in the causes of RRC access failure through the performance counters on the RNC, and analyze which factor causes the decline of RRC setup success rate. Table 1 lists the causes of RRC access failure defined by the performance counter:

    Table 1 Indicators related to RRC setup failure

    Measurement Item

    Sub Items

    RRC.FailConnEstab.Cong

    VS.RRC.Rej.Power.Cong

    VS.RRC.Rej.UL.CE.Cong

    VS.RRC.Rej.DL.CE.Cong

    VS.RRC.Rej.Code.Cong

    VS.RRC.Rej.ULIUBBandCong

    VS.RRC.Rej.DLIUBBandCong

    RAN10 KPI Troubleshooting Guide INTERNAL Measurement Item Sub Items VS.RRC.FailConnEstab VS.RRC.Rej.RL.Fail RRC.FailConnEstab.Cong VS.RRC.Rej.AAL2.Fail RRC.FailConnEstab.NoReply 3. Analyzing

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Measurement Item

    Sub Items

    VS.RRC.FailConnEstab

    VS.RRC.Rej.RL.Fail RRC.FailConnEstab.Cong

    VS.RRC.Rej.AAL2.Fail

    RRC.FailConnEstab.NoReply

    • 3. Analyzing the Main Causes of RRC Access Failure Deeply

    VS.RRC.Rej.Power.Cong

    The RNC RRM makes power admission algorithm decision. If finding the decision on uplink or downlink admission denial, the RNC RRM initiates RRC setup rejection. In the RAN10 or earlier versions, the power admission policy for RRC is as follows:

    If the RRC Connection Request is caused by emergency call, detach, or registration, directly allow the RRC connection; If the RRC Connection Request is caused by other factors, Allow the RRC connection according to the OLC threshold if the OLC is enabled; directly allow the RRC connection if the OLC is disabled. Therefore, VS.RRC.Rej.Power.Cong occurs when the OLC is enabled in the network and network load is high enough to cause congestion. If RRC setup success rate decreases because the indicator value becomes large suddenly, find the Top N cells that cause power congestion and then query the changes in the maximum RTWP (VS.MaxRTWP) and maximum TCP (VS.MaxTCP) of the Top N cells. If the RTWP increases severely, it indicates that the problem is caused by uplink power congestion. If the TCP increases severely, it indicates that the problem is caused by downlink power congestion. RTWP The RTWP increases for the following reasons:

    High traffic

    External interference

    Some neighboring cells are not configured.

    Cells re-establish.

    The equipment is abnormal. For uplink power congestion (the RTWP increases), judge the causes through the analysis of performance data, and then propose appropriate solution suggestions. Table 1 lists the related performance counters.

    Table 1 Cell traffic countAnalysis of power congestion

     

    DL

    UL

    RB Number

    CS Erlang

    VS.AMR.Ctrl.DL12.2

    VS.AMR.Ctrl.UL12.2

     

    VS.RB.DLConvCS.64

    VS.RB.ULConvCS.64

     

    PS Erlang

    VS.RB.DLInterPS.8

    VS.RB.ULInterPS.8

    VS.RB.DLInterPS.16

    VS.RB.ULInterPS.16

    VS.RB.DLInterPS.32

    VS.RB.ULInterPS.32

    RAN10 KPI Troubleshooting Guide INTERNAL DL UL VS.RB.DLInterPS.64 VS.RB.ULInterPS.64 VS.RB.DLInterPS.128 VS.RB.ULInterPS.128 VS.RB.DLInterPS.144 VS.RB.ULInterPS.144 VS.RB.DLInterPS.256 VS.RB.ULInterPS.256 VS.RB.DLInterPS.384

    RAN10 KPI Troubleshooting Guide

    INTERNAL

     

    DL

    UL

       

    VS.RB.DLInterPS.64

    VS.RB.ULInterPS.64

    VS.RB.DLInterPS.128

    VS.RB.ULInterPS.128

    VS.RB.DLInterPS.144

    VS.RB.ULInterPS.144

    VS.RB.DLInterPS.256

    VS.RB.ULInterPS.256

    VS.RB.DLInterPS.384

    VS.RB.ULInterPS.384

    VS.RB.DLBkgPS.8

    VS.RB.ULBkgPS.8

    VS.RB.DLBkgPS.16

    VS.RB.ULBkgPS.16

    VS.RB.DLBkgPS.32

    VS.RB.ULBkgPS.32

    VS.RB.DLBkgPS.64

    VS.RB.ULBkgPS.64

    VS.RB.DLBkgPS.128

    VS.RB.ULBkgPS.128

    VS.RB.DLBkgPS.144

    VS.RB.ULBkgPS.144

    VS.RB.DLBkgPS.256

    VS.RB.ULBkgPS.256

    VS.RB.DLBkgPS.384

    VS.RB.ULBkgPS.384

    HSPA User

    VS.HSDPA.UE.Mean.Cell

    VS.HSUPA.UE.Mean.Cell

    Throughput

    R99 PS

    VS.PS.Int.Kbps.DL8

    VS.PS.Int.Kbps.UL8

    Throughput

    VS.PS.Int.Kbps.DL16

    VS.PS.Int.Kbps.UL16

    VS.PS.Int.Kbps.DL32

    VS.PS.Int.Kbps.UL32

    VS.PS.Int.Kbps.DL64

    VS.PS.Int.Kbps.UL64

    VS.PS.Int.Kbps.DL128

    VS.PS.Int.Kbps.UL128

    VS.PS.Int.Kbps.DL144

    VS.PS.Int.Kbps.UL144

    VS.PS.Int.Kbps.DL256

    VS.PS.Int.Kbps.UL256

    VS.PS.Int.Kbps.DL384

    VS.PS.Int.Kbps.UL384

    VS.PS.Bkg.Kbps.DL8

    VS.PS.Bkg.Kbps.UL8

    VS.PS.Bkg.Kbps.DL16

    VS.PS.Bkg.Kbps.UL16

    VS.PS.Bkg.Kbps.DL32

    VS.PS.Bkg.Kbps.UL32

    VS.PS.Bkg.Kbps.DL64

    VS.PS.Bkg.Kbps.UL64

    VS.PS.Bkg.Kbps.DL128

    VS.PS.Bkg.Kbps.UL128

    VS.PS.Bkg.Kbps.DL144

    VS.PS.Bkg.Kbps.UL144

    VS.PS.Bkg.Kbps.DL256

    VS.PS.Bkg.Kbps.UL256

    VS.PS.Bkg.Kbps.DL384

    VS.PS.Bkg.Kbps.UL384

    RAN10 KPI Troubleshooting Guide INTERNAL DL UL HSPA VS.HSDPA.MeanChThrough VS.HSUPA.MeanChThroug Traffic put hput VS.HSDPA.MeanChThrough VS.HSUPA.MeanChThroug put.TotalBytes

    RAN10 KPI Troubleshooting Guide

    INTERNAL

     

    DL

    UL

     

    HSPA

    VS.HSDPA.MeanChThrough

    VS.HSUPA.MeanChThroug

    Traffic

    put

    hput

    VS.HSDPA.MeanChThrough

    VS.HSUPA.MeanChThroug

    put.TotalBytes

    hput.TotalBytes

    Power

     

    VS.MeanTCP

    VS.MeanRTWP

    VS.MaxTCP

    VS.MaxRTWP

    VS.MinTCP

    VS.MinRTWP

    Call

     

    VS.RRC.AttConnEstab.Cell

    VS.RRC.AttConnEstab.Cell

    Attempt

     

    Times

     

    VS.RAB.AttEstab.AMR

    VS.RAB.AttEstab.AMR

    VS.RAB.AttEstCS.Conv.64

    VS.RAB.AttEstCS.Conv.64

    VS.RAB.AttEstabPS.Cell

    VS.RAB.AttEstabPS.Cell

    VS.HSDPA.RAB.AttEstab

    VS.HSDPA.RAB.AttEstab

    VS.HSUPA.RAB.AttEstab

    VS.HSUPA.RAB.AttEstab

    The following section describes the judgment methods and solution suggestions in different scenarios where the RTWP increases:

    High traffic causes the rise in the RTWP <Features>:

    The RTWP increases abnormally when traffic is busy.

    The admission of uplink power is rejected when traffic is in peak hours.

    The RTWP becomes normal gradually while traffic decreases.

    The corresponding traffic is high, that is, about 80 equivalent Erlang (it may not serve as the necessary condition).

    <Method of analysis>:

    Through the performance data, analyze whether the RWTP increases while traffic increases. <Suggestions>:

    It is recommended that TRXs should be added in hotspot areas.

    If TRXs cannot be added within a short period, you can run the following command to enable the uplink LDR function: Run the following command: ADD CELLALGOSWITCH: NBMLdcAlgoSwitch=UL_UU_LDR-1;

     High traffic causes the rise in the RTWP <Features>: − The RTWP increases abnormally when
     

    The LDR function can relieve the congestion caused by high traffic rather than eliminate the congestion. The LDR function sacrifices the QoS of some users for the access success rate of the new users.

    External interference causes the rise in the RTWP <Features>:

    After the preceding cause is excluded, external interference causes the rise in the RTWP in two scenarios:

    The RTWP of a cell is abnormal at regular intervals.

    RAN10 KPI Troubleshooting Guide INTERNAL − For the cells in an area, the coverage directions are

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    For the cells in an area, the coverage directions are the same basically and the problem occurs at the same time and at the same frequency.

    1)

    When traffic is low, the RTWP of multiple cells in the same area increases at different degrees in the same time segment and the symptom lasts for more than 20 minutes.

    2)

    If tracing the waveform about the abnormal RTWP (by enabling the RTWP tracing task of the cells), you can find that the RTWP varies gently and has no remarkable fluctuation after the RTWP increases.

    <Method of analysis>:

    Analyze the performance data: In an area or cell where RRC power congestion occurs, check whether the problem occurs in the same time segment. Use the minimum granularity to query the performance data. During the congestion period, check whether the traffic of the cell increases sharply and thus the RTWP increases abnormally (exclude the factor that traffic increases).

    Analyze the PCHR log: Filter out all the bills of RRC admission denial because of the RTWP congestion, and determine the occurrence of congestion (as detailed as to the minute and second).

    Analyze the geographical distribution: Query the geographical distribution information about the cells. If the coverage directions of the cells are the same, it is probable that external interference causes the problem.

    <Suggestions>:

    If the problem is caused by external interference, capture the evidence by scanning the antenna interface and explain the cause to the customer.

    The RTWP increases abnormally because some neighboring cells are not configured There are two such scenarios:

    Huawei neighboring cell is not configured. The cells of other vendors are not configured with Huawei neighboring cell. <Features>:

    In such scenarios, the RTWP increases abnormally because of the mobility of subscribers. The problem occurs at random and in the time segment during which the subscribers move frequently.

    If the RTWP abnormally increases more frequently, RRC congestion and service congestion occur more frequently.

    Figure 1 shows the impact of different types of services upon the RTWP of the cells (data source: The O2 in Germany).

    PS service:

    The Nokia cell is not configured with Huawei neighboring cell. In the Nokia cell, the PS 384/384 service is initiated and it is uploaded.

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 1 Impact of the PS service upon the RTWP when

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Figure 1 Impact of the PS service upon the RTWP when some neighboring cells are not configured

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 1 Impact of the PS service upon the RTWP when

    AMR service:

    Cell1: 311

    Cell2: 312

    Cell1 and Cell2 are the intra-frequency cells. Cell 311 is not configured with the neighbor relation with Cell 312.

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 2 Impact of the CS service upon the RTWP when

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Figure 2 Impact of the CS service upon the RTWP when the neighboring cell is not configured

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 2 Impact of the CS service upon the RTWP when

    <Method of analysis>:

    Analyze the performance data of the congested cells, and find out the distribution of occurrence time of power congestion. Trace and analyze the RTWP and number of subscribers of the cells in real time. Analyze whether the congested cells are not configured with neighboring cells through the NASTAR (or through the analysis result of the neighboring cell configuration of the intelligent network optimization in the PCHR log). Check whether any neighboring cells are not configured according to the preceding analysis result and engineering map information. <Suggestions>:

    It is recommended that the corresponding neighbor relation should be configured. <Reference case>: O2 BPCR case

    • 1. During the period of 2009-01-12 to 2009-01-18, the following cells are severely

    congested: 23690, 43962, 24104, 23696, 3686, 23678, and 23701 of Cluster

    UMTS_S0048_4.

    RAN10 KPI Troubleshooting Guide Table 1 Number of top congested cells INTERNAL CellId CellName Time(As hour)

    RAN10 KPI Troubleshooting Guide

    Table 1 Number of top congested cells

    INTERNAL

    CellId

    CellName

    Time(As

    hour)

    VS.RRC.Rej.Power.Cong

    VS.LCC.OverCongNumUL

    VS.LCC.OverCongTimUL

     

    509310690S2

    • 23690 2009-1-12

     

    20:00:00

    335

    3

    680

     

    509311104S-2

    • 24104 2009-1-19

     

    17:00:00

    318

    3

    520

     

    509310692S-3

    • 43692 2009-1-15

     

    12:00:00

    238

    1

    320

     

    509311104S-2

    • 24104 2009-1-19

     

    18:00:00

    168

    7

    415

     

    509310690S2

    • 23690 2009-1-18

     

    19:00:00

    101

    1

    250

    3686

    509310686S-1

    2009-1-16

    14:00:00

    89

    1

    260

     

    509310690S2

    • 23690 2009-1-15

     

    13:00:00

    63

    2

    145

     

    509310678S2

    • 23678 2009-1-18

     

    20:00:00

    39

    1

    75

     

    509310692S-3

    • 43692 2009-1-17

     

    21:00:00

    38

    3

    95

    3686

    509310686S-1

    2009-1-16

    12:00:00

    37

    4

    155

     

    509310701S2

    • 23701 2009-1-14

     

    18:00:00

    26

    1

    40

     

    509310690S2

    • 23690 2009-1-15

     

    20:00:00

    22

    3

    135

     

    509310678S2

    • 23678 2009-1-13

     

    18:00:00

    19

    1

    40

     

    509310690S2

    • 23690 2009-1-15

     

    11:00:00

    18

    1

    60

     

    509310692S-3

    • 43692 2009-1-14

     

    10:00:00

    13

    1

    5

    3678

    509310678S1

    2009-1-13

    18:00:00

    12

    1

    65

     

    509310696S2

    • 23696 2009-1-18

     

    18:00:00

    12

    1

    220

     

    509310945S2

    • 23945 2009-1-12

     

    19:00:00

    11

    1

    25

     

    509311104S-3

    • 44104 2009-1-19

     

    16:00:00

    8

    1

    15

     

    509310690S2

    • 23690 2009-1-14

     

    18:00:00

    7

    1

    85

     

    509310691S-2

    • 23691 2009-1-19

     

    18:00:00

    7

    2

    25

     

    509310685S3

    • 43685 2009-1-12

     

    6:00:00

    6

    1

    15

     

    509310701S1

    • 3701 2009-1-16

     

    18:00:00

    5

    1

    35

     

    509310673S1

    • 3673 2009-1-19

     

    14:00:00

    4

    1

    30

     

    509310686S-1

    • 3686 2009-1-19

     

    15:00:00

    4

    1

    20

     

    509310696S1

    • 3696 2009-1-17

     

    19:00:00

    4

    2

    75

     

    509310675S2

    • 23675 2009-1-18

     

    13:00:00

    4

    1

    20

     

    509310685S2

    • 23685 2009-1-16

     

    12:00:00

    4

    1

    40

     

    509310690S2

    • 23690 2009-1-17

     

    19:00:00

    4

    1

    30

     

    509310696S2

    • 23696 2009-1-17

     

    12:00:00

    4

    1

    65

     

    509310696S2

    • 23696 2009-1-17

     

    18:00:00

    4

    1

    55

     

    509310696S2

    • 23696 2009-1-17

     

    19:00:00

    4

    6

    155

     

    509310685S3

    • 43685 2009-1-13

     

    15:00:00

    4

    1

    25

     

    509311104S-3

    • 44104 2009-1-19

     

    20:00:00

    4

    1

    15

    3675

    509310675S1

    2009-1-16

    17:00:00

    3

    1

    35

     

    509310676S2

    • 23676 2009-1-12

     

    9:00:00

    3

    3

    75

     

    509310685S2

    • 23685 2009-1-13

     

    15:00:00

    3

    2

    190

     

    509310678S3

    • 43678 2009-1-13

     

    18:00:00

    3

    1

    15

     

    509310685S3

    • 43685 2009-1-12

     

    7:00:00

    3

    1

    15

     

    509311104S-3

    • 44104 2009-1-19

     

    18:00:00

    3

    1

    10

     

    509310690S2

    • 23690 2009-1-16

     

    13:00:00

    2

    1

    30

     

    509310676S3

    • 43676 2009-1-18

     

    13:00:00

    2

    1

    35

     

    509310676S2

    • 23676 2009-1-12

     

    8:00:00

    1

    1

    15

    The satellite map of the BTS shows that Nokia neighboring cell is nearby 23690, 43692, and 24104. Therefore, it is suspected that Nokia neighboring cell has a great impact upon the RTWP of Huawei BTS.

    RAN10 KPI Troubleshooting Guide Figure 3 Satellite map of the BTS INTERNAL 2. On the RNC

    RAN10 KPI Troubleshooting Guide

    Figure 3 Satellite map of the BTS

    INTERNAL

    RAN10 KPI Troubleshooting Guide Figure 3 Satellite map of the BTS INTERNAL 2. On the RNC
    • 2. On the RNC where the Cluster is located, select the top 20 severely congested

    NodeBs for RTWP tracing and find the RTWP waveform generated at the congestion time. During the period of 16:00 to 17:00, you can trace the waveform of Cell 44587 about abnormal RTWP, as shown in Figure 4.

    Figure 4 Traced RTWP waveform

    RAN10 KPI Troubleshooting Guide Figure 3 Satellite map of the BTS INTERNAL 2. On the RNC

    Figure 5 shows the change in the number of subscribers of the corresponding cell.

    RAN10 KPI Troubleshooting Guide Figure 5 Change in the number of subscribers of the cell INTERNAL

    RAN10 KPI Troubleshooting Guide

    Figure 5 Change in the number of subscribers of the cell

    INTERNAL

    RAN10 KPI Troubleshooting Guide Figure 5 Change in the number of subscribers of the cell INTERNAL
    • 3. Query the neighboring cell configuration in the configuration script. Cell 44587 is

    configured with Nokia neighboring cells: Site 175, Site 730, and Cell 43176 of RNC 525. In addition, the signal quality information about Nokia neighboring cells is exported to the PCHR log. As a result, the RTWP of Huawei cell is raised by 10 dB when the subscriber is in a Nokia cell.

    RAN10 KPI Troubleshooting Guide Figure 5 Change in the number of subscribers of the cell INTERNAL
    RAN10 KPI Troubleshooting Guide Figure 6 Signal quality of neighboring cells INTERNAL  The RTWP increases

    RAN10 KPI Troubleshooting Guide

    Figure 6 Signal quality of neighboring cells

    INTERNAL

    RAN10 KPI Troubleshooting Guide Figure 6 Signal quality of neighboring cells INTERNAL  The RTWP increases

    The RTWP increases abnormally because cells are reestablished <Features>:

    For the equipment or transmission reason, cells are reestablished. When the cells are enabled again, a large number of RRC connection requests are generated because of cell reselection over different subsystems.

    The RTWP increases abnormally within a short period because of the burst of a large number of RRC connection requests. As a result, when the uplink power admission algorithm is enabled, some RRC connection requests are rejected because of power congestion. If the cell has a large number of subscribers, the rise in the RTWP value lasts for a longer period.

    As verified in the lab, the RTWP increases to an abnormal level if there are a large number of RRC connection requests. For details, see Figure 7.

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 7 Impact of the burst of a large number of

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Figure 7 Impact of the burst of a large number of RRC connection requests upon the RTWP

    RAN10 KPI Troubleshooting Guide INTERNAL Figure 7 Impact of the burst of a large number of

    <Method of analysis>:

    Within two or three minutes after cells are reestablished, the RTWP fluctuates continuously.

    When both the admission algorithm and OLC algorithm are enabled, a large number of RRC connection requests with the cause of cell reselection over different subsystems are rejected and other types of service requests are also rejected.

    Cell reestablishment alarm: Query the system alarms and check whether the following alarms are generated in the time segment when the RTWP increases abnormally:

    Uplink CPRI Interface Abnormal or SAAL Link Unavailable / SCTP Link Down or Cell unavailable

    Analyze the PCHR data. Power congestion mainly occurs in the time segment of 2 to 5 minutes, and more than 60% of the power-congestion subscribers undergo cell reselection over different subsystems.

    <Suggestions>:

    Disable the uplink admission algorithm or OLC algorithm. If both the uplink admission algorithm and OLC algorithm are enabled, the access success rate decreases severely. If the algorithms are disabled, you can avoid the RRC connection failure caused by power congestion.

    Analyze the cause of cell reestablishment, and try to lower the occurrence frequency of cell reestablishment in the network.

    The RTWP increases abnormally because the equipment is abnormal <Features>:

    When traffic is not high, the RTWP of one or two sites increases stably by more than 10 dB. The symptom lasts for more than 60 minutes.

    After the RTWP increases, the RTWP varies gently and has no remarkable fluctuation.

    The minimum RTWP (VS.MinRTWP) always remains at a high level.

    RAN10 KPI Troubleshooting Guide <Method of analysis>: INTERNAL − Analyze the performance data. If cells are

    RAN10 KPI Troubleshooting Guide

    <Method of analysis>:

    INTERNAL

    Analyze the performance data. If cells are congested, measure the MinRTWP value

    of the cells. Query the system alarms and check whether there exist any board-related alarms.

    Process the alarms first. Trace the RTWP and number of subscribers of the cells in real time.

    If the real-time tracing result shows that the RTWP of the cells is abnormal continuously and the number of subscribers is small, you can ascertain the cause on site.

    If all the preceding causes are excluded, you can suspect that the problem is caused by the equipment. You can collect the related information and submit the information to the Maintenance Department.

    <Suggestions>:

    Collect the related information according to the following checklist, and ask the R&D personnel to further analyze the problem.

    1) TCP

    The TCP increases for the following reasons:

    High traffic

    Other causes

    For downlink power congestion (the TCP increases), analyze the performance data, judge whether the problem is related to the rise in traffic, and then propose appropriate solution suggestions.

    RAN10 KPI Troubleshooting Guide <Method of analysis>: INTERNAL − Analyze the performance data. If cells are

    The commercial networks do not encounter the scenario where RRC admission failure is caused by the overhigh TCP. Currently, the troubleshooting experience in the aspect is not enough. The related contents will be added subsequently.

    VS.RRC.Rej.UL.CE.Cong/ VS.RRC.Rej.DL.CE.Cong

    The RNC RRM makes admission algorithm decision. The RNC RRM can find the admission denial because of the insufficiency of uplink or downlink CE resources, or the number of RRC connection rejections because the NodeB returns CE Congestion when the RNC delivers the RL_SETUP message. For the RL_Fail because the NodeB returns CE Congestion, the RAN10 or earlier versions have the following defects:

    The CE capability of the NodeB is constrained by both the license configuration and hardware specifications. At present, the NodeB reports IUB_INTERFACE_CELL_SYNC_NOT_SUPP and IUB_INTERFACE_CELL_SYNC_ADJ_NOT_SUPP to the RNC if the CE Licenses are not enough. The RNC adds the two cause values to the VS.RRC.Rej.UL.CE.Cong counter and VS.RRC.Rej.DL.CE.Cong counter respectively. However, the NodeB reports RADIO_RESOURCES_NOT_AVAILABLE to the RNC if the actual hardware capability (CE resource) of the NodeB is not enough. Then, the RNC adds the cause value to the VS.RRC.Rej.RL.Fail counter rather than to the corresponding CE congestion counter.

    You can observe the CE capability reported by the NodeB through the Iub NBAP signaling.

    RAN10 KPI Troubleshooting Guide Figure 8 Cell audit message INTERNAL The CE license configuration of the

    RAN10 KPI Troubleshooting Guide

    Figure 8 Cell audit message

    INTERNAL

    RAN10 KPI Troubleshooting Guide Figure 8 Cell audit message INTERNAL The CE license configuration of the

    The CE license configuration of the NodeB should be lower than the hardware capability of the NodeB. Why is the hardware capability not enough when the license capability is not congested? The reason is as follows: In the RAN10 or earlier versions, the NodeB reports the CE capability to the RNC according to the standard of configured licenses 110% regardless of the hardware capability. Therefore, there exists the scenario where the configured licenses exceed the hardware capability, which is not reasonable. The subsequent versions will make the following improvements:

    The following improvements are made on the NodeB:

    If the CE Licenses are not enough, the NodeB reports the following cause through the Iub interface:

    CELL_SYN_NOT_SUPP: The uplink CE licenses are not enough. CELL_SYN_ADJ_NOT_SUPP: The downlink CE licenses are not enough. The two cause values keep the design of the RAN10 version. If the hardware CE capability is not enough, the NodeB reports the following cause through the Iub interface:

    UL_RADIO_RESOURCES_NOT_AVAILABLE: The uplink hardware CE capability is not enough, the uplink logical resources (for example, FPID and CcTrchID) are not enough, and uplink subscribers are allocated. DL_RADIO_RESOURCES_NOT_AVAILABLE: The downlink hardware CE capability is not enough, and the downlink logical resources (for example, FPID and CcTrchID) are not enough. The following improvements are made on the RNC:

    Both CELL_SYN_NOT_SUPP and UL_RADIO_RESOURCES_NOT_AVAILABLE reported by the NodeB are considered as uplink CE insufficiency. Both CELL_SYN_ADJ_NOT_SUPP and DL_RADIO_RESOURCES_NOT_AVAILABLE reported by the NodeB are considered as downlink CE insufficiency. In addition, the access failure because of the preceding four causes is excluded from the VS.RRC.Rej.RL.Fail counter. It is improbable that the NodeB reports RADIO_RESOURCES_NOT_AVAILABLE for the insufficiency of other resources (for example, hardware resource). Therefore, you can basically determine that the problem is caused by the insufficiency of CEs.

    Because of the preceding defects, the number of CE congestions is not accurate. When analyzing VS.RRC.Rej.UL.CE.Cong and VS.RRC.Rej.DL.CE.Cong, you also need to consider VS.RRC.Rej.RL.Fail.

    The common causes of CE congestion are as follows:

    RAN10 KPI Troubleshooting Guide INTERNAL − High traffic − The residual CEs maintained by the NodeB

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    High traffic

    The residual CEs maintained by the NodeB are not consistent with those maintained by the RNC.

    In case of CE congestion, analyze the top N congested cells through the performance data, judge the causes of CE congestion, and propose appropriate solution suggestions.

    Table 1 Indicator of cell CE congestion

     

    DL

    UL

    Traffic

    CS

    VS.AMR.Ctrl.DL12.2

    VS.AMR.Ctrl.UL12.2

    Erlang

    VS.RB.DLConvCS.64

    VS.RB.ULConvCS.64

    PS

    VS.RB.DLInterPS.8

    VS.RB.ULInterPS.8

    Erlang

    VS.RB.DLInterPS.16

    VS.RB.ULInterPS.16

    VS.RB.DLInterPS.32

    VS.RB.ULInterPS.32

    VS.RB.DLInterPS.64

    VS.RB.ULInterPS.64

    VS.RB.DLInterPS.128

    VS.RB.ULInterPS.128

    VS.RB.DLInterPS.144

    VS.RB.ULInterPS.144

    VS.RB.DLInterPS.256

    VS.RB.ULInterPS.256

    VS.RB.DLInterPS.384

    VS.RB.ULInterPS.384

    VS.RB.DLBkgPS.8

    VS.RB.ULBkgPS.8

    VS.RB.DLBkgPS.16

    VS.RB.ULBkgPS.16

    VS.RB.DLBkgPS.32

    VS.RB.ULBkgPS.32

    VS.RB.DLBkgPS.64

    VS.RB.ULBkgPS.64

    VS.RB.DLBkgPS.128

    VS.RB.ULBkgPS.128

    VS.RB.DLBkgPS.144

    VS.RB.ULBkgPS.144

    VS.RB.DLBkgPS.256

    VS.RB.ULBkgPS.256

    VS.RB.DLBkgPS.384

    VS.RB.ULBkgPS.384

    HSPA

    VS.HSDPA.UE.Mean.Cell

    VS.HSUPA.UE.Mean.Cell

    Traffic

    VS.HSDPA.MeanChThroughput

    VS.HSUPA.MeanChThrough

     

    put

     

    VS.HSDPA.MeanChThroughput

    VS.HSUPA.MeanChThrough

    .TotalBytes

    put.TotalBytes

    Call Attempt

    VS.RRC.AttConnEstab.Cell

    VS.RRC.AttConnEstab.Cell

    Times

    VS.RAB.AttEstab.AMR

    VS.RAB.AttEstab.AMR

    VS.RAB.AttEstCS.Conv.64

    VS.RAB.AttEstCS.Conv.64

    RAN10 KPI Troubleshooting Guide INTERNAL DL UL VS.RAB.AttEstabPS.Cell VS.RAB.AttEstabPS.Cell VS.HSDPA.RAB.AttEstab VS.HSUPA.RAB.AttEstab Congestion VS.LCC.LDR.Num.DLCE VS.LCC.LDR.Num.ULCE VS.LCC.LDR.Time.DLCE VS.LCC.LDR.Time.ULCE

    RAN10 KPI Troubleshooting Guide

    INTERNAL

     

    DL

    UL

     

    VS.RAB.AttEstabPS.Cell

    VS.RAB.AttEstabPS.Cell

    VS.HSDPA.RAB.AttEstab

    VS.HSUPA.RAB.AttEstab

    Congestion

     

    VS.LCC.LDR.Num.DLCE

    VS.LCC.LDR.Num.ULCE

    VS.LCC.LDR.Time.DLCE

    VS.LCC.LDR.Time.ULCE

    VS.RAB.FailEstPs.DLCE.Cong

    VS.RAB.FailEstPs.ULCE.Co

     

    ng

     

    VS.RAB.FailEstCs.DLCE.Cong

    VS.RAB.FailEstCs.ULCE.C

     

    ong

     

    VS.RRC.Rej.DL.CE.Cong

    VS.RRC.Rej.UL.CE.Cong

    VS.RRC.Rej.RL.Fail

    VS.RRC.Rej.RL.Fail

    CE Used

    VS.LC.DLCreditUsed.CELL

    VS.LC.ULCreditUsed.CELL

    Number

    VS.LC.DLCreditUsed.CELL.M

    VS.LC.ULCreditUsed.CELL.

    ax

    Max

    VS.LC.DLCreditUsed.CELL.Mi

    VS.LC.ULCreditUsed.CELL.

    n

    Min

    CE Used

    NodeB

    VS.DLCE.Mean.Shared

    VS.ULCE.Mean.Shared

    Number

    Count

    VS.DLCE.Max.Shared

    VS.ULCE.Max.Shared

    Table 2 lists the number of CEs consumed by different services:

    Table 2 Number of CEs consumed by the DCH service

    Directio

    Spreadi

    Number of

    Corresponding

    Typical

    n

    ng

    CEs

    Credits

    Traffic

    Factor

    Consumed

    Consumed

    Class

    DL

    256

    1

    1

    3.4 kbit/s SRB

    UL

    256

    1

    2

    DL

    128

    1

    1

    13.6 kbit/s SRB

    UL

    64

    1

    2

    DL

    128

    1

    1

    12.2 kbit/s AMR

    UL

    64

    1

    2

    DL

    32

    2

    2

    64 kbit/s VP

    UL

    16

    3

    6

    DL

    64

    1

    1

    32 kbps PS

    UL

    32

    1.5

    3

    RAN10 KPI Troubleshooting Guide INTERNAL Directio Spreadi Number of Corresponding Typical n ng CEs Credits Traffic

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Directio

     

    Spreadi

    Number of

     

    Corresponding

     

    Typical

    n

    ng

    CEs

    Credits

    Traffic

    Factor

    Consumed

    Consumed

    Class

    DL

    32

    2

    2

    64 kbit/s PS

    UL

    16

    3

    6

    DL

    16

    4

    4

    128 kbit/s PS

    UL

    8

    5

    10

    DL

    8

    8

    8

    384 kbit/s PS

    UL

    4

    10

    20

    Table 3 Number of CEs consumed by the HSUPA service

     

    Direction

    Spreading

    HSUPA

    HSUPA Phase 2

    Typical

    Factor

    Phase 1

    Traffic

    Class

    UL

    64

    1+1+1

    1

    -

    UL

    32

    1+1+1.5

    1.5

    64 kbit/s

    UL

    16

    1+1+3

    3

    128 kbit/s

    UL

    8

    1+1+5

    5

    256 kbit/s

    UL

    4

    1+1+10

    10

    384 kbit/s

    UL

    2 x SF4

    1+1+20

    20

    1.45 Mbit/s

    UL

    2 x SF2

    Not supported

    32

    2.04 Mbit/s

    UL

    2 x SF2 + 2 x SF4

    Not supported

    48

    5.76 Mbit/s

    The following section describes the judgment methods and solution suggestions in different scenarios of CE congestion:

    High traffic congestion causes CE congestion <Features>:

    The CE Used Number is large, and approaches to the license capability.

    CE admission denial occurs when traffic is in peak hours.

    CE congestion disappears gradually while traffic decreases.

    <Method of analysis>:

    Analyze the performance data of the congested cells, find the NodeB to which the congested cells belong, and obtain the KPI counter of all the cells of the NodeB.

    Query the total number of CEs consumed by all cells under the NodeB (through the performance data of the RNC) and the CE count measured by the NodeB (the number of consumed CEs measured by the NodeB), and check whether they reach the upper limit of CE capability (uplink: license 110%-UlHoCeResvSf; downlink:

    RAN10 KPI Troubleshooting Guide INTERNAL license 110%-DlHoCeCodeResvSf). UlHoCeResvSf and DlHoCeCodeResvSf are configured by the RNC MML.

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    license 110%-DlHoCeCodeResvSf). UlHoCeResvSf and DlHoCeCodeResvSf are configured by the RNC MML.

    Calculate the number of consumed CEs equivalently through the number of RBs of each cell under the NodeB, and check whether they reach the upper limit of CE capability.

    Check whether CE congestion disappears gradually while traffic (CE Used Number, RBs, and HSPA subscribers) decreases gradually.

    If all the preceding conditions are met, you can basically determine that high traffic causes CE congestion.

    <Suggestions>:

    You can take the following measures:

    If the CE-based LDR function is not enabled in the existing network, you can consider enabling the CE LDR algorithm to relieve the impacts of CE congestion.

    If CE-based LDR function is enabled in the existing network, you can check whether VS.LCC.LDR.Num.DLCE, VS.LCC.LDR.Num.ULCE, VS.LCC.LDR.Time.DLCE, and VS.LCC.LDR.Time.ULCE are validated through the following performance data.

    If the preceding indicators do not measure the count and duration in LDR state, it indicates that the equipment does not enter the LDR state. The possible causes are as follows:

    A)

    The NodeB reports the CE capability according to the standard of configured licenses 110%. If the configured licenses 110% LDR threshold (UlLdrCreditSfResThd/DlLdrCreditSfResThd) exceeds the hardware capability of the NodeB, the equipment can never enter the LDR state. The RNC triggers the LDR function by judging whether the difference between the CE capability reported by the NodeB (configured licenses 110%) and the number of currently consumed CEs reaches the LDR threshold.

    B)

    The functions of the product are defective.

    When the HSUPA function is enabled in the existing network, you can enable the dynamic CE function of the NodeB or HSUPA DCCC function if uplink CE congestion is severe. Note the following points:

    A)

    If you enable HSUPA DCCC, you must configure HSUPA admission to be based on MBR access.

    B)

    If you enable dynamic CEs of the NodeB, you must disable HSUPA DCCC and configure HSUPA admission to be based on GBR access.

    Expand the capacity, purchase CEs, or add TRXs. CE congestion is caused because the residual CEs maintained by the NodeB are not consistent with those maintained by the RNC. <Features>:

    The CE Used Number is not high enough to reach the license capability. CE admission denial occurs even if traffic is not high. <Method of analysis>:

    Analyze the performance data of the congested cells, find the NodeB to which the

    congested cells belong, and obtain the performance data of all the cells of the NodeB. Query the total number of CEs consumed by all cells under the NodeB and the CE

    RAN10 KPI Troubleshooting Guide INTERNAL Count measured by the NodeB, and check whether they are below

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Count measured by the NodeB, and check whether they are below the upper limit of CEs.

    Calculate the number of consumed CEs equivalently through the number of RBs of each cell under the NodeB (query the number of RBs of each cell through the performance data, and then calculate the number of consumed CEs according to the CE consumption rules), and check whether it is below the upper limit of CEs.

    If all the preceding conditions are met, you can basically determine that the problem is caused because the residual CEs maintained by the NodeB are not consistent with those maintained by the RNC (the former is less than the latter). The possible cause is NodeB CE leakage.

    <Suggestions>:

    In case of NodeB CE leakage, you need to contact the Maintenance Department for further analysis.

    VS.RRC.Rej.RL.Fail:

    During RRC connection setup, the NodeB judges setup failure. The possible cause is that the internal resources (hardware CE capability and logical resource) of the NodeB are not enough. The hardware CE capability is not enough <Features>:

    The CE Used Number is large, and approaches to the upper limit of CEs.

    In peak hours, RL Reject occurs more frequently.

    RL Reject becomes normal gradually while traffic decreases. <Method of analysis>:

    Analyze the performance data of the RL Reject cells, find the NodeB to which the RL Reject cells belong, and obtain the performance data of all the cells of the NodeB.

    Query the total number of CEs consumed by all cells under the NodeB and the CE Count measured by the NodeB, and check whether they approach to the upper limit of the hardware CE capability of the NodeB.

    If all the preceding conditions are met, you can basically determine that the problem is caused by the constraint of hardware specifications of the NodeB. The NodeB reports the CE capability according to the standard of the configured licenses 110% regardless of the hardware specifications. If License 110% UlHoCeResvSf or license 110% DlHoCeCodeResvSf exceeds the hardware capability of the NodeB, the problem occurs.

    <Suggestions>:

    In the subsequent R11 version, the hardware specifications are taken into account when the NodeB reports the CE capability. Then, the problem does not occur.

    To avoid the problem, you can decrease the number of configured licenses. As a result, the impacts of congestion can be relieved through the LDR function.

    Other internal resources of the NodeB are not enough

    The probability of occurrence is low. Feed back the occurrence (if available) to the R&D department for analysis.

    VS.RRC.Rej.Code.Cong

    RRC setup rejection is mainly caused by the insufficiency of code resources. In a high- traffic scenario (for example, indoor micro-cell coverage), code resources may be not enough. You need to expand its capacity. Query the following count values and determine whether the problem is caused by high traffic.

    RAN10 KPI Troubleshooting Guide Table 4 Analysis of cell code congestion indicators INTERNAL DL Traffic CS

    RAN10 KPI Troubleshooting Guide

    Table 4 Analysis of cell code congestion indicators

    INTERNAL

    DL Traffic CS Erlang VS.AMR. Ctrl.DL12 .2 VS.RB.DLConvCS.64 PS Erlang VS.RB.DLInterPS.8 VS.RB.DLInterPS.16 VS.RB.DLInterPS.32 VS.RB.DLInterPS.64 VS.RB.DLInterPS.128 VS.RB.DLInterPS.144
    DL
    Traffic
    CS Erlang
    VS.AMR.
    Ctrl.DL12
    .2
    VS.RB.DLConvCS.64
    PS Erlang
    VS.RB.DLInterPS.8
    VS.RB.DLInterPS.16
    VS.RB.DLInterPS.32
    VS.RB.DLInterPS.64
    VS.RB.DLInterPS.128
    VS.RB.DLInterPS.144
    VS.RB.DLInterPS.256
    VS.RB.DLInterPS.384
    VS.RB.DLBkgPS.8
    VS.RB.DLBkgPS.16
    VS.RB.DLBkgPS.32
    VS.RB.DLBkgPS.64
    VS.RB.DLBkgPS.128
    VS.RB.DLBkgPS.144
    VS.RB.DLBkgPS.256
    VS.RB.DLBkgPS.384
    Congestion
    VS.RAB.FailEstPs.Code.Cong
    VS.RAB.FailEstPs.Code.Cong
    VS.RRC.Rej.Code.Cong

    <Suggestions>:

    Check the code setting of the HSDPA. The following configuration is recommended:

    ADD CELLHSDPA: AllocCodeMode=Manual, HsPdschCodeNum=1; /// The RNC is statically configured with one HSPDSCH code.

    SET MACHSPARA: DYNCODESW=OPEN; /// Enable the dynamic code switch of the NodeB

    Expand the capacity

    VS.RRC.Rej.ULIUBBandCong/ VS.RRC.Rej.DLIUBBandCong

    RRC setup failure is mainly caused by the transmission congestion on the IUB interface. You can check the traffic and transmission configuration of the cells, and thus judge whether the problem is caused by the insufficiency of transmission

    RAN10 KPI Troubleshooting Guide resources. Table 5 Analysis of transmission congestion indicators INTERNAL DL UL Congesti

    RAN10 KPI Troubleshooting Guide

    resources.

    Table 5 Analysis of transmission congestion indicators

    INTERNAL

     

    DL

    UL

    Congesti

     

    VS.RRC.Rej.DLIUBBandCong

    VS.RRC.Rej.ULIUBBa

    on

     

    ndCong

     

    VS.RAB.FailEstab.CS.DLIUBBand.Cong

    VS.RAB.FailEstab.CS.

     

    ULIUBBand.Cong

     

    VS.RAB.FailEstab.PS.DLIUBBand.Cong

    VS.RAB.FailEstab.PS.

     

    ULIUBBand.Cong

    Iub

    ATM

    VS.AAL2PATH.PVCLAYER.TXBYTES

    VS.AAL2PATH.PVCL

    bandwidt

     

    AYER.RXBYTES

    h utility

     

    ratio

     

    VS.QAAL2.AllocedFwd.AAL2BitRate

    VS.QAAL2.AllocedBw

     

    d.AAL2BitRate

     

    VS.QAAL2.AllocedMaxFwd.AAL2BitRat

    VS.QAAL2.AllocedMa

    e.Value

    xBwd.AAL2BitRate.Val

    ue

    IP

    VS.IPPATH.IPLAYER.TXBYTES

    VS.IPPATH.IPLAYER.

     

    RXBYTES

     

    OS.ANI.IP.AllocedFwd

    OS.ANI.IP.AllocedBwd

    The following section describes several important concepts about Iub admission:

    Iub bandwidth admission is based on the allocated bandwidth regardless of the actual traffic.

    In the versions later than the RAN10, the bandwidth is allocated for the PS service according to GBR Active Factor.

    The RAN10 provides the corresponding count indicators for both actual traffic and allocated bandwidth of the Iub interface, but they need to be converted. The admission is based on the PVC traffic consumed by the user. All traffic needs to be converted to the PVC layer.

    The following section describes several important count indicators:

    The following section describes the calculation of actual traffic on the Iub interface by taking the downlink as an example:

    ATM (kbps): SUM (VS.AAL2PATH.PVCLAYER.TXBYTES) 8 / 3600 / 1000

    Meaning: Add up the traffic of all AAL2PATHs of the Iub, and have the sum divided by the time, thus obtaining the actual traffic (kbps)

    The traffic measurement is performed in the PVC layer, so it does not need to be converted.

    IP (kbps): SUM(VS.IPPATH.IPLAYER.TXBYTES) 8 / 3600 / 1000

    Meaning: Add up the traffic of all IPPATHs of the Iub, and have the sum divided by the time, thus obtaining the actual traffic (kbps)

    The traffic measurement is performed in the IP layer, so it does not need to be converted.

    RAN10 KPI Troubleshooting Guide INTERNAL − By taking the downlink as an example, the following section

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    By taking the downlink as an example, the following section describes bandwidth allocation of the Iub interface:

    ATM (kbps): VS.QAAL2.AllocedFwd.AAL2BitRate 53 / 48 /1000

    Meaning: Convert the allocated bandwidth of the Qaal2 adjacent point corresponding to the NodeB. The conversion from the AAL2 layer to the PVC layer is 53/48.

    IP (kbps): OS.ANI.IP.AllocedFwd /1000

    Meaning: OS.ANI.IP.AllocedFwd is the traffic of the IP layer, so it does not need to be converted.

    Generally, the allocated bandwidth should be approximate to the actual traffic. Then, the configuration of the activation factor is appropriate. If there is a great difference between them, you can optimize the configuration of the activation factor appropriately.

    If IUB congestion causes RRC access failure, the reason is usually that traffic increases or the activation factor is not configured reasonably. Therefore, you need to increase the Iub bandwidth or optimize the configuration of the activation factor.

    The following section gives the judgment method and solution suggestions:

    <Features>:

    The allocated bandwidth of the Iub interface is high and is approximate to the configured bandwidth.

    <Method of analysis>:

    Measure the actual traffic and allocated bandwidth (average value per hour) of the Iub interface through the performance data. If the allocated bandwidth is high and is approximate to the configured transmission bandwidth, the transmission bandwidth may be congested.

    <Suggestions>:

    If the actual traffic is approximate to the allocated bandwidth, it indicates that high traffic causes transmission congestion. The first consideration is to expand the capacity and increase the bandwidth of the Iub interface.

    If the actual traffic is low but the allocated bandwidth is high, it indicates that the problem is caused by the inappropriate setting of the activation factor. You can reduce the activation factor appropriately. Raise the transmission utilization.

    Other possible optimization means are to modify the service GBR and modify the FP mode into the Silent mode. However, the two means are not recommended.

    VS.RRC.Rej.AAL2.Fail:

    The AAL2 Path setup fails on the Iub interface because the transmission is abnormal. Such setup failure does not frequently occur in the existing network. If such cause leads to KPI deterioration, feed back the problem to the R&D department.

    RRC.FailConnEstab.NoReply

    There are the following Noreply scenarios:

    Uu Noreply is caused by cell reselection over different subsystems.

    The RNC receives the RRC Connection Request message sent by the UE and delivers the RRC Connection Setup message, but the UE does not receive the RRC Connection Setup message (excluding the part of cell reselection over different subsystems).

    The UE receives the RRC Connection Setup message, but does not send the RRC Setup Complete message.

    RAN10 KPI Troubleshooting Guide INTERNAL  − The UE sends the RRC Setup Complete message, but

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    The UE sends the RRC Setup Complete message, but the RNC does not receive the message. It is difficult to judge whether the UE receives the RRC Connection Setup message only through the CHR log or performance data. To attain a definite result, you must conduct drive test. Of course, you can attain the preliminary analysis result through the CHR log or performance data before conducting the drive test. The following section describes the judgment methods and solution suggestions in different scenarios:

    Uu Noreply is caused by cell reselection over different subsystems <Features>:

    In the PCHR log, you can find that there exists the access success log nearby the point of access failure time of the same subscriber. The analysis data of Germany’s O2 and Spain’s VDF shows that the part accounts for about 40% of total RRC access failure count. <Method of analysis>:

    As instructed in the following operation guide, you can directly obtain the count and proportion of cell reselections over different subsystems. The operation remains yet to be attached here. The operation guide has been prepared well, but its size is large. Alternatively, analyze the problem as follows:

    For a RRC access failure recorded in the PCHR log, you can determine that the problem is caused by cell reselection over different subsystems under the following circumstances:

    The last access of the corresponding subscriber is normal The RL Release time is later than the time of the current access failure. Alternatively, The next access of the corresponding subscriber is normal, The difference between the time of the next normal access and the time of the current access failure is less than (N300+1) T300, The cell of access failure and the cell of access success are not in the same subsystem. <Suggestions>:

    In the RNC RAN11 050, the RRC access failure caused by cell reselection over different subsystems is not considered as UU Noreply. Provide a clarification report for the customer, thus explaining the impacts of cell reselection over different subsystems and excluding such impacts. The RNC receives the RRC Connection Request message sent by the UE and delivers the RRC Connection Setup message, but the RNC does not receive the RRC Setup Complete message. <Method of analysis>:

    First exclude the RRC access failure caused by cell reselection over different

    subsystems through the PCHR log. If UU Noreply is not caused by cell reselection over different subsystems, discriminate the following scenarios and then analyze the problem deeply:

    The RNC receives the RRC Connection Request message sent by the UE and delivers the RRC Connection Setup message, but the UE does not receive the RRC Connection Setup message (excluding the part of cell reselection over different subsystems). The UE receives the RRC Connection Setup message, but does not send the RRC

    RAN10 KPI Troubleshooting Guide INTERNAL − Setup Complete message. The UE sends the RRC Setup Complete

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    Setup Complete message.

    The UE sends the RRC Setup Complete message, but the RNC does not receive the message.

    For details about the judgment methods and solution suggestions, see the following section. However, the most direct method is to conduct drive test and make signaling analysis. Therefore, the <features> in the following section define several common judgment criteria, which are not absolute.

    The RNC receives the RRC Connection Request message sent by the UE and delivers the RRC Connection Setup message, but the RNC does not receive the message (excluding the part of cell reselection over different subsystems).

    <Features>:

    Through the IOS, you can find that the RRC Connection Setup message is sent repeatedly on the UU interface (based on the N300).

    The possible causes are as follows:

    The FACH coverage is poor. The cell selection and reselection parameters are not set reasonably. The equipment is abnormal or packets are lost during the transmission. <Method of analysis>:

    Analyze the EC/N0 information reported by the UE in the RRC Connection Request message (you can obtain the EC/N0 information through the PCHR log). If the EC/N0 value is lower than 12 dB (the default value), it indicates that the problem is caused by poor coverage.

    If the monitoring set in the RRC Connection Request message contains better cells, it indicates that the problem may be caused by cell reselection.

    If the EC/N0 reported by the UE in the RRC Connection Request message is higher than 7 dB, it indicates that the equipment is abnormal or packets are lost during the transmission (which seldom occurs).

    <Suggestions>:

    If the problem is caused by poor coverage, you can take appropriate measures to enhance the coverage, for example, add sites to fill the blind spots and adjust the engineering parameters. If you cannot enhance the coverage, you can raise the RACH power appropriately. During the adjustment, you need to consider the PCPICH EC/Io coverage of the existing network. For example, if the pilot Ec/Io in the coverage area is higher than -12 dB after network optimization, you can ensure the access success rate of the UE at the 3G idle state as long as the matching proportion of the power of public channels is configured to ensure that the Ec/Io is higher than -12 dB. If the UE is reselected to the GSM when the pilot Ec/Io is lower than -12 dB, you can ensure the RRC setup success rate of the UE in a weak- signal coverage area after cell reselection over different subsystems as long as the matching proportion of the power of public channels is configured to ensure that the Ec/Io is higher than -14 dB.

    If the cell selection and reselection parameters are not set reasonably, you can modify such parameters to raise the speed of cell selection and reselection.

    If the EC/N0 value is ideal but the RRC Connection Setup message is not received, feed back the symptom to the R&D department.

    RAN10 KPI Troubleshooting Guide INTERNAL The RRC CONNECTION SETUP message is carried by the FACH. The

    RAN10 KPI Troubleshooting Guide

    RAN10 KPI Troubleshooting Guide INTERNAL The RRC CONNECTION SETUP message is carried by the FACH. The

    INTERNAL

    The RRC CONNECTION SETUP message is carried by the FACH. The UE sends the RRC CONNECTION REQUEST message through the RACH after the preamble of the PRACH is received at the UTRAN side and the power of the preamble is used as the benchmark. The transmit power of the preamble can increase continuously until the UE receives a response (restricted by the maximum count of preamble retransmissions). In some poor-coverage areas, the imbalance may occur between the RACH coverage and FACH coverage. As a result, the RRC setup request sent by the UE can be received at the UTRAN side, but the UE cannot receive the RRC Connection Setup sent by the RNC.

    The UE receives the RRC Connection Setup message, but does not send the RRC Setup Complete message.

    <Features>:

    Through the IOS, you can find that the RRC Connection Setup message is sent infrequently on the UU interface and that the sending count does not reach the count as specified by the N300.

    If RRC access is based on the DCH, you do not find the RL Restore message on the Iub interface.

    If RRC access is based on the DCH, you can find that the transmit power of the UE is low.

    If both feature 1 and feature 2 (or feature 3) are available, it is probable that the UE receives the RRC Connection Setup message but does not send the RRC Setup Complete message.

    If RRC access is based on the CCH and feature 1 appears, it is probable that the UE receives the RRC Connection Setup message but does not send the RRC Setup Complete message or that the UE sends the RRC Setup Complete message but the RNC does not receive the message.

    The possible causes are as follows:

    Downlink synchronization fails.

    The UE is abnormal.

    If the RRC Setup Complete message is sent through the DCH, the UE does not send the RRC Setup Complete signaling on the uplink unless the downlink is synchronized in accordance with the description of Synchronization procedure A in procedure A (The UE shall not transmit on uplink until higher layers consider the downlink physical channel established).

    Section 25.214 gives the following description: The UE establishes downlink chip and frame synchronization of DPCCH, using the P-CCPCH timing and timing offset information notified from UTRAN. Frame synchronization can be confirmed using the frame synchronization word. Therefore, if the UE cannot synchronize the physical downlink channel, the cause may be related to the power of public channels or the power of initial downlink DPCCH. The power of public channels is determined when the cells are configured. Except the power of the PCPICH, the power of other channels is relative to that of the PCPICH. The power of the downlink DPCCH is informed to the NodeB by the RNC when the RL SETUP REQ message is sent. The power is estimated by using the open-loop power algorithm. The formula is as follows:

    Initial

    P

    Tx

    =

    R

    W

    (

    E

    b

    /

    N

    o

    )

    DL

    [

    CPICH

    _

    T

    x

    _

    power

    (

    E

    c

    /

    N

    o

    )

    CPICH

    P

    txTotal

    ]

    refers to the downlink orthogonalization factor, and (Ec/No)cpich refers to the coverage status at the UE location.

    In addition to by guess, you can also judge whether the downlink is synchronized by the TPC received by the UE and transmit power of the UE. Section 25.214 gives

    RAN10 KPI Troubleshooting Guide INTERNAL the following description: UTRAN shall start the transmission of the downlink

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    the following description: UTRAN shall start the transmission of the downlink DPCCH and may start the transmission of DPDCH if any data is to be transmitted. The initial downlink DPCCH transmit power is set by higher layers. Downlink TPC commands are generated as described in 5.1.2.2.1.2. Therefore, the downlink DPCCH power is transmitted after the RL is established. In accordance with the preceding description, the Pattern of the downlink TPC command word is to insert one “1” after the n “01”s. The n is informed to the NodeB by the RNC when cells are established. The parameter name is DlTpcPattern01Count. If the UE can resolve the downlink DPCCH, e2n+1 slots can raise the power by 1 dB until the NodeB judges that the uplink channel is synchronized. If the downlink is synchronized, the transmit power of the UE should increase from the minimum value to a high value within 1 second. If the UE does not show the symbol that the transmit power increases, you can basically determine that the physical downlink channel of the UE is not synchronized.

    If the UE can normally receive the uplink TPC and raise the power according to TPC, you can determine that the UE is abnormal.

    <Method of analysis>:

    Check whether the transmit power of the UE increases till the maximum value. If the transmit power does not increase, it indicates that the downlink is not synchronized.

    If the downlink power of the UE increases but the RRC Setup Complete message is not on the uplink, it indicates that the UE is abnormal.

     

    <Suggestions>:

     

    If the downlink is not synchronized, you can raise the power of the PCPICH or raise the initial transmit power of the downlink DPCH. However, the RNC does not provide a parameter for controlling the initial transmit power of the downlink DPCH separately, but can only control the minimum transmit power of the DPCH. By configuring the minimum transmit power parameter of the DPCH, you can control its initial transmit power.

    It is improbable that the UE is abnormal. If the UE is really abnormal, you can provide a clarification report or inquire the IOT about the related test results.

    The UE sends the RRC Setup Complete message, but the RNC does not receive the message.

    <Features>:

    Through the IOS, you can find that the RRC Connection Setup message is sent infrequently on the UU interface and that the sending count does not reach the count as specified by the N300.

    If RRC access is based on the DCH, you can find the RL Restore message on the Iub interface.

    If RRC access is based on the CCH, the RACH has lots of bit errors.

    If both feature 1 and feature 2 (or feature 3) are available, it is probable that the UE sends the RRC Setup Complete message but the RNC does not receive the message.

    The possible causes are as follows:

    The RACH has bit errors. Uplink synchronization fails. Packets are lost during the transmission. <Method of analysis>:

    If RRC access is based on the CCH, it is possible that the RACH has bit errors. You

    RAN10 KPI Troubleshooting Guide INTERNAL can check the VS.ULBler.PSNrt.Rach8 and VS.MeanRTWP values. If VS.ULBler.PSNrt.Rach8 or VS.MeanRTWP

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    can check the VS.ULBler.PSNrt.Rach8 and VS.MeanRTWP values. If VS.ULBler.PSNrt.Rach8 or VS.MeanRTWP is high, it is possible that the RTWP interference on the uplink causes the bit errors on the RACH and thus the RNC cannot receive the RRC Setup Complete message correctly.

    If RRC access is based on the DCH, it is possible that the uplink is not synchronized. You can check whether the RL Restore Indication is available on the Iub interface. If not, it is possible that the initial transmit power of the dedicated uplink channel is relatively low.

    If the RL Restore message is available but the RNC cannot receive the RRC Setup Complete message correctly, it is possible that packets are lost during the transmission or the equipment is abnormal. You need to feed back the symptom to the R&D department.

    <Suggestions>:

    If the RACH has bit errors and the RTWP is extremely high, eliminate the uplink interference according to the RTWP Check List.

    If the problem is caused by the failure of uplink synchronization, the transmit power of the UE increases by controlling the initial uplink power, which occurs improbably. The occurrence of such problem can raise the Constant Value of the dedicated channel, thus raising the initial transmit power of the uplink DPCCH of the UE. In addition, the problem is related to the setting of the initial target value of the uplink SIR, which has a great impact on the initial uplink synchronization at the time of initial link establishment. If the parameter is set to an extremely large value, overhigh uplink interference may be caused to the link initially established for the UE. If the parameter is set to an extremely small value, the time of uplink synchronization is prolonged and even initial synchronization fails. The parameter is an RNC-level parameter and has a great impact on network performance. Therefore, you need to modify the parameter with caution.

    RAN10 KPI Troubleshooting Guide INTERNAL can check the VS.ULBler.PSNrt.Rach8 and VS.MeanRTWP values. If VS.ULBler.PSNrt.Rach8 or VS.MeanRTWP

    The RRC CONNECTION SETUP COMPLETE message is sent through the DPCH, and the UE calculates the initial power of the uplink DPCCH according to the received IE"DPCCH_Power_offset" and measured CPICH_RSCP value.

    DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP

    DPCCH_Power_offset is equal to Primary CPICH DL TX Power + UL Interference + Constant Value. The Constant Value parameter can be configured on the background. If the Constant Value parameter is set to an extremely low value, it is possible that the transmit power of the UE is not enough when the UE sends the RRC CONNECTION SETUP COMPLETE message. However, the problem usually does not occur under the current default parameter setting (in the V13C03B151 version, the default value is -20).

    If the RL Restore message is received but the RRC Setup Complete message is not available, it is possible that packets are lost during the transmission or the equipment is abnormal. You need to feed back the symptom to the R&D department.

    2.4 List of Problem Information

    Checkl i st

    for

    KPI

    Troubl eshooti ng-2

    RAN10 KPI Troubleshooting Guide INTERNAL 3 RAB Access Success Rate (AMR/PS/VP/HSPA) 3.1 KPI Definition RAB setup

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    • 3 RAB Access Success Rate (AMR/PS/VP/HSPA)

    • 3.1 KPI Definition

    RAB setup success rate = (RAB setup success count)/(RAB attempt count)

    VS.RAB.SuccEstabCS.AMR.Cell.Rate = <VS.RAB.SuccEstab.AMR> / <VS.RAB.AttEstab.AMR>

    VS.RAB.SuccEstabPS.Cell.Rate = ( <VS.RAB.SuccEstabPS.Conv> + <VS.RAB.SuccEstabPS.Str> + <VS.RAB.SuccEstabPS.Inter> + <VS.RAB.SuccEstabPS.Bkg> )/( <VS.RAB.AttEstabPS.Conv> + <VS.RAB.AttEstabPS.Str> + <VS.RAB.AttEstabPS.Inter> + <VS.RAB.AttEstabPS.Bkg> )

    • 3.2 Influence Factors

    The process of RAB connection setup includes the following steps:

    • 1. The CN sends the RAB ASSIGNMENT REQUEST message to the RNC through the IU interface.

    • 2. After receiving the RAB ASSIGNMENT REQUEST message, the RNC determines that it needs to establish a new RAB. The RNC first performs resource admission.

    • 3. If resource admission fails, the RNC returns the RAB ASSIGNMENT RESPONSE message to the CN.

    • 4. If resource admission is successful, the RNC sends the RADIO BEARER SETUP message to the UE. If the radio bearer setup fails, the UE returns the RADIO BEARER SETUP FAILURE message to the RNC. If receiving the RADIO BEARER SETUP FAILURE message or no response, the RNC returns the RAB ASSIGNMENT RESPONSE message to the CN. RAB setup fails under the following scenarios:

    The RNC receives the RAB ASSIGNMENT REQUEST message, and the admission

    of code, CE or power resource fails. The RNC receives the RAB ASSIGNMENT REQUEST message. The admission of

    system resources (for example, the memory) fails. After receiving the RAB ASSIGNMENT REQUEST message, the RNC sends the

    RAN10 KPI Troubleshooting Guide INTERNAL RADIO BEARER SETUP message to the UE, but does not receive

    RAN10 KPI Troubleshooting Guide

    INTERNAL

    RADIO BEARER SETUP message to the UE, but does not receive the RADIO BEARER SETUP COMPLETE message sent by the UE.

    After receiving the RAB ASSIGNMENT REQUEST message, the RNC sends the RADIO BEARER SETUP message to the UE and receives the RADIO BEARER SETUP FAILURE message sent by the UE.

    Usually, RAB setup failure is caused by the following factors:

    Resource congestion

    Downlink coverage

    Downlink synchronization

    Uplink synchronization

    The equipment is abnormal.

    RAB parameters unsupported

    Resource congestion includes power resource congestion, CE resource congestion, code resource congestion, and transmission resource congestion. For the problem caused resource congestion, you need to first check the actual utilization of resources, and analyze the correctness of congestion threshold and configurations.

    The problems related to downlink coverage and downlink synchronization mainly occur when RAB setup fails under the DRD scenarios.

    3.3 Analysis Process

    • 1. Discussing the Problem, Ascertaining the Problem Background and Product

    Version, and Excluding the Impacts of Known Bugs

    Ask the field personnel to feed back the related information, obtain the known bug information about the corresponding version (you can inquire of the related contact person of the product or inquire about the information about similar problems of other sites), and determine whether the problem is a known problem.

    Determine the time at which the RAB setup success rate is changed, analyze whether the problem is caused by network adjustment, and focus on the impacts of network adjustment.

    • 2. Narrowing the Analysis Scope, Analyzing Whether the Problem Occurs in

    Only One or Two Cells, and Analyzing Whether the Top N Cells are

    Representative

    Analyze the change of the causes of RAB access failure through the performance counters on the RNC, and analyze which factor causes the decline of RAB setup success rate.

    Table 1 Indicators of CS RAB setup failure

    Measurement

    Sub

    Sub

    Sub Items

    Item

    Items

    Items

    Level 4

    Level 1

    Level 2

    Level 3