eran troubleshooting guide(v100r005c00_02)(pdf)-en

eRANV100R005C00

Troubleshooting Guide

Issue 02

Date 2012-07-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2012. 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 02 (2012-07-30) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[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

eRANTroubleshooting Guide About This Document


ii

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

Organization1 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.

12 Troubleshooting Transmission Synchronization Faults



iii

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.

ConventionsSymbol Conventions

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

Symbol Description

Indicates a hazard with a high level of risk, which if notavoided, will result in death or serious injury.

Indicates a hazard with a medium or low level of risk, whichif not avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation, which if notavoided, could result in equipment damage, data loss,performance degradation, or unexpected results.

Indicates a tip that may help you solve a problem or savetime.

Provides additional information to emphasize or supplementimportant points of the main text.

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.



iv


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.

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.



v

Format Description

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.....................................................................................22.1 General Troubleshooting Process.......................................................................................................................32.2 General Troubleshooting Steps..........................................................................................................................4

2.2.1 Backing Up Data.......................................................................................................................................42.2.2 Collecting Fault Information.....................................................................................................................42.2.3 Determining the Fault Scope and Type.....................................................................................................62.2.4 Identifying Fault Causes............................................................................................................................82.2.5 Rectifying the Fault...................................................................................................................................82.2.6 Checking Whether Faults Have Been Rectified........................................................................................82.2.7 Contacting Huawei Technical Support......................................................................................................9

3 Common Maintenance Functions............................................................................................113.1 User Tracing.....................................................................................................................................................123.2 Interface Tracing...............................................................................................................................................123.3 Comparison/Interchange...................................................................................................................................123.4 Switchover/Reset..............................................................................................................................................12

4 Troubleshooting Access Faults.................................................................................................144.1 Definitions of Access Faults.............................................................................................................................154.2 Background Information...................................................................................................................................154.3 Troubleshooting Method..................................................................................................................................174.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......................................................................................................325.2 Background Information...................................................................................................................................325.3 Troubleshooting Method..................................................................................................................................335.4 Troubleshooting Intra-RAT Handover Faults Due to Hardware Faults...........................................................355.5 Troubleshooting Intra-RAT Handover Faults Due to Incorrect Data Configurations......................................385.6 Troubleshooting Intra-RAT Handover Faults Due to Target Cell Congestion................................................405.7 Troubleshooting Intra-RAT Handover Faults Due to Poor Uu Quality...........................................................42

eRANTroubleshooting Guide Contents


vii

6 Troubleshooting Service Drops................................................................................................456.1 Definitions of Service Drops............................................................................................................................476.2 Background Information...................................................................................................................................476.3 Troubleshooting Method..................................................................................................................................486.4 Troubleshooting Service Drops Due to Radio Faults.......................................................................................516.5 Troubleshooting Service Drops Due to Transmission Faults...........................................................................526.6 Troubleshooting Service Drops Due to Congestion.........................................................................................536.7 Troubleshooting Service Drops Due to Handover Failures..............................................................................546.8 Troubleshooting Service Drops Due to MME Faults.......................................................................................55

7 Troubleshooting Inter-RAT Handover Faults.......................................................................577.1 Definitions of Inter-RAT Handover Faults......................................................................................................587.2 Background Information...................................................................................................................................587.3 Troubleshooting Inter-RAT Handovers............................................................................................................58

8 Troubleshooting Rate Faults.....................................................................................................648.1 Definitions of Rate Faults.................................................................................................................................658.2 Background Information...................................................................................................................................658.3 Troubleshooting Abnormal Single-UE Rates...................................................................................................688.4 Troubleshooting Abnormal Multi-UE Rates....................................................................................................74

9 Troubleshooting Cell Unavailability Faults..........................................................................769.1 Definitions of Cell Unavailability Faults..........................................................................................................779.2 Background Information...................................................................................................................................779.3 Troubleshooting Method..................................................................................................................................789.4 Troubleshooting Cell Unavailability Faults Due to Incorrect Data Configuration..........................................809.5 Troubleshooting Cell Unavailability Faults Due to Abnormal Transport Resources.......................................829.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF Resources.................................................839.7 Troubleshooting Cell Unavailability Faults Due to Limited Capacity or Capability.......................................869.8 Troubleshooting Cell Unavailability Faults Due to Faulty Hardware..............................................................87

10 Troubleshooting IP Transmission Faults.............................................................................8910.1 Definitions of IP Transmission Faults............................................................................................................9010.2 Background Information.................................................................................................................................9010.3 Troubleshooting Method................................................................................................................................9010.4 Troubleshooting IP Physical Layer Faults......................................................................................................9110.5 Troubleshooting IP Link Layer Faults............................................................................................................9410.6 Troubleshooting IP Layer Faults....................................................................................................................96

11 Troubleshooting Application Layer Faults..........................................................................9711.1 Definitions of Application Layer Faults.........................................................................................................9811.2 Background Information.................................................................................................................................9811.3 Troubleshooting Method................................................................................................................................9811.4 Troubleshooting SCTP Link Faults..............................................................................................................10011.5 Troubleshooting IP Path Faults....................................................................................................................103



viii

11.6 Troubleshooting OM Channel Faults...........................................................................................................103

12 Troubleshooting Transmission Synchronization Faults.................................................10612.1 Definitions of Transmission Synchronization Faults...................................................................................10712.2 Background Information...............................................................................................................................10712.3 Troubleshooting Specific Transmission Synchronization Faults.................................................................107

13 Troubleshooting Transmission Security Faults................................................................ 11113.1 Definitions of Transmission Security Faults................................................................................................11213.2 Background Information...............................................................................................................................11213.3 Troubleshooting Specific Transmission Security Faults..............................................................................113

14 Troubleshooting RF Unit Faults...........................................................................................12014.1 Definitions of RF Unit Faults.......................................................................................................................12114.2 Background Information...............................................................................................................................12114.3 Troubleshooting Method..............................................................................................................................12614.4 Troubleshooting VSWR Faults....................................................................................................................12714.5 Troubleshooting RTWP Faults.....................................................................................................................12914.6 Troubleshooting ALD Link Faults...............................................................................................................135

15 Troubleshooting License Faults............................................................................................13715.1 Definitions of License Faults........................................................................................................................13815.2 Background Information...............................................................................................................................13815.3 Troubleshooting Method..............................................................................................................................13815.4 Troubleshooting License Faults That Occur During License Installation....................................................13915.5 Troubleshooting License Faults That Occur During Network Running......................................................14215.6 Troubleshooting License Faults That Occur During Network Adjustment..................................................144



ix

1 Changes in eRAN Troubleshooting Guide

This chapter describes the changes in eRAN Troubleshooting Guide.

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.

Compared with issue 01 (2012-06-29), this issue includes the following changes.

Topic Change Description

Whole document Updated descriptions.

No information in issue 01 (2012-06-29) is deleted from this issue.

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.

Topic Change Description

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.

eRANTroubleshooting Guide 1 Changes in eRAN Troubleshooting Guide


1

2 Troubleshooting Process and Methods

About 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.

eRANTroubleshooting Guide 2 Troubleshooting Process and Methods


2

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.



3

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



4

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 resultsl Alarms and correlated alarms when the fault occursl 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 reflected inuser complaints, fault notifications from other offices, exceptionsdetected in maintenance, and the information collected bymaintenance personnel through different channels in the earlyperiod when the fault is found. Original information is importantfor fault locating and analysis.

Function

Original information is used to determine the fault scope and faultcategory. Original information helps narrow the fault scope andlocate the faults in the initial stage of troubleshooting. Originalinformation can also help troubleshoot other faults, especiallytrunk faults.

Reference

None



5

Type Attribute

Description

Alarminformation

Definition

Alarm information is the output of the eNodeB alarm system. Itrelates to the hardware, links, trunk, and CPU load of the eNodeB,and includes the description of faults or exceptions, fault causes,and handling suggestions. Alarm information is a key element forfault locating and analysis.

Function

Alarm information is specific and complete; therefore, it is directlyused to locate the faulty component or find the fault cause. Inaddition, alarm information can also be used with other methodsto locate a fault.

Reference

For details about how to use the alarm system, see M2000 OnlineHelp. For detailed information about each alarm, see eNodeBAlarm Reference.

Indicatorstatus

Definition

Board indicators indicate the running status of boards, circuits,links, optical channels, and nodes. Indicator status information isalso a key element for fault locating and analysis.

Function

By analyzing indicator status, you can roughly locate faultycomponents or fault causes that facilitate subsequent operations.Generally, indicator status information is combined with alarminformation for locating faults.

Reference

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

Performancecounter

Definition

Performance counters are statistics about service performance,such as statistics about service drops and handovers. They helpfind out causes of service faults so that measures can be taken ina timely manner to prevent such faults.

Function

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

Reference

For details about the usage of performance counters, see M2000Online Help. For the definitions of each performance counter, seeeNodeB 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.



6

Service FaultsService 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 FaultsEquipment 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.– The received total wideband power (RTWP) on the RX channel is abnormal.



7

– 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 FaultsLocating 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 FaultsThe 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 similar

faults from occurring in the future.

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.



8

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 Information

General 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 Information

When 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.

Contacting Huawei Technical Support

The following lists the contact information of Huawei technical support:

l If you are in mainland China, dial 4008302118.



9

l If you are outside mainland China, contact the technical support personnel in the localHuawei office.

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



10

mailto:[email protected]

http://support.huawei.com

3 Common Maintenance Functions

About 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.

eRANTroubleshooting Guide 3 Common Maintenance Functions


11

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-timel Able to trace the user over all standard interfacesl Usable when traffic is heavyl 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-timel 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.

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 identify



12

whether 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.



13

4 Troubleshooting Access Faults

About 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.

eRANTroubleshooting Guide 4 Troubleshooting Access Faults


14

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– ALM-25880 Ethernet Link Fault



15

– 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 Networkl 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 Unbalancedl 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.

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.



16

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 CausesScenario Fault Description Possible Causes

The RRC connection fails tobe set up.

l The UE cannot searchcells.

l Authentication fails.l A fault occurs in radio

interface processing.

l Parameters of the UE oreNodeB are incorrectlyconfigured.

l The radio environment isabnormal.

l Parameters of theEvolved Packet Core(EPC) are incorrectlyconfigured.

l The UE is abnormal.

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

l Parameters of the UE oreNodeB are incorrectlyconfigured.

l The radio environment isabnormal.

l Parameters of theEvolved Packet Core(EPC) are incorrectlyconfigured.

l The UE is abnormal.

Troubleshooting FlowchartFigure 4-1 and Figure 4-2 show the troubleshooting flowcharts for handling low RRCconnection setup rates and low E-RAB setup rates, respectively.



17

Figure 4-1 Troubleshooting flowchart for low RRC connection setup success rates



18

Figure 4-2 Troubleshooting flowchart for low E-RAB setup success 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.l Yes: End.



19

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.

7. Check whether the fault is rectified.

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.

l The UE has special requirements for authentication and encryption.



20

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-3 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.


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 Description

During 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-4, theaccess attempt was rejected due to no-Sultable-Cells-In-tracking-area(15).

Figure 4-4 S1 tracing result

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

Figure 4-5 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-6 shows a snapshot of the related section in 3GPP TS 29.272.



23

Figure 4-6 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-7.



24

Figure 4-7 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-8 shows the details of theS1AP_INITIAL_CONTEXT_SETUP_REQ message.

Figure 4-8 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.

Fault Handling



25

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 RRC

connection 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 messages

within the related timeout duration.l At the eNodeB side, both the RRC connection setup success rate and the E-RAB setup

success rate are low.

Background InformationRadio 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 interferenceDL 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 coverageThe 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 qualityThe 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.

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.



26

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-9 and Figure 4-10 show common causes of random access failures and E-RAB setupfailures, respectively.

Figure 4-9 Common causes of random access failures

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

Possible Causesl The cell provides weak coverage.l The UE does not use the maximum transmit power.



27

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.


3. Check whether interference exists. By using a spectral scanner, check whether there is DLinterference 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.


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.


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.



Typical Cases

Fault Description



28

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-11 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-12 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-13 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 QualityThis 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.

eRANTroubleshooting Guide 5 Troubleshooting Intra-RAT Handover Faults


31

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)


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-26234 BBU CPRI Interface Error

– ALM-26233 BBU CPRI Optical Interface Performance Degraded

– 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.



32


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 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 countersl Investigating TopN cellsl Checking alarms related to devices or data transmissionl Checking the configurations of neighboring cellsl Checking handover algorithm configurations



33

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.

2. Check whether the fault is rectified.Yes: End.



34

No: Go to 3.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:

l Abnormal cell-level performance counters– Increased service drop rate



35

– Decreased handover success rate– Decreased access success rate

l Related alarms

Background InformationRelated 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-26234 BBU CPRI Interface Error– ALM-26233 BBU CPRI Optical Interface Performance Degraded– 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 CausesPossible 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.

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



36

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.



37

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 terrestrial link (X2 interface) 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.



38

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

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

Yes: Correct the terrestrial link configuration. Go to 2.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.


5. Check whether handover parameters are incorrectly configured.Yes: Correct their configurations.No: Go to 7.




39


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.



40


Figure 5-4 shows the fault handling flowchart for intra-RAT handover faults due to target cellcongestion.

Figure 5-4 Fault handling flowchart for intra-RAT handover faults due to target cell congestion

Fault Handling Procedure1. Check whether the handover fails due to target cell congestion.

Yes: Expand the capacity of the target cell or tune the network optimization parameters ofthe target cell. Go to 2.

No: Go to 3.


Yes: End.

No: Go to 3.


Typical Cases

Fault Description

During a period, all handovers to a cell failed.

Fault Diagnosis

1. The cell coverage was checked. No coverage hole was found.

2. The RF module serving the cell was checked. No fault was found.

3. As signaling tracing for a single UE indicated, the service satisfaction rate in the cell wasalways low (lower than the admission thresholds for handed-over services with QCIsranging from 1 to 4) when a handover failure message appeared. Therefore, these handoversfailed because the traffic channel was so congested in the cell that there were no resourcesavailable for new handed-over services.

Fault Handling



41

Engineers of the customer were advised to expand the cell capacity or reduce UEs in the cell bymodifying handover parameter configurations. After the correspond measure was taken, thesuccess rate of handovers to the cell became normal.

5.7 Troubleshooting Intra-RAT Handover Faults Due toPoor Uu Quality

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.

Fault DescriptionTwo symptoms may occur when the Uu quality is poor. One is that the UE cannot receive anyhandover commands from the eNodeB, the other is that the UE cannot access the target cell andcannot report the handover complete message.

Background InformationChecking interference

1. Start a cell interference detection task and check the performance counter indicating theuplink (UL) signal quality. If high UL modulation and coding scheme (MCS) orders seldomappear, it is highly probable that interference to the cell exists.

2. Start the UE spectral scanning function and further determine whether the interferenceoriginates from neighboring cells or external systems.

Checking cell coverage

l Check for weak coverage.If the reference signal received power (RSRP) values reported by UEs during handoversare mostly lower than -115 dB, weak-coverage areas exist in the cell.

l Check for wide coverage and cross-cell coverage.Wide coverage and over-coverage can be checked by analyzing the actual radius of cellcoverage and signal quality variation in the cell.

Checking imbalance between UL and DL quality

Imbalance between UL and DL quality is classified into two situations: lower UL quality andlower DL quality.

l Check whether the transmit power of the RRU and UE falls within link budgets.l Check the actual UL and DL coverage by using drive tests.

Checking the antenna system

l Check whether the jumper is reversely connected to the feeder.Analyze the drive test data. If the UL signal level is different from the DL signal level inthe cell and UEs at cell edge easily encounter handover failures, the jumper is reverselyconnected to the feeder and needs to be corrected.

l Check whether the feeder is in poor physical condition.If a feeder is damaged, water immersed, bending, or not securely connected, the transmitpower and receive sensitivity are decreased and severe service drops occur. In this case,



42

the feeder needs to be replaced. For details, see ALM-26529 RF Unit VSWR ThresholdCrossed.

Replace faulty feeders promptly.

l Check whether the tilts and azimuths of two antennas are the same.

Possible Causes

The following Uu problems may cause handover faults:

l Interference

l Unsatisfactory coverage

l Imbalance between UL and DL quality

l Antenna system faults


To effectively diagnose handover faults due to poor Uu quality, you are advised to firstly findout whether this fault is caused by interference or unsatisfactory coverage. Figure 5-5 showsthe fault handling flowchart for intra-RAT handover faults due to poor Uu quality.

Figure 5-5 Fault Handling flowchart for intra-RAT handover faults due to poor Uu quality



43

Fault Handling Procedure1. Check whether interference exists. By using a UE spectral scanner, check whether there is

DL interference from neighboring cells or external systems. By analyzing the cellinterference detection result, check whether there is UL interference.Yes: Remove the interference. Go to 2.No: Go to 3.


3. Check whether cell coverage is abnormal.Yes: Improve cell coverage. Go to 4.No: Go to 5.


5. Check whether there is imbalance between UL and DL quality. Specifically, check whetherthe transmit power of the RRU and UE falls beyond link budgets.Yes: Remove the imbalance between UL and DL quality. Go to 6.No: Go to 7.


7. Check whether there is a fault in the antenna system.Yes: Adjust the antenna system. Go to 8.No: Go to 9.



Typical CasesNone



44

6 Troubleshooting Service Drops

About This Chapter

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.

6.1 Definitions of Service DropsThe service drop rate is an important key performance indicator (KPI) for radio networks. Itindicates the ratio of the number of dropped services to the total number of services. A highservice drop rate cannot meet user requirements.

6.2 Background InformationThis section provides background information for service drops. The background informationincludes the formula used to calculate the service drop rate, counters and alarms related to servicedrops, and drive tests and TopN cell analysis method for troubleshooting service drops.


6.4 Troubleshooting Service Drops Due to Radio FaultsThis section provides information required to troubleshoot service drops due to radio faults. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

6.5 Troubleshooting Service Drops Due to Transmission FaultsThis section provides information required to troubleshoot service drops due to transmissionfaults. The information includes fault descriptions, background information, possible causes,fault handling method and procedure, and typical cases.

6.6 Troubleshooting Service Drops Due to CongestionThis section provides information required to troubleshoot service drops due to congestion. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

6.7 Troubleshooting Service Drops Due to Handover FailuresThis section provides information required to troubleshoot service drops due to handover faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.

eRANTroubleshooting Guide 6 Troubleshooting Service Drops


45

6.8 Troubleshooting Service Drops Due to MME FaultsThis section provides information required to troubleshoot service drops due to MME faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.



46

6.1 Definitions of Service DropsThe service drop rate is an important key performance indicator (KPI) for radio networks. Itindicates the ratio of the number of dropped services to the total number of services. A highservice drop rate cannot meet user requirements.

