RF Troubleshooting Guide Radio

eRAN3.0

Troubleshooting Guide

Issue 04

Date 2013-08-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 04 (2013-08-30) Huawei Proprietary and ConfidentialCopyright Huawei Technologies Co., Ltd.

i

http://www.huawei.commailto:[email protected]

About This Document

PurposeThis document describes how to diagnose and handle eRAN faults. Maintenance engineers cantroubleshoot the following faults by referring to this document:

l Faults reflected in user complaints

l Faults found during routine maintenance

l Sudden faults

l Faults indicated by alarms

Intended AudienceThis document is intended for:

l System engineers

l Site maintenance engineers

Product VersionsThe following table lists the product versions related to this document.

Product Name Product Version

DBS3900 LTE V100R005C00

DBS3900 LTE TDD V100R005C00

BTS3900 LTE V100R005C00

BTS3900A LTE V100R005C00

BTS3900L LTE V100R005C00

BTS3900AL LTE V100R005C00

eRAN3.0Troubleshooting Guide About This Document


ii

Change HistoryFor details about the changes in this document, see 1 Changes in eRAN TroubleshootingGuide.

Organization

1 Changes in eRAN Troubleshooting Guide

2 Troubleshooting Process and Methods

This chapter describes the general troubleshooting process and methods.

3 Common Maintenance Functions

This chapter describes common maintenance functions that are used to analyze and handle faults.It also explains or provides references on how to use the functions.

4 Troubleshooting Access Faults

This chapter describes how to diagnose and handle access faults.

5 Troubleshooting Intra-RAT Handover Faults

This chapter describes how to diagnose and handle intra-RAT handover faults. RAT is short forradio access technology.

6 Troubleshooting Service Drops

This chapter describes the method and procedure for troubleshooting service drops in the LongTerm Evolution (LTE) system. It also provides the definitions of service drops and related keyperformance indicator (KPI) formulas.

7 Troubleshooting Inter-RAT Handover Faults

This section defines inter-RAT handover faults, describes handover principles, and provides thefault handling method and procedure.

8 Troubleshooting Rate Faults

This chapter provides definitions of faults related to traffic rates and describes how totroubleshoot low uplink/downlink UDP/TCP rates and rate fluctuations. UDP is short for UserDatagram Protocol, and TCP is short for Transmission Control Protocol.

9 Troubleshooting Cell Unavailability Faults

This chapter defines cell unavailability faults and provides a troubleshooting method.

10 Troubleshooting IP Transmission Faults

This section defines IP transmission faults and describes how to troubleshoot IP transmissionfaults.

11 Troubleshooting Application Layer Faults

This chapter describes the definitions of application layer faults and the troubleshooting method.



iii

12 Troubleshooting Transmission Synchronization Faults

This chapter describes how to troubleshoot transmission synchronization faults. This type offaults include the clcok reference problem, IP clock link fault, system clock unlocked fault, basestation synchronization frame number error, or time synchronization failure.

13 Troubleshooting Transmission Security Faults

This chapter describes how to troubleshoot transmission security faults.

14 Troubleshooting RF Unit Faults

This chapter describes the method and procedure for troubleshooting radio frequency (RF) unitfaults in the Long Term Evolution (LTE) system.

15 Troubleshooting License Faults

This chapter describes how to diagnose and handle license faults.

16 Fault Information Collection

When faults cannot be rectified by referring to this document, collect fault information forHuawei technical support to quickly troubleshoot the faults. This section describes how to collectfault information.

ConventionsSymbol Conventions

The symbols that may be found in this document are defined as follows.

Symbol Description

Indicates an imminently hazardous situation which, if notavoided, will result in death or serious injury.

Indicates a potentially hazardous situation which, if notavoided, could result in death or serious injury.

Indicates a potentially hazardous situation which, if notavoided, may result in minor or moderate injury.

Indicates a potentially hazardous situation which, if notavoided, could result in equipment damage, data loss,performance deterioration, or unanticipated results.NOTICE is used to address practices not related to personalinjury.

Calls attention to important information, best practices andtips.NOTE is used to address information not related to personalinjury, equipment damage, and environment deterioration.



iv

General Conventions

The general conventions that may be found in this document are defined as follows.

Convention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are inboldface. For example, log in as user root.

Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are inCourier New.

Command Conventions

The command conventions that may be found in this document are defined as follows.


Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[ ] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated byvertical bars. One item is selected.

[ x | y | ... ] Optional items are grouped in brackets and separated byvertical bars. One item is selected or no item is selected.

{ x | y | ... }* Optional items are grouped in braces and separated byvertical bars. A minimum of one item or a maximum of allitems can be selected.

[ x | y | ... ]* Optional items are grouped in brackets and separated byvertical bars. Several items or no item can be selected.

GUI Conventions

The GUI conventions that may be found in this document are defined as follows.


Boldface Buttons, menus, parameters, tabs, window, and dialog titlesare in boldface. For example, click OK.

> Multi-level menus are in boldface and separated by the ">"signs. For example, choose File > Create > Folder.



v

Keyboard Operations

The keyboard operations that may be found in this document are defined as follows.

Format Description

Key Press the key. For example, press Enter and press Tab.

Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently.

Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A meansthe two keys should be pressed in turn.

Mouse Operations

The mouse operations that may be found in this document are defined as follows.

Action Description

Click Select and release the primary mouse button without movingthe pointer.

Double-click Press the primary mouse button twice continuously andquickly without moving the pointer.

Drag Press and hold the primary mouse button and move thepointer to a certain position.



vi

Contents

About This Document.....................................................................................................................ii

1 Changes in eRAN Troubleshooting Guide..............................................................................1

2 Troubleshooting Process and Methods.....................................................................................32.1 General Troubleshooting Process...................................................................................................................................42.2 General Troubleshooting Steps......................................................................................................................................52.2.1 Backing Up Data.........................................................................................................................................................52.2.2 Collecting Fault Information.......................................................................................................................................52.2.3 Determining the Fault Scope and Type.......................................................................................................................72.2.4 Identifying Fault Causes..............................................................................................................................................92.2.5 Rectifying the Fault.....................................................................................................................................................92.2.6 Checking Whether Faults Have Been Rectified........................................................................................................102.2.7 Contacting Huawei Technical Support......................................................................................................................10

3 Common Maintenance Functions............................................................................................123.1 User Tracing.................................................................................................................................................................133.2 Interface Tracing...........................................................................................................................................................133.3 Comparison/Interchange...............................................................................................................................................133.4 Switchover/Reset..........................................................................................................................................................13

4 Troubleshooting Access Faults.................................................................................................154.1 Definitions of Access Faults.........................................................................................................................................164.2 Background Information...............................................................................................................................................164.3 Troubleshooting Method..............................................................................................................................................184.4 Troubleshooting Access Faults Due to Incorrect Parameter Configurations...............................................................204.5 Troubleshooting Access Faults Due to Radio Environment Abnormalities.................................................................26

5 Troubleshooting Intra-RAT Handover Faults.......................................................................315.1 Definitions of Intra-RAT Handover Faults..................................................................................................................335.2 Background Information...............................................................................................................................................335.3 Troubleshooting Method..............................................................................................................................................345.4 Troubleshooting Intra-RAT Handover Faults Due to Hardware Faults.......................................................................365.5 Troubleshooting Intra-RAT Handover Faults Due to Incorrect Data Configurations..................................................395.6 Troubleshooting Intra-RAT Handover Faults Due to Target Cell Congestion............................................................41

eRAN3.0Troubleshooting Guide Contents


vii

5.7 Troubleshooting Intra-RAT Handover Faults Due to Poor Uu Quality.......................................................................43

6 Troubleshooting Service Drops................................................................................................476.1 Definitions of Service Drops........................................................................................................................................496.2 Background Information...............................................................................................................................................496.3 Troubleshooting Method..............................................................................................................................................506.4 Troubleshooting Service Drops Due to Radio Faults...................................................................................................536.5 Troubleshooting Service Drops Due to Transmission Faults.......................................................................................546.6 Troubleshooting Service Drops Due to Congestion.....................................................................................................556.7 Troubleshooting Service Drops Due to Handover Failures..........................................................................................566.8 Troubleshooting Service Drops Due to MME Faults...................................................................................................57

7 Troubleshooting Inter-RAT Handover Faults.......................................................................597.1 Definitions of Inter-RAT Handover Faults..................................................................................................................607.2 Background Information...............................................................................................................................................607.3 Troubleshooting Inter-RAT Handovers........................................................................................................................60

8 Troubleshooting Rate Faults.....................................................................................................668.1 Definitions of Rate Faults.............................................................................................................................................678.2 Background Information...............................................................................................................................................678.3 Troubleshooting Abnormal Single-UE Rates...............................................................................................................708.4 Troubleshooting Abnormal Multi-UE Rates................................................................................................................76

9 Troubleshooting Cell Unavailability Faults..........................................................................799.1 Definitions of Cell Unavailability Faults......................................................................................................................819.2 Background Information...............................................................................................................................................819.3 Troubleshooting Method..............................................................................................................................................829.4 Troubleshooting Cell Unavailability Faults Due to Incorrect Data Configuration......................................................849.5 Troubleshooting Cell Unavailability Faults Due to Abnormal Transport Resources...................................................869.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF Resources.............................................................879.7 Troubleshooting Cell Unavailability Faults Due to Limited Capacity or Capability...................................................909.8 Troubleshooting Cell Unavailability Faults Due to Faulty Hardware..........................................................................91

10 Troubleshooting IP Transmission Faults.............................................................................9310.1 Definitions of IP Transmission Faults........................................................................................................................9410.2 Background Information.............................................................................................................................................9410.3 Troubleshooting Method............................................................................................................................................9410.4 Troubleshooting IP Physical Layer Faults..................................................................................................................9510.5 Troubleshooting IP Link Layer Faults........................................................................................................................9810.6 Troubleshooting IP Layer Faults..............................................................................................................................100

11 Troubleshooting Application Layer Faults........................................................................10111.1 Definitions of Application Layer Faults...................................................................................................................10211.2 Background Information...........................................................................................................................................10211.3 Troubleshooting Method..........................................................................................................................................102



viii

11.4 Troubleshooting SCTP Link Faults..........................................................................................................................10411.5 Troubleshooting IP Path Faults................................................................................................................................10711.6 Troubleshooting OM Channel Faults.......................................................................................................................107

12 Troubleshooting Transmission Synchronization Faults.................................................11012.1 Definitions of Transmission Synchronization Faults...............................................................................................11112.2 Background Information...........................................................................................................................................11112.3 Troubleshooting Specific Transmission Synchronization Faults.............................................................................111

13 Troubleshooting Transmission Security Faults................................................................ 11513.1 Definitions of Transmission Security Faults............................................................................................................11613.2 Background Information...........................................................................................................................................11613.3 Troubleshooting Specific Transmission Security Faults..........................................................................................117

14 Troubleshooting RF Unit Faults...........................................................................................12514.1 Definitions of RF Unit Faults...................................................................................................................................12614.2 Background Information...........................................................................................................................................12614.3 Troubleshooting Method..........................................................................................................................................13114.4 Troubleshooting VSWR Faults................................................................................................................................13214.5 Troubleshooting RTWP Faults.................................................................................................................................13414.6 Troubleshooting ALD Link Faults...........................................................................................................................140

15 Troubleshooting License Faults............................................................................................14215.1 Definitions of License Faults....................................................................................................................................14315.2 Background Information...........................................................................................................................................14315.3 Troubleshooting Method..........................................................................................................................................14315.4 Troubleshooting License Faults That Occur During License Installation................................................................14415.5 Troubleshooting License Faults That Occur During Network Running..................................................................14715.6 Troubleshooting License Faults That Occur During Network Adjustment..............................................................149

16 Fault Information Collection.................................................................................................153



ix

1 Changes in eRAN Troubleshooting GuideThis chapter describes the changes in eRAN Troubleshooting Guide.

04 (2013-08-30)This is the fourth official release.

Compared with issue 03 (2012-12-29), this issue includes the following new information.

Topic Change Description

16 Fault Information Collection Added the common fault information andcollection methods.

Compared with issue 03 (2012-12-29), this issue includes the following changes.


4.3 Troubleshooting Method Modified the description of possible causesand flowcharts.

No information in issue 03 (2012-12-29) is deleted from this issue.

03 (2012-12-29)This is the third official release.

Compared with issue 02 (2012-07-30), this issue does not include any new information.


eRAN3.0Troubleshooting Guide 1 Changes in eRAN Troubleshooting Guide


1


9.5 Troubleshooting Cell UnavailabilityFaults Due to Abnormal TransportResources

l Deleted the possible cause: the IP path isfaulty or not configured.

l Added a possible cause: the S1 interface isfaulty or not configured.

13.3 Troubleshooting SpecificTransmission Security Faults

Updated the figure 9.


02 (2012-07-30)

This is the second official release.

Compared with issue 01 (2012-06-29), this issue does not include any new information.



Whole document Updated descriptions.


01 (2012-06-29)

This is the first official release.

Compared with draft A (2012-05-11), this issue does not include any new information.

Compared with draft A (11.05.12), this issue includes the following changes.


14.5 Troubleshooting RTWP Faults Added the step for troubleshooting, includingthe step for diagnosing and handling the cross-connected antennas.

No information in draft A (2012-05-11) is deleted from this issue.

Draft A (2012-05-11)

This is a draft.

eRAN3.0Troubleshooting Guide 1 Changes in eRAN Troubleshooting Guide


2

2 Troubleshooting Process and MethodsAbout This Chapter

This chapter describes the general troubleshooting process and methods.

2.1 General Troubleshooting ProcessThis section describes the general troubleshooting process.

2.2 General Troubleshooting StepsThis section describes each step in the general troubleshooting process in detail.

eRAN3.0Troubleshooting Guide 2 Troubleshooting Process and Methods


3

2.1 General Troubleshooting ProcessThis section describes the general troubleshooting process.

Figure 2-1 shows the general troubleshooting process.

Figure 2-1 General troubleshooting process

Table 2-1 details each step of the general troubleshooting process.

Table 2-1 Steps in the general troubleshooting process