A service drop is counted each time the eNodeB sends an E-RAB RELEASE INDICATION orUE CONTEXT RELEASE COMMAND message to the MME with a release cause other thanNormal Release, Detach, User Inactivity, cs fallback triggered, and Inter-RATredirection after an E-UTRAN radio access bearer (E-RAB) has been successfully set up for aUE.

6.2 Background InformationThis section provides background information for service drops. The background informationincludes the formula used to calculate the service drop rate, counters and alarms related to servicedrops, and drive tests and TopN cell analysis method for troubleshooting service drops.

An E-UTRAN radio access bearer (E-RAB) is a bearer on the access stratum (AS) for carryingservice data of UEs. An E-RAB release is a process of releasing the bearer resources for UEs,and it represents the capability of a cell to release bearer resources for UEs. One E-RAB releaseis counted once.

Related Counters

E-RAB Release Measurement (Cell) (E-RAB.Rel.Cell)

Counters related to service drops are classified as follows:

l Release types

– Normal releases

– Abnormal releases

– Normal releases for outgoing handovers

– Abnormal releases for outgoing handovers

l QoS class identifier (QCI)

– QCIs of 1 to 9

l Abnormal release causes

– Radio faults (L.E-RAB.AbnormRel.Radio)

If the percentage of abnormal E-RAB releases due to radio faults to all abnormal E-RAB releases is greater than 30%, you need to check whether the network planningsuch as the physical cell identifier (PCI) and neighboring cell planning is proper.

– Transmission faults (L.E-RAB.AbnormRel.TNL)

If the percentage of abnormal E-RAB releases due to transmission faults to all abnormalE-RAB releases is greater than 30%, you need to check whether the transmission linksover the S1/X2 interface experience exceptions such as intermittent disconnections.

– Congestion (L.E-RAB.AbnormRel.Cong)



47

If the percentage of abnormal E-RAB releases due to congestion to all abnormal E-RABreleases is greater than 30%, you need to check whether congestion occurs in the cell.

– Handover failures (L.E-RAB.AbnormRel.HOFailure)If the percentage of abnormal E-RAB releases due to handover failures to all abnormalE-RAB releases is greater than 30%, you need to check whether parameters are properlyset for the neighboring cells.

– MME faults (L.E-RAB.AbnormRel.MME)If the percentage of abnormal E-RAB releases due to mobility management entity(MME) faults to all abnormal E-RAB releases is greater than 30%, you need to checkwhether parameters are properly set for the evolved packet core (EPC).


FormulaThe service drop rate is calculated based on services but not on UEs. For example, services areset up on multiple data radio bearers (DRBs) for a UE. Then, if all these services experiencedrops, multiple service drops are counted.

The formula for calculating the service drop rate is as follows:

Service drop rate = L.E-RAB.AbnormRel/(L.E-RAB.AbnormRel + L.E-RAB.NormRel)

Where,

l The L.E-RAB.AbnormRel counter measures the total number of abnormal E-RAB releasesin a cell.

l The L.E-RAB.NormRel counter measures the total number of normal E-RAB releases ina cell.

Drive TestTo identify service drops in drive tests, you need to check logs and signaling procedures on theUE side.

For details, see the related UE user guide.

TopN Cell SelectionTopN cells must be selected according to the following rules:l The service drop rate of each of topN cells must be higher than the average service drop

rate of the whole network.l Cells are sequenced in descending order based on the number of abnormal E-RAB releases.

Related AlarmsNone




48

Possible CausesIf the service drop rate increases or greatly fluctuates, you must first locate the faults and thenhandle the faults accordingly. Table 6-1 describes possible causes of service drops.

Table 6-1 Possible causes of service drops

Type Fault Description Possible Causes

The whole networkexperiences abnormalities.

l The service drop rate ofthe whole network isabnormal.


l Data transmission isabnormal.

l Network planning isimproper.

l The evolved packet core(EPC) works abnormally.

A single eNodeB experiencesabnormalities.

l The service drop rate of acell is abnormal.


l Data transmission isabnormal.

l Network planning isimproper.

l Resources areinsufficient.

l Weak coverage orinterference exists.

l The EPC worksabnormally.

Troubleshooting FlowchartTo troubleshoot service drops, you are advised to select topN cells with service drops and thenfollow the troubleshooting procedure shown in Figure 6-1.



49

Figure 6-1 Troubleshooting flowchart for service drops

Troubleshooting ProcedureTroubleshooting service drops of the whole network

1. Check whether the whole network has experienced operations such as cutover, replacement,upgrade, or patch installation.

2. Check whether the eNodeB parameters, such as timers or algorithm switches, have beenmodified.

3. Check whether the traffic volume sharply increases.The traffic volume trend of the whole network can be determined based on the number ofE-RAB setup attempts and successful E-RAB setups. Check whether there are activitiessuch as number allocation or important holidays that may lead to a traffic volume increase.



50

4. Check whether the versions or parameters of the EPC network elements (NEs) have beenmodified.

Troubleshooting service drops of the topN cells

1. Check whether the topN cells have experienced operations such as cutover or relocation.2. Check whether the topN cells have experienced operation and maintenance (OM)

operations such as cell deactivation or board restart.3. Check whether the traffic volume sharply increases.

The traffic volume trend of a topN cell can be determined based on the number of E-RABsetup attempts and successful E-RAB setups. Check whether there are activities such asconcerts or sports that may lead to a traffic volume increase.

4. Check whether the cell parameters have been modified, such as the maximum number ofacknowledged mode (AM) protocol data unit (PDU) retransmissions by the UE or eNodeB,or the UE inactivity timer length.

5. Check whether the versions or parameters of the EPC NEs corresponding to the topN cellshave been modified.

6.4 Troubleshooting Service Drops Due to Radio FaultsThis section provides information required to troubleshoot service drops due to radio faults. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

Fault DescriptionAccording to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.Radiocounter measures the number of abnormal E-RAB releases due to radio interface faults in non-handover scenarios.

Related InformationNone

Possible CausesAbnormal E-RAB releases due to radio faults are caused by faults such as the number of RadioLink Control (RLC) retransmissions reaching the maximum, UE uplink out-of-synchronization,or signaling procedure failures that are resulted from weak coverage, uplink interference, or UEexceptions.

Fault Handling FlowchartNone

Fault Handling Procedure1. Check whether UEs are mostly located in weak coverage areas.

Check the values of the counters related to different channel quality indicator (CQI) levelsand modulation and coding scheme (MCS) orders to determine whether low-level CQIsand low-order MCSs are mostly used.



51

Yes: Confirm the cell coverage by using drive tests, and then adjust the weak coverageaccordingly. Go to 2.

No: Go to 3.


Yes: End.

No: Go to 3.

3. Check whether uplink interference exists.

Yes: Remove the interference source. Go to 4.

No: Go to 5.


Yes: End.

No: Go to 5.


Typical Cases

None

6.5 Troubleshooting Service Drops Due to TransmissionFaults

This section provides information required to troubleshoot service drops due to transmissionfaults. The information includes fault descriptions, background information, possible causes,fault handling method and procedure, and typical cases.

Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.TNLcounter measures the number of abnormal E-RAB releases due to faults at the transport networklayer.

Related Information

None

Possible Causes

Abnormal E-RAB releases due to transmission faults are caused by transmission exceptionsbetween the eNodeB and the MME. For example, the transmission link over the S1 interferenceexperiences intermittent disconnections.


None



52

Fault Handling ProcedureCheck whether transmission-related alarms are reported. If any, clear the reported alarms. Then,check whether the corresponding counter has a proper value.

1. Check whether transmission-related alarms are reported on the M2000 client.Yes: Clear the alarms by referring to the instructions in the alarm reference. Go to 2.No: Go to 3.



Typical CasesNone

6.6 Troubleshooting Service Drops Due to CongestionThis section provides information required to troubleshoot service drops due to congestion. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

Fault DescriptionAccording to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.Congcounter measures the number of abnormal E-RAB releases due to resource congestion.


Possible CausesAbnormal E-RAB releases due to congestion are caused by congestion of radio resources on theeNodeB side. For example, the radio sources are insufficient if the number of UEs reaches theupper limit.


Fault Handling ProcedureIf service drops due to congestion occurs in a topN cell for a long time, mobility load balancing(MLB) can be enabled to temporarily reduce the cell load. In the long term, the cell requirescapacity expansion. After rectifying the congestion fault, check whether the correspondingcounter has a proper value.

1. Turn on the switch for the MLB algorithm, and then check whether the congestion fault isrectified.



53

Yes: End.No: Go to 2.


Typical CasesNone

6.7 Troubleshooting Service Drops Due to HandoverFailures

This section provides information required to troubleshoot service drops due to handover faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.

Fault DescriptionAccording to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.HOFailure counter measures the number of abnormal E-RAB releases due tooutgoing handover failures.

Related InformationCounters related to outgoing handovers to a specific cell

l Number of Inter-Specific Cell Outgoing Handover Attempts (L.HHO.NCell.PrepAttOut)l Number of Performed Inter-Specific Cell Outgoing Handovers

(L.HHO.NCell.ExecAttOut)l Number of Successful Outgoing Handovers Between Two Specific Cells

(L.HHO.NCell.ExecSuccOut)l Number of Ping-Pong Handovers Between Two Specific Cells

(L.HHO.Ncell.PingPongHo)

Possible CausesAbnormal E-RAB releases due to handover failures are caused by failures of handovers fromthe local cell to another cell.


Fault Handling ProcedureIf service drops due to outgoing handover failures increase in a topN cell, you can identify thecauses based on the counters related to outgoing handovers to specific cells.

1. Obtain the related counters.Calculate the number of handover failures from the topN cell to each specific target celland find out the target cell that has the highest number of handover failures. Then, check



54

the parameter settings related to the neighbor relationship with this target cell. If theparameter settings are improper, optimize the parameter settings as required.



Typical Cases

None

6.8 Troubleshooting Service Drops Due to MME FaultsThis section provides information required to troubleshoot service drops due to MME faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.

Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.MMEcounter measures the number of abnormal E-RAB releases that are initiated by the evolvedpacket core (EPC). However, these abnormal releases are not included in the value of the L.E-RAB.AbnormRel counter.

Related Information

None

Possible Causes

Abnormal E-RAB releases due to MME faults are initiated by the EPC when UEs are performingservices.


None

Fault Handling Procedure

MME faults must be identified on the EPC side.

1. Obtain the S1 tracing messages related to the topN cell and analyze specific release causes.2. Collect the analysis result and information about the signaling procedure and then contact

EPC engineers.3. Check whether the fault is rectified.





55

Typical CasesNone



56

7 Troubleshooting Inter-RAT HandoverFaults

About This Chapter

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

First office application (FOA) and commercial Long Term Evolution (LTE) networks are beingdeployed in large scales. GSM/EDGE radio access network (GERAN) and Universal terrestrialradio access network (UTRAN) will coexist with LTE networks for a long time. This requiresoperators to use effective inter-RAT policies for protecting the GERAN and UTRAN resourcesand providing rich services at the same time.

7.1 Definitions of Inter-RAT Handover FaultsInter-RAT handover faults are system faults that cause handover initiation failure or handoverfailure. RAT is short for radio access technology.

7.2 Background InformationThis section provides background information about inter-RAT handover faults. Thebackground information includes counters, handover types, handover procedures, and relatedformulas.

7.3 Troubleshooting Inter-RAT HandoversThis section provides information required to troubleshoot inter-RAT handover faults. Theinformation includes fault descriptions, background information, possible causes, and faulthandling method and procedure.

eRANTroubleshooting Guide 7 Troubleshooting Inter-RAT Handover Faults


57

7.1 Definitions of Inter-RAT Handover FaultsInter-RAT handover faults are system faults that cause handover initiation failure or handoverfailure. RAT is short for radio access technology.

7.2 Background InformationThis section provides background information about inter-RAT handover faults. Thebackground information includes counters, handover types, handover procedures, and relatedformulas.

Related Counters

Inter-RAT Outgoing Handover Measurement (Cell) (HO.IRAT.Out.Cell)


Handover Types and Procedures

For details, see eRAN Mobility Management in Connected Mode Feature ParameterDescription and 3GPP TS 23.401.

Related Formulas

Handover Success Rate Formula

Success rate of handovers from evolveduniversal terrestrial radio access network (E-UTRAN) to Wideband Code DivisionMultiple Access (WCDMA) networks

Number of Successful Outgoing Handoversfrom E-UTRAN to UTRAN/Number ofOutgoing Handover Attempts from E-UTRAN to UTRAN

Success rate of handovers from E-UTRAN toGSM/EDGE radio access network (GERAN)

Number of Successful Outgoing Handoversfrom E-UTRAN to GERAN/Number ofOutgoing Handover Attempts from E-UTRAN to GERAN

7.3 Troubleshooting Inter-RAT HandoversThis section provides information required to troubleshoot inter-RAT handover faults. Theinformation includes fault descriptions, background information, possible causes, and faulthandling method and procedure.

Fault Description

The following are symptoms of inter-RAT handover faults:

l Users file service drop complaints.



58

l The success rate of outgoing inter-RAT handovers is low.

l Signaling message tracing results indicate that handover procedures are incomplete or fail.

Related Informationl UE capability for inter-frequency handover

Monitor the network access signaling procedure on the eNodeB to check whether the UEsupports inter-frequency handovers. The information about whether the UE supports inter-frequency handovers can be obtained from the IE Feature group indicators in theUECapabilityInformation message.

According to 3GPP TS 36.331 B.1 Feature group indicators, the eighth and ninth indicatorsindicate whether a UE supports packet switched (PS) handovers to GERAN and URTAN,respectively. Table 7-1 lists the eighth and ninth indicators.

Table 7-1 B.1 "Feature group indicators" in 3GPP TS 36.331

Indicator

Event Description

8 EUTRARRC_CONNECTED toUTRA CELL_DCH PShandover

can only be set to "true" if the UE has set bit number22 to "true"

9 EUTRARRC_CONNECTED toGERAN GSM_Dedicatedhandover

related to SR-VCC - can only be set to "true" if theUE has set bit number 23 to "true"

If the value of the eighth and ninth indicators is 0, the UE does not support PS handovers.

If the value of the eighth and ninth indicators is 1, the UE supports PS handovers.

l Neighboring cell configuration check

Inter-RAT neighboring cells must be configured before handovers can be performed fromevolved universal terrestrial radio access network (E-UTRAN) to UTRAN/GERAN. Usethe related commands provided by Huawei to configure inter-RAT neighboring cells.

– Check for missing and redundant neighboring cell configurations.

Check whether the routing area code (RAC) is configured when an external UTRANcell is added by running the ADD UTRANEXTERNALCELL and whetherNoHoFlag is set to Permit Ho when a neighboring relationship is added by runningthe ADD UTRANNCELL or ADD GERANNCELL command.

– Check handover parameter settings.

Check whether handover threshold parameters are properly set by comparing thesettings with the default values or settings for a cell where handovers are normal.



59

The threshold settings can be queried by using the LSTINTERRATHOUTRANGROUP and LST INTERRATHOGERANGROUPcommands.

Possible Causesl The UE does not support inter-RAT handover.l Inter-RAT handover parameters or evolved packet core (EPC) parameters are incorrectly

set, or there are missing neighbor relationships.l The signal quality is poor. For example, the coverage is poor or there is interference.

Fault HandlingInter-RAT handover faults are complex and you need to determine whether an inter-RAThandover fault occurs in the entire network or in a cell based on the fault scope and background.If the fault occurs in the entire network, locate the fault by checking the signaling exchange andparameter settings on the mobility management entity (MME) and serving GPRS support node(SGSN). If the fault occurs in a cell, check the data configuration, frequency, and hardware ofthe cell.

Figure 7-1 shows the troubleshooting flowchart for inter-RAT handover faults.



60

Figure 7-1 Troubleshooting flowchart for inter-RAT handover faults

Fault Handling Procedure1. Check whether the UE does not support inter-frequency handover.

Yes: Use a UE that supports packet switched (PS) handover. Go to 2.No: Go to 3.


3. Check whether inter-RAT handover is disabled.Yes: Run the MOD ENODEBALGOSWITCH:HoModeSwitch=UtranPsHoSwitch-1; and MOD ENODEBALGOSWITCH:



61

HoModeSwitch=GeranPsHoSwitch-1; commands to enable PS handover to UTRAN andGERAN, respectively. Go to 4.No: Go to 5.


5. Check whether neighboring cells are incorrectly configured.Yes: Correct the neighboring cell configuration. Go to 6.No: Go to 7.


7. Check whether EPC parameters are incorrectly configured.Yes: Ask related personnel to correct the EPC parameter configurations. Go to 8.No: Go to 9.If the fault persists, go to 6.


9. Check whether interference exists and whether the coverage is poor.If the radio quality is poor, the UE cannot receive the handover command or cannot usethe channel assigned by the target cell, causing handover failure. Network planning andoptimization engineers can use drive tests to locate coverage problems and use a device orthe interference tracing function on the eNodeB to locate interference problems.Yes: Remove the interference source and adjust the coverage scope. Go to 10.No: Go to 11.



Typical Casesl Case 1: In a PS handover from E-UTRAN to UTRAN, the eNodeB did not deliver a PS

handover command but delivered a redirection command to the UE.Fault DescriptionIn a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, after the UEreported B1 measurement results to the eNodeB, the eNodeB did not deliver a PS handovercommand but delivered a redirection command.Fault DiagnosisThe result of tracing the network access procedure found that the UE did not support inter-RAT handover. If a UE does not support inter-RAT handover, the eNodeB will redirect theUE to UTRAN.Fault Handling



62

The problem was solved after a UE that supports inter-RAT handover was used.l Case 2: In a test of PS handover from E-UTRAN to UTRAN, the eNodeB did not deliver

a PS handover command.Fault DescriptionIn a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, after the UEreported B1 measurement results to the eNodeB, the eNodeB did not deliver a PS handovercommand.Fault DiagnosisThe result of tracing the network access procedure found that the UE supported inter-RAThandover. The PS handover switch was checked on the eNodeB. The check result indicatedthat the switch was turned on. Then, the neighboring cell relationships were checked. Thecheck result shows that a RAC was not configured for the neighboring UTRAN cell.Fault HandlingThe problem was resolved after an RAC was added to the neighboring UTRAN cell.