No. Step Remarks

1 2.2.1 Backing Up Data Data to be backed up includes the database, alarminformation, and log files.



4

No. Step Remarks

2 2.2.2 Collecting FaultInformation

Fault information is essential to troubleshooting.Therefore, maintenance personnel are advised to collectas much fault information as possible.

3 2.2.3 Determining theFault Scope and Type

Determine the fault scope and type based on thesymptoms.

4 2.2.4 Identifying FaultCauses

Identify the fault causes based on the fault informationand symptom.

5 2.2.5 Rectifying theFault

Take appropriate measures or steps to rectify the fault.

6 2.2.6 CheckingWhether Faults HaveBeen Rectified

Verify whether the fault is rectified.If the fault is rectified, the troubleshooting process ends.If the fault persists, check whether this fault falls inanother fault scope or type.

7 2.2.7 ContactingHuawei TechnicalSupport

If the fault scope or type cannot be determined, or thefault cannot be rectified, contact Huawei technicalsupport.

2.2 General Troubleshooting StepsThis section describes each step in the general troubleshooting process in detail.

2.2.1 Backing Up DataTo ensure data security, first save onsite data and back up related databases, alarm information,and log files during troubleshooting.

For details about data to be backed up and how to back up data, see eNodeB Routine MaintenanceGuide.

2.2.2 Collecting Fault InformationFault information is essential to troubleshooting. Therefore, maintenance personnel shouldcollect fault information as much as possible.

Fault Information to Be Collected

Before rectifying a fault, collect the following information:

l Fault symptom

l Time, location, and frequency

l Scope and impact

l Equipment running status before the fault occurs



5

l Operations performed on the equipment before the fault occurs, and the results of theseoperations

l Measures taken to deal with the fault, and the results

l Alarms and correlated alarms when the fault occurs

l Board indicator status when the fault occurs

Fault Information Collection Methods

The methods for collecting fault information are as follows:

l Consult the person who reports the fault about the symptom, time, location, and frequencyof the fault.

l Consult maintenance personnel about the equipment running status, fault symptom,operations performed before the fault occurs, and measures taken after the fault occurs andthe effect of these measures.

l Observe the board indicator, operation and maintenance (OM) system, and alarmmanagement system to obtain the software and hardware running status.

l Estimate the scope and impact of the fault by means of service demonstration, performancemeasurement, and interface or signaling tracing.

Fault Information Collection Skills

The following are skills in collecting fault information:

l Do not handle a fault hastily. Collect as much information as possible before rectifying thefault.

l Keep good liaison with maintenance personnel of other sites. Resort to them for technicalsupport if necessary.

Fault Information Classification

Table 2-2 Fault information types

Type Attribute Description

Originalinformation

Definition Original information includes the fault information reflectedin user complaints, fault notifications from other offices,exceptions detected in maintenance, and the informationcollected by maintenance personnel through differentchannels in the early period when the fault is found. Originalinformation is important for fault locating and analysis.

Function Original information is used to determine the fault scope andfault category. Original information helps narrow the faultscope and locate the faults in the initial stage oftroubleshooting. Original information can also helptroubleshoot other faults, especially trunk faults.

Reference None



6

Type Attribute Description

Alarminformation

Definition Alarm information is the output of the eNodeB alarm system.It relates to the hardware, links, trunk, and CPU load of theeNodeB, and includes the description of faults or exceptions,fault causes, and handling suggestions. Alarm information isa key element for fault locating and analysis.

Function Alarm information is specific and complete; therefore, it isdirectly used to locate the faulty component or find the faultcause. In addition, alarm information can also be used withother methods to locate a fault.

Reference For details about how to use the alarm system, see M2000Online Help. For detailed information about each alarm, seeeNodeB Alarm Reference.

Indicatorstatus

Definition Board indicators indicate the running status of boards,circuits, links, optical channels, and nodes. Indicator statusinformation is also a key element for fault locating andanalysis.

Function By analyzing indicator status, you can roughly locate faultycomponents or fault causes that facilitate subsequentoperations. Generally, indicator status information iscombined with alarm information for locating faults.

Reference For the description of indicator status, see associated hardwaredescription manuals.

Performancecounter

Definition Performance counters are statistics about serviceperformance, such as statistics about service drops andhandovers. They help find out causes of service faults so thatmeasures can be taken in a timely manner to prevent suchfaults.

Function Performance counters are used with signaling tracing andsignaling analysis to locate causes of service faults such as ahigh service drop rate, low handover success rate, and serviceexception. They are generally used for the key performanceindicator (KPI) analysis and performance monitoring of theentire network.

Reference For details about the usage of performance counters, seeM2000 Online Help. For the definitions of each performancecounter, see eNodeB Performance Counter Reference.

2.2.3 Determining the Fault Scope and TypeBased on the fault symptom, determine the fault scope and type.

In this document, faults are classified according to symptoms. eRAN faults are classified intoservice faults and equipment faults.



7

Service Faults

Service faults are further classified into the following types:

l Access faults

User access fails.

The access success rate is low.

l Handover faults

The intra-frequency handover success rate is low.

The inter-frequency handover success rate is low.

l Service drop faults

Service drops occur during handovers.

Services are unexpectedly released.

l Inter-RAT interoperability faultsInter-RAT handovers cannot be normally performed.

l Rate faults

Data rates are low.

There is no data rate.

Data rates fluctuate.

Equipment Faults

Equipment faults are further classified into the following types:

l Cell faults

Cell setup fails.

Cell activation fails.

l Operation and maintenance channel (OMCH) faults

The OMCH is interrupted or fails intermittently.

The CPRI link does not work properly.

The S1/X2/SCTP/IPPATH links do not work properly.

IP transport is abnormal.

l Clock faults

The clock source is faulty.

The IP clock link is faulty.

The system clock is out of lock.

l Security faults

The IPSec tunnel is abnormal.

SSL negotiation is abnormal.

Digital certificate processing is abnormal.

l Radio frequency faults

The standing wave is abnormal.



8

The received total wideband power (RTWP) on the RX channel is abnormal.

The antenna line device (ALD) link does not work properly.

l License faults

License installation fails.

License modification fails.

2.2.4 Identifying Fault CausesFault locating is a process of finding the fault causes from many possible causes. By analyzingand comparing all possible causes and then excluding impossible factors, you can determine thespecific fault causes.

Locating Equipment Faults

Locating equipment faults is easier than locating service faults. Though there are many types ofequipment faults, the fault scope is relatively narrow. Equipment faults are generally indicatedby the indicator status, alarms, and error messages. Based on the indicator status information,alarm handling suggestions, or error messages, users can rectify most equipment faults.

Locating Service Faults

The methods for locating different types of service faults are as follows:

l Access faults: Check the S1 interface and Uu interface. Locate transmission faults segmentby segment. Then, determine whether faults occur in the eRAN based on the interfaceconditions. If so, proceed to locate specific faults.

l Rate faults: Check whether there are access faults. If there are access faults, locate specificfaults by using the previous methods. Then, check the traffic on the IP path to determinefault points.

l Handover faults: Start signaling tracing and determine fault points according to thesignaling flow.

For instructions on fault locating and analysis, see 3 Common Maintenance Functions.

2.2.5 Rectifying the FaultTo rectify a fault, take proper measures to eliminate the fault and restore the system, includingchecking and repairing cables, replacing boards, modifying configuration data, switching overthe system, and resetting boards. Maintenance personnel need to rectify different faults usingproper methods.

After the fault is rectified, be sure to perform the following:

l Perform testing to confirm that the fault has been rectified.

l Record the troubleshooting process and key points.

l Summarize measures of preventing or decreasing such faults. This helps to prevent similarfaults from occurring in the future.



9

2.2.6 Checking Whether Faults Have Been RectifiedCheck the equipment running status, observe the board indicator status, and query alarminformation to verify that the system is running properly. Perform testing to confirm that faultshave been rectified and that services return to normal.

2.2.7 Contacting Huawei Technical SupportIf the fault scope or type cannot be determined, or the fault cannot be rectified, contact Huaweitechnical support.

If you need to contact Huawei technical support during troubleshooting, collect necessaryinformation in advance.

Collecting General Fault InformationGeneral fault information includes the following:

l Name of the officel Name and phone number of the contact personl Time when the fault occursl Detailed description of the fault symptomsl Host software version of the equipmentl Measures taken after the fault occurs and the resultl Severity level of the fault and the time required for rectifying the fault

Collecting Fault Location InformationWhen a fault occurs, collect the following information:

l One-click logs of the main control boardl One-click logs of baseband boardsl One-click logs of RRUsl Alarm informationl KPI data of the entire networkl Intelligent field test system (IFTS) tracingl Cell drive test (DT) tracingl SCTP link tracingl Signaling tracing on interfacesl eNodeB configuration informationl M2000 self-organizing network (SON) logsl M2000 adaptation logsl M2000 software module management logs

For details about how to collect fault information, see eNodeB LMT User Guide, eNodeBPerformance Monitoring Reference, eNodeB Routine Maintenance Guide, and M2000 OnlineHelp.



10

Contacting Huawei Technical SupportThe following lists the contact information of Huawei technical support:

l If you are in mainland China, dial 4008302118.l If you are outside mainland China, contact the technical support personnel in the local

Huawei office.l Email: [email protected] Website: http://support.huawei.com



11

mailto:[email protected]://support.huawei.com

3 Common Maintenance FunctionsAbout This Chapter

This chapter describes common maintenance functions that are used to analyze and handle faults.It also explains or provides references on how to use the functions.

3.1 User TracingUser tracing is a function that traces all messages of a user in sequence over standard and internalinterfaces, traces internal status of the user equipment (UE), and displays the tracing results onthe screen.

3.2 Interface TracingInterface tracing is a function that traces all messages within a period in sequence on a standardor internal interface and displays them on the screen.

3.3 Comparison/InterchangeComparison and interchange are used to locate faults in a piece or pieces of equipment.

3.4 Switchover/ResetSwitchover helps identify whether the originally active equipment is faulty or whether the active/standby relationship is normal. Reset is used to identify whether software running errors exist.

eRAN3.0Troubleshooting Guide 3 Common Maintenance Functions


12

3.1 User TracingUser tracing is a function that traces all messages of a user in sequence over standard and internalinterfaces, traces internal status of the user equipment (UE), and displays the tracing results onthe screen.

User tracing has the following advantages:

l Real-time

l Able to trace the user over all standard interfaces

l Usable when traffic is heavy

l Applicable in various scenarios, for example, call procedure analysis and VIP user tracing

User tracing is usually used to diagnose call faults that can be reproduced. For details about howto perform user tracing, see the online help for the operation and maintenance system.

3.2 Interface TracingInterface tracing is a function that traces all messages within a period in sequence on a standardor internal interface and displays them on the screen.

Interface tracing has the following advantages:

l Real-time

l Complete: All messages within a period on an interface can be traced.

l Able to trace link management messages

Interface tracing applies in scenarios where user equipment (UEs) involved are uncertain. Forexample, this function can be used to diagnose the cause for a low success rate of radio resourcecontrol (RRC) connection setup at a site. For details about how to perform interface tracing, seethe online help for the operation and maintenance system.

3.3 Comparison/InterchangeComparison and interchange are used to locate faults in a piece or pieces of equipment.

Comparison is a function used to locate a fault by comparing the faulty component or faultsymptom with a functional component or normal condition, respectively. Interchange is afunction used to locate a fault by interchanging a possibly faulty component with a functionalcomponent and comparing the running status before and after the interchange.

Comparison usually applies in scenarios with a single fault. Interchange usually applies inscenarios with complicated faults.

3.4 Switchover/ResetSwitchover helps identify whether the originally active equipment is faulty or whether the active/standby relationship is normal. Reset is used to identify whether software running errors exist.



13

Switchover switching of the active and standby roles of equipment so that the standby equipmenttakes over services. Comparing the running status before and after the switchover helps identifywhether the originally active equipment is faulty or whether the active/standby relationship isnormal. Reset is a means to manually restart part of or the entire equipment. It is used to identifywhether software running errors exist.

Switchover and reset can only be emergency resorts. Exercise caution when using them, because:

l Compared with other functions, switchover and reset can only be auxiliary means for faultlocating.

l Because software runs randomly, a fault is usually not reproduced in a short period after aswitchover or reset. This hides the fault, which causes risks in secure and stable running ofthe equipment.

l Resets might interrupt services. Improper operations may even cause collapse. Theinterruption and collapse have a severe impact on the operation of the system.



14

4 Troubleshooting Access FaultsAbout This Chapter

This chapter describes how to diagnose and handle access faults.

4.1 Definitions of Access FaultsIf an access fault occurs, UEs have difficulty accessing the network due to radio resource control(RRC) connection setup failures or E-UTRAN radio access bearer (E-RAB) setup failures.

4.2 Background InformationThis section provides counters and alarms related to access faults, and methods for analyzingTopN cells.

4.3 Troubleshooting MethodThis section describes how to identify and troubleshoot the possible cause.

4.4 Troubleshooting Access Faults Due to Incorrect Parameter ConfigurationsThis section provides information required to troubleshoot access faults due to incorrectparameter configurations. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

4.5 Troubleshooting Access Faults Due to Radio Environment AbnormalitiesThis section provides information required to troubleshoot access faults due to radio environmentabnormalities. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

eRAN3.0Troubleshooting Guide 4 Troubleshooting Access Faults


15

4.1 Definitions of Access FaultsIf an access fault occurs, UEs have difficulty accessing the network due to radio resource control(RRC) connection setup failures or E-UTRAN radio access bearer (E-RAB) setup failures.

4.2 Background InformationThis section provides counters and alarms related to access faults, and methods for analyzingTopN cells.

In Long Term Evolution (LTE) networks, access faults occur either during radio resource control(RRC) connection setup or during E-UTRAN radio access bearer (E-RAB) setup. The accesssuccess rate is a key performance indicator (KPI) that quantifies end user experience. Anexcessively low access success rate indicates that end users have difficulty making mobile-originated or mobile-terminated calls.

Related Countersl RRC Connection Setup Measurement (Cell)(RRC.Setup.Cell)