l Case 3: In a test of PS handover from E-UTRAN to UTRAN, the eNodeB sent the MMEa PSHO Required message. After two seconds, the eNodeB sent the MME a PSHO Cancelmessage.Fault DescriptionIn a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, the 4G EPCand eNodeB were provided by vendor Y and the 3G core network and radio networkcontroller (RNC) were provided by vendor Z. After handover conditions were met, theeNodeB sent the MME a PSHO Required message. After two seconds, the eNodeB sentthe MME a PSHO Cancel message.Fault DiagnosisUu and S1 signaling was traced. The tracing result shows that the eNodeB sent the MMEa HO Cancel command after the UE reported B1 measurement results to the MME and theeNodeB sent the MME a HO Required command. The reason why the eNodeB sent theHO Cancel command was that the MME did not respond to the HO Required command.The length of WaitInterRATSysHoRspTimer configured on the eNodeB was 2 seconds.The eNodeB did not receive a response from the MME when the timer expired. As a result,the eNodeB sent the Handover Cancel command to cancel the handover. The MME logwas checked. The check result shows that the MME received the HO Required commandbut did not forward the command to the SGSN. The reason why the MME did not forwardthe command is that the Gn interface was not configured between the MME and the SGSN,and as a result, the MME could not find the SGSN. When the timer expired, the eNodeBsent the UE a PSHO Cancel command.Fault HandlingThe problem was solved after the Gn interface was reconfigured between the MME andSGSN.



63

8 Troubleshooting Rate Faults

About This Chapter

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.

8.1 Definitions of Rate FaultsThis section defines rate faults.

8.2 Background InformationThis section provides background information for rate faults. The background informationincludes the user-plane protocol stack, restrictions that the protocol stipulates for UEs of differentcategories, and method used to calculate the theoretical rates.

8.3 Troubleshooting Abnormal Single-UE RatesThis section provides information required to troubleshoot abnormal single-UE rates. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

8.4 Troubleshooting Abnormal Multi-UE RatesThis section provides information required to troubleshoot abnormal multi-UE rates. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

eRANTroubleshooting Guide 8 Troubleshooting Rate Faults


64

8.1 Definitions of Rate FaultsThis section defines rate faults.

The following are rate faults and their definitions:

l No transmission

User equipment (UE) that has accessed a network cannot perform data services.

l Low downlink rate on a single UE

The observed rate of a downlink service, either a User Datagram Protocol (UDP) orTransmission Control Protocol (TCP) service, on a UE is at least 10% lower than thebaseline value.

l Downlink rate fluctuation on a single UE

The observed rate of a downlink service, either a UDP or TCP service, on a UE fluctuatesby more than 50%.

l Low uplink rate on a single UE

The observed rate of an uplink service, either a UDP or TCP service, on a UE is at least10% lower than the baseline value.

l Uplink rate fluctuation on a single UE

The observed rate of an uplink service, either a UDP or TCP service, on a UE fluctuatesby more than 50%.

l Abnormal rates on multiple UEs

A key performance indicator (KPI) indicates an abnormal rate, or a large number of userscomplain about their traffic rates. This fault may be caused by a specific single-UE ratefault or a common rate fault on multiple UEs.

l User-recognized abnormal rate

The rate of a data service on a UE is abnormal according to the user's definition. Forexample, the currently observed rate is noticeably lower than the rate of the previous dayor a period; the observed rate is considerably lower than the rate achieved by equivalentequipment.

These faults can be classified into the following types:

l No transmission

l Low single-UE rate, including uplink and downlink UDP/TCP rates

l Single-UE rate fluctuation, including uplink and downlink UDP/TCP rates

l Abnormal multi-UE rates

8.2 Background InformationThis section provides background information for rate faults. The background informationincludes the user-plane protocol stack, restrictions that the protocol stipulates for UEs of differentcategories, and method used to calculate the theoretical rates.



65

LTE User-Plane Protocol Stack

Figure 8-1 shows the LTE user-plane protocol stack. Rate statistics for different layers varybecause of headers. Note the header differences during analysis.

Figure 8-1 LTE user-plane protocol stack

The traffic rates of data services can be measured in the following ways:

l The Ethernet-layer rate can be measured by using DU Meter at the server and client.

l The rates at the RLC and MAC layers can be measured at the eNodeB.

l The rates at layers such as RLC and MAC for Huawei user equipment (UE) can be measuredby using the Probe.

Protocol-Defined Rates for UE Categories

3GPP TS 36.306 specifies the rates for various UE categories, as listed in Table 8-1 and Table8-2.

Table 8-1 Downlink physical layer parameter values for UE categories

UE Category MaximumNumber ofDL-SCHTransportBlock BitsReceivedWithin a TTI

MaximumNumber ofBits of a DL-SCHTransportBlockReceivedWithin a TTI

Total Numberof SoftChannel Bits

MaximumNumber ofSupportedLayers forSpatialMultiplexingin DL

Category 1 10296 10296 250368 1

Category 2 51024 51024 1237248 2



66

UE Category MaximumNumber ofDL-SCHTransportBlock BitsReceivedWithin a TTI

MaximumNumber ofBits of a DL-SCHTransportBlockReceivedWithin a TTI

Total Numberof SoftChannel Bits

MaximumNumber ofSupportedLayers forSpatialMultiplexingin DL

Category 3 102048 75376 1237248 2

Category 4 150752 75376 1827072 2

Category 5 302752 151376 3667200 4

Table 8-2 Uplink physical layer parameter values for UE categories

UE Category Maximum Number ofBits of a UL-SCHTransport BlockTransmitted Within a TTI

Support for 64QAM inUL

Category 1 5160 No

Category 2 25456 No

Category 3 51024 No

Category 4 51024 No

Category 5 75376 Yes

Theoretical Rate CalculationIn LTE networks, the theoretical traffic rate relates to the system bandwidth, modulation scheme,multiple-input multiple-output (MIMO) mode, and parameter settings. Theoretical ratecalculation for a cell considers the number of symbols occupied by the physical downlink controlchannel (PDCCH) in each subframe and the amount of time-frequency resources occupied bythe synchronization channel, by reference signals, and by the broadcast channel.

The theoretical rate can be determined based on the number of RBs and modulation order. Fordetails, see 3GPP TS 36.213.

Take a 20 MHz cell as an example. The only UE in the cell can use 100 RBs and MCS index28. Then, the TBS of 75736 can be selected at the MAC layer for the UE. If MIMO is used, twotransport blocks (150752) are transmitted per transmission time interval (TTI), which is 1 ms.Then, the throughput is 150.752 Mbit/s.

NOTEThe theoretical rate calculated is the protocol-stipulated MAC-layer rate, not the application-layer rate foreNodeBs.



67

8.3 Troubleshooting Abnormal Single-UE RatesThis section provides information required to troubleshoot abnormal single-UE rates. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

Fault DescriptionThe observed rate is stable but at least 10% lower than the baseline value.

Figure 8-2 Rate fault 1 - stable but lower than the baseline value

The observed rate fluctuates by more than 50%, as shown in the following figures.

Figure 8-3 Rate fault 2 - fluctuation type 1

Figure 8-4 Rate fault 2 - fluctuation type 2

Related InformationThe User Datagram Protocol (UDP) is a simple datagram-oriented transport-layer protocol. UDPprovides an unreliable service. It sends datagrams from the application to the IP layer but does



68

not ensure that the datagrams can arrive at their destinations. However, UDP features a hightransmission speed, because a connection does not need to be set up before UDP-basedtransmission between a client and a server and retransmission upon timeout is not applied.

The Transmission Control Protocol (TCP) provides connection-oriented reliable delivery of astream of bytes. A client and a server can transmit data between each other only after a TCPconnection is set up between them. TCP provides functions such as retransmission upon timeout,discarding of duplicate data, data checking, and flow control for data delivery from one end tothe other end.

TCP uses a more complicated control mechanism than UDP. In most cases, a link with a normalTCP rate has a normal UDP rate, but a link with a normal UDP rate does not necessarily havea normal TCP rate. When diagnosing rate faults, ensure normal UDP rates before handling TCPservices.

3GPP specifications impose uplink capability constraints on user equipment (UE) categories.Only UEs of category 5 support 64 quadrature amplitude modulation (64QAM) in the uplink.

Possible CausesA common way to find a cause is as follows: First, check whether the service involved is a UDPservice or a TCP service. If it is a TCP service, inject uplink and downlink UDP packets on asingle thread and check whether the uplink and downlink UDP rates can reach their peak values.The purpose is to "clear the way" for TCP rate fault diagnosis. For example, eliminate ratelimiting at the network adapter and rectify radio parameter setting errors before handling TCPrate faults. If the service involved is a UDP service, locate the fault by investigating link fromthe server to the UE in an end-to-end manner. Second, if the UDP rate can reach its peak valuebut the TCP rate cannot, the fault exists in the TCP transmission mechanism.

Abnormal rates have the following possible causes:

l Fault in the data source at the serverl Insufficient traffic into the eNodeB due to transmission problemsl Radio interface faults, such as eNodeB alarms related to the radio interface, signal quality

problems, parameter setting errors, problems caused by multiple UEs online, license issues,and uplink interference (required to be checked for abnormal uplink rates)

l Fault in the PC connected to the UEl TCP parameter setting error, or fault in the TCP transmission mechanism

Fault HandlingNone

Fault Handling Procedure1. Check whether data services run abnormally.

If a UE fails to access any data services, check whether the UE has been connected to ordisconnected from the network. Ensure that the UE is connected. Then, check the firewallsettings at the PC and the server. Ensure that the firewalls allow access of the data services.In addition, check whether routes from the server to the evolved packet core (EPC) workproperly. On the server, ping the user-plane IP address of the unified gateway (UGW). Ifthe ping operation fails or the delay is excessively long, contact EPC or datacom technicalsupport.



69

2. Check whether the server malfunctions.

a. On the server, run the following command to set the UDP packet injection volume:

iperf –c x.x.x.x –u –i 1 –t 99999 –b yyymNOTE

"x.x.x.x" denotes the service IP address of the UE."yyym" denotes the UDP packet injection volume, which depends on the UE in use and the cellbandwidth. The value can be greater than the theoretical maximum value as long as the data volumeis sufficient.

b. On the PC, run the following command to start receiving packets:iperf –s –u –i 1

c. (Optional) If the actual output traffic volume from the server does not reach thespecified "yyym", run the following command with "-l" added to adjust the UDPpacket size:iperf –c x.x.x.x –u –i 1 –t 99999 –b yyym -l 1000

d. (Optional) If the actual output traffic volume from the server still fails to reach thespecified "yyym", replace the server.

3. Check whether the input traffic volume to the eNodeB is insufficient.A common reason for the insufficient input traffic volume is a bottleneck transmissionbandwidth at an intermediate node. Check whether:l The bandwidth is correctly set along the transmission link.

Ensure that all network elements and interfaces work at the gigabit level and in auto-negotiation speed mode. The network elements include at least Ethernet ports on theserver and all switches and routers on the network.

l The transmission bandwidth on the transmission link is greater than the peak value.If microwave is used for transmission, ensure that the transmission bandwidth is greaterthan the peak value.

NOTEThe transmission link refers to the S1 interface from the server to the eNodeB.

4. Check whether the radio channel quality is unsatisfactory.l Check whether the downlink signal quality is poor.

Use the software matching the UE type to measure signal quality parameters, such asthe reference signal received power (RSRP) and signal to interference plus noise ratio(SINR). The RSRP and SINR must fulfill certain conditions to meet rate requirements.For example, to enable the actual maximum rate to approach the theoretical peak value,ensure that the RSRP and SINR stay above -85 dBm and 26 dB, respectively.

l Check whether the block error rate (BLER) is excessively high on the radio interface.Monitor the BLER on the M2000 client. If the BLER is higher than 10%, the channelcondition is poor. Improve the channel condition for better downlink signal quality.

l (Optional) Check whether uplink interference exists.When a cell is unloaded in the uplink (all UEs are powered off and there is no servicein the cell), check the received signal strength indicator (RSSI) across the uplink band.In a normal case, the RSSI on each resource block (RB) is about -120 dBm when thecell is unloaded. If the RSSI is 3 dBm to 5 dBm higher than the normal value, uplinkinterference exists. Locate the interference source, and mitigate the interference.

5. Check whether the basic information about the data services or the parameter settings areincorrect.



70

This check is twofold:

l Check whether the basic information about the data services is incorrect.

In this step, check the user's subscription information and UE's capability. Specifically,check whether the user is subscribed to the correct QCI, whether the MBR and AMBRof the UE are set as expected, and whether the UE is empowered with expectedcapabilities.

l Check whether the basic information about the parameter settings is incorrect.

The parameter settings refer to the settings for the eNodeB. Algorithm setting changescause severe drops in the traffic rate. Export eNodeB parameter settings, and comparethem with the baseline values. If the values are inconsistent, confirm whether the settingsare customized for the operator or have been changed to incorrect values. If the settingshave been changed to incorrect values, inform the operator immediately.

6. Check whether the number of users in the cell is excessively large.

Check the number of users in the cell and the downlink RB usage by performing UsersStatistics Monitoring and Usage of RB Monitoring tasks, respectively, under cellperformance monitoring. If an excessively large number of users have accessed the celland RBs are exhausted when a UE accesses the cell, the traffic rate on each UE will not behigh, and low-priority users will experience even lower traffic rates.

7. Check whether license information is incorrect.

Run the LST LICENSE command to query license information, and observe whether:

l The license has expired, or limitation is imposed on functions related to the data services.

l The licensed throughput capability is correct.

8. Check whether the client works abnormally.

Client faults may exist in the UE or in the PC connected to the UE.

l Check for faults in the UE.

If spare UEs are available, replace the UE and check whether the rate fault disappears.If it disappears, the fault exists in the UE.

l Check for faults in the PC connected to the UE.

Investigate the software installed and running on the PC. You are advised to remove orclose all programs except those required by the test. In addition, close the Windowsfirewall and firewalls of antivirus programs.

Check the central processing unit (CPU) usage. If the CPU usage exceeds 80%, the CPUis heavily loaded. Close unused software or service, or replace the PC with a better one.

9. Check for TCP errors.

TCP fault diagnosis varies depending on the symptom. If the throughput is maintained ata level lower than the peak value, check parameter settings and the round trip time (RTT).If the throughput can reach the peak value but is not stable, check for packet loss and severepacket misordering.

l Check the TCP rate status.

Use a multi-thread download program (for example, FlashGet or FileZilla) or openmultiple Windows command line windows to download data. If the rate is higher thanthe single-thread rate, perform further TCP checks. If the rate is equal to or even lowerthan the single-thread rate, go back to the previous steps to recheck for possible faults.

l Check basic TCP parameter settings.



71

Ensure that the basic TCP parameters are correctly set. The parameters include thereceive window, send window, and maximum transmission unit (MTU).

l Check the RTT.Ping the server by using 32-byte packets and MSS-byte packets (MSS is short formaximum segment size), and take the average RTT value for the two types as thecalculated RTT. Typically, the RTT value is required to be less than or equal to 50 ms.Link optimization is required if the RTT value is greater than 50 ms.

l Check for packet loss and severe packet misordering.On the PC side, trace packet headers or use the TCP fault diagnosis module to checkfor packet loss and severe packet misordering. If packet loss or severe packetmisordering occurs, contact datacom personnel for handling.

10. If the fault persists, contact Huawei technical support.

Typical Casesl Case 1: The downlink rate was low with microwave transmission.

Fault DescriptionOn network X in a country, the cell bandwidth was 15 MHz. In a downlink File TransferProtocol (FTP) throughput test using a single UE in a single cell, it was found that alleNodeBs connected to a 100 Mbit/s microwave transport network had their downlinkthroughput not exceeding 30 Mbit/s, but eNodeBs connected to a 1 Gbit/s optical transportnetwork had their downlink throughput as high as 80 Mbit/s.Fault DiagnosisA UDP test found that the UDP throughput was 100 Mbit/s at the sender but dropped toonly 80 Mbit/s at the receiver (eNodeB). Severe packet loss occurred. Due to TCPcongestion control, the throughput of 30 Mbit/s was normal, so the fault did not exist in theeNodeB. The operator requested operation and maintenance (OM) personnel to locate thepacket loss point based on the following assumption: The throughput of 80 Mbit/s on theoptical transport network did not reach 100 Mbit/s, so congestion should not occur in themicrowave transport network.The microwave transmission media were replaced with an Ethernet cable for the directionconnection between the eNodeB and the S-GW. The FTP transfer rate was maintained at30 Mbit/s. The segment-by-segment check found that packet loss occurred at a positionbetween the input and output ports on a switch before packets entered the microwavenetwork. The operator traced the input and output ports and confirmed that packet lossoccurred. The operator further found that the fault was caused by a small buffer size thatwas set for the port on the switch.Fault HandlingThe operator extended the buffer size and tested again. The test result indicated that thedownlink rate could reach the expected value. The extended buffer size helps enhance anti-burst capability, reduce the tail drop probability, and increase the FTP transfer rate.

l Case 2: UDP services were functional, but FTP services were unavailable.Fault DescriptionOperator T in country D stated that no FTP service was available on eNodeBs operating inthe 1800 MHz band but all cells operated properly with UEs normally accessing the cells,being released, and performing UDP services.Fault DiagnosisBased on the feedback from the operator, a check for TCP errors was performed directly,only to find that the FTP transfer rate dropped to zero and the server could not be pinged.



72

Because UDP services ran normally in the downlink, it was almost ascertained that the faultwas down link disconnection.The check on a 800 MHz eNodeB connected to the same transport network found that FTPservices ran normally. Therefore, it was highly possible that the eNodeBs had faults. Dueto the severe impact of the fault, data configurations were immediately restored for the1800 MHz eNodeBs by using the backup data configuration files. The fault was rectified.The faulty configuration files were compared with baseline data configurations. Thecomparison result indicated that a key radio parameter for downlink and uplinktransmission was set to a value different from the baseline value. The fault was caused bythe incorrect parameter setting.Fault HandlingParameter settings were changed to baseline values for all faulty eNodeBs.

l Case 3: The traffic rate occasionally reached the peak value using the E398 but neverreached the peak value using Samsung UEs.Fault DescriptionIn a single cell under an eNodeB on network Y in country P, a single Samsung UE couldreach only 80 Mbit/s unexpectedly in both single-thread and multi-thread (using FileZilla)TCP download. Huawei E398 could occasionally reach 100 Mbit/s in both single-threadand multi-thread TCP download. Both the Samsung UE and Huawei E398 experienced ratedrops.Fault DiagnosisA UDP packet injection test was performed, only to find that Huawei E398 and SamsungUE could both reach the peak values. Therefore, the fault should exist in the TCPtransmission mechanism. In this fault case, rate drops occurred, which was an evidence ofpacket loss. The fault symptoms on Huawei E398 and Samsung UE were different, so theremust be causes other than packet loss.The analysis of TCP/IP headers using a third-party tool indicated that packet loss occurredon the radio interface. It was found from the configuration file for the eNodeB that the QoSclass identifier (QCI) was 7 and the unacknowledged mode (UM) was used. UM isinsensitive to packet loss, so the frontline personnel tried QCI 9 upon request in a furthertest. In the test, rate drops disappeared, but Samsung UE still failed to reach the peak valuein neither single-thread nor multi-thread TCP download while Huawei E398 could reachthe peak value in both single-thread and multi-thread TCP download. A further test wasperformed on RTT using Samsung UE and Huawei E398. The test result indicated that theRTT value for Samsung UE was longer and less stable than the RTT value for HuaweiE398. A comparison between the configuration file for the eNodeB on network Y and thebaseline configuration file found a difference in the radio-interface encryption setting. TheAdvanced Encryption Standard (AES) encryption algorithm was enabled for the radiointerface on network Y, but this algorithm was disabled in the lab. The frontline personneldisabled the AES encryption algorithm as requested. Then, the traffic rate on Samsung UEcould reach 100 Mbit/s. The fault could be reproduced: The rate dropped to 80 Mbit/s afterthis algorithm was enabled. The reason for Samsung UE's failure to reach the peak valuewas the setting of the AES encryption algorithm on the radio interface.Fault HandlingThe problem in network Y was caused by more than one fault, which was further inducedby incorrect parameter settings. The problem was resolved after the parameter settings werecorrected.