l RRC Connection Setup Failure Measurement (Cell)(RRC.SetupFail.Cell)

l E-RAB Setup Measurement (Cell)(E-RAB.Est.Cell)

l E-RAB Setup Failure Measurement (Cell)(E-RAB.EstFail.Cell)

For details, see eNodeB Performance Counter Reference.

Related Alarmsl Hardware-related alarms

ALM-26104 Board Temperature Unacceptable

ALM-26106 Board Clock Input Unavailable

ALM-26107 Board Input Voltage Out of Range

ALM-26200 Board Hardware Fault

ALM-26202 Board Overload

ALM-26203 Board Software Program Error

ALM-26208 Board File System Damaged

l Temperature-related alarms

ALM-25650 Ambient Temperature Unacceptable

ALM-25651 Ambient Humidity Unacceptable

ALM-25652 Cabinet Temperature Unacceptable

ALM-25653 Cabinet Humidity Unacceptable

ALM-25655 Cabinet Air Outlet Temperature Unacceptable

ALM-25656 Cabinet Air Inlet Temperature Unacceptable

l Link-related alarms



16

ALM-25880 Ethernet Link Fault

ALM-25886 IP Path Fault

ALM-25888 SCTP Link Fault

ALM-25889 SCTP Link Congestion

ALM-26233 BBU CPRI Optical Interface Performance Degraded

ALM-26234 BBU CPRI Interface Error

ALM-29201 S1 Interface Fault

ALM-29211 Excessive Packet Loss Rate in the Transmission Network

ALM-29212 Excessive Delay in the Transmission Network

ALM-29213 Excessive Jitter in the Transmission Network

l RF-related alarms

ALM-26239 RX Channel RTWP/RSSI Unbalanced Between RF Units

ALM-26520 RF Unit TX Channel Gain Out of Range

ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

l Configuration-related alarms

ALM-26245 Configuration Data Inconsistency

ALM-26243 Board Configuration Data Ineffective

ALM-26812 System Dynamic Traffic Exceeding Licensed Limit

ALM-26815 Licensed Feature Entering Keep-Alive Period

ALM-26818 No License Running in System

ALM-26819 Data Configuration Exceeding Licensed Limit

ALM-29243 Cell Capability Degraded

ALM-29247 Cell PCI Conflict

For details, see eNodeB Alarm Reference.

TopN Cell Selection

TopN cells can be selected by analyzing the daily KPI file exported by the M2000.

l Top3 cells with the largest amounts of failed RRC connection setups(L.RRC.ConnReq.Att - L.RRC.ConnReq.Succ) and lowest RRC connection setupsuccess rates

l Top3 cells with the largest amounts of failed E-RAB setups and lowest E-RAB setupsuccess rates

Tracing TopN Cells

After finding out topN cells and the periods when they have the lowest success rates, start Uu,S1, and X2 interface tracing tasks and check the exact point where the RRC connection or E-RAB setup fails.



17

In addition, after the Evolved Packet Core (EPC) obtains the international mobile subscriberidentity (IMSI) of the UE with the lowest success rate based on the UE's temporary mobilesubscriber identity (TMSI), you can start a task to trace the UE throughout the whole network.

Analyzing Environmental Interference to TopN CellsEnvironmental interference to a cell consists of downlink (DL) interference and uplink (UL)interference to the cell. The following methods can be used to check the environmentalinterference:

l To check DL interference, use a spectral scanner. If both neighboring cells and externalsystems may cause DL interference to the cell, locate the exact source of the DLinterference.

l To check UL interference, start a cell interference detection task and analyze the result.


Possible Causes

Scenario Fault Description Possible Causes

The RRC connection fails tobe set up.

l The UE cannot searchcells.

l A fault occurs in radiointerface processing.

l Top user problems occur.

l Parameters of the UE oreNodeB are incorrectlyconfigured.

l The radio environment isabnormal.

l The UE is abnormal.

The E-RAB fails to be set up. l Resources areinsufficient.

l A fault occurs in radiointerface processing.

l The EPC is abnormal.l Top user problems occur.

l Parameters of the UE oreNodeB are incorrectlyconfigured.

l The radio environment isabnormal.

l Parameters of the EvolvedPacket Core (EPC) areincorrectly configured.

l The UE is abnormal.

Troubleshooting FlowchartFigure 4-1 show the troubleshooting flowcharts for handling low RRC connection setup ratesand low E-RAB setup rates, respectively.



18

Figure 4-1 Troubleshooting flowcharts for handling low RRC connection setup rates and lowE-RAB setup rates

Troubleshooting Procedure1. Select topN cells.2. Check whether parameters of the UE or eNodeB are incorrectly configured.

l Yes: Correct the parameter configurations. Go to 3.l No: Go to 4.

3. Check whether the fault is rectified.l Yes: End.l No: Go to 4.

4. Check whether the radio environment is abnormal.l Yes: Handle abnormalities in the radio environment. Go to 5.l No: Go to 6.

5. Check whether the fault is rectified.



19

l Yes: End.

l No: Go to 6.6. Check whether parameters of the EPC are incorrectly configured.

l Yes: Correct the parameter configurations. Go to 7.l No: Go to 8.


l Yes: End.

l No: Go to 8.8. Contact Huawei technical support.

4.4 Troubleshooting Access Faults Due to IncorrectParameter Configurations

This section provides information required to troubleshoot access faults due to incorrectparameter configurations. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

Fault Descriptionl The UE cannot receive broadcast information from the cell.

l The UE cannot receive signals from the cell.

l The UE cannot camp on the cell.

l The end user complains about an access failure, and the value of the performance counterL.RRC.ConnReq.Att is 0.

l An RRC connection is successfully set up for the UE according to standard interface tracingresults, but then the mobility management entity (MME) releases the UE because theauthentication procedure fails.

l The end user complains that the UE can receive signals from the cell but is unable to accessthe cell.

l According to the values of the performance counters on the eNodeB side, the number ofRRC connections that are successfully set up is much greater than the number of E-RABsthat are successfully set up.

l According to the KPIs, the E-RAB setup success rate is relatively low, and among all causevalues, the cause values indicated by L.E-RAB.FailEst.TNL and L.E-RAB.FailEst.RNLcontribute a large proportion.

Background Information

None

Possible Causesl Cell parameters are incorrectly configured. For example, the E-UTRA absolute radio

frequency number (EARFCN), public land mobile network (PLMN) ID, threshold used inthe evaluation of cell camping, pilot strength, and access class.



20

l The UE has special requirements for authentication and encryption.

l Parameters of the subscriber identity module (SIM) card or registration-related parameterson the home subscriber server (HSS) are incorrectly configured.

l The authentication and encryption algorithms are incorrectly configured on the EvolvedPacket Core (EPC).

l The IPPATH or IPRT managed objects (MOs) are incorrectly configured.

Fault Handling Flowchart

Figure 4-2 Fault handling flowchart for access faults due to incorrect parameter configurations



21

Fault Handling Procedure1. Check whether cell parameters are incorrectly configured. Pay special attention to the