73

8.4 Troubleshooting Abnormal Multi-UE RatesThis section provides information required to troubleshoot abnormal multi-UE rates. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

Fault Description

A key performance indicator (KPI) indicates an abnormal rate according to the routine KPImonitoring result, or a large number of users complain about their traffic rates.

Related Information

Related Counters

l DRB Measurement (Cell) (Traffic.DRB.Cell)

l Throughput Measurement (Cell) (Traffic.Thruput.Cell)

l PDCP Measurement (Cell) (Traffic.PDCP.Cell)

l MAC Data Unit Measurement (Cell) (Traffic.MAC.Cell)

l User Number Measurement (Cell) (Traffic.User.Cell)

l Packet Processing Measurement (Cell) (Traffic.Packet.Cell)

l L.Thrp.bits.DL

l L.Thrp.Time.DL

l L.Thrp.bits.UL

l L.Thrp.Time.UL

l L.Traffic.User.DLData.Avg

l L.Traffic.User.ULData.Avg

Possible Causes

If a large number of users complain about their traffic rates, find the cause by following theprocedure for troubleshooting abnormal single-UE rates. Pay more attention to faults that maycause large-scope failures, for example, eNodeB faults, transmission failures, large-sizereconfiguration, and radio frequency (RF) faults.

If a KPI indicates an abnormal rate, check whether the KPI calculation formula is correct,investigate TopN cells, analyze the changes of the KPI with other KPIs, review recent key actionson the network, and if necessary collect and provide KPI logs.

Fault Handling

None

Fault Handling Procedure1. Check whether the KPI calculation formula is correct.



74

Learn the definition of the KPI, determine whether its calculation formula and measurementare correct, and check whether the observed KPI is correct according to the calculationformula.

2. Investigate TopN cells.Select TopN cells and investigate them. If the fault exists in a single cell under a singleeNodeB, troubleshoot the fault by referring to 8.3 Troubleshooting Abnormal Single-UERates.

3. Analyze the changes of the KPI with other KPIs.Analyze the changes to find the root cause or exceptions. For example, check whether thetraffic volume changes consistently with the number of users and whether the traffic volumechanges inversely with the channel quality indicator (CQI).

4. Review recent key actions on the network.Check whether the key actions affect the KPI.


Typical CasesFault Description

On network T in a country, the routine KPI monitoring result indicated that the average trafficrate had been decreasing across the network since a day while the number of users remainedalmost unchanged.

Fault Diagnosis

The check on the rate calculation formula, counter measurement, and statistics changes foundthat network T never changed the formula or measurement method. Therefore, it was not theformula that caused the fault. The investigation of TopN cells found that the entire network hadalmost the same trend, so the fault was not caused by abnormal individual cells. The analysis ofother KPIs indicated that the number of users remained almost unchanged. In addition, networkreconfiguration should not cause a gradual decrease. Finally, the review on recent key actionsfound two actions: rollback of the evolved packet core (EPC) version and provisioning of low-rate subscription services. Further analysis was performed on the two actions.

The analysis found that the EPC version rollback did not affect the traffic rate. In an aggregatemaximum bit rate (AMBR) test in a lab, Transmission Control Protocol (TCP) services wereperformed on UEs with AMBRs of 20 Mbit/s and 100 Mbit/s. The KPI monitoring resultindicated that the rate on a UE with an AMBR of 100 Mbit/s was about four times as high asthe rate on a UE with an AMBR of 20 Mbit/s. The investigation of AMBR distribution at morethan ten sites in recent days found that the number of UEs with a subscribed rate of 256 Mbit/shad dropped by more than 70%. A majority of subscribers on the network were low-rate ones.The confirmation with the operator proved that some UEs newly subscribed to low AMBRs,and some with a subscribed rate of 256 Mbit/s switched to low AMBRs. That was the cause ofthe rate decrease.

Fault Handling

No handling was required. The rate decrease was caused by the provisioning of low-ratesubscription services.



75

9 Troubleshooting Cell Unavailability Faults

About This Chapter

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

9.1 Definitions of Cell Unavailability FaultsWhen the eNodeB detects that a cell is unavailable due to a cell activation failure, the eNodeBreports an ALM-29240 Cell Unavailable alarm.

9.2 Background InformationThis section provides background information for cell unavailability faults.


9.4 Troubleshooting Cell Unavailability Faults Due to Incorrect Data ConfigurationThis section provides information required to troubleshoot cell unavailability faults due toincorrect data configurations. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

9.5 Troubleshooting Cell Unavailability Faults Due to Abnormal Transport ResourcesThis section provides information required to troubleshoot cell unavailability faults due toabnormal transport resources. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

9.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF ResourcesThis section provides information required to troubleshoot cell unavailability faults due toabnormal RF resources. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

9.7 Troubleshooting Cell Unavailability Faults Due to Limited Capacity or CapabilityThis section provides information required to troubleshoot cell unavailability faults due tolimited capacity or capability. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

9.8 Troubleshooting Cell Unavailability Faults Due to Faulty HardwareThis section provides information required to troubleshoot cell unavailability faults due to faultyhardware. The information includes fault descriptions, background information, possible causes,fault handling method and procedure, and typical cases.

eRANTroubleshooting Guide 9 Troubleshooting Cell Unavailability Faults


76

9.1 Definitions of Cell Unavailability FaultsWhen the eNodeB detects that a cell is unavailable due to a cell activation failure, the eNodeBreports an ALM-29240 Cell Unavailable alarm.

Cell unavailability mentioned in this chapter means that all UEs in a cell cannot perform services.If only some UEs cannot perform services, the problem is due to scenario-specific causes. Thesecauses can be found with the aid of signaling tracing, which is not described in this chapter.

9.2 Background InformationThis section provides background information for cell unavailability faults.

Factors that may affect the running of a cell include transmission, hardware, configuration, andRF. If any factor is abnormal, the cell may be unavailable. In this case, check these factors fortroubleshooting.

Related Alarmsl Cell alarms

– ALM-29240 Cell Unavailablel Transmission alarms

– ALM-25880 Ethernet Link Fault– ALM-25886 IP Path Fault– ALM-25888 SCTP Link Fault

l Hardware alarms– ALM-26101 Inter-Board CANBUS Communication Failure– ALM-26200 Board Hardware Fault– ALM-26201 Board Memory Soft Failure– ALM-26205 BBU Board Maintenance Link Failure

l Optical module and CPRI alarms related to the faulty cell– ALM-26230 BBU CPRI Optical Module Fault– ALM-26246 BBU CPRI Line Rate Negotiation Abnormal

l RF module alarms related to the faulty cell– ALM-26238 RRU Network Topology Type and Configuration Mismatch

l Configuration alarms related to the faulty cell– ALM-26243 Board Configuration Data Ineffective– ALM-26251 Board Type and Configuration Mismatch

l License alarms– ALM-26817 License on Trial

l Other alarms– ALM-29201 S1 Interface Fault– ALM-26262 External Clock Reference Problem



77


Possible CausesCell unavailability may be caused by:

l Incorrect data configurationl Abnormal transport resourcesl Abnormal RF resourcesl Limited capacity or capabilityl Faulty hardware

Troubleshooting FlowchartCell unavailability faults are generally indicated by alarms, MML command outputs, and logs.Based on the information, you can know which factor leads to a failure in the setup or runningof a cell. The fault handling method provided in this section is used before log analysis, whichis shown in Figure 9-1.



78

Figure 9-1 Troubleshooting flowchart for cell unavailability faults

Troubleshooting Procedure1. Check whether there are related alarms.

Yes: Handle the alarms. For details, see eNodeB Alarm Reference. Go to 2.No: Go to 3.

2. Check whether the cell fault is rectified.Yes: End.



79

No: Go to 3.3. Check cell fault information.

Perform the following operations in different scenarios:l If the cell fault occurs during the deployment of an eNodeB or the setup of a cell, run

the ACT CELL command.l If the cell fault occurs in another scenario, run the DSP CELL command.

4. Rectify the fault based on cell fault information.Possible fault causes and handling methods are provided as follows:l If transport resources are abnormal, follow the instructions on how to troubleshoot cell

unavailability faults due to abnormal transport resources.l If RF resources are abnormal, follow the instructions on how to troubleshoot cell

unavailability faults due to abnormal RF resources.l If system capacity or capability is limited, follow the instructions on how to troubleshoot

cell unavailability faults due to limited capacity or capability.l If data configurations are incorrect, follow the instructions on how to troubleshoot cell

unavailability faults due to incorrect data configurations.5. Check whether the cell fault is rectified.


6. Check whether there are hardware faults.Yes: Handle the fault problems. Go to 7.No: Go to 8.

7. Check whether the cell fault is rectified.Yes: End.No: Go to 8.


9.4 Troubleshooting Cell Unavailability Faults Due toIncorrect Data Configuration

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

Fault DescriptionA cell fails to be set up after data configuration.

Background InformationA cell cannot be set up successfully if the cell parameter settings do not match the actual RF/baseband processing capability or other parameters.

Incorrect data configuration usually leads to a failure in the setup of a cell, not in the running ofa cell.



80

Related Alarms

l ALM-29240 Cell Unavailable

Possible Causes

A resource item is set to a value inconsistent with the hardware or software configuration, leadingto cell setup failures. Possible causes are listed as follows:

l Incorrect UL/DL subframe ratio or incorrect special subframe radio in TDD mode

l Incorrect cell power configuration

l Incorrect cell frequency configuration

l Incorrect cell preamble format configuration

l Incorrect cell UL/DL cyclic prefix configuration

l Incorrect cell bandwidth configuration

l Incorrect cell beamforming algorithm switch configuration

l Incorrect cell operator information configuration

l Incorrect cell antenna mode configuration

l Incorrect CPRI line rate configuration

l Incorrect cell network-related configuration

The common causes are:

l Incorrect cell power configuration

l Incorrect cell bandwidth configuration

l Incorrect cell network-related configuration


None

Fault Handling Procedure1. Check whether there are related alarms.

Yes: Handle the alarms. For details, see eNodeB Alarm Reference. Go to 2.

No: Go to 3.

2. Check whether the cell fault is rectified.

Yes: End.

No: Go to 3.

3. Rectify the cell fault based on the MML command outputs about cell activation failures.For details, see eNodeB Alarm Reference.


Yes: End.

No: Go to 5.




81

Typical CasesNone

9.5 Troubleshooting Cell Unavailability Faults Due toAbnormal Transport Resources

This section provides information required to troubleshoot cell unavailability faults due toabnormal transport resources. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

Fault DescriptionIf the cell unavailability is caused by abnormal transport resources, a message will be displayedafter execution of the ACT CELL or DSP CELL command. The message indicates that the S1interface used by the cell or an IP path on the S1 interface is abnormal.

Background InformationNone

Possible CausesThe possible causes are:

l An SCTP link is faulty or not configured.l An IP path is faulty or not configured.l Other transmission faults occur.


Fault Handling Procedure1. Check whether the S1 resources are unavailable.

Cell unavailability is due to S1 resource unavailability if any of the following conditionsis met:l In the output of the DSP CELL command, the value of Cell latest avail state is

Unavailable S1 link.l In the output of the ACT CELL command, the following information is provided: [0]

Configuration data activating failed: (1973485632) Cell S1 link (include S1 interfaceand IP path) is abnormal.

Yes: Configure the S1 resources. Go to 2.No: Go to 3.




82

3. Check whether there is an SCTP link alarm.Yes: Handle the alarm according to the help information of ALM-25888 SCTP Link Fault.Go to 4.No: Go to 5.


5. Check whether there are IP path alarms.Yes: Handle the alarms according to the help information of ALM-25886 IP Path Fault.Go to 6.No: Go to 7.




A cell failed to be activated. In the command output, the value of Reason For Latest StateChange wasCCEM_CELLBASIC_ERR_CELL_SETUP_FAIL_S1LINK_DOWN~1973485632.

Fault Diagnosis

OM personnel checked the active alarms and found there were not alarms related to the faultycell. OM personnel then checked the SCTP link status and found that the link was normal.Finally, OM personnel found that IP paths were not configured.

Fault Handling

After OM personnel configured IP paths, the cell fault was rectified.

9.6 Troubleshooting Cell Unavailability Faults Due toAbnormal RF Resources

This section provides information required to troubleshoot cell unavailability faults due toabnormal RF resources. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

Fault DescriptionRF-related alarms are reported.

Background InformationRF Resource Item

The RF resource items to be checked include:



83

l Whether CPRI links between RF units and LBBPs work properlyl When the working status of RF units is normall Whether RF unit versions match the main control board version.l When the line rates of CPRI links are successfully negotiatedl Whether RF networking is consistent with data configuration

Possible CausesA cell is unavailable if data configuration or hardware configuration of RF resources is incorrect.

The possible causes are abnormal CPRI links, abnormal RF units, version mismatch betweenthe main control board and RF units, unsuccessful negotiation of CPRI line rates, and mismatchbetween RF networking and data configuration.


Fault Handling Procedure1. Check whether there are alarms related to RF units or RF unit maintenance links.

Yes: Handle the alarms. For details, see eNodeB Alarm Reference. Go to 2.No: Go to 3.


3. Check whether RF resources are abnormal.Run the DSP BRD, DSP RRU, or DSP BRDVER for query.Yes: Handle the problem. Go to 4.No: Go to 5.




After a cell activation command was executed, Figure 9-2 was displayed. In another case, aftera cell query command was executed, Figure 9-3 was displayed.



84

Figure 9-2 RRU TX branch is not usable (1)

Figure 9-3 RRU TX branch is not usable (2)


OM personnel checked RF-channel-related alarms (including VSWR alarms and RF unitmaintenance link alarms) and found there were RF unit maintenance link alarms. OM personnelthen determined that fiber connections were incorrect according to alarm help information.

Fault Handling

After OM personnel reinstalled the fibers, the alarms were cleared and the cell was successfullyactivated.



85

9.7 Troubleshooting Cell Unavailability Faults Due toLimited Capacity or Capability

This section provides information required to troubleshoot cell unavailability faults due tolimited capacity or capability. The information includes fault descriptions, backgroundinformation, possible causes, fault handling method and procedure, and typical cases.

Fault DescriptionA cell fails to be set up if the required capacity or capability is limited on software or hardware.

Background InformationNone

Possible CausesThe hardware or software specification is limited (for example, the licensed capacity orcapability is limited), leading to cell unavailability.


Fault Handling Procedure1. Obtain the command output after the cell fails to be activated.2. Rectify the cell fault according to the command output. For details about the command

output, check MML help information or related eNodeB documents.3. Check whether the cell fault is rectified.




After the DSP CELL command was executed, Figure 9-4 was displayed.



86

Figure 9-4 Command output indicating a failure to obtain the licensed number of cells


According to the command output, the cell activation failure is caused by license limitation. TheDSP LICENSE command is run, and the result indicates that the licensed number of cells is 3.However, four cells are actually configured according to the result of the LST CELL command.The configured number of cells exceeds the licensed number, which leads to the cell activationfailure.

Fault Handling

After a new license is applied for, downloaded, and activated, the cell is successfully activated.

9.8 Troubleshooting Cell Unavailability Faults Due toFaulty Hardware

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

Fault Description

Board fault alarms are reported. Alternatively, cell unavailability faults cannot be rectified afterresetting, powering off, or reinstalling faulty boards.



87


None

Possible Causes

A cell may not be set up if a fault occurs in the main control board, LBBP, RF unit, other hardware(for example, a subrack).


None

Fault Handling Procedure1. Check whether the board status is abnormal and whether the board versions are mismatched.

Run the DSP BRD or DSP BRDVER for query. Pay more attention to RF units.

Yes: Rectify the board faults. Go to 2.

No: Go to 3.


Yes: End.

No: Go to 3.

3. Collect the logs of the faulty cell.

The logs to be collected include the logs of the main control board, LBBP, and RF unit.

4. Determine whether restoration operations such as eNodeB or board resets can be performed.

Yes: Go to 5.

No: Go to 9.

5. (Optional) Reset the RF unit, LBBP, or main control board.

Run the RST BRD or RST ENODEB command.

6. (Optional) Check whether the cell fault is rectified.

Yes: End.

No: Go to 7.

7. (Optional) Power off the RF unit and LBBP.

Run the OPR BRDPWR command.

8. (Optional) Check whether the cell fault is rectified.

Yes: End.

No: Go to 9.


Typical Cases

None



88

10 Troubleshooting IP Transmission Faults

About This Chapter

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

10.1 Definitions of IP Transmission FaultsIf an Internet Protocol (IP) transmission fault occurs, messages and service data cannot betransmitted between communication devices, and a peer device cannot be pinged.

10.2 Background InformationThis section provides alarms related to IP transmission faults.

10.3 Troubleshooting MethodThis section describes the method and procedure for troubleshooting IP transmission faults.

10.4 Troubleshooting IP Physical Layer FaultsThis section provides information required to troubleshoot IP physical layer faults. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.

10.5 Troubleshooting IP Link Layer FaultsThis section provides information required to troubleshoot IP link layer faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

10.6 Troubleshooting IP Layer FaultsThis section provides information required to troubleshoot IP layer faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

eRANTroubleshooting Guide 10 Troubleshooting IP Transmission Faults


89

10.1 Definitions of IP Transmission FaultsIf an Internet Protocol (IP) transmission fault occurs, messages and service data cannot betransmitted between communication devices, and a peer device cannot be pinged.

10.2 Background InformationThis section provides alarms related to IP transmission faults.

Related AlarmsThe following alarms may be reported to indicate Internet Protocol (IP) transmission faults:

l ALM-25880 Ethernet Link Faultl ALM-25885 IP Address Conflictl ALM-25886 IP Path Faultl ALM-25888 SCTP Link Faultl ALM-29240 Cell Unavailable

For details, see eNodeB Alarm Reference.

10.3 Troubleshooting MethodThis section describes the method and procedure for troubleshooting IP transmission faults.



90

Troubleshooting Flowchart

Figure 10-1 Troubleshooting flowchart for IP transmission faults

Troubleshooting Procedure1. Check whether an alarm indicating the Ethernet link fault is reported in the active alarms

on the eNodeB. If an alarm indicating the Ethernet link fault is reported, rectify the fault.If no alarm indicating the Ethernet link fault is reported, go to 2.

2. Ping the IP address nearest to the local end or the network segment IP address. If the IPaddress nearest to the local end or the network segment IP address cannot be pinged, thereis an IP data link layer fault. Rectify the fault. If the IP address nearest to the local end orthe network segment IP address can be pinged, go to 3.

3. Ping an IP address that is in the same network segment as the local IP address and ping thedestination IP address. If the IP address in the same network segment can be pinged butthe destination IP address cannot be pinged, there is an IP layer link fault. Rectify the fault.If both IP addresses can be pinged, go to 4.


10.4 Troubleshooting IP Physical Layer FaultsThis section provides information required to troubleshoot IP physical layer faults. Theinformation includes fault descriptions, background information, possible causes, fault handlingmethod and procedure, and typical cases.



91

Fault DescriptionAn alarm indicating an Ethernet link fault can be monitored among active alarms on the eNodeB.


Possible CausesThe Ethernet cable or optical module has faults.

Fault HandlingNone

Fault Handling Procedure1. Monitor the Ethernet port indicator status.

There are two indicators for an Ethernet port. If the green indicator is on, the negotiationsucceeds between the Ethernet port and the peer port. If the green indicator is off, thenegotiation fails between the Ethernet port and the peer port. If the yellow indicator blinksfast, data is being transmitted through the port. If the yellow indicator is off, no data is beingtransmitted through the port.Locate the fault based on the indicator status.

Indicator Status Possible Fault Cause

Both green indicators on the eNodeB andswitch are on.

Port negotiation is successful and the portsare up. This indicates that the physicallayer communication is normal.

The green indicator on the eNodeB is onand the green indicator on the switch is off.

The port on the eNodeB is up and the porton the switch is down. The possible causeis that the configuration is incorrect or thehardware is faulty. Perform the followingsteps to locate the fault.

The green indicator on the eNodeB is offand the green indicator on the switch is on.

The port on the eNodeB is down and theport on the switch is up. The possible causeis that the configuration is incorrect or thehardware is faulty. Perform the followingsteps to locate the fault.

Both green indicators on the eNodeB andthe switch are off.

The negotiation has failed and the ports aredown. Perform the following steps tolocate the fault.

2. Check cables.

l Check the Ethernet cable.Check whether the Ethernet cable is properly prepared and whether the cable is longerthan 100 m.



92

a. Check and record the bandwidth (100 Mbit/s or 1000 Mbit/s) supported by thepersonal computer (PC) used.

b. Disconnect the Ethernet cable from the eNodeB and connect it to the PC and checkwhether the ports used to connect the PC and the switch are up. If the ports are up,check and record the bandwidth (100 Mbit/s or 1000 Mbit/s) negotiated betweenthe PC and the switch.

l Check the optical cable and optical modules.

a. Check whether the optical modules are securely inserted. If they are not securelyinserted, reinsert them. Check information about the optical module manufacturer,rate, mode (single-mode or multi-mode), wavelength, and communicationdistance. It is recommended that the eNodeB and peer device use optical modulesprovided by the same manufacturer and with the same rate.

b. Check whether the optical cable is securely inserted. If it is not securely inserted,reinsert it. Check whether the optical cable is broken due to excessive bending. Ifit is broken, replace it.

c. Check whether the optical module is damaged by inserting two ends of one opticalcable to the optical module. Check whether an alarm indicating an optical modulefault is reported on the LMT. If no alarm indicating an optical module fault isreported, the optical module is normal. If an alarm indicating optical module faultis reported, replace the optical module.

3. Check configurations.Log in to the eNodeB and run the LST ETHPORT and DSP ETHPORT commands tocheck the Ethernet port configuration, especially the Port Attribute, Speed, and Duplex.The Port Attribute indicates whether an Ethernet port is an electrical port or optical port.The port attribute can be set to AUTO. If the Port Attribute is set to Fiber, but an electricalport is used, the port status should be down. Other parameters can be checked in a similarway.The rate and duplex mode must be configured the same on the eNodeB and the switch. Ifthey are not configured the same on the eNodeB and the switch, the port negotiation failsor the port negotiation succeeds but packets are lost. The Gigabit Ethernet (GE) electricalport on the eNodeB can be set to AUTO only. If the GE electrical port on the eNodeB isused to connect to the switch, the port attribute must be set to AUTO on both the eNodeBand the switch.The following parameter settings are recommended.

Port Type Rate and Duplex Modeon the eNodeB

Rate and Duplex Modeon the Switch

Fast Ethernet (FE)electrical or optical port

100M/FULL 100M/FULL

FE electrical or optical port AUTO/AUTO AUTO/AUTO

GE electrical port AUTO/AUTO AUTO/AUTO

GE optical port 100M/FULL 100M/FULL

GE optical port AUTO/AUTO AUTO/AUTO

Change the parameter settings on the eNodeB to check the configurations on the switch.Change both the rate and duplex mode to AUTO. If port negotiation succeeds after the



93

change and the DSP ETHPORT command output is the same as expected, the rate andduplex mode are both set to AUTO on the switch. If the port negotiation fails, the rate andduplex mode are not set to AUTO on the switch. Analyze the possible configuration on theswitch based on the DSP ETHPORT command output and change the configuration onthe eNodeB accordingly.

4. Isolate the fault.

a. Connect a PC to the Ethernet port on the eNodeB and check whether the alarm iscleared.

b. Connect a PC to the Ethernet port on the switch and check whether the PC indicatoris on.

c. Identify and isolate the fault.l If the alarm is cleared and the PC indicator is off, the Ethernet port on the switch

is faulty. Go to 4.4.l If the alarm persists and the PC indicator is on, the Ethernet port on the eNodeB

is faulty. Go to 4.5.l If the alarm is cleared and the PC indicator is on, the Ethernet ports on the peer

device and the eNodeB are not fully electrically compatible. Go to 4.6.d. Replace the switch.e. Run the RST ETHPORT and RST BRD commands to reset the Ethernet port and

the board, respectively.Check whether an alarm indicating a board chip fault is reported. If an alarm indicatinga board chip fault is reported, replace the board on which the Ethernet port is located.

f. Check the parameters negotiated between the Ethernet ports on the switch and theeNodeB.


Typical CasesNone

10.5 Troubleshooting IP Link Layer FaultsThis section provides information required to troubleshoot IP link layer faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault DescriptionSignaling messages and service data cannot be transmitted between communication devices.The peer device cannot be pinged.


Possible Causesl The Ethernet port negotiation mode is inconsistent between the eNodeB and the peer device.



94

l The virtual local area network (VLAN) is incorrectly configured.

Fault Handling

Check whether the ARP and VLAN mechanisms work properly. Before transmitting an InternetControl Message Protocol (ICMP), Stream Control Transmission Protocol (SCTP), or UserDatagram Protocol (UDP) packet, the eNodeB queries the next-hop media access control (MAC)address in the ARP table based on the IP route. The eNodeB transmits the packet only if an ARPtable is configured on the eNodeB. If no ARP table is configured, the eNodeB broadcasts anARP request for the next-hop MAC address.

Fault Handling Procedure1. Check packet transmitting and receiving on the eNodeB.

Run the DSP ETHPORT command multiple times to check packet transmitting andreceiving on the eNodeB. If only the number of packets transmitted by the eNodeBincreases, the peer device does not respond. Check whether the eNodeB has transmittedincorrect packets or the packets are correct but the peer device is faulty. Go to the next step.

2. Query the ARP table.

Check whether the eNodeB has learned the ARP.

If the eNodeB has not learned the ARP, perform a ping test and check again. If the eNodeBstill has not learned the ARP, run the STR PORTREDIRECT command to start portredirection to trace the packet header. Check whether the eNodeB has sent an ARP packetand whether the packet is correct.

(Optional) Query the ARP information on the onsite switch.

The ARP aging period is 20 minutes on the eNodeB. If the communication between theeNodeB and the peer device continues only for 20 minutes, the ARP update has failed afterthe aging. If the VLAN configuration is changed within the 20 minutes, the fault is causedby an incorrect VLAN configuration. If the VLAN configuration is not changed within the20 minutes, the peer device must also be checked.

3. Check the VLAN configuration.

Run the LST VLANMAP and LST VLANCLASS commands to check whether the VLANconfiguration is correct.

Run the STR PORTREDIRECT command on the eNodeB to start port mirroring to tracethe packet header. Compare the VLAN configuration with the VLAN information in thepacket. If the VLAN information in the packet is incorrect, modify the VLAN configurationand check again.

NOTEIf VLAN group mode is used, the ARP message type is OTHER.

If the VLAN information in the ARP message is correct, the eNodeB is normal. Confirmwith the customer the VLAN configuration and port type of the peer device and the reasonwhy the peer device does not respond.


Typical Cases

None



95

10.6 Troubleshooting IP Layer FaultsThis section provides information required to troubleshoot IP layer faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault DescriptionThe peer device cannot be pinged and an IP address in the same network segment as the eNodeBcan be pinged. Alarms indicating an SCTP link fault, cell unavailability, and a path fault arereported by the upper layer.


Possible Causesl The route configuration is incorrect or a related device is faulty.l The transmission network is disconnected.

Fault HandlingIn most cases, the cause is that routes are unavailable. If the ARP table and VLAN are normal,troubleshoot the fault as described in the next section.

Fault Handling Procedure1. Query the configured routes.

Run the LST IPRT and DSP IPRT commands to check whether routes are correctlyconfigured on the eNodeB.

2. Use the traceroute function to locate the fault.Run the TRACERT command on the eNodeB to query the nodes that the transmittedpackets pass and determine the gateway where the route becomes unavailable.

3. Trace protocol data.Run the STR PORTREDIRECT command on the eNodeB to start port mirroring to tracethe protocol and packet header.


Typical CasesNone



96

11 Troubleshooting Application LayerFaults

About This Chapter

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

11.1 Definitions of Application Layer FaultsApplication layer faults include unavailability and intermittent disconnection of Stream ControlTransmission Protocol (SCTP) links, Internet Protocol (IP) paths, and operation andmaintenance (OM) channels.

11.2 Background Information

11.3 Troubleshooting MethodThis section describes the method and procedure for troubleshooting IP transport and applicationlayer faults.

11.4 Troubleshooting SCTP Link FaultsThis section provides information required to troubleshoot SCTP link faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

11.5 Troubleshooting IP Path FaultsThis section provides information required to troubleshoot IP path faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

11.6 Troubleshooting OM Channel FaultsThis section provides information required to troubleshoot OM channel faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

eRANTroubleshooting Guide 11 Troubleshooting Application Layer Faults


97

11.1 Definitions of Application Layer FaultsApplication layer faults include unavailability and intermittent disconnection of Stream ControlTransmission Protocol (SCTP) links, Internet Protocol (IP) paths, and operation andmaintenance (OM) channels.

11.2 Background InformationThe Stream Control Transmission Protocol (SCTP) is a transmission protocol that works on theIP layer. The function of SCTP is similar to that of the Transmission Control Protocol (TCP)and User Datagram Protocol (UDP) that work on the same layer as the SCTP. The latest standardto which the SCTP conforms is Request for Comments (RFC) 2960 released in October 2000.Compared with the TCP, the SCTP is improved for specific applications. In addition, multiplefeatures are added to the SCTP. The SCTP is now widely used in radio communications,multimedia, and QoS.

The operation and maintenance (OM) channel is used for remote maintenance of eNodeBs. AnOM channel is set up using TCP handshakes.

11.3 Troubleshooting MethodThis section describes the method and procedure for troubleshooting IP transport and applicationlayer faults.



98

Troubleshooting flowchart for IP transport and application layer faults

Figure 11-1 Troubleshooting flowchart for IP transport and application layer faults

Troubleshooting Procedure1. Check whether an alarm indicating a Stream Control Transmission Protocol (SCTP) link

fault is reported or whether the SCTP link status is abnormal.Yes: Troubleshoot the SCTP link fault.No: Go to 2.

2. Check whether an alarm indicating an Internet Protocol (IP) path fault is reported or whetherthe IP path status is abnormal.Yes: Troubleshoot the IP path fault.No: Go to 3.

3. Check whether an alarm indicating an operation and maintenance (OM) channel fault isreported or whether the OM channel status is abnormal.Yes: Troubleshoot the OM channel fault.No: Go to 4.




99

11.4 Troubleshooting SCTP Link FaultsThis section provides information required to troubleshoot SCTP link faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault Descriptionl Either of the following alarms is reported:

– ALM-25888 SCTP Link Fault– ALM-25889 SCTP Link Congestion

l The Stream Control Transmission Protocol (SCTP) link is unavailable or available only inone direction.After sending data to the peer device, the sender does not receive a response from the peerdevice. In addition, the sender does not receive data from the peer device.

l The SCTP link is abnormal.The SCTP link is faulty or intermittently disconnected.

Related InformationTo rectify SCTP link faults, you need to trace SCTP messages.

SCTP message blocks include 13 types of messages such as INIT, INIT ACK, DATA, SACK,ABORT, SHUTDOWN, ERROR, COOKIEECHO, and HEARTBEAT.

Parameters such as the first peer IP address, the second peer IP address (used in SCTP dualhoming), and peer port number configured on the eNodeB must be consistent with thoseconfigured on the mobility management entity (MME). Run the LST SCTPLNK command. Inthe command output, the parameters in red rectangles are eNodeB parameters and the parametersin the blue rectangles are evolved packet core (EPC) parameters. Ensure that the MMEparameters configured on the eNodeB are consistent with the SCTP parameters of the MME andthat eNodeB parameters configured on the EPC are consistent with the SCTP parameters of theeNodeB.



100

Figure 11-2 SCTP link configuration information

On the MME, check whether the peer port number configured on the MME is the same as thelocal port number configured on the eNodeB and whether a correct network segment isconfigured.

Possible Causesl The transmission network is faulty.

l The SCTP parameters are incorrectly configured on the eNodeB or MME.

l The NE has internal faults.

Fault Handling

None

Fault Handling Procedurel Typical Scenario

To find the cause for an SCTP fault, perform the following steps:

1. Check configurations.

Check whether SCTP parameters are correctly configured on the MME and theeNodeB.

2. Check the transmission.

Ping the MME IP address. If the MME IP address cannot be pinged, check the routeand transmission network. If VLANs are configured for the eNodeB, set thedifferentiated services code point (DSCP) value in the ping command to the oneconfigured for the VLAN for user data.



101

3. Start SCTP message tracing.

Start SCTP message tracing and compare the tracing result with normal SCTP messageexchange.

4. Start a tracing task using WireShark.

Run the STR PORTREDIRECT command on the eNodeB to start port redirection.If no desired data is traced, it is possible that the transmitting port did not send thedata. If desired data is traced, the transmission network and EPC are normal.


l Intermittent SCTP Link Disconnection

If an SCTP link is intermittently interrupted, the eNodeB cannot receive a response fromthe peer device and then the SCTP link is down. After several seconds, the eNodeB initiatesSCTP link reestablishment and the SCTP link recovers.

1. Check transmission alarms.

2. Check the Quality of Service (QoS) of signaling data.

If VLANs are configured for the eNodeB, check whether the VLAN for signaling datais correctly configured on the eNodeB. If VLANs are differentiated by next-hop IPaddress, the check is not required. If VLANs are differentiated by service type, thecheck is required.

If no VLAN is configured for the eNodeB, check whether the DSCP value for signalingdata is the same as that for the transmission network. Run the LST DIFPRI commandto query the DSCP value for signaling data. Check whether the DSCP value is 46 inthe QoS configuration for the transmission network. Ensure that data with a DSCPvalue of 46 can be properly transmitted in the transmission network.

If the transport network bandwidth is limited and the DSCP value for SCTP servicesis less than that for other types of services, the SCTP link will be intermittentlyinterrupted. Therefore, check whether SCTP services has a high DSCP-indicatedpriority in the transmission network with the customer.

3. Start SCTP message tracing.

Start SCTP message tracing and analyze the messages to find the cause for the linkfailure.

4. Check the network packet loss rate.

If the SCTP message tracing shows that packets are lost, check whether the portattribute of the gigabit Ethernet (GE) or fast Ethernet (FE) port is consistent with thaton the peer device. If it is consistent, ping the peer device to check the packet loss rateon the transmission network.

5. Start a WireShark tracing task.

Run the STR PORTREDIRECT command on the eNodeB to start port redirection.If no desired data is traced, it is possible that the transmitting port did not send thedata. If desired data is traced, the transmission network and EPC are normal.

6. Take preventive measures.

If configurations are correct and the peer device can be pinged, run the MODSCTPLNK command or remove the SCTP link information and reconfigure the SCTPparameters so that the eNodeB and the peer device negotiate about the SCTP linkagain.




102

Typical CasesNone

11.5 Troubleshooting IP Path FaultsThis section provides information required to troubleshoot IP path faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault Descriptionl The S1 interface is normal and cells are successfully activated, but UEs cannot attach to

the network.l UEs can attach to the network but cannot set up bearers of some QoS class identifiers

(QCIs). QoS is short for quality of service.

Related InformationThe related alarm is as follows:

ALM-25886 IP Path Fault

Possible Causesl The Internet Protocol (IP) route is incorrectly configured.l The IP path parameters are incorrectly configured.

Fault HandlingNone

Fault Handling Procedure1. Check whether ALM-25886 IP Path Fault is reported.

Yes: clear the alarm by referring to eNodeB Alarm Reference.2. Check whether IP path parameters are correctly configured.

Run the LST IPPATH command. In the command output, if Path Type is QOS andDSCP is 0, only default bearers can be set up. In this case, change Path Type to ANY.


Typical CasesNone

11.6 Troubleshooting OM Channel FaultsThis section provides information required to troubleshoot OM channel faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.



103

Fault DescriptionThe ALM-25901 Remote Maintenance Link Failure alarm is reported.

Operation and maintenance (OM) channel faults are classified into two categories:l OM channel unavailability: The OM channel is faulty.l OM channel interruption: The OM channel is intermittently interrupted.


Possible Causesl The transmission network is faulty.l The OM channel parameters are incorrectly configured on the eNodeB or mobility

management entity (MME).l Some ports are disabled in the transport network.

Fault HandlingNone

Fault Handling ProcedureThis section describes how to handle an OM channel fault in various scenarios.

l Typical Scenario

1. Check configurations.Check whether OM channel parameters are correctly configured on the M2000 clientand the eNodeB.