following parameter settings as they are often incorrectly configured: the EARFCN, PLMNID, threshold used in the evaluation of cell camping, pilot strength, and access class.Yes: Correct the cell parameter configurations. Go to 2.No: Go to 3.

2. Check whether the fault is rectified.Yes: End.No: Go to 3.

3. Check the type and version of the UE and determine whether the authentication andencryption functions are required.Yes: Enable the authentication and encryption functions. Go to 4.No: Go to 5.


5. Check whether parameters of the SIM card or registration-related parameters on the HSSare incorrectly configured. The parameters of the SIM card include the K value, originatingpoint code (OPC), international mobile subscriber identity (IMSI), and whether this SIMcard is a UMTS SIM (USIM) card.Yes: Correct the parameter configurations. Go to 6.No: Go to 7.


7. Check whether the authentication and encryption algorithms are incorrectly configured onthe EPC. For example, check whether the switches for the algorithms are turned off.Yes: Modify the parameter configuration on the EPC. Go to 8.No: Go to 9.


9. Check whether the IPPATH or IPRT MOs are incorrectly configured.Yes: Correct the MO configurations. Go to 10.No: Go to 11.


11. Check whether the fault can be diagnosed by tracing the access signaling procedure.Yes: Handle the fault. Go to 12.No: Go to 13.



22


Yes: End.

No: Go to 13.13. Contact Huawei technical support.

Typical Casesl Case 1: An E398 UE failed to access the network despite the fact that the authentication

and encryption functions were enabled on the EPC.

Fault DescriptionDuring a site test, an E398 UE failed to access a network where the authentication andencryption functions were enabled on the EPC.

Fault Diagnosis

1. The S1 interface was traced. According to the tracing result shown in Figure 4-3, theaccess attempt was rejected due to no-Sultable-Cells-In-tracking-area(15).

Figure 4-3 S1 tracing result

2. The signaling at the EPC side was traced. According to the tracing result shown inFigure 4-4, the access attempt was rejected by the HSS in the diameter-authorization-rejected(5003) message.

Figure 4-4 Tracing result of the signaling at the EPC side

3. The UE was checked. Specifically, the configuration, registration information, andthe category of the SIM card were checked. Then, the cause of the fault was located,which was that the E398 UE used a SIM card. In response to the access request froma UE using a SIM card, the EPC would reply a diameter-authorization-rejectedmessage. Figure 4-5 shows a snapshot of the related section in 3GPP TS 29.272.



23

Figure 4-5 Related section in the protocol

In conclusion, the E398 UE was unable to access the network because the UE used aSIM card. To access an LTE network, the UE must use a USIM card.

Fault HandlingThe SIM card in the E398 UE was replaced by a USIM card. Then, the authenticationprocedure was successful and the UE successfully accessed the network.

l Case 2: The E-RAB setup success rate at a site deteriorated due to incorrect transportresource configurations.Fault DescriptionAccording to the KPIs for a site, the E-RAB setup success rate deteriorated intermittently.Fault Diagnosis

1. The cause value contained in the S1AP_INITIAL_CONTEXT_SETUP_FAILmessage (that is, the initial context setup request message) was checked and was foundto be transport resource unavailable(0), as shown in Figure 4-6.



24

Figure 4-6 Snapshot of the S1AP_INITIAL_CONTEXT_SETUP_FAIL message

This cause value indicates that the E-RAB failed to be set up due to faults related totransport resources, rather than faults related to radio resources.

2. The IP address contained in the S1AP_INITIAL_CONTEXT_SETUP_REQ messagewas checked and was found to be 8A:14:05:14. However, this IP address (8A:14:05:14) was different from the peer IP address (8A 14 05 13) specified in theIPPATH MO. Figure 4-7 shows the details of theS1AP_INITIAL_CONTEXT_SETUP_REQ message.

Figure 4-7 Snapshot of the S1AP_INITIAL_CONTEXT_SETUP_REQ message

3. This inconsistency was investigated. As the EPC maintenance personnel confirmed,multiple logical IP addresses were configured on the interface of the unified gateway(UGW), but only one IPPATH MO was configured on the eNodeB. As a result, theE-RAB failed to be set up.



25

Fault Handling

New IPPATH MOs were configured on the eNodeB based on the network plan. Then, theE-RAB setup success rate was observed for a while, during which the E-RAB setup successrate was normal all along.

4.5 Troubleshooting Access Faults Due to RadioEnvironment Abnormalities

This section provides information required to troubleshoot access faults due to radio environmentabnormalities. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

Fault Descriptionl During a random access procedure, the UE cannot receive any random access responses.

l During an RRC connection setup process, the eNodeB has not received any RRCconnection setup complete messages within the related timeout duration.

l During an E-RAB setup process, the response in security mode times out.

l The eNodeB has not received any RRC connection reconfiguration complete messageswithin the related timeout duration.

l At the eNodeB side, both the RRC connection setup success rate and the E-RAB setupsuccess rate are low.


Radio environment abnormalities include radio interference, imbalance between the uplink (UL)and downlink (DL) quality, weak coverage, and eNodeB hardware faults (such as distinctantenna configurations). The items to be investigated as well as the methods of investigatingthese items are described as follows:

l Investigating radio interference

DL interference from neighboring cells, DL interference from external systems, and ULinterference need to be investigated. To investigate the DL interference, use a spectralscanner. To investigate the UL interference, start a cell interference detection task.

l Investigating weak coverage

The reference signal received power (RSRP) values reported by UEs during their accessneed to be investigated. If most of these values are relatively low, it is highly probable thatthe access difficulties lie in the weak coverage provided by the cell.

The actual radius of cell coverage as well as the signal quality variation need to beinvestigated so that users can determine whether wide coverage or cross-cell coverageoccurs.

l Investigating the imbalance between UL and DL quality

The transmit power of the remote radio unit (RRU) and UE need to be investigated to checkwhether UL or DL limitations have occurred, because imbalance between UL and DLquality is caused by UL limitations or DL limitations.

The UL and DL radii of cell coverage need to be investigated using drive tests.



26

l Investigating eNodeB hardwareIf two antennas are used, the tilt and azimuth of each antenna need to be investigated. Iftheir tilts or azimuths are significantly different from each other, adjust them so that theirtilts and azimuths are the same.The jumper connection needs to be investigated by analyzing drive test results. If the jumperis reversely connected, the UL signal level will be much lower than the DL signal level inthe cell, in which case UEs remote from the eNodeB will easily encounter access failures.Therefore, if the jumper is reversely connected, rectify the jumper connection.The physical conditions of feeders need to be investigated. If a feeder is damaged, waterimmersed, bending, or not securely connected, a large number of call drops will occur. Ifa voltage standing wave ratio (VSWR) alarm is reported, such problems exist and you needto replace the faulty feeder.

Figure 4-8 and Figure 4-9 show common causes of random access failures and E-RAB setupfailures, respectively.

Figure 4-8 Common causes of random access failures

Figure 4-9 Common causes of E-RAB setup failures



27

Possible Causesl The cell provides weak coverage.

l The UE does not use the maximum transmit power.

l Inter-modulation interference exists.

l The UE is located at cell edge.

Fault Diagnosis