2. Check the transmission.Ping the IP address of the M2000. If the IP address of the M2000 cannot be pinged,check the route and transport network.

NOTEIf ping operations are prohibited in the operator network, do not ping the M2000 client.

3. (Optional) Trace protocol data.If allowed, a protocol data tracing tool such as WireShark can be used to analyzepacket headers. Add a switch between the transmitting port and the transmissionnetwork, configure transmitting port mirroring on the switch, and connect a personalcomputer (PC) to the mirroring port on the switch to trace packet headers. If no desiredpacket header is traced, the transmitting port is faulty. If desired packet headers aretraced, the transmission network is faulty.

4. If the fault persists, contact Huawei technical support.l Intermittent OM Channel Interruption

1. Check transmission alarms.On the M2000 client, check whether a transmission alarm is reported by the eNodeBduring the intermittent transmission, for example, whether an Ethernet trunk faultalarm is reported. If a transmission alarm is reported, adjust the transport network. If



104

no transmission alarm is reported, go to the next step. Check whether an alarmindicating intermittent link (such as SCTP link) disconnections is also reported. Ifsuch an alarm is reported, rectify the fault too.

2. Check the VLAN configuration.If VLANs are configured for the eNodeB, check whether the VLAN for OM data iscorrectly configured on the eNodeB. If VLANs are differentiated by next-hop IPaddress, the check is not required.

3. Check whether network loopbacks exist.Check whether loopbacks exist in the network based on the network topology. Thecauses of loopbacks are twofold. Some loopbacks are caused by oversights in networkdesign, whereas others are temporary loopback links that were built during link testsbut were not removed promptly. As a result, loopbacks require careful investigation.

4. (Optional) Trace protocol data.If allowed, a protocol data tracing tool such as WireShark can be used to analyzepacket headers. Add a switch between the transmitting port and the transmissionnetwork, configure transmitting port mirroring on the switch, and connect a personalcomputer (PC) to the mirroring port on the switch to trace packet headers. If no desiredpacket header is traced, the transmitting port is faulty. If desired packet headers aretraced, the transmission network is faulty.


Typical CasesNone



105

12 Troubleshooting TransmissionSynchronization Faults

About This Chapter

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.

12.1 Definitions of Transmission Synchronization FaultsThis section describes the classification and definitions of transmission synchronization faults.

12.2 Background InformationFor details about IP clock and non-IP clock, see eRAN Synchronization Feature ParameterDescription.

12.3 Troubleshooting Specific Transmission Synchronization FaultsThis section provides information required to troubleshoot specific transmission synchronizationfaults. The information includes fault descriptions, background information, possible causes,fault handling method and procedure, and typical cases.

eRANTroubleshooting Guide 12 Troubleshooting Transmission Synchronization Faults


106

12.1 Definitions of Transmission Synchronization FaultsThis section describes the classification and definitions of transmission synchronization faults.

The following defines common transmission synchronization faults:

l Clock reference problemThis fault occurs in the case of external clock reference loss, external clock referenceunavailability due to unacceptable quality, or excessive phase (or frequency) deviationbetween the local oscillator and external clock references.

l IP clock link faultThis fault occurs when the IP clock link between the eNodeB and the clock servermalfunctions.

l System clock unlocked faultThis fault occurs when a phase-locked loop in a board is unlocked.

l Base station synchronization frame number errorThis error occurs when a synchronization frame number provided to a board is incorrect.For example, a frame number jump occurs when the pps signals provided by the GPS areabnormal.

l Time synchronization failureThis failure occurs when the eNodeB fails to synchronize with the time synchronizationserver (for example, the NTP server).

12.2 Background InformationFor details about IP clock and non-IP clock, see eRAN Synchronization Feature ParameterDescription.

12.3 Troubleshooting Specific TransmissionSynchronization Faults

This section provides information required to troubleshoot specific transmission synchronizationfaults. The information includes fault descriptions, background information, possible causes,fault handling method and procedure, and typical cases.

Fault Description

External reference clocks for eNodeBs include GPS, synchronous Ethernet, clock over IP, BITS,E1/T1, and TOD clocks. Any abnormality in a reference clock will cause the eNodeB incapableof locking the reference clock. The clock status can be checked by running the DSPCLKSTAT command.

l The value of Current Clock Source State indicates an unknown status.

l The value of Current Clock Source State indicates that the reference clock is abnormal,for example, the reference clock is lost.



107

l The value of PLL Status indicates that the PLL status is abnormal, for example, thereference clock is in free-run mode or there is excessive frequency deviation.

l The value of Clock Synchronization Mode indicates that the clock synchronization modeis not set to a specified mode.

If one of the previous conditions is met, there is a transmission security problem.

Background Informationl The following describes how to perform a clock quality test:

1. Start a clock quality test by running the STR CLKTST command.2. Several hours later, stop the clock quality check by running the STP CLKTST

command.3. Check the clock quality test result by running the DSP CLKTST command.

Possible Causesl The clock mode is incorrectly set.l The clock source is incorrectly added.l The clock working mode is incorrectly set for the eNodeB.l The external reference clock is abnormal, for example, there is excessive frequency

deviation.l The clock source is incorrectly selected, which leads to a clock lock failure.

Troubleshooting FlowchartNone

Troubleshooting Procedure1. Check the clock configuration for the eNodeB.

a. Check whether the clock synchronization mode is set to a specified mode.Check whether the mode is set to the required one, for example, frequencysynchronization or phase synchronization. If the configuration is incorrect, change themode to the required one.

b. Check whether the clock sources are correctly added.Use different query commands for different clock sources. For details, see eNodeBMML Command Reference.

c. Check whether the work mode of the clock is correctly set.If the eNodeB needs to lock an external clock source, set the clock working mode toAUTO or MANUAL. The difference between the two settings are:l AUTO indicates that the eNodeB automatically selects a reference clock based on

the status, priorities, and link available status of reference clocks.l MANUAL indicates that the eNodeB is forced to select a user-defined reference

clock.Set the clock working mode based on actual requirements.

2. Check whether the external clock resources of the eNodeB work properly.



108

To check the status of an external clock source, run the DSP CLKSRC command. Payattention to the following two parameters:

l License Authorized

Generally, the value of this parameter indicates that the clock source can be used. If thevalue indicates that the clock source cannot be used, enable the eNodeB synchronizationfunction.

To check whether the eNodeB synchronization function is enabled, run the DSPLICENSE command. If the Allocated, Config, and Actual Used fields of the EnhancedSynchronization control item are all 1, the function is enabled.

l Clock Source State

The link available status (Link Available State) of a reference clock can be checkedby running a command such as DSP IPCLKLINK, DSP SYNCETH, or DSP TOD.

The value of Clock Source State is Available when the external reference clock of theeNodeB meets either of the following conditions:

– Non-IP clock

The physical connection between the reference clock and the eNodeB is normal, andthe eNodeB can properly receive clock signals sent by the reference clock.

– IP clock

The route from the eNodeB to the IP clock server is correct, and the eNodeB canproperly receive clock signals sent by the IP clock server.

If the clock source state or the link available state is unavailable, investigate the reason.

– Check whether the physical connection and communication are normal between theeNodeB and the clock source. For the GPS, the number of satellites must be greaterthan or equal to 4; the related command is DSP GPS.

– Check whether the eNodeB can properly receive clock signals. For a non-IP clock,clock signals are generated at the physical layer, and therefore you can check onlyon the equipment that sends the clock signals whether they are correctly sent. Foran IP clock, you can check whether clock packets are correctly received byperforming a trace task on the M2000 or by analyzing packet headers on the nearesttransmission equipment. The clock source state and link available state of an IP clockcan be determined based on the characteristics of received clock packets. For detailsabout the analysis, see the PTP clock packet analysis procedure in the next step.

3. Check whether the eNodeB correctly selects a clock source.

When multiple external clock sources are added and work properly, the output of the DSPCLKSRC command indicates that the status of these clock sources is Available. Inaddition, the output of the corresponding link query command (DSP IPCLKLINK, DSPSYNCETH, DSP GPS, or DSP TOD) indicates that the status of the clock link is alsoAvailable. Note that only the link activation status (Link Active State) of the clock sourceselected as the reference clock is Activated. The link activation status of other clock sourcesis Unactivated.

The reference clock is explained as follows:

l If the clock working mode is set to MANUAL using the SET CLKMODE command,the reference clock is the manually selected clock source.

l If the clock working mode is set to AUTO using the SET CLKMODE command, thereference clock is the one automatically selected. The query command is DSPCLKSTAT.



109

l If the link availability status of the selected clock source is Available but the linkactivation status is Unactivated, the reference clock is the one manually selected afterthe clock working mode is set to MANUAL using the SET CLKMODE command.

4. Check whether the eNodeB correctly locks an external clock source.To check the lock status, run the DSP CLKSTAT command. The following describes theparameters in this command:l Current Clock Source: It indicates the clock source to be traced by the eNodeB.l Current Clock Source State: The value should be Normal.l PLL Status: The initial status should be Fast Tracking, and then Locked.l Clock Synchronization Mode: It indicates the configured clock synchronization mode.

– Non-IP clockFor a non-IP clock source, if the link available state is available and the link activestate is activated in step 3, the states queried by running DSP CLKSTAT must benormal.The only risk is that the eNodeB enters free-run mode (instead of locked mode) aftera period of fast tracking. The eNodeB adjusts the local oscillator during fast tracking,but the difference between the local oscillator and external clock sources is stillabove the locking threshold. Therefore, the eNodeB cannot lock an external clocksource and enters free-run mode.In this case, perform a clock quality test to check the frequency deviation values,and report them to Huawei technical support.

– IP clockFor an IP clock, even if the clock link is available and activated, it cannot beguaranteed that all check items are normal. The query command is DSPCLKSTAT. The reason is that whether the eNodeB can lock an external clocksource depends on two packets (Sync and Delay_Resp) as well as the clockinformation the packets carry.In this situation, take two actions: (1) Collect clock packets received by the eNodeBon the M2000 or collect headers of the packets on the nearest transmissionequipment; (2) Perform a clock quality test on the IP clock in the same way as thatfor a non-IP clock. Then, send the packets (or packet headers) and quality test resultto Huawei technical support.

5. If the transmission synchronization fault persists, contact Huawei technical support.

Typical CasesNone



110

13 Troubleshooting Transmission SecurityFaults

About This Chapter

This chapter describes how to troubleshoot transmission security faults.

13.1 Definitions of Transmission Security FaultsA transmission security fault occurs when an IPSec tunnel between an eNodeB and a securitygateway (SeGW) malfunctions. This fault leads to abnormal communication between theeNodeB and the EPC.

13.2 Background InformationThis section describes the data that requires encryption in transmission security networkingscenarios. In addition, this section provides the parameters related to transmission security.

13.3 Troubleshooting Specific Transmission Security FaultsThis section provides information required to troubleshoot specific transmission security faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.

eRANTroubleshooting Guide 13 Troubleshooting Transmission Security Faults


111

13.1 Definitions of Transmission Security FaultsA transmission security fault occurs when an IPSec tunnel between an eNodeB and a securitygateway (SeGW) malfunctions. This fault leads to abnormal communication between theeNodeB and the EPC.

Transmission security faults include:

l Internet key exchange (IKE) negotiation failure: An IKE security association (SA) fails tobe set up between the eNodeB and the SeGW.

l IPSec tunnel setup failure: The IKE SA between the eNodeB and the SeGW is normal, butthe IPSec SA carried by the IKE SA fails to be set up.

l Certificate application failure: A digital certificate fails to be obtained due to an IKEnegotiation failure.

13.2 Background InformationThis section describes the data that requires encryption in transmission security networkingscenarios. In addition, this section provides the parameters related to transmission security.

l Encapsulation between two eNodeBs: Data streams between two eNodeBs are encapsulatedin transport mode.

l Encapsulation between an eNodeB and an SeGW: Data streams (except those between theSeGW and the EPC) are encapsulated in tunnel mode.

l Encapsulation between an eNodeB and the EPC: Data streams over the S1 interface areencapsulated in transport mode.

Figure 13-1 Transmission security networking



112

Transmission security faults occur in most cases where security link negotiation between theeNodeB and the security gateway fails. Parameters affecting the negotiation include IKEparameters and IPSec parameters. IKE parameters include the ciphering algorithm, verificationalgorithm, IKE version, identity authentication mode, and shared key. IPSec parameters includethe ciphering mode, ciphering algorithm, authentication algorithm, and authorization mode. Fordetails, see eRAN Transmission Security Feature Parameter Description.

13.3 Troubleshooting Specific Transmission Security FaultsThis section provides information required to troubleshoot specific transmission security faults.The information includes fault descriptions, background information, possible causes, faulthandling method and procedure, and typical cases.

Fault Description

When a transmission security fault occurs:

l The eNodeB is out of control, and all operation commands cannot be delivered from theM2000 to the eNodeB.

l The eNodeB is under control, but transmission-related alarms are displayed on the WebLMT.

l Transmission detection commands such as ping cannot be successfully executed.

Background Informationl Related Alarms

– ALM-26841 Certificate Invalid

– ALM-25891 IKE Negotiation Failure

– ALM-25880 Ethernet Link Fault

– ALM-26223 Transmission Optical Interface Performance Degraded

– ALM-26222 Transmission Optical Interface Error

– ALM-26220 Transmission Optical Module Fault

– ALM-25901 Remote Maintenance Link Failure

– ALM-25888 SCTP Link Fault

Possible Causes

Possible causes are:

l Transmission security parameters are mismatched between the local and peer ends, whichleads to IPSec tunnel negotiation failures.

l Security tunnel update fails due to certificate update failures or certificate expiry.


Transmission security faults are generally due to data configuration. Therefore, data consistencycheck between the eNodeB and the SeGW is crucial to troubleshooting.



113

Figure 13-2 Troubleshooting flowchart for transmission security faults

Troubleshooting Procedure1. Check whether an IPSec policy group is bound to the port involved.

Run the LST IPSECBIND command. The output is as follows:



114

Figure 13-3 List binding relationships

If no binding relationship is found, bind an IPSec policy group to the port. Run the ADDIPSECBIND command, and specify values for the mandatory parameters such as the slotNo., subboard type, port type, port No., and IPSec policy group name. To learn about theIPSec policy group name, run the LST IPSECPOLICY command.

2. Check whether the IKE proposal is correctly configured.Run the DSP IKEPROPOSAL command for query. If the values in the red frame areinconsistent with the network plan, run the MOD IKEPROPOSAL command to changethem.

Figure 13-4 List IKE negotiation results

3. Check whether the IKE peer is correctly configured.Run the DSP IKEPEER command for query. If the values in the red frame are inconsistentwith the network plan, run the MOD IKEPEER command to change them.



115

Figure 13-5 List IKE peer information

4. Check whether the IKE proposal configuration on the eNodeB is the same as that on theSeGW.Run the LST IKEPROPOSAL command to check whether the IKE proposal with the IDindicated in 3 is consistent with the that used by the SeGW. Pay more attention to theencryption algorithm, authentication algorithm, IKE version, and key. If the authenticationis based on digital certificates, go to 5. If the authentication is based on shared keys, go to6.

5. Check whether the eNodeB's certificate chain is correct.Run the DSP TRUSTCERT command to check the operator's root certificate. Pay moreattention to the information in the red frame. Check whether the name of the root certificateis correct and whether the root certificate has expired. If the root certificate is incorrect,apply for a new one. Then, run the DLD CERTFILE command to download the rootcertificate, and run the ADD TRUSTCERT command to add the root certificate to theeNodeB.

Figure 13-6 List operator's root certificate information

Run the DSP CERTMK command check the operator's device certificate. Pay moreattention to the information in the red frame. Check whether the issuer of the root certificateis correct and whether the root certificate has expired. If the device certificate is incorrect,apply for a new one. Then, run the DLD CERTFILE command to download the devicecertificate, and run the ADD CERTMK command to add the device certificate to theeNodeB.



116

Figure 13-7 List operator's device certificate information

Run the DSP APPCERT command to check whether the certificates used for IKE and SSLare correct. Pay more attention to the information in the red frame. If a used certificate isincorrect, run the MOD APPCERT command to change it.

Figure 13-8 List certificates used for IKE and SSL

6. Check whether the IPSec proposal is correctly configured.Run the DSP IPSECPROPOSAL command for query. If the values in the red frame areinconsistent with the network plan, run the MOD IPSECPROPOSAL command to changethem.

Figure 13-9 List IPSec proposal information

7. Check whether the IPSec policy is correctly configured.Run the DSP IPSECPOLICY command for query. If the values in the red frame areinconsistent with the network plan, run the MOD IPSECPOLICY command to changethem.



117

Figure 13-10 List IPSec policy information

8. Check whether the ACL rule is correctly configured.

Run the LST ACLRULE command for query. The following figure provides an example.If the values in the red frame are inconsistent with the network plan, run the MODACLRULE command to change them.

Figure 13-11 List ACL rule information

9. If the transmission security fault persists, contact Huawei technical support.

Before contacting Huawei technical support, collect configuration files, certificate files(including the root certificate, intermediate certificate, device certificate files), and boardlogs.



118

If possible, collect header information transmitted between the eNodeB and the SeGWduring negotiation.

Typical CasesThe following describes how to troubleshoot an IKE negotiation failure.

Fault Description

An IPSec policy group was bound to a port, but an IPSec tunnel failed to be set up between theeNodeB and the SeGW.

Fault Diagnosis

1. OM personnel checked whether the IPSec-related parameters were correctly configured.The output of the DSP IKESA command indicated that the IKE SA status in phase 1 wasReady or Ready|StayAlive, but the status in phase 2 was None. IPSec-related parametersettings were checked and were found to be the same as those on the SeGW.

2. OM personnel checked header information.There were four IKE_AUTH exchanges between the eNodeB and the SeGW. After that,the SeGW did not respond to the IKE_AUTH message from the eNodeB. When an eNodeBhas not received any responses from an SeGW for a long time, the eNodeB will continueto send six IKE_AUTH messages before staring the next round of authenticationnegotiation.

3. OM personnel checked the IKE_AUTH messages sent from the SeGW to the eNodeB.The notification payload in the messages was NO_PROPOSAL_CHOSEN. This indicatedthat the SeGW failed to obtain the required IPSec proposal and therefore this round of IKEauthentication negotiation failed. The SeGW sent these messages to notify the eNodeB ofthis failure.

NOTEThe eNodeB considered the encrypted notification messages invalid and therefore discarded thesemessages.

Fault Handling

This fault was due to the configuration on the peer equipment. After the message transmissionrule on the peer equipment was modified, the fault was rectified.



119

14 Troubleshooting RF Unit Faults

About This Chapter

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

14.1 Definitions of RF Unit FaultsIf a radio frequency (RF) unit is faulty, its sensitivity decreases, leading to deterioration of thecell demodulation performance and reduction of the uplink coverage, or even service interruptionin the cell.