To effectively diagnose access faults due to radio environment abnormalities, you are advisedto firstly find out whether this fault is caused by radio interference or weak coverage. Thefollowing procedure is recommended:

Fault Handling Procedure1. Check whether related alarms are reported.

Yes: Handle these alarms by referring to eNodeB Alarm Reference. Go to 2.No: Go to 3.


Yes: End.

No: Go to 3.3. Check whether interference exists. By using a spectral scanner, check whether there is DL

interference from neighboring cells or external systems. By analyzing the cell interferencedetection result, check whether there is UL interference.

Yes: Minimize the interference. Go to 4.No: Go to 5.


Yes: End.

No: Go to 5.5. Check whether the transmit power of the RRU and UE falls beyond link budgets.

Yes: Adjust the UL and DL transmit power. Go to 6.No: Go to 7.


Yes: End.

No: Go to 7.7. Check whether cell coverage is abnormal.

Yes: Based on the RSRP distribution of the UEs attempting to access the cell, investigateand handle possible coverage, interference, and imbalance between UL and DL quality byusing drive tests. Go to 8.No: Go to 9.


Yes: End.

No: Go to 9.



28

9. Contact Huawei technical support.

Typical CasesFault Description

According to the KPIs for an eNodeB at a site, the RRC connection setup success rate fluctuatedsignificantly within a period.

Fault Diagnosis

1. The KPIs were checked. For local cell 1, the daily RRC connection success rate was only52%.

Figure 4-10 PRS KPI about RRC connection setups

2. The signaling over the Uu interface was traced. The result indicated that all RRC connectionsetup failures occurred because UEs do not respond. The following figure shows a snapshotof the signaling traced over the Uu interface.

Figure 4-11 Signaling traced over the Uu interface

3. Simulated load was added to the LTE side. The impact of the DL LTE signals on the DLGSM signals was tested, during which the call drop rate at the GSM side raised significantly.As a result, it was highly probable that inter-modulation interference existed.

4. Online spectral scan was applied to the LTE side. Interference with a magnitude of 10 dBwas found within the high-frequency resource blocks (RBs), which affected signalingtransmission.



29

Figure 4-12 Online precise spectral scan result

5. The site was investigated and the cause of the fault was located. The LTE and GSM sidesshared the same antennas. The antennas aged and induced inter-modulation interference.

Fault Handling

The antennas were replaced. Then, the access success rate was restored.



30

5 Troubleshooting Intra-RAT HandoverFaults

About This Chapter

This chapter describes how to diagnose and handle intra-RAT handover faults. RAT is short forradio access technology.

5.1 Definitions of Intra-RAT Handover FaultsIf an intra-RAT handover fault occurs, UEs have difficulty performing intra-RAT handoversdue to system faults.

5.2 Background InformationThis section describes counters and alarms related to intra-RAT handover faults. In addition,this section provides intra-RAT handover procedures.


5.4 Troubleshooting Intra-RAT Handover Faults Due to Hardware FaultsThis section provides information required to troubleshoot intra-RAT handover faults due tohardware faults. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

5.5 Troubleshooting Intra-RAT Handover Faults Due to Incorrect Data ConfigurationsThis section provides information required to troubleshoot intra-RAT handover faults due toincorrect data configurations. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

5.6 Troubleshooting Intra-RAT Handover Faults Due to Target Cell CongestionThis section provides information required to troubleshoot intra-RAT handover faults due totarget cell congestion. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

5.7 Troubleshooting Intra-RAT Handover Faults Due to Poor Uu Quality

eRAN3.0Troubleshooting Guide 5 Troubleshooting Intra-RAT Handover Faults


31

This section provides information required to troubleshoot intra-RAT handover faults due topoor Uu quality. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.



32

5.1 Definitions of Intra-RAT Handover FaultsIf an intra-RAT handover fault occurs, UEs have difficulty performing intra-RAT handoversdue to system faults.

5.2 Background InformationThis section describes counters and alarms related to intra-RAT handover faults. In addition,this section provides intra-RAT handover procedures.

Related Countersl Outgoing Handover Measurement (Cell)(HO.eRAN.Out.Cell)l Incoming Handover Measurement (Cell)(HO.eRAN.In.Cell)

For details, see eNodeB Performance Counter Reference.

Related Alarmsl Board overload alarm

ALM-26202 Board Overloadl Alarms related to RF modules

ALM-26529 RF Unit VSWR Threshold Crossed

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalancedl Cell capability degraded alarm

ALM-29243 Cell Capability Degradedl Alarms related to CPRI links

ALM-26235 RF Unit Maintenance Link Failure



ALM-26506 RF Unit Optical Interface Performance Degradedl Alarms related to clock sources

ALM-26263 IP Clock Link Failure

ALM-26264 System Clock Unlocked

ALM-26538 RF Unit Clock Problem

ALM-26260 System Clock Failure

ALM-26265 Base Station Frame Number Synchronization Error

Handover Procedures

Handovers are classified as coverage-based, load-based, frequency-priority-based, service-based, and UL-quality-based. For details, see eRAN Mobility Management in Connected ModeFeature Parameter Description.



33


Possible Causes

There are various causes of handover faults, such as incorrect data configuration, hardware faults,interference, and poor Uu quality. Therefore, to effectively diagnose a handover fault, you needto carry out a pertinent analysis based on the actual situation.

Table 5-1 shows possible causes of handover faults.

Table 5-1 Possible causes of handover faults

Scenario Fault Description Possible Causes

The whole networkexperiences abnormalities.

l The performancecounters throughout thewhole network areabnormal.

l Related alarms arereported.

l Network parameters areincorrectly configured.

l The signaling exchangeprocedure is incorrect.

A single eNodeB experiencesabnormalities.

l The performancecounters for the servingcell are abnormal.

l Related alarms arereported.

l Handovers toneighboring cells areseldom initiated.

l Handovers toneighboring cells arefrequently initiated.

l The UE cannot receivehandover commandsfrom the network.

l Hardware is faulty.l Parameters are set to

inappropriate values.l The target cell is

congested.l The Uu quality is poor.

Fault Analysis

The following measures are effective in locating a handover fault:

l Analyzing handover-related performance counters

l Investigating TopN cells

l Checking alarms related to devices or data transmission

l Checking the configurations of neighboring cells



34

l Checking handover algorithm configurations

l Investigating interference and cell coverage

To locate an intra-RAT handover fault, you are advised to select TopN cells with handover faultsand then follow the troubleshooting procedure shown in Figure 5-1.

Figure 5-1 Troubleshooting flowchart for intra-RAT handover faults

Troubleshooting Procedure1. Check whether the hardware is faulty.

Hardware faults are the most likely cause if handovers suddenly become abnormal withoutrecent modifications to the configurations of the abnormal cell and its neighboring cells.

Yes: Hardware faults are often accompanied by alarms. You are advised to handle the faultby following the instructions on how to troubleshoot handover faults due to hardware faults.Go to 2.

No: Go to 3.



35


3. Check whether handover parameters are incorrectly configured.Specifically, check whether handover thresholds and neighboring cell configurations areincorrect.Yes: Follow the instructions on how to troubleshoot handover faults due to incorrect dataconfigurations. Go to 4.No: Go to 5.


5. Check whether the service channel of the target cell is severely congested.Check the service satisfaction rates to determine whether the service channel of the targetcell is severely congested.Yes: Follow the instructions on how to troubleshoot handover faults due to target cellcongestion. Go to 6.No: Go to 7.


7. Check whether the Uu quality is poor.Poor Uu quality will cause abnormal signaling exchanges, leading to handover failures.Yes: Follow the instructions on how to troubleshoot handover faults due to poor Uu quality.Go to 8.No: Go to 9.



5.4 Troubleshooting Intra-RAT Handover Faults Due toHardware Faults

This section provides information required to troubleshoot intra-RAT handover faults due tohardware faults. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

Fault DescriptionTypical hardware faults include faulty or overloaded boards, as well as abnormal radio frequency(RF) module or clock sources. If a hardware fault occurs, the cell will degrade in capability oreven become out of service, in addition to the following symptoms:



36

l Abnormal cell-level performance counters

Increased service drop rate

Decreased handover success rate

Decreased access success rate

l Related alarms


Related Alarms

l Board overload alarm

ALM-26202 Board Overload

l Alarms related to RF modules

ALM-26529 RF Unit VSWR Threshold Crossed

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

l Cell capability degraded alarm

ALM-29243 Cell Capability Degraded

l Alarms related to CPRI links

ALM-26235 RF Unit Maintenance Link Failure



ALM-26506 RF Unit Optical Interface Performance Degraded

l Alarms related to clock sources

ALM-26263 IP Clock Link Failure

ALM-26264 System Clock Unlocked

ALM-26538 RF Unit Clock Problem

ALM-26260 System Clock Failure

ALM-26265 Base Station Frame Number Synchronization Error

Possible Causes

Possible hardware faults that will cause handover faults are listed as follows:

l A board is overloaded.

l An RF module is faulty.

l A common public radio interface (CPRI) link is faulty.

l A clock source is faulty.


Figure 5-2 shows the fault handling flowchart for intra-RAT handover faults due to hardwarefaults.



37

Figure 5-2 Fault handling flowchart for intra-RAT handover faults due to hardware faults

Fault Handling Procedure1. Check whether a hardware fault alarm is reported.

Yes: Handle the hardware fault alarm. Go to 2.

No: Go to 3.


Yes: End.

No: Go to 3.


Typical Cases

Fault Description

Handovers between cell 0 and cell 2 under an eNodeB were normal with a high success rate, butthe handovers from cell 1 under the eNodeB to its neighboring cells were abnormal with arelatively low success rate (7%) during busy hours.

Fault Diagnosis

1. Alarms about the eNodeB were checked. Cell 1 had reported ALM-26529 RF Unit VSWRThreshold Crossed.

2. As engineers of the customer confirmed, the eNodeB had been reconstructed recently.Therefore, it was highly probable that the RF connections became abnormal during the sitereconstruction.

3. At the site, it was found that the jumper was not securely connected to the feeder, whichhad caused the cell malfunction.

Fault Handling

The jumper was securely connected to the feeder. According to the KPI log, the inter-cellhandover success rate was restored.



38

5.5 Troubleshooting Intra-RAT Handover Faults Due toIncorrect Data Configurations

This section provides information required to troubleshoot intra-RAT handover faults due toincorrect data configurations. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

Fault Descriptionl Handovers to neighboring cells are seldom initiated.

According to drive test results or signaling tracing results, the UE experiences relativelylow signal quality in its serving cell. The signal level of neighboring cells meets thethreshold for a handover, but handovers occur with a low probability This leads to a highservice drop rate.

l Handovers to neighboring cells are frequently initiated.The signal level and quality of neighboring cells are almost the same as those of the servingcell, but handovers to the neighboring cells are frequently initiated. This leads to poorquality of voice services and a high probability of service drops.


None

Possible Causesl Configurations of neighboring cells are incorrect.

If neighboring cells are not configured or incorrectly configured, handovers cannot betriggered even after the UE reports measurements of these neighboring cells.

l The X2 link is incorrectly configured.If an X2 interface is incorrectly configured, handovers to some neighboring cells cannotbe successfully executed. For example, if the IP path for an X2 interface is incorrectlyconfigured, X2-based inter-eNodeB handovers cannot be executed; or, if the IP path fromthe target eNodeB to the source serving gateway (S-GW) is not configured, X2-based inter-S-GW handovers cannot be executed.

l Parameters such as handover thresholds, hysteresis, and time-to-trigger are inappropriatelyconfigured.In the preceding handover scenario, a handover is triggered only when the signal level ofa neighboring cell is higher than that of the serving cell by at least a certain amount. As aresult, if handover parameters (such as the threshold, cell individual offsets [CIOs],hysteresis, and time-to-trigger) are inappropriately set, the probability of triggeringhandovers is either significantly low or significantly high.


Figure 5-3 shows the fault handling flowchart for intra-RAT handover faults due to incorrectdata configurations.



39

Figure 5-3 Fault handling flowchart for intra-RAT handover faults due to incorrect dataconfigurations

Fault Handling Procedure1. Check whether the X2 link is incorrectly configured.

Yes: Correct the X2 link configuration. Go to 2.No: Go to 3.


Yes: End.

No: Go to 3.3. Check whether there are missing configurations of neighboring cells.

Yes: Complete neighboring cell configurations. Go to 4.No: Go to 5.


Yes: End.

No: Go to 5.5. Check whether handover parameters are incorrectly configured.

Yes: Correct their configurations.

No: Go to 7.6. Check whether the fault is rectified.

Yes: End.



40

No: Go to 7.7. Contact Huawei technical support.

Typical Cases

Fault Description

During a drive test, a UE did not receive any handover commands after sending A3 measurementreports to the eNodeB. Ultimately, the service is dropped.

Fault Diagnosis

1. According to Huawei maintenance personnel, these A3 measurement reports weresuccessfully received by the source eNodeB. Later, the source eNodeB sent a HandoverRequest message through the X2 interface to the target eNodeB, but the target eNodeBresponded with a Handover Failure message containing a cause value indicatingunavailable transport resources.

2. The signaling over the X2 interface was traced and was found to be normal.

3. The configuration of the IPPATH MO for the X2 interface was checked and aninconsistency was found. The adjacent node ID specified in the IPPATH MO was differentfrom the X2 interface ID, which caused a resource request failure and ultimately a handoverfailure.

Fault Handling

The configuration of the IPPATH MO was corrected. Then, the test was conducted again andthe UE was successfully handed over to the target cell.

5.6 Troubleshooting Intra-RAT Handover Faults Due toTarget Cell Congestion

This section provides information required to troubleshoot intra-RAT handover faults due totarget cell congestion. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

Fault Description

The service satisfaction rate in the target cell is lower than the admission threshold for handed-over services, due to which the target eNodeB rejects the requests of handovers to the target cell.The service satisfaction rate in a cell can be viewed on the M2000.


None

Possible Causesl UEs in the target cell surge due to assemblies or activities.

l A large number of UEs have been handed over to the target cell due to inappropriateparameter configurations.



41

Documents

RF Troubleshooting Guide Radio