14.2 Background InformationThis section defines the concepts related to RF unit fault troubleshooting. The concepts arevoltage standing wave ratio (VSWR) tests, passive intermodulation (PIM) interference, externalinterference, and remote electrical tilt (RET) antennas.


14.4 Troubleshooting VSWR FaultsThis section provides information required to troubleshoot VSWR faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

14.5 Troubleshooting RTWP FaultsThis section provides information required to troubleshoot RTWP faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

14.6 Troubleshooting ALD Link FaultsThis section provides information required to troubleshoot ALD link faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

eRANTroubleshooting Guide 14 Troubleshooting RF Unit Faults


120

14.1 Definitions of RF Unit FaultsIf a radio frequency (RF) unit is faulty, its sensitivity decreases, leading to deterioration of thecell demodulation performance and reduction of the uplink coverage, or even service interruptionin the cell.

Generally, RF unit faults are indicated by alarms. Therefore, this chapter describes how totroubleshoot RF unit faults based on reported alarms.

14.2 Background InformationThis section defines the concepts related to RF unit fault troubleshooting. The concepts arevoltage standing wave ratio (VSWR) tests, passive intermodulation (PIM) interference, externalinterference, and remote electrical tilt (RET) antennas.

VSWR Test

During a VSWR test on a radio frequency (RF) unit, power of the RF unit is first coupled asforward power and backward power by using directional couplers, and then they are measuredby using standing-wave detectors. The difference between the measured forward power andbackward power is the return loss, which can be converted to a VSWR value by using relatedformulas. The VSWR value is used to determine whether a VSWR alarm is reported.

Figure 14-1 Principle of a VSWR test

The VSWR test result indicates the connection condition between the RF unit and the antennasystem. If a large VSWR value is obtained, the antenna system is improperly connected withthe RF unit. The output power of the RF unit is not transmitted through the antenna but reflectedback. A high reflected power damages the RF unit, and the total reflection may break down theunit. To avoid the preceding faults, the VSWR alarm post-processing switch must be turned onfor a remote radio unit (RRU) to be added. In this way, if a major VSWR alarm is generated,the RRU automatically shuts down the faulty transmit (TX) channels and then does not provideoutput power. In this scenario, the cell served by the RRU degrades the capacity or becomesunavailable. The cell coverage and performance also deteriorate.



121

NOTEIf a major VSWR alarm is generated, the faulty TX channels are automatically shut down. If you haverectified the related faults, you can run the STR VSWRTEST command or manually modify the TXchannel configuration to open the TX channels. However, the VSWR alarm still exists. It will be clearedonly after the RRU is reset.

PIM InterferencePIM interference is induced by non-linearity of the passive components in the TX system. Theantenna non-linearity is indicated by the intermodulation (IM) suppression degree. For a linearsystem, if the input is two signals, the output is also two signals without any additional frequencycomponent. For a non-linear system, if the input is two signals, new frequency components aregenerated in the system and added to the output, and then the output is more than two signals.The added frequency components are known as the IM products. The process of generatingfrequency components is called IM. If the IM products work on frequencies within the receive(RX) frequency band and accordingly increase the uplink interference or received total widebandpower (RTWP), IM interference is generated. In a high-power and multi-channel system, non-linearity of the passive components generates high-order IM products. These IM products andthe operating frequency are mixed to from a group of new frequencies, and accordingly a groupof useless spectra is generated and affects the normal communication.

In a linear system, assume that the two input signals work on the frequencies of f1 and f2. Then,IM components are generated, such as two IM3 components operating on the frequencies of (2x f1 - f2) and (2 x f2 - f1), and two IM5 components operating on the frequencies of (3 x f1 - 2x f2) and (3 x f2 - 2 x f1). As shown in the following figure, the input signals and IM componentsare marked in green and red, respectively. The IM order of an IM component (m x f2 - n x f1)is the sum of m and n. These IM components are generated symmetrically on the left and rightof the wanted signals. Their intervals depend on the IM orders and the maximum frequencyspacing (or bandwidth) of the input signals. A higher IM order leads to a lower amplitude forthe IM components and a further distance from the wanted signals, and therefore a smallerimpact.

The following figure shows an example of a PIM result.



122

Figure 14-2 Example of a PIM result

All passive components encounter intermodulation distortion that may be caused by unreliablemechanical contacts, poor soldering, or oxidization.

Passive components such as combiners, duplexers, and filters require specific IM suppressiondegrees. If the IM suppression degree of an IM order meets the requirements, the IM productshave no impact on the system performance. Generally, cables do not have requirements for PIMsuppression degrees. A cable requiring high PIM suppression degrees can reduce PIMinterference, but it is too expensive to be used widely.

Note that an improper connection is not definitely coupled with the PIM interference. If an RFunit is properly connected with the antenna system, high-power IM components may also begenerated due to insufficient PIM suppression degrees of the cables.

If the IM components work on frequencies within the RX frequency band, this increases thenoise floor of the RX channels and decreases the sensitivity of the RF unit. For a frequencydivision duplex (FDD) system, frequency bands such as 800MHz and 700MHz have smallduplex spacing (spacing between the DL frequency and the UL frequency). Meanwhile, the IM3and IM5 products of the TX signals work on frequencies within the RX frequency band. In thisscenario, the impact of PIM interference must be paid special attention.

To sum up, the generating conditions for PIM interference are as follows:

The input is TX signals of the eNodeB, or occasionally external interference signals transmittedthrough the antenna. The media is cables or passive components such duplexers and antennas.The output is IM products. The power of the IM components depends on the IM suppressiondegree of the passive components or cables.

PIM interference has the following typical characteristics:

l The RTWP multiplies while the TX power increases.Add downlink simulated load to increase the TX power. If the RTWP obviously multiplies,PIM interference exists.



123

l The RTWP is sensitive to the positions of cables and connectors.Observe the RTWP while shaking the cable near a connector or hitting a connector. If theRTWP changes greatly, PIM interference exists.

l The impact of PIM interference increases with the bandwidth.The impact of PIM interference must be taken into account for frequency bands with theduplex spacing within 30 MHz.

l The generating mechanism of PIM interference is complicated.Generally, PIM interference exists when multiple frequency components are generated.However, in a non-linear system, a single amplitude-modulated signal may generatefrequency components, and this leads to spectrum expansion. These frequency componentsare also IM products. Moreover, in a scenario with improper connections, even continuouswave (CW) signals generate frequency components.

External Interference

Electromagnetic waves are propagated through space in certain directions in the electric field.Based on the directions (also known as polarization), the electromagnetic waves are classifiedinto linear polarized waves and circular polarized waves. Antennas with different polarizationcan obtain various gains from linear polarized waves.

eNodeBs use orthogonal 45° dual-polarized antennas. Therefore, linear polarized wavesreceived by these antennas have main and diversity gain differences.

Interference signals can also be classified based on the polarization:

l Linear polarized interference signalsInterference signals are propagated through various transmission media, and are frequentlyreflected and refracted in some places such as urban areas. As a result, the linear polarizedinterference signals continuously change their propagation directions and also change theirpolarization in the electric field.When they arrive the antennas of the eNodeB, their polarization has little difference fromeach other, and two antenna ports of each sector receive interference signals with similarpower.

l Circular polarized interference signalsCircular polarized interference signals are propagated without directions. Therefore, whenthey arrive the dual-polarized antennas of the eNodeB, two antenna ports of each sectorcan receive interference signals with similar power.

In some cases, external interference may also lead to RTWP imbalance alarms.

For example, linear polarized radio signals from a radar or navigation satellite high up in the airare propagated without multiple reflections. When the eNodeB receives such interferencesignals, the orthogonal dual-polarized antennas can obtain various gains based on the anglebetween the interference signals and the antenna polarization. If the interference signals existfor a long time, an RTWP imbalance alarm can be generated.

To determine whether external interference exists, perform the following steps:

1. Check whether PIM interference exists.Shut down downlink channels and then check whether the RTWP is excessively high.Yes: Go to 2.



124

No: There is no PIM interference.2. Check whether external interference exists. Perform the following steps:

Disconnect an RRU or RFU from the jumper, and then connect the RRU or RFU to amatched load or direct open-circuit to check whether the RTWP falls within the normalrange.If the RTWP is normal, external interference exists.

Stable external interference has the following typical characteristics:

l Two interference signals received by a receiver are correlated but with different power.They have the same impact on the RTWP.

l External interference occupies a certain bandwidth. Monophony interference does not carryany useful information, however, it seldom exists.

l External interference is received only by antennas, which simplifies the troubleshootingprocedure.

Remote Electrical Tilt AntennaA remote electrical tilt (RET) antenna can be remotely controlled because it is equipped with adrive called the remote control unit (RCU). The RCU is installed closely to the RET antenna.Each RCU consists of a driving motor, control circuit, and drive structure. The driving motor isusually a digitally controlled step motor. The control circuit communicates with the controllerand controls the driving motor. The drive structure contains a gear that meshes with a pullingbar. Under the control of the driving motor, the gear moves to transmit motion to the pullingbar, and accordingly the tilt angle of the antenna can be adjusted.

The following figure shows the structure and working principles of an RET antenna equippedwith an RCU.



125

Figure 14-3 Structure and working principles of an RET antenna equipped with an RCU




126


Figure 14-4 Troubleshooting flowchart for RF unit faults

Troubleshooting Procedure1. Check whether there is any alarm related to voltage standing wave ratio (VSWR) faults in

the active alarms on the eNodeB or there is any abnormal VSWR test result. If yes,troubleshoot the VSWR faults. If no, go to 2.

2. Check whether there is any alarm related to RTWP faults in the active alarms on theeNodeB. If yes, troubleshoot the RTWP faults. If no, go to 3.

3. Check whether there is any alarm related to ALD link faults in the active alarms on theeNodeB or there are any abnormal ALD links. If yes, troubleshoot the ALD link faults. Ifno, go to 4


14.4 Troubleshooting VSWR FaultsThis section provides information required to troubleshoot VSWR faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault DescriptionAn alarm ALM-26529 RF Unit VSWR Threshold Crossed is reported if there are VSWR faultsin the radio frequency (RF) channels of an RF unit.



127


Possible Causesl The VSWR alarm threshold is set to a low value.l Hardware installation is improper. For example, a jumper is improperly connected; a feeder

connector is insecurely installed or is immersed in water; the feeder connected to an antennaport is bent, deformed, or damaged; a feeder is insecurely connected.

l The frequency band supported by the RF unit is inconsistent with that supported by thecomponents of the antenna system.

l A VSWR-related circuit fault occurs in the RF unit, or other hardware faults occur in theRF unit.


Fault Handling Procedure1. Check the detected VSWR value when the alarm is reported.

If the VSWR value is greater than 10, it means that all output power is reflected backbecause no feeder is connected to the related antenna port or the related feeder is bent ordamaged.

2. Check the VSWR alarm threshold of the RF unit.Run the LST RRU command to query the VSWR alarm threshold of the RF unit. Then,check whether the threshold is properly set according to the network plan. If the thresholdis improper, change it by running the MOD RRU command.

3. Check the current VSWR value.

a. Run the DSP VSWR command to query the current VSWR value.

b. NOTE

The execution of the STR VSWRTEST command interrupts services carried by the RF unit.

Run the STR VSWRTEST command to query the offline VSWR value.TIPIt is recommended that multiple frequencies within the operating frequency range supportedby the cell be used as the test frequencies.

Figure 14-5 Command for starting a VSWR test

4. Compare the VSWR values queried by running the STR VSWRTEST and DSP VSWRcommands.



128

If the two values are the same and are greater than the threshold for reporting VSWR alarms,onsite investigation is required. Go to 5.If the two values are significantly different, run the STR VSWRTEST command toperform VSWR tests on a frequency point at an interval of 1 MHz or smaller within thebandwidth range to compare tested VSWR values.l If the values are the same, the feeder between the RF unit and the antenna system may

be insecurely connected and accordingly the queried VSWR values are not stable. Inthis case, check the feeder connection at the local end. Then, go to step 4.

l If some of the values are large, a hardware fault may occur in the RF unit. Save the testresults and submit the results together with one-click log files of the main control boardand RF unit to Huawei technical support for further analysis.

5. Check the feeder connection at the local end.Check whether the frequency band supported by the RF unit is consistent with thatsupported by the components of the antenna system according to the network plan. Theantenna system consists of antennas, feeders, jumpers, combiner-dividers, filters, andtower-mounted amplifiers (TMAs).It is recommended that a Sitemaster be used to measure the distance between the point witha large VSWR value and the test point during a VSWR test.If no Sitemaster is available, locate the fault by using isolation methods. Add load todifferent parts of the feeder at the local end. Then, run the STR VSWRTEST to start aVSWR test on each isolation part of the feeder to locate the fault.

6. If the feeder connection is normal, contact Huawei technical support.

Typical CasesNone

14.5 Troubleshooting RTWP FaultsThis section provides information required to troubleshoot RTWP faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault DescriptionAn RTWP-related alarm is reported if there are received total wideband power (RTWP) faultsin the radio frequency (RF) channels of an RF unit.

Related InformationRelated alarms are as follows:

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

Possible Causesl The setting of attenuation on the RX channel of the RF unit is incorrect.l The feeder connected to the RF unit is faulty.



129

l Passive intermodulation (PIM) exists.l External interference exists.l The feeder is improperly connected with the antenna.l The hardware in an RF module is faulty.l Faults may be caused by other uncertain factors.


Figure 14-6 Fault handling flowchart for RTWP faults

Fault Handling Procedure1. Rectify the faults and modify the improper settings.

a. Run the LST ALMAF command to check whether alarms related to ALD or TDMare reported. If such an alarm is reported, clear the alarm by referring to 14.6Troubleshooting ALD Link Faults.

b. Run the LST RXBRANCH command to check whether attenuation of the RXchannel of the RRU is configured as planned.If it is not configured as planned, run the MOD RXBRANCH command to modifythe configuration. If it is configured as planned, go to 1.3.



130

The result is similar to the following:List RxBranch Configure Information----------------------------------- Cabinet No. = 0 Subrack No. = 62 Slot No. = 0 RX Channel No. = 0Logical Switch of RX Channel = ON Attenuation(0.5dB) = 0(Number of results = 1)

c. Check whether the ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalancedor ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low alarm is reported.If either of the alarms is reported, clear the alarm by referring to ALM-26522 RF UnitRX Channel RTWP/RSSI Unbalanced or ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low. If the ALM-26522 RF Unit RX Channel RTWP/RSSIUnbalanced alarm cannot be cleared by referring to ALM-26522 RF Unit RX ChannelRTWP/RSSI Unbalanced, perform 2 to 6.

2. Check whether PIM interference exists.PIM has a typical characteristic: The level of the intermodulation products increases withthe transmit power. Using this typical characteristic, the existence of PIM interference canbe determined. If the uplink interference increases significantly with the transmit power,PIM interference exists. Otherwise, PIM interference does not exist. You can increase thetransmit power by adding a downlink simulated load, and then compare the received signalstrength indicator (RSSI) values before and after the simulated load is added.The procedure is as follows:

a. Run the ADD CELLSIMULOAD command to add a simulated load. For example,ADD CELLSIMULOAD: LocalCellId=x, SimLoadCfgIndex=9;The simulated load and transmit power have a positive correlation with the value ofthe SimLoadCfgIndex parameter.

NOTENote that load simulation is mainly used in interference tests. You are advised not to use loadsimulation for a cell with more than six active UEs. Otherwise, the scheduling performance cannotbe ensured.

b. Start RSSI tracing.From the main menu on the M2000 client, choose Monitor > Signaling Trace >Signaling Trace Management. In the left navigation tree, choose LTE > CellPerformance Monitoring > Interference RSSI Statistic Detect Monitoring. Then,click New in the right pane. An RSSI tracing task is created. Figure 14-7 shows anexample of RSSI tracing results.If the values on one RSSI curve are significantly greater than the values on other RSSIcurves, PIM interference exists. If values on all RSSI curves are basically the same,there is no PIM interference and go to 3.



131

Figure 14-7 RSSI tracing result

If PIM interference exists according to the preceding investigation, use either of thefollowing methods to determine the location or device where PIM is introduced:l Add a simulated load and shake the cable segments by segments from the RF unit top

to the antenna port. If RSSI values change dramatically when shaking a segment, PIMinterference is introduced by this segment.

l Breakpoint-based PIM detection:By using breakpoints, divide the cable connecting the RF unit top to the antenna portinto several segments by using breakpoints. Disconnect the cable at the breakpoints oneby one along the direction from the RF unit top to the antenna port. Each time the cableis disconnected at a breakpoint, connect the breakpoint to a matched load or a low-intermodulation attenuator, add a downlink simulated load, and check whether theRTWP values increase. Ensure the inserted attenuator has low intermodulationinterference so that it will not add additional PIM interference to the cable. If the RTWPvalues increase, PIM interference is introduced by the device or cable before thisbreakpoint.For example, set four breakpoints from the RF unit top to the antenna port, as shown inFigure 14-8. At first, disconnect the cable at breakpoint 1, connect breakpoint 1 to alow-intermodulation attenuator, and add a downlink simulation load. If RTWP valuesdo not change, PIM interference is not caused by the RF unit. If RTWP values increase,PIM interference is caused by the RF unit. Perform the similar steps to the otherbreakpoints.



132

Figure 14-8 Schematic diagram for breakpoint-based PIM detection

If the interference is caused by the RF unit, replace the RF unit. If the interference is causedby the cable, replace the cable and then check whether the interference still exists. If theinterference is removed, no further action is required.If the interference persists, check whether the interference exists in the antenna.

3. Perform Broadband on-line frequency scan to check whether external interference exists.Observe the scan result until the ALM-26239 RX Channel RTWP/RSSI UnbalancedBetween RF Units alarm is reported. Then, send the local tracing results, running logs ofRF units, and investigation results to Huawei technical support for fault diagnosis.For the procedure for performing Broadband on-line frequency scan, see MonitoringeNodeB Performance in Real Time > Spectrum Detection in eNodeB LMT UserGuide.

4. Check whether a crossed pair connection exists.DescriptionRF channels in an RF unit must be used by the same sector except in MIMO mutual-aidscenarios. The purpose is to ensure the consistency between the direction and coverage ofan antenna so that balanced RTWP values are obtained. If the RF channels of an RF unitare used by different sectors, the RF unit will have different RTWP values. Note that theALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm is reported onlywhen the number of UEs is significantly different between two cells with a crossed pairconnection.The ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm caused by acrossed pair connection has the following characteristics:l The alarm is reported in at least two sectors under the same eNodeB.



133

l RTWP variations of different RF channels are uncorrelated.l RTWP variations are similar in different sectors.Troubleshooting MethodThe cells with a crossed pair connection can be determined by using either of the followingtwo methods:l Perform drive tests and trace signaling without interrupting the services.

Make a phone call in a cell (for example, cell 1). Check whether the UE accesses cell1, where the UE is located. If the UE accesses another cell (for example, cell 3), theantennas of cells 1 and 3 are cross-connected.

l Run the STR CROSFEEDTST command to start the a crossed pair connection test.If the antenna system is not equipped with an external filter, the Start TestFrequency and End Test Frequency parameters do not need to be specified. The testwill be performed in the test frequency band supported by the RF unit. If the antennasystem is equipped with an external filter, specify the Start Test Frequency and EndTest Frequency parameters to the start frequency and end frequency, respectively, forthe external filter.

NOTENote the following before starting a crossed pair connection test:

l This test is an offline test and the execution of this command interrupts services. If this commandis executed on a multi-mode RF unit or an RF unit connected to an antenna shared by the localand peer modes, the services of the peer mode carried by this RF unit are also interrupted.

l This test cannot be performed simultaneously with the VSWR test or distance to fault (DTF) test.

l This command applies to the scenario where RF modules are in 2T2R mode. If this command isexecuted in other scenarios, the result may be incorrect.

l The VSWR test has a great impact on the precision of this test because the VSWR will cause again loss. You are advised to perform a high-precision VSWR test before running this command.If the VSWR is greater than 2.5, you are not advised to run this command.

l This test cannot be applied to 1T2R RF units if RRU combination is not used. Otherwise, the resultmay be incorrect.

l This command does not apply to multi-RRU cells, distributed cells, or cells under the eNodeBwith an omnidirectional antenna.

l This command does not apply to the scenario where all antennas of one sector are connected toanother sector.

l Do not start this test if the number of sectors that work in the same frequency band and supportthe test is less than two.

l If the bandwidth between the start frequency and end frequency of the external filter is less than10 MHz, the execution output is not reliable.

The Crossed value of RESULT appears in pairs. If RESULT is Crossed for twosectors, a cross pair connection exists between the two sectors. Detailed informationabout the sectors with a crossed pair connection is displayed in the detection result.The result is similar to the following:To start a cross feeder test,run the following command:STR CROSFEEDTST:;The result is shown as follows:+++ HUAWEI 2012-02-02 10:54:58O&M #453%%STR CROSFEEDTST:;%%RETCODE = 0 Operation succeeded.Session ID = 65537(Number of results = 1)--- END+++ HUAWEI 2012-02-02 10:55:15



134

O&M #452%%STR CROSFEEDTST:;%%RETCODE = 0 Progress report, Operation succeeded.Report Type = Cross Feeder Test Progress Status = Success Session ID = 65537Cross Feeder Test Result------------------------Sector No. RESULT0 Normal1 Normal(Number of results = 2)--- END

Handling SuggestionAfter the sectors with a crossed pair connection are determined, adjust their antennaconnection. Since there are three types of crossed pair connections (main-main, main-diversity, and diversity-diversity), several rounds of antenna adjustment may be requiredbefore the test result verifies no crossed pair connection.

5. Check whether random electromagnetic interference exists.If the fault is not caused by the preceding factors, it may be caused by randomelectromagnetic interference. Occasional electromagnetic interference has a small impacton the network performance. Therefore, ignore it if the RTWP imbalance alarm is notfrequently triggered. If the RTWP imbalance alarm is frequently triggered, contact Huaweitechnical support.


Typical CasesNone

14.6 Troubleshooting ALD Link FaultsThis section provides information required to troubleshoot ALD link faults. The informationincludes fault descriptions, background information, possible causes, fault handling method andprocedure, and typical cases.

Fault DescriptionAn ALD-related alarm is reported if there are antenna line device (ALD) link faults in the radiofrequency (RF) channels of an RF unit.

Related InformationRelated alarms are as follows:

l ALM-26530 RF Unit ALD Current Out of Rangel ALM-26541 ALD Maintenance Link Failurel ALM-26751 RET Antenna Motor Faultl ALM-26754 RET Antenna Data Lossl ALM-26757 RET Antenna Running Data and Configuration Mismatchl ALM-26752 ALD Hardware Faultl ALM-26753 RET Antenna Not Calibrated



135

l ALM-26531 RF Unit ALD Switch Configuration Mismatch

Possible CausesPossible causes for ALD-related alarms are listed as follows:l The setting of the ALD power supply switch is improper.l The settings of the ALD current alarm thresholds are incorrect.l The ALD connections are abnormal.l The ALDs are faulty.


Fault Handling Procedure1. Rectify the faults and modify the improper settings.2. If the fault persists, contact Huawei technical support.

Typical CasesNone



136

15 Troubleshooting License Faults

About This Chapter

This chapter describes how to diagnose and handle license faults.

15.1 Definitions of License FaultsLicense faults are license-related alarms and faults that occur during eNodeB license installation.

15.2 Background InformationA license is an authorization agreement between the supplier and the operator on the use ofproducts. It defines the product features, versions, capacity, validity period, and applicationscope.

15.3 Troubleshooting MethodTo troubleshoot license faults, determine in which scenarios the license faults occur, for example,during license installation or during network running, and then take different measures.

15.4 Troubleshooting License Faults That Occur During License InstallationThis section provides information required to troubleshoot license faults that occur during licenseinstallation. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

15.5 Troubleshooting License Faults That Occur During Network RunningThis section provides information required to troubleshoot license faults that occur duringnetwork running. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

15.6 Troubleshooting License Faults That Occur During Network AdjustmentThis section provides information required to troubleshoot license faults that occur duringnetwork adjustment. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

eRANTroubleshooting Guide 15 Troubleshooting License Faults


137

15.1 Definitions of License FaultsLicense faults are license-related alarms and faults that occur during eNodeB license installation.

NOTEProblems that may be encountered during license application are not described in this document. For details,see eRAN License Management Feature Parameter Description.

15.2 Background InformationA license is an authorization agreement between the supplier and the operator on the use ofproducts. It defines the product features, versions, capacity, validity period, and applicationscope.

Operators can purchase the license to determine the network functions and capacity at a specificstage, maximizing the return on investment. For details, see eRAN License Management FeatureParameter Description.

15.3 Troubleshooting MethodTo troubleshoot license faults, determine in which scenarios the license faults occur, for example,during license installation or during network running, and then take different measures.

Possible CausesThe possible causes of license faults are as follows:

l Incorrect operationsl Misunderstanding over the license mechanisml Errors in license filesl Product defects

Troubleshooting FlowchartThe following figure shows the troubleshooting flowchart for license faults that occur in differentscenarios.



138

Figure 15-1 Troubleshooting flowchart for license faults

Troubleshooting Procedure1. Determine whether license faults occur during license installation. If so, perform the

procedure for troubleshooting license faults that occur during license Installation. If not,go to 2.

2. Determine whether license faults occur during network running. If so, perform theprocedure for troubleshooting license faults that occur during network running. If not, goto 3.

3. Determine whether license faults occur during network adjustment. If so, perform theprocedure for troubleshooting license faults that occur during network adjustment. If not,go to 4.

4. If the faults persist, contact Huawei technical support.

15.4 Troubleshooting License Faults That Occur DuringLicense Installation

This section provides information required to troubleshoot license faults that occur during licenseinstallation. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

Fault DescriptionIf license installation fails, the following error messages will be displayed in the MML commandoutput:



139

l License check failed; license serial number became invalid; the license file does not matchthe product; the license versions do not match.

l The license file has expired; the file type is DEMO.l The license control items do not match; the configured value exceeds the value in the license

file or the validity date of the control item is earlier than that in the license file.

Related Information

During license installation, the eNodeB checks the license. The check items are as follows:l Integrity check: Whether the product name in the license file matches the software name;

whether the checks on full-text signature, Service field signature, and feature signature aresuccessful.

l Accuracy check: Whether the equipment serial number (ESN) in the Service field matchesthe ESN of the equipment; whether the VR version number in the Service field matchesthe VR version of the software.

l Validity period check: Whether the license for the feature exceeds the validity date; whetherthe license for the feature exceeds the validity date and protection period.

l Difference check: Differences between new and old license files, including whether anyfunction items in the new license files are lost, whether any resource items are reduced orlost, and whether the validity period for the feature becomes short.

If the license check fails, the subsequent processing is as follows:

l If the integrity check fails, the license file installation fails.l If the accuracy check fails (the ESNs or the VR versions do not match), users need to

confirm whether to continue with the installation. If users choose to continue with theinstallation, the feature defined in the license file can run in trial mode for 60 days. After60 days, the feature enters the default mode. The license file with the same errors cannotbe installed repeatedly.

NOTE

l If the ESNs or VR versions do not match, the system runs based on the function items and resourceconfiguration defined in the license file. If the system does not read correct function items or resourceitems from the license file, the system runs with the minimum configuration.

l If the ESNs or VR versions do not match and the license for the feature exceeds the validity date andprotection period, the feature runs in default mode. Otherwise, the feature runs in trial mode.

l If there is a license file in which the ESNs or VR versions do not match on the system, a license filewith the same error as the existing license file cannot be installed. If a correct license file exists, alicense file in which the ESNs or VR versions do not match can also be installed.

l If the license file to be installed expires, that is, the license for all features exceeds the validity date,the license file installation fails. If only the license for some features exceeds the validity date, thelicense file can be installed and a message prompting that the license for some features exceeds thevalidity date is displayed.

l During license installation, if the function items, resource items, and validity period in the license fileare different from those in the previous license file, the installation result indicates the differences andthe user can choose to forcibly install the new license file.

l If the value of a license control item in the license file is smaller than the corresponding configuredvalue (for example, the number of cells), the license file fails to be installed.

Possible Causesl The ESNs, VR versions, or product types do not match.



140

l The license file has expired or the license file type is incorrect.l The system configuration items do not match the license control items.

Fault DiagnosisIf the license installation fails, an error message will be displayed in the MML command output.You can diagnose the fault based on the error message. For details, see eRAN LicenseManagement Feature Parameter Description.

Fault Handling1. Rectify the fault based on the error message by referring to eRAN License Management

Feature Parameter Description.2. If the fault persists, contact Huawei technical support.


After eNodeBs at a site were upgraded from eRAN2.0 to eRAN2.1, the eNodeBs experiencedfailures to install commercial licenses. The following error message was displayed:The configured value of the control item is greater than the value in the license file

Fault Diagnosis

During commercial license installation, the M2000 displayed the following message:The confitgred valued of the control item is greater than the value in the license fileThis message shows that the configured values on the current eNodeB exceeded the limits ofthe license file. Compare the license control items in the license file with the configuration thathas taken effect on the eNodeB to find the configuration items that have been activated on theeNodeB but were not authorized by the license file.

Fault Handling

1. Query the configured values on the eNodeB with the authorized values in the license file.Run the DSP LICENSE command to query the configured values on the eNodeB, andcompare the configured values with the allocated values in the license file. The commandoutput is as follows:

Figure 15-2 Querying license information

As shown in the figure, Allocated, Config, and Actual Used are the allocated value in thelicense file, the configured value on the eNodeB, and the actual value.



141

When the configured value on the eNodeB exceeds the allocated value in the license file,the following error message is displayed:Data Configuration Exceeding Licensed Limit

2. Check the functions not authorized by the license file.Find the configuration items that are activated (the Config value is set to 1) on the eNodeBbut not included in the license file.

3. Reinstall the license.Modify the eNodeB configuration, disable the functions not authorized by the license file,or apply for a new license file that includes these function items and in which the allocatedvalues are equal to or greater than the configured values on the eNodeB. Then, reinstall thelicense.


15.5 Troubleshooting License Faults That Occur DuringNetwork Running

This section provides information required to troubleshoot license faults that occur duringnetwork running. The information includes fault descriptions, background information, possiblecauses, fault handling method and procedure, and typical cases.

Fault Description

Related alarms and events are generated.

Related Informationl Related alarms

– ALM-26815 Licensed Feature Entering Keep-Alive Period

– ALM-26816 Licensed Feature Unusable

– ALM-26817 License on Trial

– ALM-26818 No License Running in System

– ALM-26819 Data Configuration Exceeding Licensed Limitl Related events

– EVT-26820 License Emergency Status Activated

– EVT-26821 License Emergency Status Ceased

Possible Causesl Licensed Feature Entering Keep-Alive Period

This alarm is generated when the licensed feature exceeds the validity date. You can runthe DSP LICENSE command to check the license control items that exceed the validitydate. After the licensed feature exceeds the validity date, the feature enters the keep-aliveperiod of 60 days (the keep-alive period is not affected by the system time jumping). Duringthe keep-alive period, the expired feature operates in the current license settings. After thekeep-alive period, the expired feature operates in the default license settings.

l Licensed Feature Unusable



142

This alarm is generated when the licensed feature exceeds the keep-alive period.

l License on Trial

This alarm is generated when a license file enters the keep-alive period. The possible causesare as follows:

– The license file exceeds the validity date.

– The license file is revoked.

– The ESN in the license file is inconsistent with the actual ESN of the eNodeB.

– The eNodeB version in the license file is inconsistent with the running version of theeNodeB.

– The ESN and eNodeB version in the license file are inconsistent with the actual ESNand the running version of the eNodeB.

l No License Running in System

This alarm is generated when there is no valid license file on the system. The possiblecauses are as follows:

– The license file exceeds the keep-alive period of 60 days.

– The license file is not found or errors occur during the license check when the systemis started.

l Data Configuration Exceeding Licensed Limit

This alarm is generated when the eNodeB configuration exceeds the limits of the license(including the default license). If this alarm is generated due to data modification duringthe system running, the original data configuration is used. If this alarm is generated duringthe system startup, the licensed specifications of the feature is used.

l License Emergency Status Activated

This event is generated when the license emergency status is activated. In the licenseemergency status, the eNodeB operates with the dynamic count-type resource items andperformance control items (such as traffic and number of users) reaching the maximumvalues, and the other control items remain unchanged.

l License Emergency Status Ceased

This event is generated when the license emergency status is ceased automatically sevendays after the eNodeB enters the emergency status or the license file is uploaded again tothe eNodeB in the emergency status.

Fault Diagnosis

Refer to the alarm reference documents to locate the alarm causes and clear the alarms.

Fault Handling1. Clear the alarms according to the alarm handling suggestions.


Typical Cases

None



143

15.6 Troubleshooting License Faults That Occur DuringNetwork Adjustment

This section provides information required to troubleshoot license faults that occur duringnetwork adjustment. The information includes fault descriptions, background information,possible causes, fault handling method and procedure, and typical cases.

Fault DescriptionAfter a command was run to enable a function, a configuration activation failure occurred dueto license restriction.

Figure 15-3 Example of a configuration activation failure due to license restriction

Related Informationl License control item classification

License control items are classified into resource items and function items. The DSPLICENSE command can be used to list all the control items on the maintenance console.– The allocated value for a resource item generally exceeds 1. Operators determine the

number of resource items in the commercial license they purchase based on the siterequirements. Typical resource items include the cell bandwidth, number of accessedusers, and number of cells.

– The function items are assigned values of 0 or 1 to indicate whether the functions arepurchased. The typical function items include enhanced synchronization (clocksynchronization), IPSec, and IEEE 802.1X-based access control.

License control items can be further classified into the following five categories based onthe configured value and usage:– Dynamic counting items (resource items): These items are passive control items without

requiring manual configuration. The configured value is NULL. These itemsdynamically occupy session resources. When a session starts, the occupied resourcesare counted and are subtracted from the total number of resources. When the sessionstops, the occupied resources are released.

– Performance items (resource items): These items are passive control items withoutrequiring manual configuration. The configured value is NULL. When the eNodeBstarts up, the eNodeB learns about the allocated values of these items by queries. During



144

eNodeB operation, the quantity of occupied resources is ensured to be less than theallocated values.

– Static counting items (resource items): These items are active control items and requiremanual configuration. The corresponding resources are statically configured resources.When the eNodeB starts up, the eNodeB obtains the configured values of these itemsfrom the configuration file and uses these configured values to apply for thecorresponding types of resource. When the eNodeB stops providing services, theresources are released.

– Boolean counting items (resource items): These items are active control items andrequire manual configuration. The corresponding resources are Boolean resources atthe NE's submodule level. When the eNodeB starts up, the eNodeB decides whether toapply for the corresponding resources based on the configured values (0 or 1). When asubmodule stops providing services, its resources are released.

– Boolean items (function items): These items are passive control items without requiringmanual configuration. The configured value is NULL, and the corresponding resourcesare NE-level Boolean resources. When the eNodeB starts up, the eNodeB checks thevalues of these items to see whether the corresponding functions are enabled.

l License control item description– Power: RF Output Power (per 20W) (FDD)

The power license controls the total required power of radio frequency (RF) modulesin an eNodeB. Each RF module provides 20 W power by default. Extra power must bepurchased in units of 20 W. If the eNodeB operates in default license mode, the licensedpower is 0 W by default.

– Bandwidth: Carrier Bandwidth (per 5MHz) (FDD)The bandwidth license controls the total required bandwidth of an eNodeB. In the LongTerm Evolution (LTE) system, bandwidth of each carrier is scalable. It can be 1.4 MHz,3 MHz, 5 MHz, 10 MHz, 15 MHz, or 20 MHz. Bandwidth is purchased in units of 5MHz.

– CSFB control itemThe control items for UTRAN, GERAN, and CDMA control the CSFB function forthese three radio access technologies (RATs).LLT1CFBU01: CSFB to UTRANLLT1CFBG01: CSFB to GERANLLT1CFBR01: CSFB (FDD) to CDMA2000 1xRTT

– eNodeB throughput: Throughput Capacity (per Mbps)This control item specifies the total licensed throughput of the eNodeB, which includesthe uplink and downlink throughput. Users can run the MOD LICRATIO commandto specify the proportion of licensed uplink throughput to the total licensed throughput.

Possible Causesl No license is running on the eNodeB.l The license for the eNodeB has expired, and the keep-alive period has expired.l The license for the eNodeB does not have the permission to apply for license control items.



145

Fault Handling FlowchartWhen this type of fault occurs, the message "Failed to activate the configuration because oflicense control" is displayed on the maintenance console. The following figure shows the faulthandling flowchart.

Figure 15-4 Fault handling flowchart

Fault Handling Procedure1. Check whether any license-related alarms are generated on the eNodeB.2. If license-related alarms are generated, clear the alarms by referring to eNodeB Alarm

Reference.3. If there are no license-related alarms, run the DSP LICENSE command to view the

allocated values and configured values for the current control items.4. Check whether the functions to be enabled on the eNodeB are authorized by control items

or whether the configured values exceed the allocated values in the license file.5. If the configured values exceed the allocated values, apply for a new license that meets

requirements and reinstall the license.6. If the fault persists, contact Huawei technical support.

Typical CasesNone



146

eran troubleshooting guide(v100r005c00_02)(pdf)-en

Documents