Huawei.pdf

eRAN11.1

eRAN Troubleshooting Guide Issue

Draft A

Date

2016-03-07

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent 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.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase 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 representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

i

eRAN11.1 eRAN Troubleshooting Guide

About This Document

About This Document Purpose This document describes how to diagnose and handle eRAN faults. Maintenance engineers can troubleshoot 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

Product Versions The following table lists the product versions related to this document. Product Name

Solution Version

Product Version

BTS3900

l SRAN11.1

V100R011C10

BTS3900A

l eRAN11.1

BTS3900L BTS3900AL BTS3202E BTS3911E DBS3900

l SRAN11.1

DBS3900 LampSite

l eRAN11.1 l eRAN TDD 11.1

Intended Audience This document is intended for: l

System engineers

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ii

eRAN11.1 eRAN Troubleshooting Guide

l

About This Document

Site maintenance engineers

Organization 1 Change Description This chapter describes the changes in eRAN Troubleshooting Guide. 2 Troubleshooting Process 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 for radio access technology. 6 Troubleshooting Service Drops This chapter describes the method and procedure for troubleshooting service drops in the Long Term Evolution (LTE) system. It also provides the definitions of service drops and related key performance indicator (KPI) formulas. 7 Troubleshooting Inter-RAT Handover Faults This section defines inter-RAT handover faults, describes handover principles, and provides the fault handling method and procedure. 8 Troubleshooting Rate Faults This chapter provides definitions of faults related to traffic rates and describes how to troubleshoot low uplink/downlink UDP/TCP rates and rate fluctuations. UDP is short for User Datagram 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 transmission faults. 11 Troubleshooting Application Layer Faults This chapter describes the definitions of application layer faults and the troubleshooting method. 12 Troubleshooting Transmission Synchronization Faults Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iii

eRAN11.1 eRAN Troubleshooting Guide

About This Document

This chapter describes how to troubleshoot transmission synchronization faults. The faults of this type include the clock reference problem, IP clock link fault, system clock unlocked fault, base station 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) unit faults in the Long Term Evolution (LTE) system. 15 Troubleshooting License Faults This chapter describes how to diagnose and handle license faults. 16 Wireless Fault Management Generally, when a radio performance fault or network-level performance fault occurs, OM engineers cannot quickly delimit the fault range and recover the service by resetting, powering off, or replacing corresponding boards. To address this issue, the FMA provides a radio performance fault analysis function, helping OM engineers quickly find the method of recovering services. Using this function, the troubleshooting efficiency is improved. 17 Collecting the Information Required for Fault Location When faults cannot be rectified by referring to this document, collect fault information for Huawei technical support to quickly troubleshoot the faults. This section describes how to collect fault information.

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

Description Indicates an imminently hazardous situation which, if not avoided, will result in death or serious injury. Indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury. Indicates a potentially hazardous situation which, if not avoided, may result in minor or moderate injury. Indicates a potentially hazardous situation which, if not avoided, could result in equipment damage, data loss, performance deterioration, or unanticipated results. NOTICE is used to address practices not related to personal injury.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iv

eRAN11.1 eRAN Troubleshooting Guide

About This Document

Symbol

Description Calls attention to important information, best practices and tips. NOTE is used to address information not related to personal injury, equipment damage, and environment deterioration.

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 in boldface. For example, log in as user root.

Italic

Book titles are in italics.

Courier New

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

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

Description

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 by vertical bars. One item is selected.

[ x | y | ... ]

Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected.

{ x | y | ... }*

Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected.

[ x | y | ... ]*

Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.

GUI Conventions Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

v

eRAN11.1 eRAN Troubleshooting Guide

About This Document

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

Description

Boldface

Buttons, menus, parameters, tabs, window, and dialog titles are 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.

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 means the 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 moving the pointer.

Double-click

Press the primary mouse button twice continuously and quickly without moving the pointer.

Drag

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

vi

eRAN11.1 eRAN Troubleshooting Guide

Contents

Contents About This Document.....................................................................................................................ii 1 Change Description.......................................................................................................................1 2 Troubleshooting Process.............................................................................................................. 2 2.1 General Troubleshooting Process................................................................................................................................... 3 2.2 Troubleshooting Methods............................................................................................................................................... 4 2.2.1 Data Backup................................................................................................................................................................ 4 2.2.2 Fault Information Collection....................................................................................................................................... 4 2.2.3 Determining the Fault Scope and Type....................................................................................................................... 6 2.2.4 Identifying Fault Causes.............................................................................................................................................. 8 2.2.5 Rectifying the Fault..................................................................................................................................................... 8 2.2.6 Checking Whether Faults Have Been Rectified.......................................................................................................... 8 2.2.7 Contacting Huawei Technical Support........................................................................................................................ 9

3 Common Maintenance Functions............................................................................................ 11 3.1 User Tracing................................................................................................................................................................. 12 3.2 Interface Tracing...........................................................................................................................................................12 3.3 Comparison/Interchange...............................................................................................................................................12 3.4 Switchover/Reset.......................................................................................................................................................... 12 3.5 MBTS Emergency OM Channel.................................................................................................................................. 13 3.5.1 Overview................................................................................................................................................................... 13 3.5.2 Application Scenarios................................................................................................................................................14 3.5.3 Emergency OM Channel Establishment....................................................................................................................16 3.5.4 Function Description................................................................................................................................................. 21 3.5.5 Troubleshooting......................................................................................................................................................... 25 3.5.6 Example of Using the Proxy MML Function............................................................................................................ 25 3.5.7 Other Operations........................................................................................................................................................30 3.6 Remote Query of Services on Disconnected eNodeBs.................................................................................................30 3.6.1 Overview................................................................................................................................................................... 31 3.6.2 Application Scenarios................................................................................................................................................31 3.6.3 Function Description................................................................................................................................................. 31 3.6.4 Troubleshooting......................................................................................................................................................... 34

4 Troubleshooting Access Faults................................................................................................. 35 4.1 Definitions of Access Faults.........................................................................................................................................36 Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

vii

eRAN11.1 eRAN Troubleshooting Guide

Contents

4.2 Background Information...............................................................................................................................................36 4.3 Troubleshooting Method...............................................................................................................................................38 4.4 Troubleshooting Access Faults Caused by Incorrect Parameter Configurations......................................................... 41 4.5 Troubleshooting Access Faults Caused by Radio Environment Abnormalities...........................................................47

5 Troubleshooting Intra-RAT Handover Faults....................................................................... 52 5.1 Definitions of Intra-RAT Handover Faults................................................................................................................... 53 5.2 Background Information...............................................................................................................................................53 5.3 Troubleshooting Method...............................................................................................................................................54 5.4 Troubleshooting Intra-RAT Handover Faults Caused by Hardware Faults..................................................................56 5.5 Troubleshooting Intra-RAT Handover Faults Caused by Incorrect Data Configurations............................................ 59 5.6 Troubleshooting Intra-RAT Handover Faults Caused by Target Cell Congestion....................................................... 61 5.7 Troubleshooting Intra-RAT Handover Faults Caused by Poor-Quality Uu Interface.................................................. 63

6 Troubleshooting Service Drops................................................................................................67 6.1 Definitions of Service Drop Faults............................................................................................................................... 69 6.2 Background Information...............................................................................................................................................69 6.3 Troubleshooting Method...............................................................................................................................................72 6.4 Troubleshooting Radio Faults.......................................................................................................................................74 6.5 Troubleshooting Transmission Faults...........................................................................................................................75 6.6 Troubleshooting Congestion.........................................................................................................................................76 6.7 Troubleshooting Handover Failures............................................................................................................................. 77 6.8 Troubleshooting MME Faults.......................................................................................................................................78

7 Troubleshooting Inter-RAT Handover Faults....................................................................... 81 7.1 Definitions of Inter-RAT Handover Faults................................................................................................................... 83 7.2 Background Information...............................................................................................................................................83 7.3 Troubleshooting Method...............................................................................................................................................83 7.4 Troubleshooting Inter-RAT Handover Faults Due to Hardware Faults........................................................................87 7.5 Troubleshooting Inter-RAT Handover Faults Due to Poor UE Capabilities................................................................ 90 7.6 Troubleshooting Inter-RAT Handover Faults Due to Incorrect Parameter Configurations..........................................93 7.7 Troubleshooting Inter-RAT Handover Faults Due to Target Cell Congestion............................................................. 96 7.8 Troubleshooting Inter-RAT Handover Faults Due to Incorrect EPC Configurations...................................................97 7.9 Troubleshooting Inter-RAT Handover Faults Due to Radio Environment Abnormalities........................................... 98 7.10 Troubleshooting Inter-RAT Handover Faults Due to Abnormal UEs...................................................................... 101

8 Troubleshooting Rate Faults................................................................................................... 103 8.1 Definitions of Rate Faults...........................................................................................................................................104 8.2 Background Information.............................................................................................................................................104 8.3 Troubleshooting Abnormal Single-UE Rates............................................................................................................. 107 8.4 Troubleshooting Abnormal Multi-UE Rates.............................................................................................................. 113

9 Troubleshooting Cell Unavailability Faults........................................................................ 116 9.1 Definitions of Cell Unavailability Faults....................................................................................................................117 9.2 Background Information.............................................................................................................................................117 Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

viii

eRAN11.1 eRAN Troubleshooting Guide

Contents

9.3 Troubleshooting Method.............................................................................................................................................118 9.4 Troubleshooting Cell Unavailability Faults Due to Incorrect Data Configuration.................................................... 120 9.5 Troubleshooting Cell Unavailability Faults Due to Abnormal Transport Resources.................................................122 9.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF Resources........................................................... 123 9.7 Troubleshooting Cell Unavailability Faults Due to Limited Capacity or Capability................................................. 126 9.8 Troubleshooting Cell Unavailability Faults Due to Faulty Hardware........................................................................127

10 Troubleshooting IP Transmission Faults........................................................................... 130 10.1 Definitions of IP Transmission Faults...................................................................................................................... 131 10.2 Background Information...........................................................................................................................................131 10.3 Troubleshooting Method...........................................................................................................................................131 10.4 Troubleshooting the Physical Layer......................................................................................................................... 132 10.5 Troubleshooting the Data Link Layer.......................................................................................................................135 10.6 Troubleshooting the IP Layer................................................................................................................................... 137

11 Troubleshooting Application Layer Faults........................................................................ 139 11.1 Definitions of Application Layer Faults................................................................................................................... 140 11.2 Background Information...........................................................................................................................................140 11.3 Troubleshooting Method...........................................................................................................................................140 11.4 Troubleshooting the SCTP Link............................................................................................................................... 141 11.5 Troubleshooting the IP Path......................................................................................................................................145 11.6 Troubleshooting the OM Channel............................................................................................................................ 146

12 Troubleshooting Transmission Synchronization Faults................................................. 149 12.1 Definitions of Transmission Synchronization Faults................................................................................................150 12.2 Background Information...........................................................................................................................................150 12.3 Troubleshooting Specific Transmission Synchronization Faults............................................................................. 150

13 Troubleshooting Transmission Security Faults................................................................ 154 13.1 Definitions of Transmission Security Faults............................................................................................................ 155 13.2 Background Information...........................................................................................................................................155 13.3 Troubleshooting Specific Transmission Security Faults.......................................................................................... 156

14 Troubleshooting RF Unit Faults........................................................................................... 165 14.1 Definitions of RF Unit Faults................................................................................................................................... 166 14.2 Background Information...........................................................................................................................................166 14.3 Troubleshooting Method...........................................................................................................................................171 14.4 Troubleshooting VSWR Faults.................................................................................................................................172 14.5 Troubleshooting RTWP Faults................................................................................................................................. 174 14.6 Troubleshooting ALD Link Faults........................................................................................................................... 180

15 Troubleshooting License Faults............................................................................................182 15.1 Definitions of License Faults....................................................................................................................................183 15.2 Background Information...........................................................................................................................................183 15.3 Troubleshooting Method...........................................................................................................................................183 15.4 Troubleshooting License Faults That Occur During License Installation................................................................184 Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ix

eRAN11.1 eRAN Troubleshooting Guide

Contents

15.5 Troubleshooting License Faults That Occur During Network Running...................................................................187 15.6 Troubleshoot License Faults That Occur During Network Adjustment...................................................................189

16 Wireless Fault Management.................................................................................................. 193 16.1 Overview of Wireless Fault Management................................................................................................................ 194 16.2 Starting Wireless Fault Management........................................................................................................................194 16.2.1 (Optional) Setting Parameters for Performance Fault Analysis............................................................................ 194 16.2.2 Starting Fault Overview.........................................................................................................................................195 16.2.3 Starting Fault Delimitation.................................................................................................................................... 200 16.2.4 Starting Information Collection.............................................................................................................................204 16.3 Appendix.................................................................................................................................................................. 204 16.3.1 KPIs Supported by Wireless Fault Management and Their Calculation Formulas...............................................204

17 Collecting the Information Required for Fault Location.................................................207 Index................................................................................................................................................223

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

x

eRAN11.1 eRAN Troubleshooting Guide

1 Change Description

1

Change Description

This chapter describes the changes in eRAN Troubleshooting Guide.

Draft A (2016-03-7) This is a draft. Compared with 01 (2015-12-31) of V100R010C10, this issue includes the following new information. Topic

Change History

3.6 Remote Query of Services on Disconnected eNodeBs

Added the function of querying resources and services on neighboring eNodeBs based on X2 interface tracing when neighboring eNodeBs are disconnected from the OSS.

Compared with 01 (2015-12-31) of V100R010C10, this issue includes the following changes. Topic

Change History

17 Collecting the Information Required for Fault Location

Added the method of using WebNIC to collect fault location information in cell DT tracing and spectrum detection.

No information in 01 (2015-12-31) of V100R010C10 is deleted from this issue.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

1

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

2

Troubleshooting Process

About This Chapter This chapter describes the general troubleshooting process and methods. 2.1 General Troubleshooting Process This section describes the troubleshooting procedure. 2.2 Troubleshooting Methods This section describes each step in the troubleshooting procedure in detail.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

2.1 General Troubleshooting Process This section describes the troubleshooting procedure. Figure 2-1 shows the troubleshooting flowchart. Figure 2-1 Troubleshooting flowchart

Table 2-1 details each step of the troubleshooting procedure. Table 2-1 Steps in the troubleshooting procedure No.

Step

Remarks

1

2.2.1 Data Backup

Data to be backed up includes the database, alarm information, and log files.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

No.

Step

Remarks

2

2.2.2 Fault Information Collection

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

3

2.2.3 Determining the Fault Scope and Type

Determine the fault scope and type based on the symptoms.

4

2.2.4 Identifying Fault Causes

Identify the fault causes based on the fault information and symptom.

5

2.2.5 Rectifying the Fault

Take appropriate measures or steps to rectify the fault.

6

2.2.6 Checking Whether Faults Have Been Rectified

Verify whether the fault is rectified.

2.2.7 Contacting Huawei Technical Support

If the fault type cannot be determined, or the fault cannot be rectified, contact Huawei technical support.

7

If the fault is rectified, the troubleshooting process ends. If the fault persists, check whether this fault falls in another fault type.

2.2 Troubleshooting Methods This section describes each step in the troubleshooting procedure in detail.

2.2.1 Data Backup To 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 eRAN Routine Maintenance Guide.

2.2.2 Fault Information Collection Fault information is essential to troubleshooting. Therefore, maintenance personnel should collect 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

l

Operations performed on the equipment before the fault occurs, and the results of these operations

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

4

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

l

Measures taken to deal with the fault, and the results

l

Alarms and correlated alarms when the fault occurs

l

Board indicator status when the fault occurs

Fault Information Collection Methods The methods for collecting fault information are as follows: l

Consult the person who reports the fault about the symptom, time, location, and frequency of 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 and the effect of these measures.

l

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

l

Estimate the scope and impact of the fault by means of service demonstration, performance measurement, 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 the fault.

l

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

Fault Information Classification Table 2-2 Fault information types Type

Attrib ute

Description

Original information

Definiti on

Original information includes the fault information reflected in user complaints, fault notifications from other offices, exceptions detected in maintenance, and the information collected by maintenance personnel through different channels in the early period when the fault is found. Original information is important for fault locating and analysis.

Functio n

Original information is used to determine the fault scope and fault category. Original information helps narrow the fault scope and locate the faults in the initial stage of troubleshooting. Original information can also help troubleshoot other faults, especially trunk faults.

Referen ce

None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

5

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

Type

Attrib ute

Description

Alarm information

Definiti on

Alarm information is the output of the eNodeB alarm system. It relates 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 for fault locating and analysis.

Functio n

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

Referen ce

For details about how to use the alarm system, see U2000 Online Help. For detailed information about each alarm, see eNodeB Alarm Reference.

Definiti on

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

Functio n

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

Referen ce

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

Definiti on

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

Functio n

Performance counters are used with signaling tracing and signaling analysis to locate causes of service faults such as a high service drop rate, low handover success rate, and service exception. They are generally used for the key performance indicator (KPI) analysis and performance monitoring of the entire network.

Referen ce

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

Indicator status

Performance counter

2.2.3 Determining the Fault Scope and Type Based on the fault symptom, determine the fault type. In this document, faults are classified according to symptoms. eRAN faults are classified into service faults and equipment faults.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

6

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

Service Faults Service faults are further classified into the following types: l

l

l

l

Access faults –

User access fails.

–

The access success rate is low.

Handover faults –

The intra-frequency handover success rate is low.

–

The inter-frequency handover success rate is low.

Service drop faults –

Service drops occur during handovers.

–

Services are unexpectedly released.

Inter-RAT interoperability faults Inter-RAT handovers cannot be normally performed.

l

Rate faults –

Data rates are low.

–

There is no data rate.

–

Data rates fluctuate.

Equipment Faults Equipment faults are further classified into the following types: l

l

l

l

l

Cell faults –

Cell setup fails.

–

Cell activation fails.

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.

Clock faults –

The clock source is faulty.

–

The IP clock link is faulty.

–

The system clock is out of lock.

Security faults –

The IPSec tunnel is abnormal.

–

SSL negotiation is abnormal.

–

Digital certificate processing is abnormal.

Radio frequency faults –

The standing wave is abnormal.

–

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

7

eRAN11.1 eRAN Troubleshooting Guide

– l

2 Troubleshooting Process

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

License faults –

License installation fails.

–

License modification fails.

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

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

Locating Service Faults The methods for locating different types of service faults are as follows: l

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

l

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

l

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

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

2.2.5 Rectifying the Fault To troubleshoot a fault, take proper measures to eliminate the fault and restore the system, including checking and repairing cables, replacing boards, modifying configuration data, switching over the system, and resetting boards. Maintenance personnel need to clear different faults using proper methods. After the fault is cleared, 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 Rectified Check the equipment running status, observe the board indicator status, and query alarm information to verify that the system is running properly. Perform testing to confirm that the fault has been cleared and that services return to normal. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

8

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

2.2.7 Contacting Huawei Technical Support If the fault type cannot be determined, or the fault cannot be cleared, contact Huawei technical support. If you need to contact Huawei technical support during troubleshooting, collect necessary information in advance.

Collecting General Fault Information General fault information includes the following: l

Name of the office

l

Name and phone number of the contact person

l

Time when the fault occurs

l

Detailed description of the fault symptoms

l

Host software version of the equipment

l

Measures taken after the fault occurs and the result

l

Severity 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 board (Applicable to 3900 series base stations only)

l

One-click logs of baseband boards (Applicable to 3900 series base stations only)

l

One-click logs of RRUs (Applicable to 3900 series base stations only)

l

One-click logs (Applicable to BTS3202E and BTS3911E only)

l

Alarm information

l

KPI data of the entire network

l

Intelligent field test system (IFTS) tracing

l

Cell drive test (DT) tracing

l

SCTP link tracing

l

Signaling tracing on interfaces

l

eNodeB configuration information

l

U2000 self-organizing network (SON) logs

l

U2000 adaptation logs

l

U2000 software module management logs

For details about how to collect fault information, see 3900 Series Base Station LMT User Guide, eNodeB Performance Monitoring Reference, eRAN Routine Maintenance Guide, and U2000 Online Help.

Contacting Huawei Technical Support The following lists the contact information of Huawei technical support: Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

9

eRAN11.1 eRAN Troubleshooting Guide

2 Troubleshooting Process

l

Contact the technical support personnel in the local Huawei office.

l

Email: [email protected]

l

Website: http://support.huawei.com

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

10

eRAN11.1 eRAN Troubleshooting Guide

3

3 Common Maintenance Functions

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 Tracing User tracing is a function that traces all messages of a user in sequence over standard and internal interfaces, traces internal status of the user equipment (UE), and displays the tracing results on the screen. 3.2 Interface Tracing Interface tracing is a function that traces all messages within a period in sequence on a standard or internal interface and displays them on the screen. 3.3 Comparison/Interchange Comparison and interchange are used to locate faults in a piece or pieces of equipment. 3.4 Switchover/Reset Switchover 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. 3.5 MBTS Emergency OM Channel This chapter describes the functions, application scenarios, and usage methods of MBTS emergency OM channel. 3.6 Remote Query of Services on Disconnected eNodeBs This section describes the function, application scenarios, and methods of remotely querying services on disconnected eNodeBs based on X2 interface tracing.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

11

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

3.1 User Tracing User tracing is a function that traces all messages of a user in sequence over standard and internal interfaces, traces internal status of the user equipment (UE), and displays the tracing results on the screen. User tracing has the following advantages: l

Real-time

l

Able to trace the user over all standard interfaces

l

Usable when traffic is heavy

l

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

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

3.2 Interface Tracing Interface tracing is a function that traces all messages within a period in sequence on a standard or internal interface and displays them on the screen. Interface tracing has the following advantages: l

Real-time

l

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

l

Able to trace link management messages

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

3.3 Comparison/Interchange Comparison 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 fault symptom with a functional component or normal condition, respectively. Interchange is a function used to locate a fault by interchanging a possibly faulty component with a functional component and comparing the running status before and after the interchange. Comparison usually applies in scenarios with a single fault. Interchange usually applies in scenarios with complicated faults.

3.4 Switchover/Reset Switchover 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. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

12

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Switchover switching of the active and standby roles of equipment so that the standby equipment takes over services. Comparing the running status before and after the switchover helps identify whether the originally active equipment is faulty or whether the active/standby relationship is normal. Reset is a means to manually restart part of or the entire equipment. It is used to identify whether 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 fault locating.

l

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

l

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

3.5 MBTS Emergency OM Channel This chapter describes the functions, application scenarios, and usage methods of MBTS emergency OM channel.

3.5.1 Overview If the OM channel of one mode in a separate-MPT MBTS fails, the available OM channels of other modes can be used for remote troubleshooting on the LMT for the base station whose OM channel is faulty. In this way, unnecessary site visit is avoided and fault location becomes efficient and cost-effective.

Function Introduction An emergency OM channel can be established between a GBTS and an eGBTS/NodeB/ eNodeB, or among the eGBTS, NodeB, and eNodeB, as shown in Figure 3-1 and Figure 3-2. A GBTS can only serve as the proxy base station instead of the target base station. A base station whose OM channel is normal can serve as the proxy base station; while a base station whose OM channel is faulty is the target base station. Figure 3-1 Emergency OM channel between a GBTS and an eGBTS/NodeB/eNodeB

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

13

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-2 Emergency OM channel among eGBTS, NodeB, and eNodeB

With an emergency OM channel, the Proxy MML and Proxy PNP Trace functions can be used on the proxy base station. For details about the functions, see 3.5.4 Function Description.

Security About the Emergency OM Channel If the security requirement of the target base station is higher than that of the proxy base station, using the emergency OM channel lowers the security of the target base station. For example, if a NodeB and an eNodeB serve as the proxy and target base stations, respectively and the OM channel encryption mechanism of the eNodeB is higher than that of the NodeB, using the emergency OM channel lowers the security of the eNodeB.

3.5.2 Application Scenarios This chapter describes the application scenarios for MBTS emergency OM channel. Read the following notes before establishing an emergency OM channel: l

The proxy base station and the target base station support different transport protocol stacks. Table 3-1 shows the transport protocol stacks supported by the proxy base station and the target base station. Table 3-1 Transport protocol stacks supported by the proxy and target base stations Transport Protocol Stack

Is Supported by Proxy Base Station?

Is Supported by Target Base Station?

TDM for GBTS

Yes

No

IP over E1 for GBTS/ eGBTS/NodeB

Yes

Yes

IP over Ethernet for GBTS/NodeB/eNodeB

Yes

Yes

ATM for NodeB

Yes

Yes

l

Either separate transmission or co-transmission can be used by the proxy and target base stations. In the co-transmission scenario, both panel and backplane interconnections can be used.

l

The proxy and target base stations can be configured with either one or multiple BBUs. At present, a maximum of two BBUs are supported.

l

Table 3-2 describes the MPT types and modes of the proxy and target base stations, which can be combined to support the emergency OM channel establishment.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

14

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Table 3-2 Combination of MPT types and modes of the proxy and target base stations MPT Type and Mode of Proxy Base Station

MPT Type and Mode of Target Base Station

GTMU

l WMPT l LMPT l UMPT_U l UMPT_L l UMPT_UL l LMPT

WMPT

l UMPT_L l UMPT_GL l WMPT

LMPT

l UMPT_U l UMPT_GU UMPT_G

l WMPT l LMPT l UMPT_UL l UMPT_U l UMPT_L

UMPT_U

l LMPT l UMPT_GL l UMPT_G l UMPT_L

UMPT_L

l WMPT l UMPT_GU l UMPT_G l UMPT_U

UMPT_GU

l LMPT l UMPT_L

UMPT_GL

l WMPT l UMPT_U

UMPT_UL

UMPT_G

When the emergency OM channel is enabled, the OM data is transmitted to the target base station through the OM channel of the proxy base station. The data rate on the OM channel of the GBTS is less than 64 kbit/s. Therefore, before enabling the emergency OM channel, ensure that the no congestion occurs on the OM channel of the proxy base station. Otherwise,

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

15

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

the emergency OM channel cannot work or services of the proxy base station will not be affected.

3.5.3 Emergency OM Channel Establishment This section describes how to establish an emergency OM channel and verify establishment results.

Establishment Method To establish an emergency OM channel, the proxy base station must be selected first and then the information of the target base station must be correctly configured. 1.

Select the proxy base station. The methods of confirming which base station can be selected as the proxy base stations are as follows –

If the base stations of all modes in a multi-mode base station are configured with the same DID, the U2000 automatically matches the proxy base station to the target base station. For example, MBTS-GUMUX+L3 separate-MPT base stations are in the same frame in the Main Topology window. Figure 3-3 Automatically matching the proxy base station to target base station

–

You can select the proxy base station according to the site planning of the operator, for example, by identifying the base stations with the same site name. If the GBTS serves as the proxy base station, you need to establish the emergency OM channel on the GBSC LMT. If the eGBTS/NodeB/eNodeB serves as the proxy

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

16

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

base station, you need to establish the emergency OM channel on the LMT of the corresponding base station. Take the GBTS as an example. Start the GBSC LMT on the U2000 by rightclicking the GBTS serving as the proxy base station and then choosing Maintenance Client from the shortcut menu, as shown in Figure 3-4. Figure 3-4 Selecting the proxy base station

2.

Establish the emergency OM channel. Figure 3-5 and Figure 3-6 show how to establish the emergency OM channel on the GBSC LMT and on the LMT of eGBTS/NodeB/eNodeB, respectively. Figure 3-5 Emergency OM channel establishment on the GBSC LMT

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

17

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-6 Emergency OM channel establishment on the LMT of eGBTS/NodeB/ eNodeB (taking the eGBTS as an example)

Figure 3-7 shows the parameter settings in different configuration scenarios. Figure 3-7 Parameter settings of GBSC

SN

Configuration Scenario

1

Single-BBU

2

Two-BBU (in multi-BBU scenario) with the subrack number of the target base station being 0

3

Two-BBU (in multi-BBU scenario) with the subrack number of the target base station being 1

Configuration notes are as follows: –

Issue Draft A (2016-03-07)

In single-BBU scenario, the following information of the target base station must be configured. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

18

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions n

Main Control Board Sot No.: This parameter can be set to 6 or 7.

n

User Name and Password: These two parameters specify the user name and password for logging in to the LMT. Note that the user name and password must have been granted administrator permissions. By default, the user name is admin and the password is hwbs@com. Both are case-sensitive. NOTE

If they have been changed, set the parameters to the new ones.

–

In multi-BBU scenario, in addition to the preceding information in single-BBU scenario, the inter-BBU topology information of base stations must also be configured. n

Main Control Board Subrack No.: This parameter specifies the number of the BBU housing the main control board of the target base station. This parameter is set to 0 and 1 if the main control board is configured in the root BBU and leaf BBU, respectively.

n

If the preceding parameter is set to 1, parameters in the CTRLLNK MO need to be configured. ○

CTPLLNK Parent Node Slot No.: This parameter is set to the number of the slot where the parent-node UMPT locates in UMPT interconnection scenario, and is set to the number of the slot where the parent-node UCIU locates in UCIU-UMPT interconnection scenario.

○

CTPLLNK Parent Node Port No.: This parameter is fixedly set to 8 in UMPT interconnection scenario, and is set to a value within the range of 0 to 4 in UCIU-UMPT interconnection scenario.

NOTICE If the parameter setting is inconsistent with the actual configuration, the OM channel may be connected to an incorrect board, therefore failing to establish the emergency OM channel.

Establishment Result Verification After an emergency OM channel is successfully established, a message indicating the successful establishment will be displayed on the Web LMT, as shown in Figure 3-8. Figure 3-8 Message for successful emergency OM channel establishment

If the emergency OM channel fails to be established, a message indicating the establishment failure will be displayed on the Web LMT, as shown in Figure 3-9. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

19

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-9 Message for emergency OM channel establishment failure

If the establishment fails, check and handle faults according to the following causes: l

The connection of the remote OM channel or local LMT of the target base station is normal. If the OM channel between the target base station and the U2000 is normal or the target base station is locally logged in to using the Web LMT, the emergency OM channel cannot be established.

NOTICE An emergency OM channel is an emergent troubleshooting method for fault scenarios. Its priority is lower than that of normal maintenance methods. In normal maintenance modes, do not establish emergency OM channels. l

An emergency OM channel has been established on the target or proxy base station. During the establishment of an emergency OM channel, a single main control board can serve as or is served by the proxy of only one main control board within the MBTS.

l

The emergency OM channel is immediately enabled after they automatically disable due to exceptions on the target or proxy base station. For example, the target or proxy base station resets, or the transmission on the emergency OM channel is interrupted for a period and then recovers. If an emergency OM channel disables abnormally, it retains between the target and proxy base stations within five minutes after the disabling and deletes automatically after five minutes.

l

The target base station does not support the establishment of the emergency OM channel. Emergency OM channel is unavailable if the GBTS serves as the target base station.

l

The number of emergency OM channels established on a GBSC exceeds the maximum value. Currently, a maximum of 30 emergency OM channels can be established on the GBTSs connecting to one GBSC. If the number exceeds the maximum value, a message indicating establishment failure will be displayed. In this case, existing emergency OM channels can be disabled so that a new emergency OM channel can be established.

l

Emergency OM channel establishment expires. Establishment expiration may be caused by location information configuration failure of the target base station, the main control board of the target base station being the standby board, or internal communication errors. The handling suggestions are as follows: a.

Ensure that the location information of the target base station is correctly configured.

b.

Ensure that the main control board of the target base station works in the active mode.

c.

Check whether the OM link is congested if the GBTS serves as the proxy base station. If yes, establish the emergency OM channel when the OM link is not congested.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

20

eRAN11.1 eRAN Troubleshooting Guide

l

3 Common Maintenance Functions

If the fault persists, contact Contacting Huawei Technical Support.

3.5.4 Function Description This chapter describes the function description of Proxy PNP Trace.

Proxy PNP Trace After the emergency channel is enabled, you can use the Proxy PNP Trace function on the proxy base station to start a PNP tracing task for the target base station so that remote monitoring can be performed for the PnP deployment of the target base station. NOTE

To start a proxy PNP tracing task on the GBSC LMT, information of the proxy base station must be specified.

The proxy PNP tracing task provides the same functions as a common PNP tracing task. Both can be started and stopped, and the tracing results can be automatically or manually saved.

NOTICE PNP tracing applies only to the IP protocol stack. Figure 3-10 and Figure 3-11 show the dialog box for setting parameters and the main window for showing tracing results of a proxy PNP tracing task on the GBSC LMT, respectively. Figure 3-10 Dialog box for setting parameter on the GBSC LMT

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

21

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-11 Main window for showing tracing results on the GBSC LMT

Figure 3-12 shows the main window for showing tracing results of a proxy PNP tracing task on the LMT of eGBTS/NodeB/eNodeB (taking the eGBTS as an example below). Figure 3-12 Main window for showing tracing results on the LMT of eGBTS/NodeB/eNodeB

Proxy MML After the emergency OM channel is established, MML commands can be delivered to the target base station. If the GBTS serves as the proxy base station, choose BTS Maintenance > MML By Proxy on the GBSC LMT, and then input the commands. l

Figure 3-13 shows the main window for using the Proxy MML function on the GBSC LMT.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

22

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-13 Main window for using Proxy MML on the GBSC LMT

The details about the Proxy MML function on the GBSC LMT are as follows:

l

–

Commands can only be manually input or copied to the MML command input area.

–

Batch execution of MML commands is supported. The user can input a maximum of 20 commands at a time and the LMT executes the commands one by one.

–

Commands can be entered, copied, pasted, and deleted.

–

Command outputs can be manually or automatically saved and can be cleared.

–

Format check can be performed for commands. However, semantic check and parameter check are not supported.

–

The command expiration complies with the expiration mechanism set for all commands on the LMT.

–

CTRL+Q can be pressed to stop ping commands.

Figure 3-14 shows the main window for using the Proxy MML function on the LMT of eGBTS/NodeB/eNodeB (taking the eGBTS as an example below).

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

23

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-14 Main window for using Proxy MML on the LMT of eGBTS/NodeB/ eNodeB

The details about the Proxy MML function on the LMT of eGBTS/NodeB/eNodeB are as follows: –

To deliver commands to the target base station, select the Use MML By Proxy check box. To execute commands on the proxy base station, clear the Use MML By Proxy check box.

–

Both the command outputs for the proxy and target base stations will be printed in the Common Maintenance tab page.

–

Command auto-displaying, parameter check, and semantic check are supported for commands of the target base station based on the Macro.ini of the proxy base station. The navigation tree, search, operation record, online help, historical command help, and execution function are the same as those of normal MML.

–

Performing the preceding checks based on the Macro.ini of the proxy base station may result in mismatch in MML command sets, parameters, and descriptions with those of the target base station. The differences are as follows:

–

Issue Draft A (2016-03-07)

n

RAT-related command sets: RAT-related commands cannot be delivered using the emergency OM channel.

n

Common command sets: ATM-related commands are not supported on GBTSs/eGBTSs and eNodeBs and IPv6-related commands are not supported on GBTSs and NodeBs. If a GBTS/eGBTS or an eNodeB serves as the proxy of a NodeB, ATM-related commands cannot be input. If a NodeB serves as the proxy of a GBTS/eGBTS or an eNodeB, ATM-related commands can be input but cannot be executed on the GBTS/eGBTS or eNodeB.

n

Online help and attribute information in notes: Only the online help and attribute information in notes of the proxy base station can displayed.

When the Use MML By Proxy check box is selected, only format check rather than semantic check can be performed for the commands entered or copied in the MML command input area. The commands are directly delivered to the target base station. These commands cannot be displayed in the Command History text box, which ensure that the commands having differences in two RATs can be normally input. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

24

eRAN11.1 eRAN Troubleshooting Guide

–

3 Common Maintenance Functions

CTRL+Q can be pressed to stop ping commands.

3.5.5 Troubleshooting This chapter provides methods of troubleshooting Proxy status and MML command execution exceptions.

Abnormal Proxy Status During the enabling or operation of proxy functions, the functions may automatically disable. The causes are as follows: l

The connection of the remote OM channel or local LMT of the target base station restores.

l

The communication among the Web LMT, proxy base station, and target base station is abnormal, or the proxy base station is busy.

For the first cause, the Web LMT displays a message and the target base station automatically switches to the normal OM channel for maintenance. For the second cause, whether the connection between the Web LMT and the proxy base station is normal must be checked first. If the connection is abnormal, restore the connection. If the connection is normal and the GBTS serves as the proxy base station, check whether the OM link is congested using an Abis interface tracing task. NOTE

If the connection is normal and the eGBTS/NodeB/eNodeB serves as the proxy base station, the bandwidth is large and OM link congestion seldom occurs. In this case, no message tracing is required for checking the congestion.

MML Command Execution Exception l

When the GBTS serves as the proxy base station, commands for querying logs, such as alarm logs and operation logs, generates a large number of messages to be reported. In this case, the commands may be discarded by the GBTS due to capability limitation. Therefore, it is not recommended such commands be executed on the emergency OM channel, especially when GTMUa is used as the main control board of the GBTS as its data processing capability is limited. n the preceding case, the command execution expiration is displayed.

l

Commands related to FTP file transfer fail to be executed due to the following reason: File transfer is based on FTP and the FTP server is on the LMT. An emergency OM channel only enables commands related to FTP file transfer to be delivered to the target base station and to be executed. However, the FTP server is unreachable, and therefore file transfer fails. If the multimode base station properly connects to the FTP server, commands related to FTP file transfer can be executed.

3.5.6 Example of Using the Proxy MML Function The emergency OM channel does not support the transmission of configuration file using an FTP server. Therefore, the OM channel must be established for the target base station as soon as possible using MML commands. This section describes how to establish an OM channel for the target base station using the Proxy MML function in separate transmission networking with an SeGW, separate transmission networking without an SeGW, and co-transmission networkingseparate transmission networking without an SeGW and co-transmission networking. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

25

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Separate Transmission Networking with an SeGW Figure 3-15 shows the separate transmission networking with an SeGW. Figure 3-15 Separate transmission networking with an SeGW

Assume that the OM channel of the eNodeB is faulty and the GBTS/eGBTS serves as the proxy base station. Establish the emergency OM channel for the eNodeB as follows: 1.

Configure the OM channel. a.

Disable f the DHCP detection. The following is a command example: SET DHCPSW: SWITCH=DISABLE;

b.

Add a cabinet. The following is a command example: ADD CABINET: CN=0, TYPE=APM30;

c.

Add a subrack. The following is a command example: ADD SUBRACK: CN=0, SRN=0, TYPE=BBU3900;

d.

Add a board. The following is a command example: ADD BRD: CN=0, SRN=0, SN=7, BT=UMPT:;

e.

Add an Ethernet port. The following is a command example: ADD ETHPORT: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PN=0, PA=COPPER, MTU=1500, SPEED=100M, DUPLEX=FULL, FC=OPEN:;

f.

Add the interface IP address for the OM channel. The following is a command example: ADD DEVIP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, IP="192.168.20.188", MASK="255.255.255.0":;

g.

Add the route for the OM channel. The following is a command example: ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=7, SBT=BASE_BOARD, DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP, NEXTHOP="192.168.20.1"; ADD IPRT: RTIDX=1, CN=0, SRN=0, SN=7, SBT=BASE_BOARD, DSTIP="192.168.90.90", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP, NEXTHOP="192.168.20.1";

h.

Add an OM channel. The following is a command example: ADD OMCH: FLAG=MASTER, IP="192.168.31.188", MASK="255.255.255.0", PEERIP="192.168.60.60", PEERMASK="255.255.255.0", BEAR=IPV4, BRT=YES, RTIDX=0, BINDSECONDARYRT=NO, CHECKTYPE=NONE:;

2.

Configure the IPSec tunnel. a.

Configure the local IKE. The following is a command example: SET IKECFG: IKELNM="IKECFG1", IKEKLI=20, IKEKLT=60, DSCP=48;

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

26

eRAN11.1 eRAN Troubleshooting Guide

b.

3 Common Maintenance Functions

Add the IKE proposal. The following is a command example: ADD IKEPROPOSAL: PROPID=10, ENCALG=3DES, AUTHALG=MD5, AUTHMETH=IKE_RSA_SIG, DHGRP=DH_GROUP14, DURATION=86400;

c.

Add the IKE peer. The following is a command example: ADD IKEPEER: PEERNAME="ike", PROPID=10, IKEVERSION=IKE_V1, EXCHMODE=MAIN, IDTYPE=IP, REMOTEIP="192.168.90.90", REMOTENAME="secgw", DPD=PERIODIC, DPDIDLETIME=20, DPDRETRI=4, DPDRETRN=6, LOCALIP="192.168.20.188";

d.

Add an ACL. The following is a command example: ADD ACL: ACLID=3000, ACLDESC="for IPsec";

e.

Add ACL rules to the ACL. The following is a command example: ADD ACLRULE: ACLID=3000, RULEID=1, ACTION=PERMIT, PT=IP, SIP="192.168.31.188", SWC="0.0.0.0", DIP="192.168.60.60", DWC="0.0.0.0", MDSCP=NO;

f.

Add the IPSec proposal. The following is a command example: ADD IPSECPROPOSAL: PROPNAME="prop0", ENCAPMODE=TUNNEL, TRANMODE=ESP, ESPAUTHALG=MD5,ESPENCALG=DES;

g.

Add the IPSec security policy. The following is a command example: ADD IPSECPOLICY: SPGN="Policy", SPSN=1, ACLID=3000, PROPNAME="prop0", PEERNAME="ike", PFS= DISABLE, LTCFG=LOCAL, LTS=86400, REPLAYWND=WND_DISABLE;

h.

Bind the IPSec security policy and the outgoing port. The following is a command example: ADD IPSECBIND: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, SPGN="Policy";

3.

If the base station has obtained the device certificate of the operator, perform the following operation to enable it to take effect. a.

Set the parameters related to the application certificate. The following is a command example: MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer ";

The base station automatically obtains the device certificate from the CA during PnP deployment or shares the device certificate with the main control board of another board. 4.

If the base station has not obtained the device certificate of the operator, manually obtain the certificate. The PKI process is as follows: a.

Specify the main control board for loading the device certificate on the eNodeB. The following is a command example: SET CERTDEPLOY: DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=7;

b.

Set the parameters related to certificate request template. The following is a command example: MOD CERTREQ: COMMNAME=ESN, USERADDINFO=".huawei.com", COUNTRY="CN", ORG="ITEF", ORGUNIT="Hw", STATEPROVINCENAME="sc", LOCALITY="cd", KEYUSAGE=DATA_ENCIPHERMENT-1&DIGITAL_SIGNATURE-1&KEY_AGREEMENT-1&KEY_ENCI PHERMENT-1, SIGNALG=SHA1, KEYSIZE=KEYSIZE1024, LOCALNAME="abcdefghijklmn.huawei.com", LOCALIP="192.168.20.188";

c.

Set the parameters related to the CA server of the operator. The following is a command example: ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1", URL="http://88.88.88.88:80/pkix/";

d.

Set the parameters required for device certificate application for the eNodeB. The following is a command example: REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1", APPCERT="OPKIDevCert.cer";

After the configuration takes effect, the certificate application starts. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

27

eRAN11.1 eRAN Troubleshooting Guide

e.

3 Common Maintenance Functions

Load the root certificate of the operator. The following is a command example: ADD TRUSTCERT: CERTNAME="OperationCA.cer";

f.

Set the parameters related to the application certificate. The following is a command example: MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer ";

g.

Set the tasks for periodically checking the certificate validity. The following is a command example: SET CERTCHKTSK: ISENABLE=ENABLE, PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;

h.

Download the CRL file. The following is a command example: DLD CERTFILE:IP="192.168.60.60",USR="admin",PWD="*****",SRCF="eNodeB.crl",DST F="eNodeB.crl";

i.

(Optional) Set the parameters related to CRL. The following is a command example: ADD CRL: CERTNAME="eNodeB.crl";

j.

(Optional) Set the parameters related to periodical CRL download task. The following is a command example: ADD CRLTSK: IP="192.168.86.86", USR="admin", PWD="*****", FILENAME="NodeB.crl", ISCRLTIME=DISABLE, TSKID=0, CRLGETMETHOD=FTP;

k.

(Optional) Set the CRL application policy. The following is a command example: SET CRLPOLICY: CRLPOLICY= NOVERIFY;

5.

Observe the OM Channel State and check whether the OM channel state is normal. The following is a command example: DSP OMCH: FLAG=MASTER;

6.

Observe the IPSec Tunnel. a.

Check the status of the IKE SA. Run the following command and check whether the SA FLAG is Ready in the command output: DSP IKESA: CN=0, SRN=0, SN=7, IKEVSN=IKE_V1, DSPMODE=VERBOSE, IKEPNM="peer", PHASE=PHASE1;

If yes, go to step 6.b. If no, IPSec fails to be activated. b.

Check the status of the IPSec SA. Run the following command and check whether IPSec SA data is displayed in the command output: DSP IPSECSA: CN=0, SRN=0, SN=7, SPGN="policy", SPSN=1;

If yes, this feature has been activated. c.

Check whether services are properly protected by the IPSec tunnel. Run the following command to check the ACL rules and determine whether services are properly protected by the IPSec tunnel: LST ACLRULE:;

7.

Observe PKI features. a.

Check the status of the device certificate. Run the following command and check whether the certificate loading state is normal in the command output: DSP APPCERT:;

If yes, the device certificate has been loaded on the eNodeB. b.

Check the status of the trust certificate. Run the following command and check whether the certificate loading state is normal in the command output: DSP TRUSTCERT:;

If yes, the trust certificate has been loaded on the eNodeB. c.

(Optional) Check the CRL status. Run the following command and check whether the certificate loading state is normal in the command output: DSP CRL:;

If yes, the CRL has been loaded on the eNodeB. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

28

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Separate Transmission Networking Without an SeGW Figure 3-16 shows the separate transmission networking without an SeGW. Figure 3-16 Separate transmission networking without an SeGW

Establish the emergency OM channel for the eNodeB as follows: 1.

Configure the OM channel. a.

Turn off the DHCP detection. The following is a command example: SET DHCPSW: SWITCH=DISABLE;

b.

Add a cabinet. The following is a command example: ADD CABINET: CN=0, TYPE=APM30;

c.

Add a subrack. The following is a command example: ADD SUBRACK: CN=0, SRN=0, TYPE=BBU3900;

d.

Add a board. The following is a command example: ADD BRD: CN=0, SRN=0, SN=7, BT=UMPT:;

e.

Add an Ethernet port. The following is a command example: ADD ETHPORT: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PN=0, PA=COPPER, MTU=1500, SPEED=100M, DUPLEX=FULL, FC=OPEN:;

f.

Add the interface IP address for the OM channel. The following is a command example: ADD DEVIP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, IP="192.168.20.188", MASK="255.255.255.0":;

g.

Add the route for the OM channel. The following is a command example: ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=7, SBT=BASE_BOARD, DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP, NEXTHOP="192.168.20.1"; ADD IPRT: RTIDX=1, CN=0, SRN=0, SN=7, SBT=BASE_BOARD, DSTIP="192.168.90.90", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP, NEXTHOP="192.168.20.1";

h.

Add an OM channel. The following is a command example: ADD OMCH: FLAG=MASTER, IP="192.168.31.188", MASK="255.255.255.0", PEERIP="192.168.60.60", PEERMASK="255.255.255.0", BEAR=IPV4, BRT=YES, RTIDX=0, BINDSECONDARYRT=NO, CHECKTYPE=NONE:;

2.

Observe the OM channel state and check whether the OM channel state is normal. The following is a command example: DSP OMCH: FLAG=MASTER;

Co-Transmission Networking Figure 3-17 shows the co-transmission networking. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

29

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-17 Co-transmission networking

Establish the emergency OM channel for the eNodeB as follows: 1.

Configure the OM channel. a.

Turn off the DHCP detection. The following is a command example: SET DHCPSW: SWITCH=DISABLE;

b.

Add a cabinet. The following is a command example: ADD CABINET: CN=0, TYPE=APM30;

c.

Add a subrack. The following is a command example: ADD SUBRACK: CN=0, SRN=0, TYPE=BBU3900;

d.

Add a board. The following is a command example: ADD BRD: CN=0, SRN=0, SN=6, BT=UMPT:;

e.

Add the route for the OM channel. The following is a command example: ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=6, SBT=BACK_BOARD, DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=IF, IFT=TUNNEL;

f.

Add an OM channel. The following is a command example: ADD OMCH: FLAG=MASTER, IP="192.168.31.188", MASK="255.255.255.0", PEERIP="192.168.60.60", PEERMASK="255.255.255.0", BEAR=IPV4, BRT=YES, RTIDX=0, BINDSECONDARYRT=NO, CHECKTYPE=NONE:;

2.

Check whether the OM channel state is normal. The following is a command example: DSP OMCH: FLAG=MASTER;

If no, the OM channel is faulty.

3.5.7 Other Operations This chapter describes the other operations of MBTS emergency OM channel.

Query the MAC Address of the Target Base Station To obtain the MAC address of the target base station, run the following command: DSP ETHPORT: CN=0, SRN=0, SN=7, SBT=BASE_BOARD;

Query the ESN of the Main Control Board in the Target Base Station To obtain the ESN of the main control board, run the following command: LST ESN:;

3.6 Remote Query of Services on Disconnected eNodeBs This section describes the function, application scenarios, and methods of remotely querying services on disconnected eNodeBs based on X2 interface tracing. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

30

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

3.6.1 Overview Function Introduction This function supports the query of resources and services on neighboring eNodeBs based on X2 interface tracing when neighboring eNodeBs are disconnected from the OSS. Figure 3-18 Remote query of services on disconnected eNodeBs

3.6.2 Application Scenarios When an eNodeB is disconnected from the OSS, services on the eNodeB must be timely queried to check whether the services are interrupted. Whether the fault is reported is based on the query results, and accordingly the fault level is determined.

3.6.3 Function Description 1.

Query the X2 interface state of the disconnected peer eNodeB. Run the DSP X2INTERFACE command.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

31

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-19 Checking command outputs

NOTE

l If the X2 interface is normal, go to the next step. l If the X2 interface is abnormal, the disconnected peer eNodeB may experience transmission failures, and the eNodeB operating state cannot be queried based on X2 interface tracing.

2.

Start an X2 interface tracing task. a.

Create an X2 interface tracing task by choosing Monitor > Signaling Trace > Signaling Trace Management > LTE > Application Layer > X2 Interface Trace.

b.

Specify the ID of the peer eNodeB to be traced, as shown in Figure 3-20. Figure 3-20 Specifying the ID of the peer eNodeB to be traced

c. 3.

Click Finish to start the X2 interface tracing task.

Run an MML command to report services on the neighboring eNodeB.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

32

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Run the CHK NBRENODEB: NbrENodeBId=xx, Mcc="xx", Mnc="xx" command, as shown in Figure 3-21. Figure 3-21 Running the CHK NBRENODEB command

NOTE

This command is used to query response messages from neighboring eNodeBs, which facilitates service query on neighboring eNodeBs.

4.

Query services on the neighboring eNodeB. a.

In X2 interface tracing results, query the RESOURCE STATUS UPDATE message sent from the disconnected peer eNodeB, as shown in Figure 3-22. Figure 3-22 Querying the RESOURCE STATUS UPDATE message

b.

Among the messages traced over the X2 interface, the local eNodeB sends the peer eNodeB a RESOURCE STATUS REQUEST message, instructing the peer eNodeB to report service status, as shown in Figure 3-23. Figure 3-23 Instructing the peer eNodeB to report service status

c.

Issue Draft A (2016-03-07)

Check service status on the peer eNodeB sending the RESOURCE STATUS UPDATE message, as shown in Figure 3-24.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

33

eRAN11.1 eRAN Troubleshooting Guide

3 Common Maintenance Functions

Figure 3-24 Checking service status on the peer eNodeB

d.

After receiving the first RESOURCE STATUS UPDATE message sent from the peer eNodeB, the local eNodeB sends the peer eNodeB another RESOURCE STATUS REQUEST message, instructing the peer eNodeB to stop reporting service status, as shown in Figure 3-25. Figure 3-25 Instructing the peer eNodeB to stop reporting service status

3.6.4 Troubleshooting If no messages sent from the disconnected peer eNodeB can be found in the X2 interface tracing results, repeatedly execute the CHK NBRENODEB command and then check whether messages sent from the peer eNodeB are received.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

34

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

4

Troubleshooting Access Faults

About This Chapter This chapter describes how to diagnose and handle access faults. 4.1 Definitions of Access Faults If 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 Information This section provides counters and alarms related to access faults, and methods for analyzing topN cells. 4.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause. 4.4 Troubleshooting Access Faults Caused by Incorrect Parameter Configurations This section provides information required to troubleshoot access faults due to incorrect parameter configurations. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 4.5 Troubleshooting Access Faults Caused by Radio Environment Abnormalities This section provides information required to troubleshoot access faults due to radio environment abnormalities. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

35

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

4.1 Definitions of Access Faults If 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 Information This section provides counters and alarms related to access faults, and methods for analyzing topN 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 access success rate is a key performance indicator (KPI) that quantifies end user experience. An excessively low access success rate indicates that end users have difficulty making mobile-originated or mobile-terminated calls.

Related Counters l

Measurement related to RRC setup (RRC.Setup.Cell)

l

Measurement related to RRC setup failure (RRC.SetupFail.Cell)

l

Measurement related to E-RAB establish (E-RAB.Est.Cell)

l

Measurement related to E-RAB establish failure (E-RAB.EstFail.Cell)

For 3900 series base stations, see eNodeB Performance Counter Reference. For the BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see BTS3911E Performance Counter Reference

Related Alarms l

l

Hardware-related alarms –

ALM-26104 Board Temperature Unacceptable

–

ALM-26106 Board Clock Input Unavailable (Applicable to 3900 series base stations only)

–

ALM-26107 Board Input Voltage Out of Range (Applicable to 3900 series base stations only)

–

ALM-26200 Board Hardware Fault

–

ALM-26202 Board Overload

–

ALM-26203 Board Software Program Error

–

ALM-26208 Board File System Damaged

Temperature-related alarms (Applicable to 3900 series base stations only) –

ALM-25650 Ambient Temperature Unacceptable

–

ALM-25651 Ambient Humidity Unacceptable

–

ALM-25652 Cabinet Temperature Unacceptable

–

ALM-25653 Cabinet Humidity Unacceptable

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

36

eRAN11.1 eRAN Troubleshooting Guide

l

l

l

l

4 Troubleshooting Access Faults

–

ALM-25655 Cabinet Air Outlet Temperature Unacceptable

–

ALM-25656 Cabinet Air Inlet Temperature Unacceptable

Link-related alarms –

ALM-25880 Ethernet Link Fault

–

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

–

ALM-25889 SCTP Link Congestion

–

ALM-26233 BBU CPRI Optical Interface Performance Degraded (Applicable to 3900 series base stations only)

–

ALM-26234 BBU CPRI Interface Error (Applicable to 3900 series base stations only)

–

ALM-29201 S1 Interface Fault

–

ALM-29207 eNodeB Control Plane Transmission Interruption

–

ALM-25904 IP Link Performance Measurement Fault

RF-related alarms –

ALM-26239 RX Channel RTWP/RSSI Unbalanced Between RF Units (Applicable to 3900 series base stations only)

–

ALM-26520 RF Unit TX Channel Gain Out of Range

–

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

–

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

–

ALM-26527 RF Unit Input Power Out of Range

–

ALM-26534 RF Unit Overload

–

ALM-26562 RF Unit and RET Antenna Connection Failure (Applicable to 3900 series base stations only)

–

ALM-26524 RF Unit PA Overcurrent

–

ALM-29248 RF Out of Service

Configuration-related alarms –

ALM-26245 Configuration Data Inconsistency

–

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

Cell-related alarms –

ALM-29240 Cell Unavailable

–

ALM-29241 Cell Reconfiguration Failed

–

ALM-29245 Cell Blocked

TopN Cell Selection TopN cells can be selected by analyzing the daily KPI file exported by the U2000. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

37

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

l

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

l

Top3 cells with the largest amounts of failed E-RAB setups and lowest E-RAB setup success 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 ERAB setup fails. In addition, after the Evolved Packet Core (EPC) obtains the international mobile subscriber identity (IMSI) of the UE with the lowest success rate based on the UE's temporary mobile subscriber identity (TMSI), you can start a task to trace the UE throughout the whole network.

Analyzing Environmental Interference to TopN Cells Environmental 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 environmental interference: l

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

l

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

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

Possible Causes Scenario

Fault Description

Possible Causes

The RRC connection fails to be set up.

l The UE cannot search cells.

l Parameters of the UE or eNodeB are incorrectly configured.

l A fault occurs in radio interface processing. l Top user problems occur.

l The radio environment is abnormal. l The UE is abnormal.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

38

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Scenario

Fault Description

Possible Causes

The E-RAB fails to be set up.

l Resources are insufficient.

l Parameters of the UE or eNodeB are incorrectly configured.

l A fault occurs in radio interface processing. l The EPC is abnormal. l Top user problems occur.

l The radio environment is abnormal. l Parameters of the Evolved Packet Core (EPC) are incorrectly configured. l The UE is abnormal.

Troubleshooting Flowchart Figure 4-1 shows the troubleshooting flowchart for handling low RRC connection setup rate and low E-RAB setup rate.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

39

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Figure 4-1 Troubleshooting flowchart for handling low RRC connection setup rate and low E-RAB setup rate

Troubleshooting Procedure 1.

Select topN cells.

2.

Check whether parameters of the UE or eNodeB are incorrectly configured.

3.

4.

5.

–

Yes: Correct the parameter configurations. Go to 3.

–

No: Go to 4.

Check whether the fault is rectified. –

Yes: End.

–

No: Go to 4.

Check whether the radio environment is abnormal. –

Yes: Handle abnormalities in the radio environment. Go to 5.

–

No: Go to 6.

Check whether the fault is rectified.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

40

eRAN11.1 eRAN Troubleshooting Guide

6.

7.

8.

4 Troubleshooting Access Faults

–

Yes: End.

–

No: Go to 6.

Check whether parameters of the EPC are incorrectly configured. –

Yes: Correct the parameter configurations. Go to 7.

–

No: Go to 8.

Check whether the fault is rectified. –

Yes: End.

–

No: Go to 8.

Contact Huawei technical support.

4.4 Troubleshooting Access Faults Caused by Incorrect Parameter Configurations This section provides information required to troubleshoot access faults due to incorrect parameter configurations. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description l

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 counter L.RRC.ConnReq.Att is 0.

l

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

l

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

l

According to the values of the performance counters on the eNodeB side, the number of RRC connections that are successfully set up is much greater than the number of ERABs that are successfully set up.

l

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

Related Information None

Possible Causes l

Cell parameters are incorrectly configured. For example, the E-UTRA absolute radio frequency number (EARFCN), public land mobile network (PLMN) ID, threshold used in the evaluation of cell camping, pilot strength, and access class.

l

The UE has special requirements for authentication and encryption.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

41

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

l

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

l

The authentication and encryption algorithms are incorrectly configured on the Evolved Packet Core (EPC).

l

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

Troubleshooting Flowchart Figure 4-2 Troubleshooting flowchart for access faults due to incorrect parameter configurations

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

42

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Troubleshooting Procedure 1.

Check whether cell parameters are incorrectly configured. Pay special attention to the following parameter settings as they are often incorrectly configured: the EARFCN, PLMN ID, 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 and encryption functions are required. Yes: Enable the authentication and encryption functions. Go to 4. No: Go to 5.

4.

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

5.

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

6.

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

7.

Check whether the authentication and encryption algorithms are incorrectly configured on the 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.

8.

Check whether the fault is rectified. Yes: End. 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.

10. Check whether the fault is rectified. Yes: End. 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. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

43

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

12. Check whether the fault is rectified. Yes: End. No: Go to 13. 13. Contact Huawei technical support.

Typical Cases l

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 and encryption functions were enabled on the EPC. Fault Diagnosis a.

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

b.

The signaling at the EPC side was traced. According to the tracing result shown in Figure 4-4, the access attempt was rejected by the HSS in the diameterauthorization-rejected(5003) message. Figure 4-4 Tracing result of the signaling at the EPC side

c.

Issue Draft A (2016-03-07)

The UE was checked. Specifically, the configuration, registration information, and the 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 from a UE using a SIM card, the EPC would reply a diameter-authorizationrejected message. Figure 4-5 shows a snapshot of the related section in 3GPP TS 29.272. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

44

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Figure 4-5 Related section in the protocol

In conclusion, the E398 UE was unable to access the network because the UE used a SIM card. To access an LTE network, the UE must use a USIM card. Fault Handling The SIM card in the E398 UE was replaced by a USIM card. Then, the authentication procedure 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 transport resource configurations. Fault Description According to the KPIs for a site, the E-RAB setup success rate deteriorated intermittently. Fault Diagnosis a.

Issue Draft A (2016-03-07)

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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

45

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Figure 4-6 Snapshot of the S1AP_INITIAL_CONTEXT_SETUP_FAIL message

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

The IP address contained in the S1AP_INITIAL_CONTEXT_SETUP_REQ message was 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 the IPPATH MO. Figure 4-7 shows the details of the S1AP_INITIAL_CONTEXT_SETUP_REQ message. Figure 4-7 Snapshot of the S1AP_INITIAL_CONTEXT_SETUP_REQ message

c.

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, the E-RAB failed to be set up.

Fault Handling Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

46

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

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

4.5 Troubleshooting Access Faults Caused by Radio Environment Abnormalities This section provides information required to troubleshoot access faults due to radio environment abnormalities. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description l

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.

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

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

l

Investigating weak coverage The reference signal received power (RSRP) values reported by UEs during their access need to be investigated. If most of these values are relatively low, it is highly probable that the 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 be investigated so that users can determine whether wide coverage or cross-cell coverage occurs.

l

Investigating the imbalance between UL and DL quality The transmit power of the remote radio unit (RRU) and UE need to be investigated to check whether UL or DL limitations have occurred, because imbalance between UL and DL quality 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 hardware If two antennas are used, the tilt and azimuth of each antenna need to be investigated. If their tilts or azimuths are significantly different from each other, adjust them so that their tilts and azimuths are the same.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

47

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

The jumper connection needs to be investigated by analyzing drive test results. If the jumper is reversely connected, the UL signal level will be much lower than the DL signal level in the 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, water immersed, bending, or not securely connected, a large number of call drops will occur. If a voltage standing wave ratio (VSWR) alarm is reported, such problems exist and you need to replace the faulty feeder. Figure 4-8 and Figure 4-9 show common causes of random access failures and E-RAB setup failures, respectively. Figure 4-8 Common causes of random access failures

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

Possible Causes l

The cell provides weak coverage.

l

The UE does not use the maximum transmit power.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

48

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

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 advised to first find out whether this fault is caused by radio interference or weak coverage. The following procedure is recommended:

Troubleshooting Procedure 1.

Check whether related alarms are reported. Yes: Handle the alarms. For 3900 series base stations, see eNodeB Alarm Reference. For the BTS3202E, see BTS3202E Alarm Reference. For the BTS3911E, see BTS3911E Alarm Reference. Go to 2. No: Go to 3.

2.

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

3.

Check whether interference exists. By using a spectral scanner, check whether there is DL interference from neighboring cells or external systems. By analyzing the cell interference detection result, check whether there is UL interference. Yes: Minimize the interference. Go to 4. No: Go to 5.

4.

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

5.

Check whether the transmit power of the RRU and UE falls beyond link budgets. Yes: Adjust the UL and DL transmit power. Go to 6. No: Go to 7.

6.

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

7.

Check whether cell coverage is abnormal. Yes: Based on the RSRP distribution of the UEs attempting to access the cell, investigate and handle possible coverage, interference, and imbalance between UL and DL quality by using drive tests. Go to 8. No: Go to 9.

8.

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

9.

Contact Huawei technical support.

Typical Cases Fault Description Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

49

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

According to the KPIs for an eNodeB at a site, the RRC connection setup success rate fluctuated significantly within a period. Fault Diagnosis 1.

The KPIs were checked. For local cell 1, the daily RRC connection success rate was only 52%. Figure 4-10 PRS KPI about RRC connection setups

2.

The signaling over the Uu interface was traced. The result indicated that all RRC connection setup failures occurred because UEs do not respond. The following figure shows a snapshot of the signaling traced over the Uu interface. Figure 4-11 Signaling traced over the Uu interface

3.

Simulated load was added to the LTE side. The impact of the DL LTE signals on the DL GSM 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 dB was found within the high-frequency resource blocks (RBs), which affected signaling transmission.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

50

eRAN11.1 eRAN Troubleshooting Guide

4 Troubleshooting Access Faults

Figure 4-12 Online precise spectral scan result

5.

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

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

51

eRAN11.1 eRAN Troubleshooting Guide

5

5 Troubleshooting Intra-RAT Handover Faults

Troubleshooting Intra-RAT Handover Faults

About This Chapter This chapter describes how to diagnose and handle intra-RAT handover faults. RAT is short for radio access technology. 5.1 Definitions of Intra-RAT Handover Faults If an intra-RAT handover fault occurs, UEs have difficulty performing intra-RAT handovers due to system faults. 5.2 Background Information This section describes counters and alarms related to intra-RAT handover faults. In addition, this section provides intra-RAT handover procedures. 5.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause. 5.4 Troubleshooting Intra-RAT Handover Faults Caused by Hardware Faults This section provides information required to troubleshoot intra-RAT handover faults due to hardware faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 5.5 Troubleshooting Intra-RAT Handover Faults Caused by Incorrect Data Configurations This section provides information required to troubleshoot intra-RAT handover faults due to incorrect data configurations. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 5.6 Troubleshooting Intra-RAT Handover Faults Caused by Target Cell Congestion This section provides information required to troubleshoot intra-RAT handover faults due to target 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 Caused by Poor-Quality Uu Interface This section provides information required to troubleshoot intra-RAT handover faults due to poor Uu quality. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

52

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

5.1 Definitions of Intra-RAT Handover Faults If an intra-RAT handover fault occurs, UEs have difficulty performing intra-RAT handovers due to system faults.

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

Related Counters l

Measurement related to Intra eRan HOOUT (HO.eRAN.Out.Cell)

l

Measurement related to Intra eRan HOIN (HO.eRAN.In.Cell)

For 3900 series base stations, see eNodeB Performance Counter Reference. For the BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see BTS3911E Performance Counter Reference

Related Alarms l

Board overload alarm –

l

l

Alarms related to RF modules –

ALM-26529 RF Unit VSWR Threshold Crossed

–

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

Cell capability degraded alarm –

l

l

l

ALM-26202 Board Overload

ALM-29243 Cell Capability Degraded

Alarms related to CPRI links (Applicable to 3900 series base stations only) –

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

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 (Applicable to 3900 series base stations only)

Alarms related to transmission faults –

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

53

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

–

ALM-25952 User Plane Path Fault

–

ALM-29201 S1 Interface Fault

Handover Procedures Handovers are classified as coverage-based, load-based, frequency-priority-based, servicebased, and UL-quality-based. For details, see eRAN Mobility Management in Connected Mode Feature Parameter Description.

5.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause.

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 need to 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 network experiences abnormalities.

l The performance counters throughout the whole network are abnormal.

l Network parameters are incorrectly configured. l The signaling exchange procedure is incorrect.

l Related alarms are reported. A single eNodeB experiences abnormalities.

l The performance counters for the serving cell are abnormal.

l Hardware is faulty. l Parameters are set to inappropriate values.

l Related alarms are reported.

l The target cell is congested.

l Handovers to neighboring cells are seldom initiated.

l The Uu quality is poor.

l Handovers to neighboring cells are frequently initiated. l The UE cannot receive handover commands from the network.

Troubleshooting Flowchart The following measures are effective in locating a handover fault: Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

54

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

l

Analyzing handover-related performance counters

l

Investigating topN cells

l

Checking alarms related to devices or data transmission

l

Checking the configurations of neighboring cells

l

Checking handover algorithm configurations

l

Investigating interference and cell coverage

To locate an intra-RAT handover fault, you are advised to select topN cells with handover faults and then follow the troubleshooting procedure shown in Figure 5-1. Figure 5-1 Troubleshooting flowchart for intra-RAT handover faults

Troubleshooting Procedure 1.

Check whether the hardware is faulty. Hardware faults are the most likely cause if handovers suddenly become abnormal without recent modifications to the configurations of the abnormal cell and its neighboring cells.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

55

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

Yes: Hardware faults are often accompanied by alarms. You are advised to handle the fault by 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. No: Go to 3.

3.

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

4.

Check whether the fault is rectified. Yes: End. 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 target cell is severely congested. Yes: Follow the instructions on how to troubleshoot handover faults due to target cell congestion. Go to 6. No: Go to 7.

6.

Check whether the fault is rectified. Yes: End. 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.

8.

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

9.

Contact Huawei technical support.

5.4 Troubleshooting Intra-RAT Handover Faults Caused by Hardware Faults This section provides information required to troubleshoot intra-RAT handover faults due to hardware faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

56

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

Fault Description Typical 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 or even become out of service, in addition to the following symptoms: l

l

Abnormal cell-level performance counters –

Increased service drop rate

–

Decreased handover success rate

–

Decreased access success rate

Related alarms

Related Information Related Alarms l

Board overload alarm –

l

l

Alarms related to RF modules –

ALM-26529 RF Unit VSWR Threshold Crossed

–

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

Cell capability degraded alarm –

l

l

l

ALM-26202 Board Overload

ALM-29243 Cell Capability Degraded

Alarms related to CPRI links (Applicable to 3900 series base stations only) –

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

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 (Applicable to 3900 series base stations only)

Alarms related to transmission faults –

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

–

ALM-25952 User Plane Path Fault

–

ALM-29201 S1 Interface Fault

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

A board is overloaded.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

57

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

l

An RF module is faulty.

l

A common public radio interface (CPRI) link is faulty. (Applicable to 3900 series base stations only)

l

A clock source is faulty.

Troubleshooting Flowchart Figure 5-2 shows the troubleshooting flowchart for intra-RAT handover faults due to hardware faults. Figure 5-2 Troubleshooting flowchart for intra-RAT handover faults due to hardware faults

Troubleshooting Procedure 1.

Check whether a hardware fault alarm is reported. Yes: Handle the hardware fault alarm. Go to 2. No: Go to 3.

2.

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

3.

Contact Huawei technical support.

Typical Cases Fault Description Handovers between cell 0 and cell 2 under an eNodeB were normal with a high success rate, but the handovers from cell 1 under the eNodeB to its neighboring cells were abnormal with a relatively low success rate (7%) during busy hours. Fault Diagnosis 1.

Alarms about the eNodeB were checked. Cell 1 had reported ALM-26529 RF Unit VSWR Threshold 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 site reconstruction.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

58

eRAN11.1 eRAN Troubleshooting Guide

3.

5 Troubleshooting Intra-RAT Handover Faults

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

Fault Handling The jumper was securely connected to the feeder. According to the KPI log, the inter-cell handover success rate was restored.

5.5 Troubleshooting Intra-RAT Handover Faults Caused by Incorrect Data Configurations This section provides information required to troubleshoot intra-RAT handover faults due to incorrect data configurations. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description l

Handovers to neighboring cells are seldom initiated. According to drive test results or signaling tracing results, the UE experiences relatively low signal quality in its serving cell. The signal level of neighboring cells meets the threshold for a handover, but handovers occur with a low probability This leads to a high service 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 serving cell, but handovers to the neighboring cells are frequently initiated. This leads to poor quality of voice services and a high probability of service drops.

Related Information None

Possible Causes l

Configurations of neighboring cells are incorrect. If neighboring cells are not configured or incorrectly configured, handovers cannot be triggered 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 cannot be successfully executed. For example, if the IP path for an X2 interface is incorrectly configured, X2-based inter-eNodeB handovers cannot be executed; or, if the IP path from the target eNodeB to the source serving gateway (S-GW) is not configured, X2based inter-S-GW handovers cannot be executed.

l

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

59

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

Troubleshooting Flowchart Figure 5-3 shows the troubleshooting flowchart for intra-RAT handover faults due to incorrect data configurations. Figure 5-3 Troubleshooting flowchart for intra-RAT handover faults due to incorrect data configurations

Troubleshooting Procedure 1.

Check whether the terrestrial link is incorrectly configured. Yes: Correct the terrestrial link configuration. Go to 2. No: Go to 3.

2.

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

3.

Check whether there are missing configurations of neighboring cells. Yes: Complete neighboring cell configurations. Go to 4. No: Go to 5.

4.

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

5.

Check whether handover parameters are incorrectly configured. Yes: Correct their configurations.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

60

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

No: Go to 7. 6.

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

7.

Contact Huawei technical support.

Typical Cases Fault Description During a drive test, a UE did not receive any handover commands after sending A3 measurement reports to the eNodeB. Ultimately, the service is dropped. Fault Diagnosis 1.

According to Huawei maintenance personnel, these A3 measurement reports were successfully received by the source eNodeB. Later, the source eNodeB sent a Handover Request message through the X2 interface to the target eNodeB, but the target eNodeB responded with a Handover Failure message containing a cause value indicating unavailable 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 an inconsistency was found. The adjacent node ID specified in the IPPATH MO was different from the X2 interface ID, which caused a resource request failure and ultimately a handover failure.

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

5.6 Troubleshooting Intra-RAT Handover Faults Caused by Target Cell Congestion This section provides information required to troubleshoot intra-RAT handover faults due to target 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 U2000.

Related Information None

Possible Causes l

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

61

eRAN11.1 eRAN Troubleshooting Guide

l

5 Troubleshooting Intra-RAT Handover Faults

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

Troubleshooting Flowchart Figure 5-4 shows the troubleshooting flowchart for intra-RAT handover faults due to target cell congestion. Figure 5-4 Troubleshooting flowchart for intra-RAT handover faults due to target cell congestion

Troubleshooting Procedure 1.

Check whether the handover fails due to target cell congestion. Yes: Expand the capacity of the target cell or tune the network optimization parameters of the target cell. Go to 2. No: Go to 3.

2.

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

3.

Contact Huawei technical support.

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 was always low (lower than the admission thresholds for handed-over services with QCIs ranging from 1 to 4) when a handover failure message appeared. Therefore, these handovers failed because the traffic channel was so congested in the cell that there were no resources available for new handed-over services.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

62

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

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

5.7 Troubleshooting Intra-RAT Handover Faults Caused by Poor-Quality Uu Interface This section provides information required to troubleshoot intra-RAT handover faults due to poor Uu quality. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

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

Related Information Checking interference 1.

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

2.

Start the UE spectral scanning function and further determine whether the interference originates 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 handovers are 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 cell coverage 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 and lower 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 in the cell and UEs at cell edge easily encounter handover failures, the jumper is reversely connected to the feeder and needs to be corrected.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

63

eRAN11.1 eRAN Troubleshooting Guide

l

5 Troubleshooting Intra-RAT Handover Faults

Check whether the feeder is in poor physical condition. If a feeder is damaged, water immersed, bending, or not securely connected, the transmit power and receive sensitivity are decreased and severe service drops occur. In this case, the feeder needs to be replaced. For details, see ALM-26529 RF Unit VSWR Threshold Crossed. 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

Troubleshooting Flowchart To effectively diagnose handover faults due to poor Uu quality, you are advised to first find out whether this fault is caused by interference or unsatisfactory coverage. Figure 5-5 shows the troubleshooting flowchart for intra-RAT handover faults due to poor Uu quality.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

64

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

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

Troubleshooting Procedure 1.

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 cell interference detection result, check whether there is UL interference. Yes: Remove the interference. Go to 2. No: Go to 3.

2.

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

3.

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

4.

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

5.

Check whether there is imbalance between UL and DL quality. Specifically, check whether the transmit power of the RRU and UE falls beyond link budgets.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

65

eRAN11.1 eRAN Troubleshooting Guide

5 Troubleshooting Intra-RAT Handover Faults

Yes: Remove the imbalance between UL and DL quality. Go to 6. No: Go to 7. 6.

Check whether the fault is rectified. Yes: End. 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.

8.

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

9.

Contact Huawei technical support.

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

66

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

6

Troubleshooting Service Drops

About This Chapter This chapter describes the method and procedure for troubleshooting service drops in the Long Term Evolution (LTE) system. It also provides the definitions of service drops and related key performance indicator (KPI) formulas. 6.1 Definitions of Service Drop Faults The service drop rate is an important key performance indicator (KPI) for radio networks. It indicates the ratio of the number of dropped services to the total number of services. A high service drop rate cannot meet user requirements. 6.2 Background Information This section provides background information for service drops. The background information includes the formula used to calculate the service drop rate, counters and alarms related to service drops, and drive tests and topN cell analysis method for troubleshooting service drops. 6.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause. 6.4 Troubleshooting Radio Faults This section provides information required to troubleshoot service drops due to radio faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 6.5 Troubleshooting Transmission Faults This section provides information required to troubleshoot service drops due to transmission faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 6.6 Troubleshooting Congestion This section provides information required to troubleshoot service drops due to congestion. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 6.7 Troubleshooting Handover Failures This section provides information required to troubleshoot service drops due to handover faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

67

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

68

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

6.1 Definitions of Service Drop Faults The service drop rate is an important key performance indicator (KPI) for radio networks. It indicates the ratio of the number of dropped services to the total number of services. A high service drop rate cannot meet user requirements. A service drop is counted each time the eNodeB sends an E-RAB RELEASE INDICATION or UE CONTEXT RELEASE COMMAND message to the MME with a release cause other than Normal Release, Detach, User Inactivity, cs fallback triggered, and Inter-RAT redirection after an E-UTRAN radio access bearer (E-RAB) has been successfully set up for a UE.

6.2 Background Information This section provides background information for service drops. The background information includes the formula used to calculate the service drop rate, counters and alarms related to service drops, 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 carrying service 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 ERAB release is counted once.

Related Counters Measurement related to E-RAB release (E-RAB.Rel.Cell) Counters related to service drops are classified as follows: l

l

Release types –

Normal releases

–

Abnormal releases

–

Normal releases for outgoing handovers

–

Abnormal releases for outgoing handovers

QoS class identifier (QCI) –

l

QCIs of 1 to 9

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 ERAB releases is greater than 30%, you need to check whether the network planning such 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 abnormal E-RAB releases is greater than 30%, you need to check whether the transmission links over the S1/X2 interface experience exceptions such as intermittent disconnections.

– Issue Draft A (2016-03-07)

Congestion (L.E-RAB.AbnormRel.Cong) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

69

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

If the percentage of abnormal E-RAB releases due to congestion to all abnormal ERAB releases 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 abnormal E-RAB releases is greater than 30%, you need to check whether parameters are properly set 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 check whether parameters are properly set for the evolved packet core (EPC).

For 3900 series base stations, see eNodeB Performance Counter Reference. For the BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see BTS3911E Performance Counter Reference

Formula The service drop rate is calculated based on services but not on UEs. For example, services are set up on multiple data radio bearers (DRBs) for a UE. Then, if all these services experience drops, 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) * 100% Where, l

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

l

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

Drive Test To identify service drops in drive tests, you need to check logs and signaling procedures on the UE side. For details, see the related UE user guide.

TopN Cell Selection TopN 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 Alarms l

Hardware-related alarms –

Issue Draft A (2016-03-07)

ALM-26104 Board Temperature Unacceptable Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

70

eRAN11.1 eRAN Troubleshooting Guide

l

l

l

l

6 Troubleshooting Service Drops

–

ALM-26106 Board Clock Input Unavailable (Applicable to 3900 series base stations only)

–

ALM-26107 Board Input Voltage Out of Range (Applicable to 3900 series base stations only)

–

ALM-26200 Board Hardware Fault

–

ALM-26202 Board Overload

–

ALM-26203 Board Software Program Error

–

ALM-26208 Board File System Damaged

Temperature-related alarms (Applicable to 3900 series base stations only) –

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

Link-related alarms –

ALM-25880 Ethernet Link Fault

–

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

–

ALM-25889 SCTP Link Congestion

–

ALM-26233 BBU CPRI Optical Interface Performance Degraded (Applicable to 3900 series base stations only)

–

ALM-26234 BBU CPRI Interface Error (Applicable to 3900 series base stations only)

–

ALM-29201 S1 Interface Fault

–

ALM-25952 User Plane Path Fault

RF-related alarms –

ALM-26520 RF Unit TX Channel Gain Out of Range

–

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

–

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

–

ALM-26506 RF Unit Optical Interface Performance Degraded

–

ALM-26529 RF Unit VSWR Threshold Crossed

–

ALM-26532 RF Unit Hardware Fault

–

ALM-26534 RF Unit Overload

–

ALM-26527 RF Unit Input Power Out of Range

–

ALM-26758 TMA Running Data and Configuration Mismatch

Configuration-related alarms –

ALM-26245 Configuration Data Inconsistency

–

ALM-26812 System Dynamic Traffic Exceeding Licensed Limit

–

ALM-26815 Licensed Feature Entering Keep-Alive Period

–

ALM-26818 No License Running in System

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

71

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

–

ALM-26819 Data Configuration Exceeding Licensed Limit

–

ALM-29243 Cell Capability Degraded

–

ALM-29247 Cell PCI Conflict

l

ALM-29240 Cell Unavailable

l

ALM-29246 Cell Simulated Load Startup

6.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause.

Possible Causes If the service drop rate increases or greatly fluctuates, you must first locate the faults and then handle 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 network experiences abnormalities.

l The service drop rate of the whole network is abnormal.

l Data transmission is abnormal.

l Related alarms are reported.

A single eNodeB experiences abnormalities.

l Network planning is improper. l The evolved packet core (EPC) works abnormally.

l The service drop rate of a cell is abnormal.

l Data transmission is abnormal.

l Related alarms are reported.

l Network planning is improper. l Resources are insufficient. l Weak coverage or interference exists. l The EPC works abnormally.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

72

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

Figure 6-1 Troubleshooting flowchart for service drops

Troubleshooting Procedure Troubleshooting 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 been modified.

3.

Check whether the traffic volume sharply increases. The traffic volume trend of the whole network can be determined based on the number of E-RAB setup attempts and successful E-RAB setups. Check whether there are

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

73

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

activities such as number allocation or important holidays that may lead to a traffic volume increase. 4.

Check whether the versions or parameters of the EPC network elements (NEs) have been modified.

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 ERAB setup attempts and successful E-RAB setups. Check whether there are activities such as concerts or sports that may lead to a traffic volume increase.

4.

Check whether the cell parameters have been modified, such as the maximum number of acknowledged 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 cells have been modified.

6.4 Troubleshooting Radio Faults This section provides information required to troubleshoot service drops due to radio faults. 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.ERAB.AbnormRel.Radio counter measures the number of abnormal E-RAB releases due to radio interface faults in non-handover scenarios.

Related Information None

Possible Causes Abnormal E-RAB releases due to radio faults are caused by faults such as the number of Radio Link Control (RLC) retransmissions reaching the maximum, UE uplink out-ofsynchronization, or signaling procedure failures that are resulted from weak coverage, uplink interference, or UE exceptions.

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether UEs are mostly located in weak coverage areas.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

74

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

Check the values of the counters related to different channel quality indicator (CQI) levels and modulation and coding scheme (MCS) orders to determine whether low-level CQIs and low-order MCSs are mostly used, the uplink reference signal received power (RSRP) is poor, and the uplink signal to interference plus noise ratio (SINR) is low. Yes: Confirm the cell coverage by using drive tests, and then adjust the weak coverage accordingly. Go to 2. No: Go to 3. 2.

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

3.

Check whether uplink interference exists. Yes: Remove the interference source. Go to 4. No: Go to 5.

4.

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

5.

Contact Huawei technical support.

Typical Cases Fault Description According to the routine KPI monitoring result, the service drop rate of cell A is 16%. Fault Diagnosis 1.

The rate of abnormal E-RAB releases to total E-RAB releases is 16%.

2.

According to the CHR logs, the E-RAB release is initiated with the release cause of UE_RESYNC_DATA_IND_REL_CAUSE. (UE_RESYNC_DATA_IND_REL_CAUSE indicates that the abnormal E-RAB release is caused by resynchronization that is triggered by L2 data reporting after the UE experiences an out-of-synchronization.)

3.

According to the CHR logs, the uplink RSRP is less than -135 dBm and the average SINR is less than -3 dB before the service drop occurs.

Fault Handling Improve LTE network coverage.

6.5 Troubleshooting Transmission Faults This section provides information required to troubleshoot service drops due to transmission faults. 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.TNL counter measures the number of abnormal E-RAB releases due to faults at the transport network layer. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

75

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

Related Information None

Possible Causes Abnormal E-RAB releases due to transmission faults are caused by transmission exceptions between the eNodeB and the MME. For example, the transmission link over the S1 interference experiences intermittent disconnections. The BTS3202E/BTS3911E does not support SCTPLINK6.

Troubleshooting Flowchart None

Troubleshooting Procedure Check 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 U2000 client. Yes: Clear the alarms by referring to the instructions in the alarm reference. Go to 2. No: Go to 3.

2.

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

3.

Contact Huawei technical support.

Typical Cases None

6.6 Troubleshooting Congestion This section provides information required to troubleshoot service drops due to congestion. 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.ERAB.AbnormRel.Cong counter measures the number of abnormal E-RAB releases due to resource congestion.

Related Information None Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

76

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

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

Troubleshooting Flowchart None

Troubleshooting Procedure If 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 requires capacity expansion. After rectifying the congestion fault, check whether the corresponding counter has a proper value. 1.

Turn on the switch for the MLB algorithm, and then check whether the congestion fault is rectified. Yes: End. No: Go to 2.

2.

Contact Huawei technical support.

Typical Cases None

6.7 Troubleshooting Handover Failures This section provides information required to troubleshoot service drops due to handover faults. 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.ERAB.AbnormRel.HOFailure counter measures the number of abnormal E-RAB releases due to outgoing handover failures.

Related Information Counters related to outgoing handovers to a specific cell l

L.HHO.NCell.PrepAttOut

l

L.HHO.NCell.ExecAttOut

l

L.HHO.NCell.ExecSuccOut

l

L.HHO.Ncell.PingPongHo

l

L.HHO.NCell.HoToolate

l

L.HHO.NCell.HoTooearly

l

L.HHO.NCell.MMEAbnormRsp

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

77

eRAN11.1 eRAN Troubleshooting Guide

l

6 Troubleshooting Service Drops

L.HHO.NCell.Succ.ReEst2Src

Possible Causes Abnormal E-RAB releases due to handover failures are caused by failures of handovers from the local cell to another cell.

Fault Handling Flowchart None

Fault Handling Procedure If service drops due to outgoing handover failures increase in a topN cell, you can identify the causes 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 cell and find out the target cell that has the highest number of handover failures. Then, check the parameter settings related to the neighbor relationship with this target cell. If the parameter settings are improper, optimize the parameter settings as required.

2.

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

3.

Contact Huawei technical support.

Typical Cases Fault Description After the X2 relationship is manually configured, handovers fail in the site, increasing the service drop rate. Fault Diagnosis 1.

Check the base station configurations. X2 configurations are modified.

2.

Check message exchanges over the standard interface. The UE does not receive any handover instructions.

3.

Check the CHR of the source site. The uplink RSRP is about -140 dBm before the handover failure occurs, which means coverage is poor.

Fault Handling Reconfigure the neighboring relationship.

6.8 Troubleshooting MME Faults This section provides information required to troubleshoot service drops due to MME faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

78

eRAN11.1 eRAN Troubleshooting Guide

6 Troubleshooting Service Drops

Fault Description According to the definitions of eNodeB performance counters, the L.ERAB.AbnormRel.MMETot (applicable only to 3900 series base stations) and L.ERAB.AbnormRel.MME counters measure the number of E-RAB releases that are initiated by the MME when the corresponding E-RABs do not have and have data transmission, respectively, and the L.E-RAB.AbnormRel counter measures the number of E-RAB releases that are initiated by the eNodeB. If an E-RAB having data transmission is abnormally released and the release is included in the value of the L.E-RAB.AbnormRel.MME counter, it can be determined that the release is an abnormal E-RAB release initiated by the evolved packet core (EPC). However, the abnormal release is not included in the value of the L.ERAB.AbnormRel counter.

Related Information None

Possible Causes Abnormal E-RAB releases due to MME faults are initiated by the EPC when UEs are performing services.

Troubleshooting Flowchart None

Troubleshooting 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. Yes: End. No: Go to 4.

4.

Contact Huawei technical support.

Typical Cases Fault Description At the early stage of network deployment, the outgoing handover success rate is 94.7% on the entire network, and therefore, the service drop rate is high. Fault Diagnosis 1.

Analyze the CHRs of the source site and target site to check for problems, such as weak coverage, topN UEs, capacity, and interference.

2.

Analyze the CHR of the source site. The UE obtains the handover instruction but the source site does not receive any context release instruction from the target site.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

79

eRAN11.1 eRAN Troubleshooting Guide

3.

6 Troubleshooting Service Drops

Analyze the message exchanges over the standard interface of the target site. The MME does not send the PATH_SWITCH_ACK message to the target site.

Fault Handling Identify faults on the EPC side.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

80

eRAN11.1 eRAN Troubleshooting Guide

7

7 Troubleshooting Inter-RAT Handover Faults

Troubleshooting Inter-RAT Handover Faults

About This Chapter This section defines inter-RAT handover faults, describes handover principles, and provides the fault handling method and procedure. First office application (FOA) and commercial Long Term Evolution (LTE) networks are being deployed in large scales. GSM/EDGE radio access network (GERAN) and Universal terrestrial radio access network (UTRAN) will coexist with LTE networks for a long time. This requires operators to use effective inter-RAT policies for protecting the GERAN and UTRAN resources and providing rich services at the same time. 7.1 Definitions of Inter-RAT Handover Faults Inter-RAT handover faults are system faults that cause handover initiation failure or handover failure. RAT is short for radio access technology. 7.2 Background Information This section provides background information about inter-RAT handover faults. The background information includes counters, handover types, and handover procedures. 7.3 Troubleshooting Method This section describes how to identify possible causes for inter-RAT handover faults and troubleshoot the faults. 7.4 Troubleshooting Inter-RAT Handover Faults Due to Hardware Faults This section provides information required to troubleshoot inter-RAT handover faults due to hardware faults. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.5 Troubleshooting Inter-RAT Handover Faults Due to Poor UE Capabilities Inter-RAT handovers require high UE capabilities. If the UE cannot support inter-RAT handovers, inter-RAT handovers may fail. This section provides information required to troubleshoot inter-RAT handover faults due to poor UE capabilities. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.6 Troubleshooting Inter-RAT Handover Faults Due to Incorrect Parameter Configurations This section provides information required to troubleshoot inter-RAT handover faults due to incorrect parameter configurations on the E-UTRAN side. The information includes fault Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

81

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.7 Troubleshooting Inter-RAT Handover Faults Due to Target Cell Congestion This section provides information required to troubleshoot inter-RAT handover faults due to target cell congestion. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.8 Troubleshooting Inter-RAT Handover Faults Due to Incorrect EPC Configurations This section provides information required to troubleshoot inter-RAT handover faults due to incorrect EPC configurations. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.9 Troubleshooting Inter-RAT Handover Faults Due to Radio Environment Abnormalities This section provides information required to troubleshoot inter-RAT handover faults due to radio environment abnormalities. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. 7.10 Troubleshooting Inter-RAT Handover Faults Due to Abnormal UEs This section provides information required to troubleshoot inter-RAT handover faults due to UE exceptions. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

82

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

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

7.2 Background Information This section provides background information about inter-RAT handover faults. The background information includes counters, handover types, and handover procedures.

Related Counters l

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

l

Inter-RAT Incoming Handover Measurement (Cell) (HO.IRAT.In.Cell)

For 3900 series base stations, see eNodeB Performance Counter Reference. For the BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see BTS3911E Performance Counter Reference

Handover Types and Procedures Inter-RAT handovers are classified by handover cause into the following types: coveragebased handover, load-based handover, service-based handover, UL-quality-based handover, and distance-based handover. For details, see eRAN Mobility Management in Connected Mode Feature Parameter Description and eRAN CS Fallback Feature Parameter Description.

7.3 Troubleshooting Method This section describes how to identify possible causes for inter-RAT handover faults and troubleshoot the faults.

Possible Causes When the KPIs related to inter-RAT handovers deteriorate or fluctuate dramatically, determine whether the deterioration or fluctuation is caused by TopN cells/sites, or the entire network. 4 describes possible causes of inter-RAT handover faults. Table 7-1 Possible causes of inter-RAT handover faults Scenario

Fault Description

Possible Causes

The TopN cells or sites experience abnormaliti es.

l Performance counters related to inter-RAT handovers in a cell are abnormal.

l Hardware is faulty. l Parameters are inappropriately set.

l Related alarms are reported.

l Weak coverage or interference exists.

l The target cell is congested. l The EPC works abnormally. l The UE is abnormal.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

83

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Scenario

Fault Description

Possible Causes

The whole network experiences abnormaliti es.

l Performance counters related to inter-RAT handovers throughout the whole network are abnormal.

l Network parameters are incorrectly configured. l The EPC works abnormally.

l Related alarms are reported.

Troubleshooting Flowchart The following measures are effective in locating an inter-RAT handover fault: l

Analyzing performance counters related to inter-RAT handovers

l

Investigating TopN cells

l

Checking devices, data transmission, and alarms

l

Checking UE capabilities

l

Checking parameter configurations for inter-RAT handovers and neighboring cell configurations

l

Checking EPC configurations

l

Investigating neighboring cell planning, interference, and cell coverage

l

Locating the fault in TopN UEs

To locate an inter-RAT handover fault, you are advised to do the following: l

First investigate the NE where signaling abnormalities occur.

l

Select TopN cells with inter-RAT handover faults and then troubleshoot the faults according to Figure 7-1.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

84

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

85

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Troubleshooting Procedure 1.

Locate TopN sites with inter-RAT handover faults by viewing performance counters.

2.

Check whether the hardware is faulty. Yes: Hardware faults are often associated with alarms. You are advised to handle the fault by following the instructions on how to troubleshoot handover faults due to hardware faults. Then go to 3. No: Go to 4. NOTE

Hardware faults are the most likely causes if performance counters related to inter-RAT handovers suddenly deteriorate without recent modifications to the configurations of the abnormal cell and its neighboring cells.

3.

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

4.

Check whether the UE supports inter-RAT handovers. No: Use a UE that supports inter-RAT handovers or modify the inter-RAT handover policy. Then go to 5. Yes: Go to 6. NOTE

Inter-RAT handovers require high UE capabilities and you are advised to check UE capabilities first.

5.

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

6.

Check whether the switch, threshold, and neighboring cells for inter-RAT handovers are incorrectly configured on the eRAN side. Yes: Follow the instructions on how to troubleshoot handover faults due to incorrect data configurations. Then go to 7. No: Go to 8.

7.

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

8.

Check whether the service channel of the target cell is severely congested. Yes: Follow the instructions on how to troubleshoot handover faults due to target cell congestion. Then go to 9. No: Go to 10.

9.

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

10. Check whether the EPC is incorrectly configured. That is, check whether abnormal signaling messages are delivered by the EPC. Yes: Ask EPC personnel to reconfigure the EPC. Then go to 11. No: Go to 12. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

86

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

11. Check whether the fault is rectified. Yes: End. No: Go to 12. 12. Check whether the radio environment is abnormal. Yes: Follow the instructions on how to troubleshoot handover faults due to radio environment abnormalities. Then go to 13. No: Go to 14. 13. Check whether the fault is rectified. Yes: End. No: Go to 14. 14. Check whether the UE is abnormal. Yes: Contact the UE manufacturers to locate and then troubleshoot the fault. Then go to 15. No: Go to 16. 15. Check whether the fault is rectified. Yes: End. No: Go to 16. 16. Contact Contacting Huawei Technical Support.

7.4 Troubleshooting Inter-RAT Handover Faults Due to Hardware Faults This section provides information required to troubleshoot inter-RAT handover faults due to hardware faults. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Fault Description Typical 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 or even become out of service, in addition to the following symptoms: l

l

Abnormal cell-level performance counters –

Increased service drop rate

–

Decreased handover success rate

–

Decreased access success rate

Related alarms

Related Information Related Alarms l

Board overload alarm –

l

ALM-26202 Board Overload

Alarms related to RF modules

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

87

eRAN11.1 eRAN Troubleshooting Guide

l

–

ALM-26529 RF Unit VSWR Threshold Crossed

–

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

Cell capability degraded alarm –

l

l

l

7 Troubleshooting Inter-RAT Handover Faults

ALM-29243 Cell Capability Degraded

Alarms related to CPRI links (Applicable to 3900 series base stations only) –

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

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 (Applicable to 3900 series base stations only)

Alarms related to transmission faults –

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

–

ALM-25952 User Plane Path Fault

–

ALM-29201 S1 Interface Fault

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

A board is overloaded.

l

An RF module is faulty.

l

A common public radio interface (CPRI) link is faulty. (Applicable to 3900 series base stations only)

l

A clock source is faulty.

Troubleshooting Flowchart Figure 7-2 shows the flowchart for troubleshooting inter-RAT handover faults due to hardware faults.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

88

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-2 Troubleshooting flowchart for inter-RAT handover faults due to hardware faults

Troubleshooting Procedure 1.

Check whether a hardware fault alarm is reported. Yes: Handle the hardware fault alarm. Go to 2. No: Go to 3.

2.

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

3.

Contact Huawei technical support.

Typical Cases Fault Description Handovers between cell 0 and cell 2 under an eNodeB were normal with a high success rate, but the handovers from cell 1 under the eNodeB to its neighboring cells were abnormal with a relatively low success rate (7%) during busy hours. Fault Diagnosis 1.

Alarms about the eNodeB were checked. Cell 1 had reported ALM-26529 RF Unit VSWR Threshold 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 site reconstruction.

3.

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

Fault Handling The jumper was securely connected to the feeder. According to the KPI log, the inter-RAT handover success rate becomes normal.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

89

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

7.5 Troubleshooting Inter-RAT Handover Faults Due to Poor UE Capabilities Inter-RAT handovers require high UE capabilities. If the UE cannot support inter-RAT handovers, inter-RAT handovers may fail. This section provides information required to troubleshoot inter-RAT handover faults due to poor UE capabilities. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Fault Description l

l

Cell-level performance counters are abnormal. –

The service drop rate increases.

–

The CSFB performance counters are abnormal.

Handovers to inter-RAT neighboring cells cannot be triggered. The eNodeB does not deliver inter-RAT handover commands in either of the following conditions: –

Drive test results and signaling tracing results over standard interfaces on the eNodeB side show that the UE experiences poor signal quality in its serving cell and the threshold for inter-RAT handovers is met.

–

The eNodeB has received a CSFB Indicator from the EPC.

Related Information l

Inter-RAT frequency band supported by the UE: For detailed information, see the interRAT-Parameters IE carried in the UE CAPABILITY INFORMATION message.

l

UE's capability of supporting inter-RAT handovers: For detailed information, see B.1 "Feature group indicators" in 3GPP TS 36.331. –

UE's capability of supporting PS handovers to URTAN: According to B.1 "Feature group indicators" in 3GPP TS 36.331, bit 8 in featureGroupIndicators indicates whether the UE supports PS handovers to UTRAN. 0: not supported; 1: supported.

–

UE's capability of supporting PS handovers to GERAN: interRAT-PS-HOToGERAN indicates whether the UE supports PS handovers to GERAN. false: not supported; true: supported.

Inter-RAT frequency bands supported by the UE and UE's capability of supporting inter-RAT handovers can be viewed in the Uu interface tracing results on the eNodeB side, as shown in Figure 7-3. Bit 8 in featureGroupIndicators indicates whether the UE supports PS handovers to UTRAN and interRAT-PS-HO-ToGERAN indicates whether the UE supports PS handovers to GERAN. Information in the blue rectangle indicates the UTRAN and GERAN frequency bands supported by the UE.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

90

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-3 Example of Uu interface tracing results

Possible Causes The UE does not support inter-RAT frequency bands or inter-RAT PS handovers.

Troubleshooting Flowchart Figure 7-4 shows the flowchart for troubleshooting inter-RAT handover faults due to poor UE capabilities.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

91

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-4 Troubleshooting flowchart for inter-RAT handover faults due to poor UE capabilities

Typical Cases Fault Description During an LTE to UMTS PS handover test at a site, Uu interface tracing results show that the eNodeB did not deliver a PS handover command after receiving the B1 measurement report from the UE. Fault Locating 1.

The UMTS frequency band configured for this site is band7 and the UE access signaling procedure shows that the UE supports band0, band2, and band7. Therefore, the fault is not caused by not supporting inter-RAT frequency bands. Figure 7-5 shows an example of Uu interface tracing results.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

92

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-5 Example of Uu interface tracing results

2.

Check whether the UE supports PS handovers to UTRAN. As shown in Figure 7-5, bit 8 in featureGroupIndicators is 0, which indicates that the UE does not support PS handovers to UTRAN. According to 3GPP TS 36.331, the eNodeB does not deliver PS handover commands when the UE does not support PS handovers.

Troubleshooting This fault is rectified after a UE that supports PS handovers to UTRAN is used or after the inter-RAT handover policy is changed to redirection.

7.6 Troubleshooting Inter-RAT Handover Faults Due to Incorrect Parameter Configurations This section provides information required to troubleshoot inter-RAT handover faults due to incorrect parameter configurations on the E-UTRAN side. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Fault Description Handovers to inter-RAT neighboring cells cannot be triggered. l

Drive test results or signaling tracing results over standard interfaces show that the UE experiences poor signal quality in its serving cell. The signal level in an inter-RAT neighboring cell meets the threshold for inter-RAT handovers but the handover cannot be triggered.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

93

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

l

The value of counters that measure the number of outgoing handover attempts from EUTRAN to inter-RAT networks (L.IRATHO.E2XXX.PrepAttOut) is 0. XXX refers to inter-RAT networks.

l

Voice services cannot be performed in GERAN or UTRAN by CSFB, leading to call failures.

Related Information None

Possible Causes l

The inter-RAT handover switch is turned off. Run the LST ENODEBALGOSWITCH command to query whether the switch for inter-RAT handovers to the corresponding RAT is turned on.

l

Neighboring cells are not configured or incorrectly configured. If inter-RAT neighboring cells are not configured or incorrectly configured, inter-RAT handovers cannot be triggered even after the UE reports these neighboring cells to the eNodeB. Run the LST GERANNCELL command to query the neighbor relationships with GERAN cells and run the LST UTRANNCELL command to query the neighbor relationships with UTRAN cells.

l

Parameters such as the inter-RAT handover threshold, hysteresis, and time-to-trigger are inappropriately configured. Inter-RAT handovers are triggered only when the signal level of the target inter-RAT neighboring cell is higher than that of the serving cell by the amount specified by the inter-RAT handover threshold. If parameters (such as the inter-RAT handover threshold, hysteresis, and time-to-trigger) are inappropriately set, handovers may be difficult to trigger or may be frequently triggered.

Troubleshooting Flowchart Figure 7-6 shows the flowchart for troubleshooting inter-RAT handover faults due to incorrect parameter configurations.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

94

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-6 Troubleshooting flowchart for inter-RAT handover faults due to incorrect parameter configurations

Typical Cases Fault Description During an LTE to UMTS PS handover test at a site, the eNodeB did not deliver a PS handover command after the UE sent the B1 measurement report. Fault Locating 1.

The output of the LST ENODEBALGOSWITCH command shows that the UTRAN PS handover switch on the eNodeB side is turned on.

2.

eNodeB neighbor relationships show that the routing area code (RAC) was not configured during the neighboring UTRAN cell configuration. The RAC is not configured by default. As a result, the eNodeB will not deliver PS handover commands. In this case, parameters for neighboring cells are incompletely configured, leading to inter-RAT handover faults.

Troubleshooting Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

95

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Run the MOD UTRANEXTERNALCELL command to change the value of the Routing area code indicator parameter for external UTRAN cells to CFG and configure Routing area code based on the RAC of external UTRAN cells.

7.7 Troubleshooting Inter-RAT Handover Faults Due to Target Cell Congestion This section provides information required to troubleshoot inter-RAT handover faults due to target cell congestion. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Fault Description l

Traffic statistics for inter-RAT handover failures include the counters that measure the number of outgoing handover preparation failures due to handover preparation failures in inter-RAT networks (L.IRATHO.E2XXX.Prep.FailOut.PrepFailure).

l

Traffic statistics for inter-RAT handover failures include the counters that measure the number of outgoing handover preparation failures due to no responses from inter-RAT networks (L.IRATHO.E2XXX.Prep.FailOut.NoReply).

Related Information None

Possible Causes l

The number of UEs in the target cell surges due to celebrations or gatherings.

l

A large number of UEs have been handed over to the target cell due to inappropriate parameter settings.

Troubleshooting Flowchart Figure 7-7 shows the flowchart for troubleshooting inter-RAT handover faults due to target cell congestion. Figure 7-7 Troubleshooting flowchart for inter-RAT handover faults due to target cell congestion

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

96

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Typical Cases Fault Description During an LTE to UMTS PS handover test at a site, the handover keeps failing. Traffic statistics for inter-RAT handover failures include the counter that measures the number of outgoing handover preparation failures due to handover preparation failures in WCDMA network (L.IRATHO.E2W.Prep.FailOut.PrepFailure). Fault Locating 1.

Obtain the Uu and S1 interface tracing results. The S1AP_HANDOVER_PREPARATION_FAIL message is displayed in S1 interface tracing results and the cause value for this message is "Invalid QoS combination."

2.

Investigation results from the EPC side show that this cause value is sent by UMTS.

3.

Confirmation results with UMTS network personnel show that the UMTS frequency is blocked, leading to handover preparation failures.

Troubleshooting This fault is rectified after the frequency is unblocked on the UMTS side.

7.8 Troubleshooting Inter-RAT Handover Faults Due to Incorrect EPC Configurations This section provides information required to troubleshoot inter-RAT handover faults due to incorrect EPC configurations. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

Fault Description l

Traffic statistics for inter-RAT handover failures include the counters that measure the number of outgoing handover preparation failures from E-UTRAN to inter-RAT networks due to faults in the EPC (L.IRATHO.E2XXX.Prep.FailOut.MME).

l

The signaling procedure contains failure messages delivered by the EPC or no reply on the EPC side, such as RAU failures or TAU failures.

Related Information None

Possible Causes Interfaces in the EPC are incorrectly configured or become faulty.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

97

eRAN11.1 eRAN Troubleshooting Guide

3.

7 Troubleshooting Inter-RAT Handover Faults

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

4.

Contact Huawei technical support.

Typical Cases Fault Description During an LTE to UMTS PS handover test at a site, traffic statistics for outgoing inter-RAT handover failures include the counter that measures the number of outgoing handover preparation failures due to no responses from WCDMA network (L.IRATHO.E2W.Prep.FailOut.NoReply). Fault Locating 1.

Uu interface tracing results show that the UE has sent the B1 measurement report to the eNodeB. S1 interface tracing results show that the eNodeB has sent the HO Required command to the MME.

2.

After a while, the eNodeB sent a HO Cancel command to the MME with the cause value "radioNetwork: tS1relocprep-expiry", which indicates that the timer for the eNodeB to wait for a response from the EPC expires.

3.

The confirmation results with EPC personnel show that the MME has received the HO Required command but failed to forward this message to the SGSN. The reason is that the Gn interface between the MME and SGSN had been inappropriately set and the MME cannot find the corresponding SGSN. The MME sent the UE a PSHO Cancel message after the S1 message waiting timer expires.

Troubleshooting The fault was rectified after the EPC personnel reconfigured the Gn interface between the MME and the SGSN.

7.9 Troubleshooting Inter-RAT Handover Faults Due to Radio Environment Abnormalities This section provides information required to troubleshoot inter-RAT handover faults due to radio environment abnormalities. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases.

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

Related Information Checking interference 1.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

98

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

2.

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

3.

Check whether uplink interference exists by viewing the L.UL.Interference.Avg counter.

Checking cell coverage l

Check for weak coverage. If the reference signal received power (RSRP) values reported by UEs during handovers are 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 cell coverage 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 and lower 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 in the cell and UEs at cell edge easily encounter handover failures, the jumper is reversely connected 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 transmit power and receive sensitivity are decreased and severe service drops occur. In this case, the feeder needs to be replaced. For details, see ALM-26529 RF Unit VSWR Threshold Crossed. 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

Troubleshooting Flowchart Figure 7-8 shows the flowchart for troubleshooting inter-RAT handover faults due to radio environment abnormalities.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

99

eRAN11.1 eRAN Troubleshooting Guide

7 Troubleshooting Inter-RAT Handover Faults

Figure 7-8 Troubleshooting flowchart for inter-RAT handover faults due to radio environment abnormalities

Troubleshooting Procedure 1.

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 cell interference detection result, check whether there is UL interference. Yes: Remove the interference. Go to 2. No: Go to 3.

2.

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

3.

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

4.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

100

eRAN11.1 eRAN Troubleshooting Guide

5.

7 Troubleshooting Inter-RAT Handover Faults

Check whether there is imbalance between UL and DL quality. Specifically, check whether the 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.

6.

Check whether the fault is rectified. Yes: End. 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.

8.

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

9.

Contact Huawei technical support.

Typical Cases None

7.10 Troubleshooting Inter-RAT Handover Faults Due to Abnormal UEs This section provides information required to troubleshoot inter-RAT handover faults due to UE exceptions. The information includes fault descriptions, related information, possible causes, troubleshooting procedure, and typical cases. Abnormal UEs cannot perform inter-RAT handovers as other types of UEs in the same conditions.

Related Information None

Possible Causes The UE is faulty or the UE is incompatible with the network.

Fault Locating None

Fault Handling Personnel on the UE and eRAN sides must work together to handle this fault. 1.

Obtain Uu and S1 interface tracing messages for TopN cells and then analyze the distribution of inter-RAT handover failures caused by abnormal UEs.

2.

Collect the analysis results and information about the signaling procedures, and handle the fault with personnel on the UE side.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

101

eRAN11.1 eRAN Troubleshooting Guide

3.

7 Troubleshooting Inter-RAT Handover Faults

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

4.

Contact Contacting Huawei Technical Support.

Typical Cases Fault Description A large number of LTE to UMTS PS handovers fail at a site and the value of the L.IRATHO.E2W.ExecAttOu counter is far greater than that of the L.IRATHO.E2W.ExecSuccOut counter. Fault Locating 1.

View the Uu and S1 interface tracing results. The eNodeB has delivered a handover command to the UMTS network over the Uu interface but the UE did not access the UMTS network. Instead, the UE initiates cell reestablishment in the source LTE cell with the cause value "handoverFailure."

2.

Inter-RAT handovers using the abnormal UE occasionally fail when the network remains unchanged. NOTE

Inter-RAT handovers using other types of UEs succeed.

3.

Contact personnel on the UE side to locate and then troubleshoot the fault.

Troubleshooting This fault is rectified by personnel on the UE side.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

102

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

8

Troubleshooting Rate Faults

About This Chapter This chapter provides definitions of faults related to traffic rates and describes how to troubleshoot low uplink/downlink UDP/TCP rates and rate fluctuations. UDP is short for User Datagram Protocol, and TCP is short for Transmission Control Protocol. 8.1 Definitions of Rate Faults This section defines rate faults. 8.2 Background Information This section provides background information for rate faults. The background information includes the user-plane protocol stack, restrictions that the protocol stipulates for UEs of different categories, and method used to calculate the theoretical rates. 8.3 Troubleshooting Abnormal Single-UE Rates This section provides information required to troubleshoot abnormal single-UE rates. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 8.4 Troubleshooting Abnormal Multi-UE Rates This section provides information required to troubleshoot abnormal multi-UE rates. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

103

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

8.1 Definitions of Rate Faults This 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) or Transmission Control Protocol (TCP) service, on a UE is at least 10% lower than the baseline 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 fluctuates by 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 least 10% 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 fluctuates by more than 50%.

l

Abnormal rates on multiple UEs A key performance indicator (KPI) indicates an abnormal rate, or a large number of users complain about their traffic rates. This fault may be caused by a specific single-UE rate fault 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. For example, the currently observed rate is noticeably lower than the rate of the previous day or a period; the observed rate is considerably lower than the rate achieved by equivalent equipment.

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 Information This section provides background information for rate faults. The background information includes the user-plane protocol stack, restrictions that the protocol stipulates for UEs of different categories, and method used to calculate the theoretical rates.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

104

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

LTE User-Plane Protocol Stack Figure 8-1 shows the LTE user-plane protocol stack. Rate statistics for different layers vary because 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 measured by 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 Table 8-2. Table 8-1 Downlink physical layer parameter values for UE categories UE Category

Maximum Number of DL-SCH Transport Block Bits Received Within a TTI

Maximum Number of Bits of a DLSCH Transport Block Received Within a TTI

Total Number of Soft Channel Bits

Maximum Number of Supported Layers for Spatial Multiplexing in DL

Category 1

10296

10296

250368

1

Category 2

51024

51024

1237248

2

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

105

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

UE Category

Maximum Number of DL-SCH Transport Block Bits Received Within a TTI

Maximum Number of Bits of a DLSCH Transport Block Received Within a TTI

Total Number of Soft Channel Bits

Maximum Number of Supported Layers for Spatial Multiplexing in DL

Category 3

102048

75376

1237248

2

Category 4

150752

75376

1827072

2

Category 5

299552

149776

3667200

4

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

Maximum Number of Bits of a UL-SCH Transport Block Transmitted Within a TTI

Support for 64QAM in UL

Category 1

5160

No

Category 2

25456

No

Category 3

51024

No

Category 4

51024

No

Category 5

75376

Yes

Theoretical Rate Calculation In LTE networks, the theoretical traffic rate relates to the system bandwidth, modulation scheme, multiple-input multiple-output (MIMO) mode, and parameter settings. Theoretical rate calculation for a cell considers the number of symbols occupied by the physical downlink control channel (PDCCH) in each subframe and the amount of time-frequency resources occupied by the 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. For details, 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 index 28. Then, the TBS of 75736 can be selected at the MAC layer for the UE. If MIMO is used, two transport blocks (150752) are transmitted per transmission time interval (TTI), which is 1 ms. Then, the throughput is 150.752 Mbit/s. NOTE

The theoretical rate calculated is the protocol-stipulated MAC-layer rate, not the application-layer rate for eNodeBs.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

106

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

8.3 Troubleshooting Abnormal Single-UE Rates This section provides information required to troubleshoot abnormal single-UE rates. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description The 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 Information The User Datagram Protocol (UDP) is a simple datagram-oriented transport-layer protocol. UDP provides an unreliable service. It sends datagrams from the application to the IP layer Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

107

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

but does not ensure that the datagrams can arrive at their destinations. However, UDP features a high transmission speed, because a connection does not need to be set up before UDP-based transmission between a client and a server and retransmission upon timeout is not applied. The Transmission Control Protocol (TCP) provides connection-oriented reliable delivery of a stream of bytes. A client and a server can transmit data between each other only after a TCP connection 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 to the other end. TCP uses a more complicated control mechanism than UDP. In most cases, a link with a normal TCP rate has a normal UDP rate, but a link with a normal UDP rate does not necessarily have a normal TCP rate. When diagnosing rate faults, ensure normal UDP rates before handling TCP services. 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 Causes A common way to find a cause is as follows: First, check whether the service involved is a UDP service or a TCP service. If it is a TCP service, inject uplink and downlink UDP packets on a single 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 rate limiting at the network adapter and rectify radio parameter setting errors before handling TCP rate faults. If the service involved is a UDP service, locate the fault by investigating link from the server to the UE in an end-to-end manner. Second, if the UDP rate can reach its peak value but 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 server

l

Insufficient traffic into the eNodeB due to transmission problems

l

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 UE

l

TCP parameter setting error, or fault in the TCP transmission mechanism

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether data services run abnormally. If a UE fails to access any data services, check whether the UE has been connected to or disconnected from the network. Ensure that the UE is connected. Then, check the firewall settings 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) work properly. On the server, ping the user-plane IP address of the unified gateway (UGW). If the ping operation fails or the delay is excessively long, contact EPC or datacom technical support.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

108

eRAN11.1 eRAN Troubleshooting Guide

2.

8 Troubleshooting Rate Faults

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 yyym NOTE

"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 cell bandwidth. The value can be greater than the theoretical maximum value as long as the data volume is 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 the specified "yyym", run the following command with "-l" added to adjust the UDP packet size: iperf –c x.x.x.x –u –i 1 –t 99999 –b yyym -l 1000

d. 3.

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

Check whether the input traffic volume to the eNodeB is insufficient. A common reason for the insufficient input traffic volume is a bottleneck transmission bandwidth at an intermediate node. Check whether: –

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 the server and all switches and routers on the network.

–

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 greater than the peak value. NOTE

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

4.

Check whether the radio channel quality is unsatisfactory. –

Check whether the downlink signal quality is poor. Use the software matching the UE type to measure signal quality parameters, such as the 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.

–

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

–

(Optional) Check whether uplink interference exists. Create an interference tracing task on the U2000 client and monitor the strength of interference noises received by each resource block (RB) in the whole uplink bandwidth. Generally, the interference strength on each RB is about –120 dBm. If

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

109

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

the interference strength is higher than –115 dBm, uplink interference exists and interference sources need to be checked. 5.

Check whether the basic information about the data services or the parameter settings are incorrect. This check is twofold: –

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 AMBR of the UE are set as expected, and whether the UE is empowered with expected capabilities.

–

Check whether the basic information about the parameter settings is incorrect. The parameter settings refer to the settings for the eNodeB. Algorithm setting changes cause severe drops in the traffic rate. Export eNodeB parameter settings, and compare them with the baseline values. If the values are inconsistent, confirm whether the settings are customized for the operator or have been changed to incorrect values. If the settings have 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 Users Statistics Monitoring and Usage of RB Monitoring tasks, respectively, under cell performance monitoring. If an excessively large number of users have accessed the cell and RBs are exhausted when a UE accesses the cell, the traffic rate on each UE will not be high, 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:

8.

–

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

–

The licensed throughput capability is correct.

Check whether the client works abnormally. Client faults may exist in the UE or in the PC connected to the UE. –

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.

–

Check for faults in the PC connected to the UE. Investigate the software installed and running on the PC. You are advised to remove or close all programs except those required by the test. In addition, close the Windows firewall and firewalls of antivirus programs. Check the central processing unit (CPU) usage. If the CPU usage exceeds 80%, the CPU is 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 at a 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 severe packet misordering. –

Issue Draft A (2016-03-07)

Check the TCP rate status. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

110

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

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

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

–

Check the RTT. Ping the server by using 32-byte packets and MSS-byte packets (MSS is short for maximum segment size), and take the average RTT value for the two types as the calculated 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.

–

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

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

Typical Cases l

Case 1: The downlink rate was low with microwave transmission. Fault Description On network X in a country, the cell bandwidth was 15 MHz. In a downlink File Transfer Protocol (FTP) throughput test using a single UE in a single cell, it was found that all eNodeBs connected to a 100 Mbit/s microwave transport network had their downlink throughput not exceeding 30 Mbit/s, but eNodeBs connected to a 1 Gbit/s optical transport network had their downlink throughput as high as 80 Mbit/s. Fault Diagnosis A UDP test found that the UDP throughput was 100 Mbit/s at the sender but dropped to only 80 Mbit/s at the receiver (eNodeB). Severe packet loss occurred. Due to TCP congestion control, the throughput of 30 Mbit/s was normal, so the fault did not exist in the eNodeB. The operator requested operation and maintenance (OM) personnel to locate the packet loss point based on the following assumption: The throughput of 80 Mbit/s on the optical transport network did not reach 100 Mbit/s, so congestion should not occur in the microwave transport network. The microwave transmission media were replaced with an Ethernet cable for the direction connection between the eNodeB and the S-GW. The FTP transfer rate was maintained at 30 Mbit/s. The segment-by-segment check found that packet loss occurred at a position between the input and output ports on a switch before packets entered the microwave network. The operator traced the input and output ports and confirmed that packet loss occurred. The operator further found that the fault was caused by a small buffer size that was set for the port on the switch. Fault Handling The operator extended the buffer size and tested again. The test result indicated that the downlink 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 Description

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

111

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

Operator T in country D stated that no FTP service was available on eNodeBs operating in the 1800 MHz band but all cells operated properly with UEs normally accessing the cells, being released, and performing UDP services. Fault Diagnosis Based 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. Because UDP services ran normally in the downlink, it was almost ascertained that the fault was down link disconnection. The check on an 800 MHz eNodeB connected to the same transport network found that FTP services ran normally. Therefore, it was highly possible that the eNodeBs had faults. Due to the severe impact of the fault, data configurations were immediately restored for the 1800 MHz eNodeBs by using the backup data configuration files. The fault was rectified. The faulty configuration files were compared with baseline data configurations. The comparison result indicated that a key radio parameter for downlink and uplink transmission was set to a value different from the baseline value. The fault was caused by the incorrect parameter setting. Fault Handling Parameter 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 never reached the peak value using Samsung UEs. Fault Description In a single cell under an eNodeB on network Y in country P, a single Samsung UE could reach 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-thread and multi-thread TCP download. Both the Samsung UE and Huawei E398 experienced rate drops. Fault Diagnosis A UDP packet injection test was performed, only to find that Huawei E398 and Samsung UE could both reach the peak values. Therefore, the fault should exist in the TCP transmission mechanism. In this fault case, rate drops occurred, which was an evidence of packet loss. The fault symptoms on Huawei E398 and Samsung UE were different, so there must be causes other than packet loss. The analysis of TCP/IP headers using a third-party tool indicated that packet loss occurred on the radio interface. It was found from the configuration file for the eNodeB that the QoS class identifier (QCI) was 7 and the unacknowledged mode (UM) was used. UM is insensitive to packet loss, so the frontline personnel tried QCI 9 upon request in a further test. In the test, rate drops disappeared, but Samsung UE still failed to reach the peak value in neither single-thread nor multi-thread TCP download while Huawei E398 could reach the peak value in both single-thread and multi-thread TCP download. A further test was performed on RTT using Samsung UE and Huawei E398. The test result indicated that the RTT value for Samsung UE was longer and less stable than the RTT value for Huawei E398. A comparison between the configuration file for the eNodeB on network Y and the baseline configuration file found a difference in the radio-interface encryption setting. The Advanced Encryption Standard (AES) encryption algorithm was enabled for the radio interface on network Y, but this algorithm was disabled in the lab. The frontline personnel disabled the AES encryption algorithm as requested. Then, the traffic rate on Samsung UE could reach 100 Mbit/s. The fault could be reproduced: The rate dropped to 80 Mbit/s after this algorithm was enabled. The reason for Samsung UE's

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

112

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

failure to reach the peak value was the setting of the AES encryption algorithm on the radio interface. Fault Handling The problem in network Y was caused by more than one fault, which was further induced by incorrect parameter settings. The problem was resolved after the parameter settings were corrected.

8.4 Troubleshooting Abnormal Multi-UE Rates This section provides information required to troubleshoot abnormal multi-UE rates. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

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

Related Information Related Counters l

Measurement related to DRB (Traffic.DRB.Cell)

l

Measurement related to Thruput (Traffic.Thruput.Cell)

l

Measurement related to PDCP (Traffic.PDCP.Cell)

l

Measurement related to MAC (Traffic.MAC.Cell)

l

Measurement related to the number of User (Traffic.User.Cell)

l

Measurement related to Packet (Traffic.Packet.Cell)

l

L.Thrp.bits.DL

l

L.Thrp.bits.DL.LastTTI

l

L.Thrp.Time.DL.RmvLastTTI

l

L.Thrp.bits.UL

l

L.Thrp.bits.UE.UL.LastTTI

l

L.Thrp.Time.UE.UL.RmvLastTTI

l

L.Traffic.ActiveUser.DL.Avg

l

L.Traffic.ActiveUser.UL.Avg

Possible Causes If a large number of users complain about their traffic rates, find the cause by following the procedure for troubleshooting abnormal single-UE rates. Pay more attention to faults that may cause large-scope failures, for example, eNodeB faults, transmission failures, large-size reconfiguration, 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 actions on the network, and if necessary collect and provide KPI logs. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

113

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether the KPI calculation formula is correct. Learn the definition of the KPI, determine whether its calculation formula and measurement are correct, and check whether the observed KPI is correct according to the calculation formula.

2.

Investigate topN cells. Select topN cells and investigate them. If the fault exists in a single cell under a single eNodeB, troubleshoot the fault by referring to 8.3 Troubleshooting Abnormal SingleUE Rates.

3.

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

4.

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

5.

If the fault persists, contact Huawei technical support.

Typical Cases Fault Description On network T in a country, the routine KPI monitoring result indicated that the average traffic rate had been decreasing across the network since a day while the number of users remained almost unchanged. Fault Diagnosis The check on the rate calculation formula, counter measurement, and statistics changes found that network T never changed the formula or measurement method. Therefore, it was not the formula that caused the fault. The investigation of topN cells found that the entire network had almost the same trend, so the fault was not caused by abnormal individual cells. The analysis of other KPIs indicated that the number of users remained almost unchanged. In addition, network reconfiguration should not cause a gradual decrease. Finally, the review on recent key actions found 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 aggregate maximum bit rate (AMBR) test in a lab, Transmission Control Protocol (TCP) services were performed on UEs with AMBRs of 20 Mbit/s and 100 Mbit/s. The KPI monitoring result indicated that the rate on a UE with an AMBR of 100 Mbit/s was about four times as high as the rate on a UE with an AMBR of 20 Mbit/s. The investigation of AMBR distribution at more than ten sites in recent days found that the number of UEs with a subscribed rate of 256 Mbit/s had dropped by more than 70%. A majority of subscribers on the network were lowrate 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 of the rate decrease. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

114

eRAN11.1 eRAN Troubleshooting Guide

8 Troubleshooting Rate Faults

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

115

eRAN11.1 eRAN Troubleshooting Guide

9

9 Troubleshooting Cell Unavailability Faults

Troubleshooting Cell Unavailability Faults

About This Chapter This chapter defines cell unavailability faults and provides a troubleshooting method. 9.1 Definitions of Cell Unavailability Faults When the eNodeB detects that a cell is unavailable due to a cell activation failure, the eNodeB reports an ALM-29240 Cell Unavailable alarm. 9.2 Background Information This section provides background information for cell unavailability faults. 9.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause. 9.4 Troubleshooting Cell Unavailability Faults Due to Incorrect Data Configuration This section provides information required to troubleshoot cell unavailability faults due to incorrect data configurations. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 9.5 Troubleshooting Cell Unavailability Faults Due to Abnormal Transport Resources This section provides information required to troubleshoot cell unavailability faults due to abnormal transport resources. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 9.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF Resources This section provides information required to troubleshoot cell unavailability faults due to abnormal 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 Capability This section provides information required to troubleshoot cell unavailability faults due to limited capacity or capability. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 9.8 Troubleshooting Cell Unavailability Faults Due to Faulty Hardware This section provides information required to troubleshoot cell unavailability faults due to faulty hardware. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

116

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

9.1 Definitions of Cell Unavailability Faults When the eNodeB detects that a cell is unavailable due to a cell activation failure, the eNodeB reports 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. These causes can be found with the aid of signaling tracing, which is not described in this chapter.

9.2 Background Information This section provides background information for cell unavailability faults. Factors that may affect the running of a cell include transmission, hardware, configuration, and RF. If any factor is abnormal, the cell may be unavailable. In this case, check these factors for troubleshooting.

Related Alarms l

Cell alarms –

l

l

l

l

Transmission alarms –

ALM-25880 Ethernet Link Fault

–

ALM-25886 IP Path Fault

–

ALM-25888 SCTP Link Fault

Hardware alarms –

ALM-26101 Inter-Board CANBUS Communication Failure (Applicable to 3900 series base stations only)

–

ALM-26200 Board Hardware Fault

–

ALM-26205 BBU Board Maintenance Link Failure (Applicable to 3900 series base stations only)

Optical module and CPRI alarms related to the faulty cell (Applicable to 3900 series base stations only) –

ALM-26230 BBU CPRI Optical Module Fault

–

ALM-26246 BBU CPRI Line Rate Negotiation Abnormal

RF module alarms related to the faulty cell (Applicable to 3900 series base stations only) –

l

ALM-26251 Board Type and Configuration Mismatch (Applicable to 3900 series base stations only)

License alarms –

l

ALM-26238 RRU Network Topology Type and Configuration Mismatch

Configuration alarms related to the faulty cell –

l

ALM-29240 Cell Unavailable

ALM-26817 License on Trial

Other alarms –

Issue Draft A (2016-03-07)

ALM-29201 S1 Interface Fault Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

117

eRAN11.1 eRAN Troubleshooting Guide

–

9 Troubleshooting Cell Unavailability Faults

ALM-26262 External Clock Reference Problem

9.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause.

Possible Causes Cell unavailability may be caused by: l

Incorrect data configuration

l

Abnormal transport resources

l

Abnormal RF resources

l

Limited capacity or capability

l

Faulty hardware

Troubleshooting Flowchart Cell 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 running of a cell. The fault handling method provided in this section is used before log analysis, which is shown in Figure 9-1.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

118

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

Figure 9-1 Troubleshooting flowchart for cell unavailability faults

Troubleshooting Procedure 1.

Check whether there are related alarms. Yes: Handle the alarms. For 3900 series base stations, see eNodeB Alarm Reference. For the BTS3202E, see BTS3202E Alarm Reference. For the BTS3911E, see BTS3911E Alarm Reference.Go to 2. No: Go to 3.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

119

eRAN11.1 eRAN Troubleshooting Guide

2.

9 Troubleshooting Cell Unavailability Faults

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

3.

Check cell fault information. Perform the following operations in different scenarios:

4.

–

If the cell fault occurs during the deployment of an eNodeB or the setup of a cell, run the ACT CELL command.

–

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

Rectify the fault based on cell fault information. Possible fault causes and handling methods are provided as follows:

5.

–

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

–

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

–

If system capacity or capability is limited, follow the instructions on how to troubleshoot cell unavailability faults due to limited capacity or capability.

–

If data configurations are incorrect, follow the instructions on how to troubleshoot cell unavailability faults due to incorrect data configurations.

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

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.

8.

Contact Huawei technical support.

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

Fault Description A cell fails to be set up after data configuration.

Related Information A cell cannot be set up successfully if the cell parameter settings do not match the actual RF/ baseband processing capability or other parameters. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

120

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

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

ALM-29240 Cell Unavailable

Possible Causes A resource item is set to a value inconsistent with the hardware or software configuration, leading to 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 (Applicable to 3900 series base stations only)

l

Incorrect cell network-related configuration (Applicable to 3900 series base stations only)

The common causes are: l

Incorrect cell power configuration

l

Incorrect cell bandwidth configuration

l

Incorrect cell network-related configuration (Applicable to 3900 series base stations only)

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether there are related alarms. Yes: Handle the alarms. For 3900 series base stations, see eNodeB Alarm Reference. For the BTS3202E, see BTS3202E Alarm Reference. For the BTS3911E, see BTS3911E 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.

4.

Check whether the cell fault is rectified.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

121

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

Yes: End. No: Go to 5. 5.

Contact Huawei technical support.

Typical Cases None

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

Fault Description If the cell unavailability is caused by abnormal transport resources, a message will be displayed after the ACT CELL or DSP CELL command is executed. The message indicates that the S1 interface used by the cell or an IP path on the S1 interface is abnormal.

Related Information None

Possible Causes The 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.

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether S1 resources are unavailable. Cell unavailability is caused by S1 resource unavailability if any of the following conditions is met: –

In the output of the DSP CELL command, the value of Cell latest avail state is Unavailable S1 link.

–

In the output of the ACT CELL command, the following information is provided: [0]Configuration data activating failed: (1973485632) Cell S1 link (include S1 interface and IP path) is abnormal.

Yes: Configure S1 resources. Go to 2. No: Go to 3. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

122

eRAN11.1 eRAN Troubleshooting Guide

2.

9 Troubleshooting Cell Unavailability Faults

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

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.

4.

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

5.

Check whether there is an S1 interface fault alarm. Yes: Handle the alarm according to the help information of ALM-29201 S1 Interface Fault. Go to 6. No: Go to 7.

6.

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

7.

Contact Huawei technical support.

Typical Cases Fault Description A cell failed to be activated. In the command output, the value of Reason For Latest State Change was CCEM_CELLBASIC_ERR_CELL_SETUP_FAIL_S1LINK_DOWN~1973485632. Fault Diagnosis 1.

Check for active alarms of the site. It was found that there was no alarms related to this cell.

2.

Run the DSP SCTPLNK command to query the status of the desired SCTP link. The result showed that the link status was normal.

3.

Run the DSP S1INTERFACE command to query the status of the desired S1 interface. No result was displayed, indicating that the S1 interface was not configured.

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

9.6 Troubleshooting Cell Unavailability Faults Due to Abnormal RF Resources This section provides information required to troubleshoot cell unavailability faults due to abnormal RF resources. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

123

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

Fault Description RF-related alarms are reported.

Related Information RF Resource Item The RF resource items to be checked include: l

Whether CPRI links between RF units and LBBPs work properly (Applicable to 3900 series base stations only)

l

When the working status of RF units is normal

l

Whether RF unit versions match the main control board version (Applicable to 3900 series base stations only)

l

When the line rates of CPRI links are successfully negotiated (Applicable to 3900 series base stations only)

l

Whether RF networking is consistent with data configuration (Applicable to 3900 series base stations only)

Possible Causes A 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 between the main control board and RF units, unsuccessful negotiation of CPRI line rates, and mismatch between RF networking and data configuration.

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether there are alarms related to RF units or RF unit maintenance links. Yes: Handle the alarms. For 3900 series base stations, see eNodeB Alarm Reference. For the BTS3202E, see BTS3202E Alarm Reference. For the BTS3911E, see BTS3911E Alarm Reference.Go to 2. No: Go to 3.

2.

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

3.

Check whether RF resources are abnormal. For 3900 series base stations, run the DSP BRD, DSP RRU, or DSP BRDVER command to check whether RF resources are abnormal. For the BTS3202E/BTS3911E, run the DSP BRU or DSP BRDVER command to check whether RF resources are abnormal. Yes: Handle the problem. Go to 4. No: Go to 5.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

124

eRAN11.1 eRAN Troubleshooting Guide

4.

9 Troubleshooting Cell Unavailability Faults

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

5.

If the fault persists, contact Huawei technical support.

Typical Cases Fault Description After a cell activation command was executed, Figure 9-2 was displayed. In another case, after a cell query command was executed, Figure 9-3 was displayed. Figure 9-2 RRU TX branch is not usable (1)

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

125

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

Fault Handling Flowchart OM personnel checked RF-channel-related alarms (including VSWR alarms and RF unit maintenance link alarms) and found there were RF unit maintenance link alarms. OM personnel then 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 successfully activated.

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

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

Related Information None

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

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

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. Yes: End. No: Go to 4.

4.

If the fault persists, contact Huawei technical support.

Typical Cases Fault Description After the DSP CELL command was executed, Figure 9-4 was displayed. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

126

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

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

Fault Handling Flowchart According to the command output, the cell activation failure is caused by license limitation. The DSP 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 activation failure. Fault Handling After a new license is applied for, downloaded, and activated, the cell is successfully activated.

9.8 Troubleshooting Cell Unavailability Faults Due to Faulty Hardware This section provides information required to troubleshoot cell unavailability faults due to faulty hardware. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

127

eRAN11.1 eRAN Troubleshooting Guide

9 Troubleshooting Cell Unavailability Faults

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

Related Information 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).

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether the board status is abnormal and whether the board versions are mismatched. For 3900 series base stations, run the DSP BRD or DSP BRDVER command for query. Pay more attention to RF units. For the BTS3202E/BTS3911E, run the DSP BRU or DSP BRDVER command for query. Pay more attention to RF units. Yes: Rectify the board faults. Go to 2. No: Go to 3.

2.

Check whether the cell fault is rectified. 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, and boards, such as the LBBP, or main control board. For 3900 series base stations, run the RST BRD or RST ENODEB command. For the BTS3202E/BTS3911E, run the RST BRD or RST BTSNODEB 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. (Applicable to 3900 series base stations only) Run the OPR BRDPWR command.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

128

eRAN11.1 eRAN Troubleshooting Guide

8.

9 Troubleshooting Cell Unavailability Faults

(Optional) Check whether the cell fault is rectified. Yes: End. No: Go to 9.

9.

If the fault persists, contact Huawei technical support.

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

129

eRAN11.1 eRAN Troubleshooting Guide

10

10 Troubleshooting IP Transmission Faults

Troubleshooting IP Transmission Faults

About This Chapter This section defines IP transmission faults and describes how to troubleshoot IP transmission faults. 10.1 Definitions of IP Transmission Faults If an Internet Protocol (IP) transmission fault occurs, messages and service data cannot be transmitted between communication devices, and a peer device cannot be pinged. 10.2 Background Information This section provides alarms related to IP transmission faults. 10.3 Troubleshooting Method This section describes the method and procedure for troubleshooting IP transmission faults. 10.4 Troubleshooting the Physical Layer This section provides information required to troubleshoot IP physical layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 10.5 Troubleshooting the Data Link Layer This section provides information required to troubleshoot IP link layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 10.6 Troubleshooting the IP Layer This section provides information required to troubleshoot IP layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

130

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

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

10.2 Background Information This section provides alarms related to IP transmission faults.

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

ALM-25880 Ethernet Link Fault

l

ALM-25885 IP Address Conflict

l

ALM-25886 IP Path Fault

l

ALM-25888 SCTP Link Fault

l

ALM-29240 Cell Unavailable

l

ALM-25952 User Plane Path Fault

l

ALM-29207 eNodeB Control Plane Transmission Interruption

l

ALM-25891 IKE Negotiation Failure

l

ALM-29201 S1 Interface Fault

For details, see eNodeB Alarm Reference.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

131

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

Troubleshooting Flowchart Figure 10-1 Troubleshooting flowchart for IP transmission faults

Troubleshooting Procedure 1.

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 IP address nearest to the local end or the network segment IP address cannot be pinged, there is an IP data link layer fault. Rectify the fault. If the IP address nearest to the local end or the 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 the destination IP address. If the IP address in the same network segment can be pinged but the 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.

4.

If the fault persists, contact Huawei technical support.

10.4 Troubleshooting the Physical Layer This section provides information required to troubleshoot IP physical layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

132

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

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

Related Information None

Possible Causes The Ethernet cable or optical module has faults.

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Monitor the Ethernet port indicator status. There are two indicators for an Ethernet port. If the green indicator is on, the negotiation succeeds between the Ethernet port and the peer port. If the green indicator is off, the negotiation fails between the Ethernet port and the peer port. If the yellow indicator blinks fast, data is being transmitted through the port. If the yellow indicator is off, no data is being transmitted through the port. Locate the fault based on the indicator status.

2.

Indicator Status

Possible Fault Cause

Both green indicators on the eNodeB and switch are on.

Port negotiation is successful and the ports are up. This indicates that the physical layer communication is normal.

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

The port on the eNodeB is up and the port on the switch is down. The possible cause is that the configuration is incorrect or the hardware is faulty. Perform the following steps to locate the fault.

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

The port on the eNodeB is down and the port on the switch is up. The possible cause is that the configuration is incorrect or the hardware is faulty. Perform the following steps to locate the fault.

Both green indicators on the eNodeB and the switch are off.

The negotiation has failed and the ports are down. Perform the following steps to locate the fault.

Check cables. –

Check the Ethernet cable. Check whether the Ethernet cable is properly prepared and whether the cable is longer than 100 m.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

133

eRAN11.1 eRAN Troubleshooting Guide

–

10 Troubleshooting IP Transmission Faults

i.

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

ii.

Disconnect the Ethernet cable from the eNodeB and connect it to the PC and check whether 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 between the PC and the switch.

Check the optical cable and optical modules. i.

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

ii.

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. If it is broken, replace it.

iii. Check whether the optical module is damaged by inserting two ends of one optical cable to the optical module. Check whether an alarm indicating an optical module fault is reported on the LMT. If no alarm indicating an optical module fault is reported, the optical module is normal. If an alarm indicating optical module fault is reported, replace the optical module. 3.

Check configurations. Log in to the eNodeB and run the LST ETHPORT and DSP ETHPORT commands to check 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 electrical port is used, the port status should be down. Other parameters can be checked in a similar way. The rate and duplex mode must be configured the same on the eNodeB and the switch. If they are not configured the same on the eNodeB and the switch, the port negotiation fails or the port negotiation succeeds but packets are lost. The Gigabit Ethernet (GE) electrical port on the eNodeB can be set to AUTO only. If the GE electrical port on the eNodeB is used to connect to the switch, the port attribute must be set to AUTO on both the eNodeB and the switch. The following parameter settings are recommended.

Issue Draft A (2016-03-07)

Port Type

Rate and Duplex Mode on the eNodeB

Rate and Duplex Mode on 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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

134

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

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 change and the DSP ETHPORT command output is the same as expected, the rate and duplex mode are both set to AUTO on the switch. If the port negotiation fails, the rate and duplex mode are not set to AUTO on the switch. Analyze the possible configuration on the switch based on the DSP ETHPORT command output and change the configuration on the eNodeB accordingly. 4.

Isolate the fault. a.

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

b.

Connect a PC to the Ethernet port on the switch and check whether the PC indicator is on.

c.

Identify and isolate the fault. n

If the alarm is cleared and the PC indicator is off, the Ethernet port on the switch is faulty. Go to 4.d.

n

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

n

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

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 indicating a board chip fault is reported, replace the board on which the Ethernet port is located.

f. 5.

Check the parameters negotiated between the Ethernet ports on the switch and the eNodeB.

If the fault persists, contact Huawei technical support.

Typical Cases None

10.5 Troubleshooting the Data Link Layer This section provides information required to troubleshoot IP link layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

135

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

Related Information None

Possible Causes l

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

l

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

Fault Diagnosis Check whether the ARP and VLAN mechanisms work properly. Before transmitting an Internet Control Message Protocol (ICMP), Stream Control Transmission Protocol (SCTP), or User Datagram 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 ARP table is configured on the eNodeB. If no ARP table is configured, the eNodeB broadcasts an ARP request for the next-hop MAC address.

Troubleshooting Procedure 1.

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

2.

Query the ARP table. Run the DSP ARP to check whether the eNodeB has learnt ARP information and obtained the MAC address mapping to the IP address of the peer port. If the eNodeB has not learnt ARP information, perform a ping test to the next-hop IP address of the route and check again whether the eNodeB learns ARP information. If not, go to the next step. (Optional) Query the ARP information on the onsite switch. The ARP aging period is 20 minutes on the eNodeB. If the communication between the eNodeB and the peer device continues only for 20 minutes, the ARP update has failed after the aging. If the VLAN configuration is changed within the 20 minutes, the fault is caused by an incorrect VLAN configuration. If the VLAN configuration is not changed within the 20 minutes, the peer device must also be checked.

3.

Check the VLAN configuration. Run the LST VLANMAP or LST VLANCLASS command to check whether the VLAN configuration is correct. If the VLAN configuration is correct but the eNodeB has not learnt ARP information, run the RST ETHPORT to reset the port. If the eNodeB does not learn the ARP information of the peer device after the port reset, capture packets for problem analysis. To capture packets, run the STR PORTREDIRECT command on the eNodeB to start port mirroring and then use another local physical port to connect to the PC on which the packet capturing tool is installed for tracing packet headers. Packets are captured for checking whether the eNodeB can send ARP messages normally. By comparing the VLAN information in the transmitted and received ARP messages, the consistency between the VLAN configuration of the eNodeB and that of the peer device can be checked. If the VLAN

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

136

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

configurations are inconsistent, modify the VLAN configuration on the eNodeB and perform the check again. NOTE

If 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. Confirm with the customer the VLAN configuration and port type of the peer device and the reason why the peer device does not respond. 4.

If the fault persists, contact Huawei technical support.

Typical Cases None

10.6 Troubleshooting the IP Layer This section provides information required to troubleshoot IP layer faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description The peer device cannot be pinged and an IP address in the same network segment as the eNodeB can be pinged. Alarms indicating an SCTP link fault, cell unavailability, and a path fault are reported by the upper layer.

Related Information None

Possible Causes l

The route configuration is incorrect or a related device is faulty.

l

The transmission network is disconnected.

Fault Diagnosis In 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.

Troubleshooting Procedure 1.

Query the configured routes. Run the LST IPRT and DSP IPRT commands to check whether routes are correctly configured on the eNodeB.

2.

Use the traceroute function to locate the fault. If the transport network supports the traceroute function, run the TRACERT command on the eNodeB to query the nodes on which the messages are transmitted, and then check which gateway is disconnected

3.

Trace protocol data.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

137

eRAN11.1 eRAN Troubleshooting Guide

10 Troubleshooting IP Transmission Faults

Run the STR PORTREDIRECT command on the eNodeB to start port mirroring to trace the protocol and packet header. 4.

If the fault persists, contact Huawei technical support.

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

138

eRAN11.1 eRAN Troubleshooting Guide

11

11 Troubleshooting Application Layer Faults

Troubleshooting Application Layer Faults

About This Chapter This chapter describes the definitions of application layer faults and the troubleshooting method. 11.1 Definitions of Application Layer Faults Application layer faults include unavailability and intermittent disconnection of Stream Control Transmission Protocol (SCTP) links, Internet Protocol (IP) paths, and operation and maintenance (OM) channels. 11.2 Background Information 11.3 Troubleshooting Method This section describes the method and procedure for troubleshooting IP transport and application layer faults. 11.4 Troubleshooting the SCTP Link This section provides information required to troubleshoot SCTP link faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 11.5 Troubleshooting the IP Path This section provides information required to troubleshoot IP path faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 11.6 Troubleshooting the OM Channel This section provides information required to troubleshoot OM channel faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

139

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

11.1 Definitions of Application Layer Faults Application layer faults include unavailability and intermittent disconnection of Stream Control Transmission Protocol (SCTP) links, Internet Protocol (IP) paths, and operation and maintenance (OM) channels.

11.2 Background Information The Stream Control Transmission Protocol (SCTP) is a transmission protocol that works on the IP 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 standard to which the SCTP conforms is Request for Comments (RFC) 4960 released in October 2000. Compared with the TCP, the SCTP is improved for specific applications. In addition, multiple features 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. An OM channel is set up using TCP handshakes.

11.3 Troubleshooting Method This section describes the method and procedure for troubleshooting IP transport and application layer faults.

Troubleshooting Flowchart Figure 11-1 shows the troubleshooting flowchart for IP transport and application layer faults.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

140

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

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

Troubleshooting Procedure 1.

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 whether the 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 is reported or whether the OM channel status is abnormal. Yes: Troubleshoot the OM channel fault. No: Go to 4.

4.

Contact Huawei technical support.

11.4 Troubleshooting the SCTP Link This section provides information required to troubleshoot SCTP link faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

141

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

Fault Description l

l

Either of the following alarms is reported: –

ALM-25888 SCTP Link Fault

–

ALM-25889 SCTP Link Congestion

–

ALM-29207 eNodeB Control Plane Transmission Interruption

–

ALM-29208 M2 Interface Fault

All or part of SCTP links are disconnected or one-way disconnected. The eNodeB sends signaling or service data but cannot receive response or data from the peer device.

l

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

Related Information To 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 dual homing), and peer port number configured on the eNodeB must be consistent with those configured on the mobility management entity (MME). Run the LST SCTPLNK command. In the command output, the parameters in red rectangles are eNodeB parameters and the parameters in the blue rectangles are evolved packet core (EPC) parameters. Ensure that the MME parameters configured on the eNodeB are consistent with the SCTP parameters of the MME and that eNodeB parameters configured on the EPC are consistent with the SCTP parameters of the eNodeB.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

142

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

Figure 11-2 SCTP link configuration information

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

Possible Causes l

The transmission network is faulty.

l

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

l

The NE has internal faults.

Troubleshooting Flowchart None Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

143

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

Troubleshooting Procedure l

Typical Scenario To find the cause for an SCTP fault, perform the following steps: a.

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

b.

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

c.

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

d.

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 the data. If desired data is traced, the transmission network and EPC are normal.

e. l

If the fault persists, contact Huawei technical support.

Intermittent SCTP Link Disconnection If an SCTP link is intermittently interrupted, the eNodeB cannot receive a response from the peer device and then the SCTP link is down. After several seconds, the eNodeB initiates SCTP link reestablishment and the SCTP link recovers. a.

Check transmission alarms.

b.

Check the Quality of Service (QoS) of signaling data. If VLANs are configured for the eNodeB, check whether the VLAN for signaling data is correctly configured on the eNodeB. If VLANs are differentiated by nexthop IP address, the check is not required. If VLANs are differentiated by service type, the check is required. If no VLAN is configured for the eNodeB, check whether the DSCP value for signaling data is the same as that for the transmission network. Run the LST DIFPRI command to query the DSCP value for signaling data. Check whether the DSCP value is 46 in the QoS configuration for the transmission network. Ensure that data with a DSCP value of 46 can be properly transmitted in the transmission network. If the transport network bandwidth is limited and the DSCP value for SCTP services is less than that for other types of services, the SCTP link will be intermittently interrupted. Therefore, check whether SCTP services has a high DSCP-indicated priority in the transmission network with the customer.

c.

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

d.

Check the network packet loss rate. If the SCTP message tracing shows that packets are lost, check whether the port attribute of the gigabit Ethernet (GE) or fast Ethernet (FE) port is consistent with

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

144

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

that on the peer device. If it is consistent, ping the peer device to check the packet loss rate on the transmission network. e.

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 the data. If desired data is traced, the transmission network and EPC are normal.

f.

Take preventive measures. If configurations are correct and the peer device can be pinged, run the MOD SCTPLNK command or remove the SCTP link information and reconfigure the SCTP parameters so that the eNodeB and the peer device negotiate about the SCTP link again.

g.

If the fault persists, contact Huawei technical support.

Typical Cases None

11.5 Troubleshooting the IP Path This section provides information required to troubleshoot IP path faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description l

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 Information The related alarm is as follows: l

ALM-25886 IP Path Fault

l

ALM-25952 User Plane Path Fault

Possible Causes l

The IP path parameters are incorrectly configured.

l

The bearer link of the IP path is faulty.

l

No packet filtering criteria for IP paths is included in access control list (ACL) rules.

l

The lower-layer link of the user-plane bear link is faulty.

l

The user-plane bearer link detection fails because the packet filtering function is enabled on the eNodeB.

l

The user-plane bearer link detection fails because network or peer device configurations are incomplete.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

145

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check whether ALM-25886 IP Path Fault or ALM-25952 User Plane 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 and DSCP is 0, only default bearers can be set up. In this case, change Path Type to ANY.

3.

Query the configuration of ACL rules. Run the LST ACLRULE command to check whether packet filtering criteria is configured for IP paths or user-plane bearer links. If yes, check whether the criteria is incorrectly configured by comparing the configuration with that on an eNodeB in normal status.

4.

Contact EPC engineers and check whether the P-GW supports GTP-U detection. If the P-GW supports the detection, check whether the P-GW is incorrectly configured. If the P-GW does not support the detection, the detection must be disabled on the eNodeB.

5.

If the fault persists, contact Huawei technical support.

Typical Cases None

11.6 Troubleshooting the OM Channel This section provides information required to troubleshoot OM channel faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description The 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.

Related Information None

Possible Causes l

The transmission network is faulty.

l

The OM channel parameters are incorrectly configured on the eNodeB or mobility management entity (MME).

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

146

eRAN11.1 eRAN Troubleshooting Guide

l

11 Troubleshooting Application Layer Faults

Certain ports are disabled on intermediate transport equipment.

Troubleshooting Flowchart None

Troubleshooting Procedure This section describes how to handle an OM channel fault in various scenarios. l

Typical Scenario a.

Check configurations. Check whether OM channel parameters are correctly configured on the U2000 client and the eNodeB.

b.

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

If ping operations are prohibited in the operator network, do not ping the U2000 client.

c.

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

d. l

If the fault persists, contact Huawei technical support.

Intermittent OM Channel Interruption a.

Check IP address conflict. Search for the OM IP address of the eNodeB on the U2000 client and check whether the OM IP address conflicts with that of another eNodeB. If conflict occurs, modify OM IP addresses based on the network planning. If no conflict occurs, perform the following operation to locate the fault.

b.

Check transmission alarms. On the U2000 client, check whether a transmission alarm is reported by the eNodeB during the intermittent transmission, for example, whether an Ethernet trunk fault alarm is reported. If a transmission alarm is reported, adjust the transport network. If no transmission alarm is reported, go to the next step. Check whether an alarm indicating intermittent link (such as SCTP link) disconnections is also reported. If such an alarm is reported, rectify the fault too.

c.

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

d.

Check whether network loopbacks exist. Check whether loopbacks exist in the network based on the network topology. The causes of loopbacks are twofold. Some loopbacks are caused by oversights in network design, whereas others are temporary loopback links that were built during

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

147

eRAN11.1 eRAN Troubleshooting Guide

11 Troubleshooting Application Layer Faults

link tests but were not removed promptly. As a result, loopbacks require careful investigation. e.

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

f.

If the fault persists, contact Huawei technical support.

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

148

eRAN11.1 eRAN Troubleshooting Guide

12 Troubleshooting Transmission Synchronization Faults

12

Troubleshooting Transmission Synchronization Faults

About This Chapter This chapter describes how to troubleshoot transmission synchronization faults. The faults of this type include the clock reference problem, IP clock link fault, system clock unlocked fault, base station synchronization frame number error, or time synchronization failure. 12.1 Definitions of Transmission Synchronization Faults This section describes the classification and definitions of transmission synchronization faults. 12.2 Background Information For details about IP clock and non-IP clock, see eRAN Synchronization Feature Parameter Description. 12.3 Troubleshooting Specific Transmission Synchronization Faults This section provides information required to troubleshoot specific transmission synchronization faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

149

eRAN11.1 eRAN Troubleshooting Guide

12 Troubleshooting Transmission Synchronization Faults

12.1 Definitions of Transmission Synchronization Faults This section describes the classification and definitions of transmission synchronization faults. The following defines common transmission synchronization faults: l

Clock reference problem This fault occurs in the case of external clock reference loss, external clock reference unavailability due to unacceptable quality, or excessive phase (or frequency) deviation between the local oscillator and external clock references.

l

IP clock link fault This fault occurs when the IP clock link between the eNodeB and the clock server malfunctions.

l

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

l

Base station synchronization frame number error This 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 are abnormal.

l

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

12.2 Background Information For details about IP clock and non-IP clock, see eRAN Synchronization Feature Parameter Description.

12.3 Troubleshooting Specific Transmission Synchronization Faults This section provides information required to troubleshoot specific transmission synchronization faults. 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 incapable of locking the reference clock. The clock status can be checked by running the DSP CLKSTAT 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.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

150

eRAN11.1 eRAN Troubleshooting Guide

12 Troubleshooting Transmission Synchronization Faults

l

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

l

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

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

Related Information l

The following describes how to perform a clock quality test: a.

Start a clock quality test by running the STR CLKTST command.

b.

Several hours later, stop the clock quality check by running the STP CLKTST command.

c.

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

Possible Causes l

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 Flowchart None

Troubleshooting Procedure 1.

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, frequency synchronization or phase synchronization. If the configuration is incorrect, change the mode to the required one.

b.

Check whether the clock sources are correctly added. Use different query commands for different clock sources. For details, see eNodeB MML 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 to AUTO or MANUAL. The difference between the two settings is: n

AUTO indicates that the eNodeB automatically selects a reference clock based on the status, priorities, and link available status of reference clocks.

n

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.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

151

eRAN11.1 eRAN Troubleshooting Guide

12 Troubleshooting Transmission Synchronization Faults

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

License Authorized Generally, the value of this parameter indicates that the clock source can be used. If the value indicates that the clock source cannot be used, enable the eNodeB synchronization function. To check whether the eNodeB synchronization function is enabled, run the DSP LICENSE command. If the Allocated, Config, and Actual Used fields of the Enhanced Synchronization control item are all 1, the function is enabled.

–

Clock Source State The link available status (Link Available State) of a reference clock can be checked by 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 the eNodeB meets either of the following conditions: n

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

n

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

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

3.

n

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

n

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 only on the equipment that sends the clock signals whether they are correctly sent. For an IP clock, you can check whether clock packets are correctly received by performing a trace task on the U2000 or by analyzing packet headers on the nearest transmission equipment. The clock source state and link available state of an IP clock can be determined based on the characteristics of received clock packets. For details about the analysis, see the PTP clock packet analysis procedure in the next step.

Check whether the eNodeB correctly selects a clock source. When multiple external clock sources are added and work properly, the output of the DSP CLKSRC command indicates that the status of these clock sources is Available. In addition, the output of the corresponding link query command (DSP IPCLKLINK, DSP SYNCETH, DSP GPS, or DSP TOD) indicates that the status of the clock link is also Available. Note that only the link activation status (Link Active State) of the clock source selected as the reference clock is Activated. The link activation status of other clock sources is Unactivated. The reference clock is explained as follows: –

Issue Draft A (2016-03-07)

If the clock working mode is set to MANUAL using the SET CLKMODE command, the reference clock is the manually selected clock source. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

152

eRAN11.1 eRAN Troubleshooting Guide

4.

12 Troubleshooting Transmission Synchronization Faults

–

If the clock working mode is set to AUTO using the SET CLKMODE command, the reference clock is the one automatically selected. The query command is DSP CLKSTAT.

–

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

Check whether the eNodeB correctly locks an external clock source. To check the lock status, run the DSP CLKSTAT command. The following describes the parameters in this command: –

Current Clock Source: It indicates the clock source to be traced by the eNodeB.

–

Current Clock Source State: The value should be Normal.

–

PLL Status: The initial status should be Fast Tracking, and then Locked.

–

Clock Synchronization Mode: It indicates the configured clock synchronization mode. n

Non-IP clock For a non-IP clock source, if the link available state is available and the link active state is activated in step 3, the states queried by running DSP CLKSTAT must be normal. The only risk is that the eNodeB enters free-run mode (instead of locked mode) after a 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 still above the locking threshold. Therefore, the eNodeB cannot lock an external clock source 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.

n

IP clock For an IP clock, even if the clock link is available and activated, it cannot be guaranteed that all check items are normal. The query command is DSP CLKSTAT. The reason is that whether the eNodeB can lock an external clock source depends on two packets (Sync and Delay_Resp) as well as the clock information the packets carry. In this situation, take two actions: (1) Collect clock packets received by the eNodeB on the U2000 or collect headers of the packets on the nearest transmission equipment; (2) Perform a clock quality test on the IP clock in the same way as that for a non-IP clock. Then, send the packets (or packet headers) and quality test result to Huawei technical support.

5.

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

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

153

eRAN11.1 eRAN Troubleshooting Guide

13

13 Troubleshooting Transmission Security Faults

Troubleshooting Transmission Security Faults

About This Chapter This chapter describes how to troubleshoot transmission security faults. 13.1 Definitions of Transmission Security Faults A transmission security fault occurs when an IPSec tunnel between an eNodeB and a security gateway (SeGW) malfunctions. This fault leads to abnormal communication between the eNodeB and the EPC. 13.2 Background Information This section describes the data that requires encryption in transmission security networking scenarios. In addition, this section provides the parameters related to transmission security. 13.3 Troubleshooting Specific Transmission Security Faults This section provides information required to troubleshoot specific transmission security faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

154

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

13.1 Definitions of Transmission Security Faults A transmission security fault occurs when an IPSec tunnel between an eNodeB and a security gateway (SeGW) malfunctions. This fault leads to abnormal communication between the eNodeB and the EPC. Transmission security faults include: l

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

l

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

l

Certificate application failure: An IKE negotiation fails because the eNodeB fails to obtain a digital certificate.

13.2 Background Information This section describes the data that requires encryption in transmission security networking scenarios. In addition, this section provides the parameters related to transmission security. l

Encapsulation between two eNodeBs: Data streams between two eNodeBs are encapsulated in transport mode.

l

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

l

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

Figure 13-1 Transmission security networking

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

155

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

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

13.3 Troubleshooting Specific Transmission Security Faults This section provides information required to troubleshoot specific transmission security faults. The information includes fault descriptions, background information, possible causes, fault handling 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 the U2000 to the eNodeB.

l

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

l

Transmission detection commands such as ping cannot be successfully executed.

Related Information l

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, which leads to IPSec tunnel negotiation failures.

l

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

Troubleshooting Flowchart Transmission security faults are generally due to data configuration. Therefore, data consistency check between the eNodeB and the SeGW is crucial to troubleshooting. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

156

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-2 Troubleshooting flowchart for transmission security faults

Troubleshooting Procedure 1.

Check whether an IPSec policy group is bound to the port involved. Run the LST IPSECBIND command. The output is shown in Figure 13-3:

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

157

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-3 List binding relationships

NOTE

This section uses the 3900 series base station as an example. The value of Slot No. is 0 for the BTS3202E/BTS3911E in the example.

2.

–

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

–

If the binding relationship is incorrect, run the RMV IPSECBIND command to remove the IPSec bind, and then run the ADD IPSECBIND command to add the bind.

Resolve the problem of the IKE negotiation failure. Run the DSP DIAGNOSE command with the Diagnose Type parameter set to IKENEGO(IKENEGO) to identify the cause of the IKE negotiation failure. –

Issue Draft A (2016-03-07)

If IKE negotiation fails due to incorrect settings of IKE-related parameters (for example, parameters related to the encryption algorithm, authentication algorithm, authentication methods, or DH algorithm), run the DSP IKEPROPOSAL command for query. If the values in the red frame are inconsistent with the network plan, run the MOD IKEPROPOSAL command to change them.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

158

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-4 List IKE negotiation results

–

If IKE negotiation fails due to inconsistency between IKE versions, inconsistency of interaction modes, incorrect configuration of the IP address for negotiation, or incorrect configuration of local ID type, run the DSP IKEPEER command for query. If the values in the red frame are inconsistent with the network plan, run the MOD IKEPEER command to change them. The following information in the red frame needs to be mainly concerned and checked:

Issue Draft A (2016-03-07)

n

Whether the settings of the Version and Exchange Mode parameters on the eNodeB are consistent with those on the gateway.

n

Whether the setting of the Remote IP Address parameter on the eNodeB is consistent with the interface IP address configured on the gateway.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

159

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-5 List IKE peer information

3.

Check whether the eNodeB's certificate chain is correct. Run the DSP IKEPROPOSAL command. If the Authentication Method parameter is IKE_RSA_SIG, perform the following operations: a.

Check the operator's root certificate. Run the DSP TRUSTCERT command. Pay more attention to the information in the red frame. Check whether the name of the root certificate is 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 root certificate, and run the ADD TRUSTCERT command to add the root certificate to the eNodeB. Figure 13-6 List operator's root certificate information

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

160

eRAN11.1 eRAN Troubleshooting Guide

b.

13 Troubleshooting Transmission Security Faults

Check the operator's device certificate. Run the DSP CERTMK command. Pay more attention to the information in the red frame. Check whether the issuer of the root certificate is 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 device certificate, and run the ADD CERTMK command to add the device certificate to the eNodeB. Figure 13-7 List operator's device certificate information

c.

Check whether the certificates used for IKE and SSL are correct. Run the DSP APPCERT command. Pay more attention to the information in the red frame. If a used certificate is incorrect, run the MOD APPCERT command to change it. Figure 13-8 List certificates used for IKE and SSL

4.

Check whether the IPSec proposal is correctly configured. Run the DSP IPSECPROPOSAL command for query. If the values in the red frame are inconsistent with the network plan, run the MOD IPSECPROPOSAL command to change them.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

161

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-9 List IPSec proposal information

5.

Check whether the IPSec policy is correctly configured. Run the DSP IPSECPOLICY command for query. If the values in the red frame are inconsistent with the network plan, run the MOD IPSECPOLICY command to change them. Figure 13-10 List IPSec policy information

6.

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 MOD ACLRULE command to change them.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

162

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

Figure 13-11 List ACL rule information

7.

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 board logs. If possible, collect header information transmitted between the eNodeB and the SeGW during negotiation.

Typical Cases The 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 the eNodeB and the SeGW. Fault Diagnosis 1.

OM personnel checked whether the IPSec-related parameters were correctly configured.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

163

eRAN11.1 eRAN Troubleshooting Guide

13 Troubleshooting Transmission Security Faults

The output of the DSP IKESA command indicated that the IKE SA status in phase 1 was Ready or Ready|StayAlive, but the status in phase 2 was None. IPSec-related parameter settings 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 eNodeB has not received any responses from an SeGW for a long time, the eNodeB will continue to send six IKE_AUTH messages before staring the next round of authentication negotiation.

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 indicated that the SeGW failed to obtain the required IPSec proposal and therefore this round of IKE authentication negotiation failed. The SeGW sent these messages to notify the eNodeB of this failure. NOTE

The eNodeB considered the encrypted notification messages invalid and therefore discarded these messages.

Fault Handling This fault was due to the configuration on the peer equipment. After the message transmission rule on the peer equipment was modified, the fault was rectified.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

164

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

14

Troubleshooting RF Unit Faults

About This Chapter This chapter describes the method and procedure for troubleshooting radio frequency (RF) unit faults in the Long Term Evolution (LTE) system. 14.1 Definitions of RF Unit Faults If a radio frequency (RF) unit is faulty, its sensitivity decreases, leading to deterioration of the cell demodulation performance and reduction of the uplink coverage, or even service interruption in the cell. 14.2 Background Information This section defines the concepts related to RF unit fault troubleshooting. The concepts are voltage standing wave ratio (VSWR) tests, passive intermodulation (PIM) interference, external interference, and remote electrical tilt (RET) antennas. 14.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause. 14.4 Troubleshooting VSWR Faults This section provides information required to troubleshoot VSWR faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 14.5 Troubleshooting RTWP Faults This section provides information required to troubleshoot RTWP faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 14.6 Troubleshooting ALD Link Faults This section provides information required to troubleshoot ALD link faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Description in this section is applicable only to 3900 series base stations.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

165

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

14.1 Definitions of RF Unit Faults If a radio frequency (RF) unit is faulty, its sensitivity decreases, leading to deterioration of the cell demodulation performance and reduction of the uplink coverage, or even service interruption in the cell. Generally, RF unit faults are indicated by alarms. Therefore, this chapter describes how to troubleshoot RF unit faults based on reported alarms.

14.2 Background Information This section defines the concepts related to RF unit fault troubleshooting. The concepts are voltage standing wave ratio (VSWR) tests, passive intermodulation (PIM) interference, external interference, 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 as forward power and backward power by using directional couplers, and then they are measured by using standing-wave detectors. The difference between the measured forward power and backward power is the return loss, which can be converted to a VSWR value by using related formulas. 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 antenna system. If a large VSWR value is obtained, the antenna system is improperly connected to the RF unit. The output power of the RF unit is not transmitted through the antenna but reflected back. A high reflected power damages the RF unit, and the total reflection may break down the unit. To avoid the preceding faults, the VSWR alarm post-processing switch must be turned on for 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 provide output power. In this scenario, the cell served by the RRU degrades the capacity or becomes unavailable. The cell coverage and performance also deteriorate. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

166

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

NOTE

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

PIM Interference PIM interference is induced by non-linearity of the passive components in the TX system. The antenna non-linearity is indicated by the intermodulation (IM) suppression degree. For a linear system, if the input is two signals, the output is also two signals without any additional frequency component. For a non-linear system, if the input is two signals, new frequency components are generated 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 generating frequency 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 wideband power (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 and the operating frequency are mixed to from a group of new frequencies, and accordingly a group of 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 (2 x f1 - f2) and (2 x f2 - f1), and two IM5 components operating on the frequencies of (3 x f1 - 2 x f2) and (3 x f2 - 2 x f1). As shown in the following figure, the input signals and IM components are 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 right of the wanted signals. Their intervals depend on the IM orders and the maximum frequency spacing (or bandwidth) of the input signals. A higher IM order leads to a lower amplitude for the IM components and a further distance from the wanted signals, and therefore a smaller impact. The following figure shows an example of a PIM result.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

167

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

Figure 14-2 Example of a PIM result

All passive components encounter intermodulation distortion that may be caused by unreliable mechanical contacts, poor soldering, or oxidization. Passive components such as combiners, duplexers, and filters require specific IM suppression degrees. If the IM suppression degree of an IM order meets the requirements, the IM products have no impact on the system performance. Generally, cables do not have requirements for PIM suppression degrees. A cable requiring high PIM suppression degrees can reduce PIM interference, but it is too expensive to be used widely. Note that an improper connection is not definitely coupled with the PIM interference. If an RF unit is properly connected to the antenna system, high-power IM components may also be generated due to insufficient PIM suppression degrees of the cables. If the IM components work on frequencies within the RX frequency band, this increases the noise floor of the RX channels and decreases the sensitivity of the RF unit. For a frequency division duplex (FDD) system, frequency bands such as 800 MHz and 700 MHz have small duplex spacing (spacing between the DL frequency and the UL frequency). Meanwhile, the IM3 and IM5 products of the TX signals work on frequencies within the RX frequency band. In this scenario, 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 transmitted through 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 suppression degree 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.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

168

eRAN11.1 eRAN Troubleshooting Guide

l

14 Troubleshooting RF Unit Faults

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 the RTWP 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 the duplex 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 generate frequency components, and this leads to spectrum expansion. These frequency components are also IM products. Moreover, in a scenario with improper connections, even continuous wave (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 classified into linear polarized waves and circular polarized waves. Antennas with different polarization can obtain various gains from linear polarized waves. eNodeBs use orthogonal 45° dual-polarized antennas. Therefore, linear polarized waves received by these antennas have main and diversity gain differences. Interference signals can also be classified based on the polarization: l

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

l

Circular polarized interference signals Circular polarized interference signals are propagated without directions. Therefore, when they arrive the dual-polarized antennas of the eNodeB, two antenna ports of each sector can 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 air are propagated without multiple reflections. When the eNodeB receives such interference signals, the orthogonal dual-polarized antennas can obtain various gains based on the angle between the interference signals and the antenna polarization. If the interference signals exist for 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. No: There is no PIM interference.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

169

eRAN11.1 eRAN Troubleshooting Guide

2.

14 Troubleshooting RF Unit Faults

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 a matched load or direct open-circuit to check whether the RTWP falls within the normal range. 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 carry any useful information, however, it seldom exists.

l

External interference is received only by antennas, which simplifies the troubleshooting procedure.

Remote Electrical Tilt Antenna A remote electrical tilt (RET) antenna can be remotely controlled because it is equipped with a drive 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 is usually a digitally controlled step motor. The control circuit communicates with the controller and controls the driving motor. The drive structure contains a gear that meshes with a pulling bar. Under the control of the driving motor, the gear moves to transmit motion to the pulling bar, and accordingly the tilt angle of the antenna can be adjusted. The following figure shows the structure and working principles of an RET antenna equipped with an RCU.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

170

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

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

14.3 Troubleshooting Method This section describes how to identify and troubleshoot the possible cause.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

171

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

Troubleshooting Flowchart Figure 14-4 Troubleshooting flowchart for RF unit faults

Troubleshooting Procedure 1.

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 the eNodeB. If yes, troubleshoot the RTWP faults. If no, go to 3.

3.

(Applicable to 3900 series base stations only) Check whether there is any alarm related to ALD link faults in the active alarms on the eNodeB or there are any abnormal ALD links. If yes, troubleshoot the ALD link faults. If no, go to 4

4.

If the fault persists, contact Huawei technical support.

14.4 Troubleshooting VSWR Faults This section provides information required to troubleshoot VSWR faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description An alarm ALM-26529 RF Unit VSWR Threshold Crossed is reported if there are VSWR faults in the radio frequency (RF) channels of an RF unit. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

172

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

Related Information None

Possible Causes l

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 antenna port 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 the components of the antenna system.

l

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

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

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 back because no feeder is connected to the related antenna port or the related feeder is bent or damaged.

2.

Check the VSWR alarm threshold of the RF unit. For 3900 series base stations, 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 threshold is improper, change it by running the MOD RRU command. For the BTS3202E/BTS3911E, run the LST BRU 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 threshold is improper, change it by running the MOD BRU command.

3.

Check the current VSWR value. a. b.

Run the DSP VSWR command to query the current VSWR value. 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. NOTE

It is recommended that multiple frequencies within the operating frequency range supported by the cell be used as the test frequencies.

4.

Compare the VSWR values queried by running the STR VSWRTEST and DSP VSWR commands. 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 values differ greatly, run the STR VSWRTEST command with the Test Mode parameter set to MULTI_ARFCN and compare the VSWR values.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

173

eRAN11.1 eRAN Troubleshooting Guide

5.

14 Troubleshooting RF Unit Faults

–

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. In this case, check the feeder connection at the local end. Then, go to step 4.

–

For 3900 series base stations, if some of the values are large, a hardware fault may occur in the RF unit. Save the test results and submit the results together with oneclick log files of the main control board and RF unit to Huawei technical support for further analysis.

–

For the BTS3202E/BTS3911E, if some of the values are large, a hardware fault may occur in the BTS3202E/BTS3911E. Save the test results and submit the results together with one-click log files to Huawei technical support for further analysis.

Check the feeder connection at the local end. Check whether the frequency band supported by the RF unit is consistent with that supported by the components of the antenna system according to the network plan. The antenna system consists of antennas, feeders, jumpers, combiner-dividers, filters, and tower-mounted amplifiers (TMAs). It is recommended that a Sitemaster be used to measure the distance between the point with a 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 to different parts of the feeder at the local end. Then, run the STR VSWRTEST to start a VSWR test on each isolation part of the feeder to locate the fault.

6.

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

Typical Cases None

14.5 Troubleshooting RTWP Faults This section provides information required to troubleshoot RTWP faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

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

Related Information Related alarms are as follows: l

ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced

l

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

Possible Causes l

The setting of attenuation on the RX channel of the RF unit is incorrect.

l

The feeder connected to the RF unit is faulty.

l

Passive intermodulation (PIM) exists.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

174

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

l

External interference exists.

l

The feeder is improperly connected to the antenna.

l

The hardware in an RF module is faulty.

l

Faults may be caused by other uncertain factors.

Troubleshooting Flowchart Figure 14-5 Troubleshooting flowchart for RTWP faults

Troubleshooting Procedure 1.

Rectify the faults and modify the improper settings. a.

Run the LST ALMAF command to check whether alarms related to ALD or TDM are reported (applicable only to 3900 series base stations). If such an alarm is reported, clear the alarm by referring to Troubleshooting ALD Link Faults.

b.

Run the LST RXBRANCH command to check whether attenuation of the RX channel of the RRU is configured as planned. If it is not configured as planned, run the MOD RXBRANCH command to modify the configuration. If it is configured as planned, go to 1.c.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

175

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

Command output for 3900 series base stations (The values of Cabinet No., Subrack No., and Slot No. are 0 for the BTS3202E/BTS3911E.) List RxBranch Configure Information ----------------------------------Cabinet No. = 0 Subrack No. = 62 Slot No. = 0 RX Channel No. = 0 Logical Switch of RX Channel = ON Attenuation(0.5dB) = 0 RTWP Initial0(0.1dB) = 0 RTWP Initial1(0.1dB) = 0 RTWP Initial2(0.1dB) = 0 RTWP Initial3(0.1dB) = 0 RTWP Initial4(0.1dB) = 0 RTWP Initial5(0.1dB) = 0 RTWP Initial6(0.1dB) = 0 RTWP Initial7(0.1dB) = 0 (Number of results = 1)

c.

Check whether the ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced or 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 Unit RX Channel RTWP/RSSI Unbalanced or ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low. If the ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm cannot be cleared by referring to ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced, perform 2 to 6.

2.

Check whether PIM interference exists. PIM has a typical characteristic: The level of the intermodulation products increases with the transmit power. Using this typical characteristic, the existence of PIM interference can be determined. If the uplink interference increases significantly with the transmit power, PIM interference exists. Otherwise, PIM interference does not exist. You can check the existence of PIM interference using the following two methods: Method 1: Run the STR RFTEST command and determine whether PIM interference exists based on the PIM test results. For details about the command, see eNodeB MML Command Reference. Method 2: Increase the transmit power by adding a downlink simulated load, and then compare the received signal strength 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 of the SimLoadCfgIndex parameter. NOTE

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

b.

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

176

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

Figure 14-6 RSSI tracing result

If PIM interference exists according to the preceding investigation, use either of the following methods to determine the location or device where PIM is introduced: –

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, PIM interference is introduced by this segment.

–

Breakpoint-based PIM detection: By using breakpoints, divide the cable connecting the RF unit top to the antenna port into several segments by using breakpoints. Disconnect the cable at the breakpoints one by one along the direction from the RF unit top to the antenna port. Each time the cable is disconnected at a breakpoint, connect the breakpoint to a matched load or a low-intermodulation attenuator, add a downlink simulated load, and check whether the RTWP values increase. Ensure the inserted attenuator has low intermodulation interference so that it will not add additional PIM interference to the cable. If the RTWP values increase, PIM interference is introduced by the device or cable before this breakpoint. For example, set four breakpoints from the RF unit top to the antenna port, as shown in Figure 14-7. At first, disconnect the cable at breakpoint 1, connect breakpoint 1 to a low-intermodulation attenuator, and add a downlink simulation load. If RTWP values do 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 other breakpoints.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

177

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

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

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

Monitor the results in Broadband on-line frequency scan for at least 30 minutes or until the 26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm is reported. Then, send the local tracing results, running logs of RF units, and investigation results to Huawei technical support for fault diagnosis. For the procedure for performing Broadband on-line frequency scan, see Monitoring eNodeB Performance in Real Time > Spectrum Detection in 3900 Series Base Station LMT User Guide.

4.

Check whether a crossed pair connection exists (applicable only to 3900 series base stations). Description RF channels in an RF unit must be used by the same sector except in MIMO mutual-aid scenarios. The purpose is to ensure the consistency between the direction and coverage of an antenna so that balanced RTWP values are obtained. If the RF channels of an RF unit are used by different sectors, the RF unit will have different RTWP values. Note that the ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm is reported only when the number of UEs is significantly different between two cells with a crossed pair connection. The ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm caused by a crossed pair connection has the following characteristics:

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

178

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

–

The alarm is reported in at least two sectors under the same eNodeB.

–

RTWP variations of different RF channels are uncorrelated.

–

RTWP variations are similar in different sectors.

Troubleshooting Method The cells with a crossed pair connection can be determined by using either of the following two methods: –

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 cell 1, where the UE is located. If the UE accesses another cell (for example, cell 3), the antennas of cells 1 and 3 are cross-connected.

–

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

Note 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 command is executed on a multi-mode RF unit or an RF unit connected to an antenna shared by the local and 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 is executed 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 a gain 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 result may be incorrect. l This command does not apply to multi-RRU cells, distributed cells, or cells under the eNodeB with an omnidirectional antenna. l This command does not apply to the scenario where all antennas of one sector are connected to another sector. l Do not start this test if the number of sectors that work in the same frequency band and support the test is less than two. l If the bandwidth between the start frequency and end frequency of the external filter is less than 10 MHz, the execution output is not reliable.

The Crossed value of RESULT appears in pairs. If RESULT is Crossed for two sectors, a cross pair connection exists between the two sectors. Detailed information about 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:58 O&M #453 %%STR CROSFEEDTST:;%% RETCODE = 0 Operation succeeded. Session ID = 65537 (Number of results = 1) --END +++ HUAWEI 2012-02-02 10:55:15 O&M #452 %%STR CROSFEEDTST:;%% RETCODE = 0 Progress report, Operation succeeded. Report Type = Cross Feeder Test Progress Status = Success Session

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

179

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults ID = 65537 Cross Feeder Test Result ------------------------ Sector No. RESULT 0 Normal 1 Normal (Number of results = 2) --END

Handling Suggestion After the sectors with a crossed pair connection are determined, adjust their antenna connection. Since there are three types of crossed pair connections (main-main, maindiversity, and diversity-diversity), several rounds of antenna adjustment may be required before 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 random electromagnetic interference. Occasional electromagnetic interference has a small impact on the network performance. Therefore, ignore it if the RTWP imbalance alarm is not frequently triggered. If the RTWP imbalance alarm is frequently triggered, contact Huawei technical support.

6.

If the fault persists, contact Huawei technical support.

Typical Cases None

14.6 Troubleshooting ALD Link Faults This section provides information required to troubleshoot ALD link faults. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. Description in this section is applicable only to 3900 series base stations.

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

Related Information Related alarms are as follows: l

ALM-26530 RF Unit ALD Current Out of Range

l

ALM-26541 ALD Maintenance Link Failure

l

ALM-26751 RET Antenna Motor Fault

l

ALM-26754 RET Antenna Data Loss

l

ALM-26757 RET Antenna Running Data and Configuration Mismatch

l

ALM-26752 ALD Hardware Fault

l

ALM-26753 RET Antenna Not Calibrated

l

ALM-26531 RF Unit ALD Switch Configuration Mismatch

Possible Causes Possible causes for ALD-related alarms are listed as follows: l

The setting of the ALD power supply switch is improper.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

180

eRAN11.1 eRAN Troubleshooting Guide

14 Troubleshooting RF Unit Faults

l

The settings of the ALD current alarm thresholds are incorrect.

l

The ALD connections are abnormal.

l

The ALDs are faulty.

Troubleshooting Flowchart None

Troubleshooting Procedure 1.

Check for related alarms and configuration issues. If ALM-26541 ALD Maintenance Link Failure, ALM-26751 RET Antenna Motor Fault, or ALM-26753 RET Antenna Not Calibrated is generated, you can use the IUANT trace function on the web LMT of the eNodeB to collect the interaction information between antenna line devices (ALDs) and RF modules for root cause locating and classification.

2.

If the fault persists, contact Huawei technical support.

Typical Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

181

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

15

Troubleshooting License Faults

About This Chapter This chapter describes how to diagnose and handle license faults. 15.1 Definitions of License Faults License faults are license-related alarms and faults that occur during eNodeB license installation. 15.2 Background Information A license is an authorization agreement between the supplier and the operator on the use of products. It defines the product features, versions, capacity, validity period, and application scope. 15.3 Troubleshooting Method To 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 Installation This section provides information required to troubleshoot license faults that occur during license installation. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 15.5 Troubleshooting License Faults That Occur During Network Running This section provides information required to troubleshoot license faults that occur during network running. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases. 15.6 Troubleshoot License Faults That Occur During Network Adjustment This section provides information required to troubleshoot license faults that occur during network adjustment. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

182

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

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

Problems 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 Information A license is an authorization agreement between the supplier and the operator on the use of products. It defines the product features, versions, capacity, validity period, and application scope. Operators can purchase the license to determine the network functions and capacity at a specific stage, maximizing the return on investment. For details, see eRAN License Management Feature Parameter Description.

15.3 Troubleshooting Method To 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 Causes The possible causes of license faults are as follows: l

Incorrect operations

l

Misunderstanding over the license mechanism

l

Errors in license files

l

Product defects

Troubleshooting Flowchart The following figure shows the troubleshooting flowchart for license faults that occur in different scenarios.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

183

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

Figure 15-1 Troubleshooting flowchart for license faults

Troubleshooting Procedure 1.

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 the procedure for troubleshooting license faults that occur during network running. If not, go to 3.

3.

Determine whether license faults occur during network adjustment. If so, perform the procedure 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 During License Installation This section provides information required to troubleshoot license faults that occur during license installation. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description If license installation fails, the following error messages will be displayed in the MML command output: Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

184

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

l

License check failed; license serial number became invalid; the license file does not match the 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 are successful.

l

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

l

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

l

Difference check: Differences between new and old license files, including whether any function items in the new license files are lost, whether any resource items are reduced or lost, 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 the installation, the feature defined in the license file can run in trial mode for 60 days. After 60 days, the feature enters the default mode. The license file with the same errors cannot be installed repeatedly. NOTE

l If the ESNs or VR versions do not match, the system runs based on the function items and resource configuration defined in the license file. If the system does not read correct function items or resource items 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 and protection 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 file with the same error as the existing license file cannot be installed. If a correct license file exists, a license 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, the license file can be installed and a message prompting that the license for some features exceeds the validity date is displayed. l During license installation, if the function items, resource items, and validity period in the license file are different from those in the previous license file, the installation result indicates the differences and the 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 configured value (for example, the number of cells), the license file fails to be installed.

Possible Causes l

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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

185

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

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 Diagnosis If 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 License Management Feature Parameter Description.

Troubleshooting Procedure 1.

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.

Typical Cases Fault Description After eNodeBs at a site were upgraded from eRAN2.0 to eRAN2.1, the eNodeBs experienced failures 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 U2000 displayed the following message: The configured value of the control item is greater than the value in the license file

This message shows that the configured values on the current eNodeB exceeded the limits of the license file. Compare the license control items in the license file with the configuration that has taken effect on the eNodeB to find the configuration items that have been activated on the eNodeB 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 LICINFO command to query the configured values on the eNodeB, and compare the configured values with the allocated values in the license file. The command output is as follows: Figure 15-2 Querying license information

As shown in the figure, Allocated, Config, and Actual Used are the allocated value in the license file, the configured value on the eNodeB, and the actual value. 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

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

186

eRAN11.1 eRAN Troubleshooting Guide

2.

15 Troubleshooting License Faults

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 eNodeB but 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 allocated values are equal to or greater than the configured values on the eNodeB. Then, reinstall the license.

4.

If the fault persists, contact Huawei technical support.

15.5 Troubleshooting License Faults That Occur During Network Running This section provides information required to troubleshoot license faults that occur during network running. The information includes fault descriptions, background information, possible causes, fault handling method and procedure, and typical cases.

Fault Description Related alarms and events are generated.

Related Information l

l

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 Limit

Related events –

EVT-26820 License Emergency Status Activated

–

EVT-26821 License Emergency Status Ceased

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

187

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

Possible Causes Table 15-1 Alarm

Possible Causes

Licensed Feature Entering Keep-Alive Period

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

Licensed Feature Unusable

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

License on Trial

This alarm is generated when a license file enters the keep-alive period. The possible causes are as follows: l The license file exceeds the validity date. l The license file is revoked. l The ESN in the license file is inconsistent with the actual ESN of the eNodeB. l The eNodeB version in the license file is inconsistent with the running version of the eNodeB. l The ESN and eNodeB version in the license file are inconsistent with the actual ESN and the running version of the eNodeB.

No License Running in System

This alarm is generated when there is no valid license file on the system. The possible causes are as follows: l The license file exceeds the keep-alive period of 60 days. l The license file is not found or errors occur during the license check when the system is started.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

188

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

Alarm

Possible Causes

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 during the system running, the original data configuration is used. If this alarm is generated during the system startup, the licensed specifications of the feature are used.

License Emergency Status Activated

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

License Emergency Status Ceased

This event is generated when the license emergency status is ceased automatically seven days after the eNodeB enters the emergency status.

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

Troubleshooting Procedure 1.

Clear the alarms according to the alarm handling suggestions.

2.

If the fault persists, contact Huawei technical support.

Typical Cases None

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

Fault Description After a command was run to enable a function, a configuration activation failure occurred due to license restriction. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

189

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

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

Related Information l

License control item classification License control items are classified into resource items and function items. The DSP LICINFO 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 site requirements. Typical resource items include the cell bandwidth, number of accessed users, and number of cells.

–

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

License control items can be further classified into the following five categories based on the 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 items dynamically occupy session resources. When a session starts, the occupied resources are counted and are subtracted from the total number of resources. When the session stops, the occupied resources are released.

–

Performance items (resource items): These items are passive control items without requiring manual configuration. The configured value is NULL. When the eNodeB starts up, the eNodeB learns about the allocated values of these items by queries. During eNodeB operation, the quantity of occupied resources is ensured to be less than the allocated values.

–

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

–

Boolean counting items (resource items): These items are active control items and require manual configuration. The corresponding resources are Boolean resources at the NE's submodule level. When the eNodeB starts up, the eNodeB decides whether to apply for the corresponding resources based on the configured values (0 or 1). When a submodule stops providing services, its resources are released.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

190

eRAN11.1 eRAN Troubleshooting Guide

–

l

15 Troubleshooting License Faults

Boolean items (function items): These items are passive control items without requiring manual configuration. The configured value is NULL, and the corresponding resources are NE-level Boolean resources. When the eNodeB starts up, the eNodeB checks the values of these items to see whether the corresponding functions are enabled.

Examples of license control items –

Power: RF Output Power (per 20W) (FDD) The power license controls the total required power of radio frequency (RF) modules in an eNodeB. Each RF module provides 20 W power by default. Extra power must be purchased in units of 20 W. If the eNodeB operates in default license mode, the licensed power is 0 W by default.

–

Bandwidth: Carrier Bandwidth (per 5MHz) (FDD) The bandwidth license controls the total required bandwidth of an eNodeB. In the Long Term 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 5 MHz.

–

CSFB control item The control items for UTRAN, GERAN, and CDMA control the CSFB function for these three radio access technologies (RATs). LT1S00CFBU00: CSFB (FDD) to UTRAN LT1S00CFBG00: CSFB (FDD) to GERAN LT1S00CFBR00: CSFB (FDD) to CDMA2000 1xRTT

–

eNodeB throughput: Throughput Capacity This control item specifies the total licensed throughput of the eNodeB, which includes the uplink and downlink throughput. Users can run the MOD LICRATIO command to specify the proportion of licensed uplink throughput to the total licensed throughput.

Possible Causes l

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.

Troubleshooting Flowchart When this type of fault occurs, the message "Failed to activate the configuration because of license control" is displayed on the maintenance console. The following figure shows the troubleshooting flowchart.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

191

eRAN11.1 eRAN Troubleshooting Guide

15 Troubleshooting License Faults

Figure 15-4 Troubleshooting flowchart

Troubleshooting Procedure 1.

Check whether any license-related alarms are generated on the eNodeB.

2.

If license-related alarms are generated, clear the alarms by referring to Alarm Reference.

3.

If there are no license-related alarms, run the DSP LICINFO 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 Cases None

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

192

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

16

Wireless Fault Management

About This Chapter Generally, when a radio performance fault or network-level performance fault occurs, OM engineers cannot quickly delimit the fault range and recover the service by resetting, powering off, or replacing corresponding boards. To address this issue, the FMA provides a radio performance fault analysis function, helping OM engineers quickly find the method of recovering services. Using this function, the troubleshooting efficiency is improved. 16.1 Overview of Wireless Fault Management Radio performance fault analysis consists of five sub-functions: Fault Overview, Fault Delimitation, Confirm Recovery, Collect Information, and Parameter Settings. 16.2 Starting Wireless Fault Management This section describes how to start the a wireless fault management. 16.3 Appendix This section lists KPIs that wireless fault management supports and their calculation formulas.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

193

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

16.1 Overview of Wireless Fault Management Radio performance fault analysis consists of five sub-functions: Fault Overview, Fault Delimitation, Confirm Recovery, Collect Information, and Parameter Settings. l

Fault Overview: This function provides KPI status information related to one or multiple NEs. It helps OM engineers completely learn and decide the current fault status.

l

Fault Delimitation: This function provides a detailed analysis on an abnormal KPI that is found by the Fault Overview function or decided by OM engineers to find out the cause and help OM engineers formulate the service recovery scheme.

l

Confirm Recovery: This function helps OM engineers monitor the effect and decide whether a service is recovered after a service recovery scheme is implemented. NOTE

To perform Confirm Recovery, use the performance monitoring function of the U2000 client or use the PRS to monitor performance counters.

l

Collect Information: This function collects information about a fault when the cause of the fault cannot be decided and the fault cannot be rectified using the preceding functions. Then, the fault information can be provided to Huawei technical support for analysis and troubleshooting.

l

Parameter Settings: This function sets values for the parameters required by fault analysis, such as the threshold of each KPI.

16.2 Starting Wireless Fault Management This section describes how to start the a wireless fault management.

16.2.1 (Optional) Setting Parameters for Performance Fault Analysis The Parameter Settings window displays the parameters required by fault analysis, such as the threshold of each KPI. This section describes the procedure for setting parameters for performance fault analysis.

Context The following table describes the Parameter Settings window. Table 16-1 Window description Function

Description

Selecting the base station version

Select from the drop-down list a version whose parameter settings need to be changed.

Parameter table

Provides the parameters of the selected version. The default and current values of each parameter are displayed. The default value cannot be changed, but the current value can.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

194

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Function

Description

Saving parameter settings

Saves the current parameters value.

Restoring parameter values

Restores parameters to their default values.

NOTE

The parameter default value configuration file of each base station version is released with the U2000 mediation of the version. If the U2000 is reinstalled with the mediation of a certain base station version, the parameter setting function needs to be used to save the parameter settings of the version again, so that the parameter settings are consistent.

Procedure Step 1 After logging in to the FMA system, choose Wireless > Parameter Settings. Step 2 Select the target version for performance fault analysis from the Parameter Settings dropdown list box. Then, change the parameter values in the Current Threshold column to appropriate ones. Step 3 Click Save in the lower left corner of the page. ----End

16.2.2 Starting Fault Overview The fault overview window provides KPI status information related to one or multiple NEs. It helps users completely learn and decide the current fault status.

Context The following table describes the Fault Overview window. Table 16-2 Window description Function

Description

View Historical Data

The fault overview function automatically saves analysis results of the latest 10 tasks. You can click View Historical Data to view historical analysis reports.

Export

Exports the result data.

Detailed Analysis

Starts a fault overview analysis.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

195

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Function

Description

Topology Tree

Selects a subnet and groups within the subnet to be analyzed. NOTE The Topology tree is divided into two parts: l In the 1.Select Subnet area, select a subnet. NEs are grouped based on NE versions in the Default group of the 2.Subzones of LTE Subnet area. NEs earlier than V100R010C10 are not displayed in the Default group. l The User-Defined group is in the 2.Subzones of LTE Subnet area. The group is provided when you group NEs using Subzone Settings based on site requirements. l If NEs in the User-Defined group are marked with Version Changed and Version Deleted, you need to re-group NEs to be analyzed using Subzone Settings.

Subzone Settings

Sets the grouping information about NEs.

Import/ Export

Import: Imports the NE list, which is in .csv format and exported from the NE topology view of the U2000 client, into a self-defined NE group. Export: Selects an NE list you want to export and click Export to save it on the local PC in .csv format. NOTE l If the Internet Explorer (IE) cannot export the result data, choose Tool > Manage Add-ons on the menu bar of IE. In the Manage Add-ons dialog box, select Toolbars and Extensions in the Add-on Types area. In the right pane, right-click ChromeFrame BHO and choose Disable from the shortcut menu. Then, restart the IE. l If you click a displayed Download Analysis dialog box on Internet Explorer during report export but the result is invisible, you need to configure the following settings on Internet Explorer. On the menu bar, choose Tools. In the displayed Internet Options dialog box, click the Security tab. l If the current website is not added to trusted sites, click Local intranet and set the security level to Medium-low. l If the current website has been added to trusted sites, click Trusted sites and set the security level to Medium-low.

KPI Failure Cause Statistics

Issue Draft A (2016-03-07)

Displays the statistics of all KPI failure causes in the current NE group within the performance measurement period started by T0.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

196

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Function

Description

Site List

Displays the percent of KPI failures or deteriorations of each eNodeB in the current eNodeB group within the performance measurement period started by T0 and sorts the eNodeBs in descending order by the percent of failures. NOTE l Failure contribution rate of non-traffic-volume-related counters = number of cell failures in a site having abnormal counter values / number of cell failures in all sites x 100% Where, the number of cell failures in a site having abnormal counter values = number of attempts – number of successes l Failure contribution rate of traffic-volume-related counters = (difference in the counter value between the time in the previous period and the current time in each site) / difference in the counter value between the time in the previous period and the current time in all sites x 100% l The failure contribution rate may become negative when the throughput of the rate set is being measured. This indicates that the site rate increases as compared with the previous period.

KPI Change Trend Chart

Displays the KPI trends from the past 24 hours to the current time, from the past 48 hours to the past 24 hours, and in the same period on the same day of the last week. NOTE The start time of the first week from when the KPI changes from stable to dramatic is marked T0.

Current KPIs

Displays KPIs of subzone under a subnet.

Procedure Step 1 After you log in to the FMA system, choose FMA > Fault Overview to open the Fault Overview window. Step 2 In the Topology node in the left navigation tree, select one or multiple subnets you want to analyze. Then, the grouping information of the NEs included in the subnets is displayed in the lower part of the navigation tree, as shown in the following figure.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

197

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Figure 16-1 Selecting Subnet

NOTE

The FMA automatically groups NEs in a subnet by TAC by default, but you can group NEs yourself.

Step 3 Optional: You can add desired eNodeBs to a subzone by using the Subzone Settings function, as shown in the following figure. 1.

Click Subzone Settings at the lower part of the topology tree.

2.

In the displayed dialog box, select eNodeBs, add them to a subzone, set the subzone name, and then save the subzone information, as shown in the following figure.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

198

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Figure 16-2 Subzone Settings

Step 4 Select one NE group you want to analyze and click Analyse. After the operation is completed, the analysis result will be displayed on the Fault Overview window. Step 5 Click a desired KPI in the table for further analysis. Then, the trend analysis, its deterioration time points, failure cause distribution, and the KPI failure contribution rate of each eNodeB in the eNodeB list can be obtained, as shown in the following figure. Figure 16-3 Selecting KPI to Be Analyzed

Step 6 Optional: When need look historical analysis report, perform this step. Click View Historical Data in the Fault Overview page and choose a historical analysis report in the displayed dialog box, historical analysis reports are arranged based on the time when the analysis was conducted. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

199

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Step 7 Select the sites you want to perform a detailed analysis from the Site List, as shown in the following figure. Figure 16-4 Selecting NEs to Be Analyzed

Step 8 Optional: Specify the analysis period, and the default value is the latest 24 hours, as shown in the following figure. NOTE

You can set Analysis Period on the Fault Overview page only to the time within today.

Figure 16-5 Specify the analysis period

NOTE

The analysis period has an impact on the following: l Start time and end time of all traffic-statistics-related charts for Fault Delimitation. l Range of extracting historical alarms. l Range of extracting operation logs.

Step 9 Click Next. Then, the Fault Delimitation function is started and the selected sites are analyzed one by one. ----End

16.2.3 Starting Fault Delimitation This section describes how to perform a detailed analysis on an abnormal KPI by using the Fault Delimitation function.

Context The Fault Delimitation window has a Site tab page and a Cell tab page. Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

200

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

The Site tab page consists of basic information of sites, the transmission diagnosis information, a list of active alarms, and site-level fault diagnosis reports, the following table describes the Site tab page. Table 16-3 Site tab page description Function

Description

Basic Site Information Table

l Site Name: indicates the name of a site. l Contribution Rate: indicates the percent of failures in a site to the total failures, which is analyzed by the Fault Delimitation function at the time. l Version Change Info: lists the latest software version changes of a site. l Risky Operation: displays the risky operation records in the specified period.

Transmission Diagnosis Info

The following eNodeB transmission diagnosis information is displayed: l Transmission port information, that is, the command output of the DSP ETHPORT MML command. l ARP information learned by the transmission ports, that is, the command output of the DSP ARP MML command. l Configured route information, that is, the command output of the DSP IPRT MML command. l S1 interface transmission quality information, that is, results of the ping command over the S1 interface

Active Alarms

Displays the current active alarms of the to-be-analyzed site.

Site-level Fault Diagnosis Reports

Displays the preliminary fault analysis result on each cell of the current site.

The Cell tab page consists of the basic information of cells, the cell dashboard, the board diagnosis information, cell-level key counter analysis information, and cell-level fault diagnosis reports, the following table describes the Cell tab page.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

201

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Table 16-4 Cell tab page description Function

Description

Basic Cell Information Table

l Cell ID: specifies the ID of a cell. l Contribution Rate: indicates the percent of failures in a cell to the total failures, which is analyzed by the Fault Delimitation function at the time. l Actual value of a KPI: indicates the cell-level KPI value at the time when the KPI is analyzed. l Denominator (number of attempts) of a KPI]: If a non-trafficvolume-related KPI is analyzed, such as success rate or service drop rate, the value of the this field indicates the number of setup attempts related to this KPI. l Heavily Loaded: determines whether a cell is highly loaded based on the CPU usage of the eNodeB board serving the cell and the number of connected users in the cell. l TDD Interference: For TDD cells, the FMA determines whether the following types of interference are present based on uplinkinterference-related counter statistics: 1. TDD clock out-of-synchronization interference 2. Super-distance interference 3. Other interference For FDD cells, the FMA does not perform a TDD analysis and these FDD cells are displayed as "Non-TDD cells".

Cell Dashboard

Provides correlation analyses on the KPIs and alarms of a cell and the operation log. After you click a time point when a KPI changes, the alarms and operation log at the time will be queried. This helps users quickly find the possible fault cause.

Board Diagnosis Info

Displays the CPU usage trends of the main control board and baseband processing unit (BBP) serving a cell and the trend of the number of connected users in the cell. This helps users observe the relationship between the KPI changes in the cell and the CPU usage of the boards.

Cell KPI Analysis

Displays the change trends of some cell-level counters.

Fault Diagnosis Results of Cells

Displays the preliminary fault analysis result on the current cell.

Procedure l

If you cannot decide the NE having a fault, you are advised to perform a KPI analysis in the Fault Overview window and then perform the Fault Delimitation function for a certain KPI. a.

Starting Fault Overview.

b.

On the Site tab page, click Analyze in front of each site name in the table, as shown in the following figure.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

202

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

Figure 16-6 Detailed site analysis

c.

On the Cell tab page, click Analyze in front of a cell ID in the table, as shown in the following figure. Figure 16-7 Detailed cell analysis

NOTE

l Board Diagnosis Info, Cell KPI Analysis, and Fault Diagnosis Result of Cells of the cell will be displayed after you click Analyze. l Click a time in the Cell Dashboard KPI trend chart. Then, operation logs and alarm logs around this time will be highlighted in the operation and alarm log lists. Such information helps you to decide whether the operation records or alarm records have relationships with the KPI changes. See the following figure.

Figure 16-8 Cell Dashboard

l

If you can decide the top failure sites, you can directly perform the Fault Delimitation function. a.

Issue Draft A (2016-03-07)

After you log in to the FMA system, choose FMA > Fault Delimitation to open the Fault Delimitation window. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

203

eRAN11.1 eRAN Troubleshooting Guide

b.

16 Wireless Fault Management

In the NE Root node in the left navigation tree, select one or multiple subnets you want to analyze. Then, the grouping information of the NEs included in the subnets is displayed in the lower part of the navigation tree. NOTE

The FMA automatically groups NEs in a subnet by TAC by default, but you can group NEs yourself.

c.

Select one NE groups you want to analyze.

d.

In the KPI list on the right, select the KPIs you want to analyze.

e.

Set the start time and time range for analysis in Fault Occurrence Time and Analysis Period.

f.

Click Analyze. The analysis result will be displayed later.

----End

16.2.4 Starting Information Collection This section describes how to start information collection.

Context WebNIC is an information collection tool provided by U2000. For detailed operations and GUIs, see the iManager U2000 Online Help.

Procedure Step 1 After you log in to the FMA system, choose FMA > Collect Information to open the Collect Information window. Step 2 Click Collect Information. Then, the WebNIC window for information collection is displayed. ----End

16.3 Appendix This section lists KPIs that wireless fault management supports and their calculation formulas.

16.3.1 KPIs Supported by Wireless Fault Management and Their Calculation Formulas This section lists KPIs that wireless fault management supports and their calculation formulas. No.

Function

RRC Success Rate

L.RRC.ConnReq.Succ / L.RRC.ConnReq.Att * 100%

S1SIG Setup Success Rate

L.S1Sig.ConnEst.Succ / L.S1Sig.ConnEst.Att * 100%

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

204

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

No.

Function

E-RAB Setup Success Rate

L.E-RAB.SuccEst / L.E-RAB.AttEst * 100%

Call Drop Rate

L.E-RAB.AbnormRel / (L.E-RAB.NormRel + L.ERAB.AbnormRel) * 100%

UL User Throughput(Kbit/s) Delta

(L.Thrp.bits.UL - L.Thrp.bits.UE.UL.SmallPkt) / L.Thrp.Time.UE.UL.RmvSmallPkt

UL Cell Throughput(Kbit/s) Delta

L.Thrp.bits.UL / L.Thrp.Time.Cell.UL.HighPrecision

UL Cell Traffic Volume(bit) Delta

L.Thrp.bits.UL

DL User Throughput(Kbit/s) Delta

(L.Thrp.bits.DL - L.Thrp.bits.DL.LastTTI) / L.Thrp.Time.DL.RmvLastTTI

DL Cell Throughput(Kbit/s) Delta

L.Thrp.bits.DL / L.Thrp.Time.Cell.DL.HighPrecision

DL Cell Traffic Volume(bit) Delta

L.Thrp.bits.DL

CSFB Execution Success Rate

(L.CSFB.E2W + L.CSFB.E2G + L.CSFB.E2T) / L.CSFB.PrepSucc * 100%

CSFB Preparation Success Rate

L.CSFB.PrepSucc / L.CSFB.PrepAtt * 100%

Inter-Frequency HO Success Rate

(L.HHO.IntraeNB.InterFreq.ExecSuccOut + L.HHO.IntereNB.InterFreq.ExecSuccOut) / (L.HHO.IntraeNB.InterFreq.ExecAttOut + L.HHO.IntereNB.InterFreq.ExecAttOut) * 100%

Intra-Frequency HO Success Rate

(L.HHO.IntraeNB.IntraFreq.ExecSuccOut + L.HHO.IntereNB.IntraFreq.ExecSuccOut) / (L.HHO.IntraeNB.IntraFreq.ExecAttOut + L.HHO.IntereNB.IntraFreq.ExecAttOut) * 100%

Handover In Success Rate

(L.HHO.IntraeNB.ExecSuccIn + L.HHO.IntereNB.ExecSuccIn) / (L.HHO.IntraeNB.ExecAttIn + L.HHO.IntereNB.ExecAttIn) * 100%

X2 HO Out Success Rate

(L.HHO.X2.IntraFreq.ExecSuccOut + L.HHO.X2.InterFreq.ExecSuccOut) / (L.HHO.X2.IntraFreq.ExecAttOut + L.HHO.X2.InterFreq.ExecAttOut) * 100%

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

205

eRAN11.1 eRAN Troubleshooting Guide

16 Wireless Fault Management

No.

Function

S1 HO Out Success Rate

(L.HHO.IntereNB.IntraFreq.ExecSuccOut + L.HHO.IntereNB.InterFreq.ExecSuccOut L.HHO.X2.IntraFreq.ExecSuccOut L.HHO.X2.InterFreq.ExecSuccOut) / (L.HHO.IntereNB.IntraFreq.ExecAttOut + L.HHO.IntereNB.InterFreq.ExecAttOut L.HHO.X2.IntraFreq.ExecAttOut L.HHO.X2.InterFreq.ExecAttOut) * 100%

FDD TDD HO In Success Rate

(L.HHO.IntraeNB.InterFddTdd.ExecSuccOut + L.HHO.IntereNB.InterFddTdd.ExecSuccOut) / (L.HHO.IntraeNB.InterFddTdd.ExecAttOut + L.HHO.IntereNB.InterFddTdd.ExecAttOut) * 100%

FDD TDD HO Out Success Rate

(L.HHO.IntraeNB.InterFddTdd.ExecAttOut + L.HHO.IntereNB.InterFddTdd.ExecAttOut) / (L.HHO.IntraeNB.InterFddTdd.PrepAttOut + L.HHO.IntereNB.InterFddTdd.PrepAttOut) * 100%

FDD TDD HO In Pre Success Rate

(L.HHO.InterFddTdd.IntraeNB.ExecAttIn + L.HHO.InterFddTdd.IntereNB.ExecAttIn) / (L.HHO.InterFddTdd.IntraeNB.PrepAttIn + L.HHO.InterFddTdd.IntereNB.PrepAttIn) * 100%

FDD TDD HO Out Pre Success Rate

(L.HHO.InterFddTdd.IntraeNB.ExecAttIn + L.HHO.InterFddTdd.IntereNB.ExecAttIn) / (L.HHO.InterFddTdd.IntraeNB.PrepAttIn + L.HHO.InterFddTdd.IntereNB.PrepAttIn) * 100%

RACH Setup Success Rate

(L.RA.Dedicate.HO.Msg3Rcv + L.RA.GrpA.ContResolution + L.RA.GrpB.ContResolution) / (L.RA.Dedicate.HO.Att + L.RA.GrpA.Att+L.RA.GrpB.Att) * 100%

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

206

eRAN11.1 eRAN Troubleshooting Guide

17

17 Collecting the Information Required for Fault Location

Collecting the Information Required for Fault Location When faults cannot be rectified by referring to this document, collect fault information for Huawei technical support to quickly troubleshoot the faults. This section describes how to collect fault information. Common fault information and collection methods are as follows. Table 17-1 Common fault information and collection methods Infor matio n Type

Collectio n Item

Collection Method

Log file

eNodeB software version

Run the LST VER command to query the eNodeB software version.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

207

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Configurati on file

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the BKP CFGFILE:ENCRYPTMODE=UNENCRYPTED command to back up the current configuration file. 3. Run the ULD CFGFILE: MODE=IPV4,IP="XX.XX.XX.XX",USR="XXX",PWD=" ***" command to upload the configuration file. The uploaded file is saved in the directory set during FTP server configuration. NOTE l The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively. l The Encrypted Mode parameter (the parameter ID is ENCRYPTMODE) specifies the encryption mode of the configuration file. UNENCRYPTED indicates that the configuration file is no encrypted. PWD_ENCRYPTED indicates that the configuration file is encrypted using the password specified by the user.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

208

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the BKP CFGFILE:ENCRYPTMODE=UNENCRYPTED command to back up the current configuration file. 2. Run the ULD CFGFILE: MODE=IPV4,IP="XX.XX.XX.XX",USR="XXX",PWD=" ***" command to upload the configuration file in /export/ ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

3. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE l The FTP client must transmit files in binary format. l The Encrypted Mode parameter (the parameter ID is ENCRYPTMODE) specifies the encryption mode of the configuration file. UNENCRYPTED indicates that the configuration file is no encrypted. PWD_ENCRYPTED indicates that the configuration file is encrypted using the password specified by the user.

BRD log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ALL,SRCF=BRDLOG,CN=0,SRN=0,S N=X,DSTF="MPT-BRDLOG",MODE=IPV4,IP="XX.XX.XX.XX",USR="XXX",P WD="***" command to upload the BRD logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

209

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ALL,SRCF=BRDLOG,CN=0,SRN=0,S N=X,DSTF="MPT-BRDLOG",MODE=IPV4,IP="XX.XX.XX.XX",USR="XXX",P WD="***" command to upload the BRD logs in /export/ ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

CHR log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ENODEB,SRCF=CHRLOG,DSTF="C HRLOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the CHR logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

210

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ENODEB,SRCF=CHRLOG,DSTF="C HRLOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the CHR logs in /export/ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

DBG log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ENODEB,SRCF=BRDLOGENODEB,DSTF="DBGLOG",IP="XX.XX.XX.XX",USR= "XXX",PWD="***" command to upload the DBG logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

211

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ENODEB,SRCF=BRDLOGENODEB,DSTF="DBGLOG",IP="XX.XX.XX.XX",USR= "XXX",PWD="***" command to upload the DBG logs in / export/ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

SIG log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD LOG:FT=eNodeB,LT=SIGLOG,FN="XXX.SIG",MODE=I PV4,IP="XX.XX.XX.XXX",DSTF="SIGLOG",USR="XX X",PWD="***" command to upload the SIG logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

212

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD LOG:FT=eNodeB,LT=SIGLOG,FN="XXX.SIG",MODE=I PV4,IP="XX.XX.XX.XXX",DSTF="SIGLOG",USR="XX X",PWD="***" command to upload the SIG logs in /export/ ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

OPR log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ALL,SRCF=OPRLOG,DSTF="OPRL OG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the OPR logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ALL,SRCF=OPRLOG,DSTF="OPRL OG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the OPR logs in /export/ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

213

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Alarm log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ALL,SRCF=ALMLOG,DSTF="ALM LOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the alarm logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ALL,SRCF=ALMLOG,DSTF="ALM LOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the alarm logs in /export/ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

Fault log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=ALL,SRCF=CFLTLOG,DSTF="CFLT LOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the fault logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

214

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD FILE:FUNCTYPE=ALL,SRCF=CFLTLOG,DSTF="CFLT LOG",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the fault logs in /export/ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

Radio interferenc e detection log

Using the Web LMT 1. Ensure that the FTP server has been configured. For details about how to configure the FTP server, see section "Configuring the FTP Server" in 3900 Series Base Station LMT User Guide. 2. Run the ULD FILE:FUNCTYPE=eNodeB,SRCF=RNFILE,DSTF="RNFI LE",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the interference detection logs. The uploaded logs are saved in the directory set during FTP server configuration. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

215

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Run the ULD FILE:FUNCTYPE=eNodeB,SRCF=RNFILE,DSTF="RNFI LE",IP="XX.XX.XX.XX",USR="XXX",PWD="***" command to upload the interference detection logs in /export/ ossuser of the FTP server on the U2000. NOTE The values of the Server IP (the parameter ID is IP), FTP User Name (the parameter ID is USR), and FTP Password (the parameter ID is PWD) parameters are the IP address, user name, and password of the FTP server on the U2000, respectively.

2. Log in to the FTP server on the U2000 through the FTP client to obtain the configuration file. NOTE The FTP client must transmit files in binary format.

Statistics log

Method 1: If the statistics is included in the BRD logs, refer to the collection method for BRD log. Method 2: Choose Performance > Measurement Management from the main window of the U2000 and query statistics logs in the Measurement Management window. Method 3: Log in to the FTP server on the U2000 through the FPT client and obtain the statistics logs in /ftproot/pm. The statistics logs of different NEs are distinguished from each other by the NE names.

Trace file

U2000 log

U2000 logs include the current logs and archived historical logs. Current logs are saved in /export/home/omc/var/logs of the U2000 server. Historical logs are archived in /export/ home/omc/var/logs/tracebak of the U2000 server. Log in to the FTP server on the U2000 through the FTP client to obtain the required logs.

Signaling tracing on standard interfaces

Using the Web LMT 1. In the LMT main window, click the Trace tab. 2. In the navigation tree, choose Trace > LTE Services. Doubleclick S1 Interface Trace. The S1 Interface Trace dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the tracing task. 4. After the tracing task is completed, obtain the tracing files in the save path set in the preceding step.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

216

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

NOTE Standard interface signaling tracing includes the tracing on S1, X2, and Uu interfaces. Obtaining S1 interface tracing files is used as an example.

Using the U2000

IFTS tracing

Using the Web LMT

1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE > Application Layer > S1 Interface Trace. The S1 Interface Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

1. In the LMT main window, click the Trace tab. 2. In the navigation tree, choose Trace > LTE Services. Doubleclick IFTS Trace. The IFTS Trace dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the tracing task. 4. After the tracing task is completed, obtain the tracing files in the save path set in the preceding step. Using the U2000 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE > Information Collection > IFTS Trace. The IFTS Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

217

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Cell DT tracing

Cell DT tracing can be performed on the U2000 or WebNIC. l On the U2000, you can obtain the tracing file as follows: 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE > Information Collection > Cell DT Trace. The Cell DT Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory. l On the WebNIC, you can obtain the tracing file as follows: 1. On the Task List tab page in the WebNIC main window, select Based on Customize Collection Item from the Create Task drop-down list. 2. Select the Cell DT collection item. 3. After the collection task completes, click the task name and then click Download on the Result Information tab page in the main window to download the collection result.

LTE/EPC end-to-end user tracing

The LTE/EPC end-to-end user tracing can be performed only on the U2000 and you can obtain the tracing file as follows: 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE/EPC > LTE/EPC End To End User Trace. The LTE/EPC End To End User Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

218

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

LTE cell tracing

The LTE cell tracing can be performed only on the U2000 and you can obtain the tracing file as follows: 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, choose Trace Type > LTE > Cell Trace. Double click Cell Trace. The Cell Trace dialog box is displayed. 3. Set parameters and then click OK to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

SCTP tracing

Using the Web LMT 1. In the LMT main window, click the Trace tab. 2. In the navigation tree, choose Trace > Common Services. Double-click SCTP Trace. The SCTP Trace dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the tracing task. 4. After the tracing task is completed, obtain the tracing files in the save path set in the preceding step. Using the U2000 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > Base Station Device and Transport > Transport Trace > SCTP Trace. The SCTP Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

219

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

GTP-U tracing

The GTP-U tracing can be performed only on the U2000 and you can obtain the tracing file as follows: 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > Base Station Device and Transport > Transport Trace > GTPU Trace. The GTPU Trace dialog box is displayed. 3. Set parameters and then click Finish to start the tracing task. 4. After the tracing task is completed, click Export to export the tracing file to the specified directory.

Antenna feeder informatio n tracing

Using the Web LMT 1. In the LMT main window, click the Trace tab. 2. In the navigation tree, choose Trace > Common Services. Double-click IUANT Trace. The IUANT Trace dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the tracing task. 4. After the tracing task is completed, obtain the tracing files in the save path set in the preceding step.

Perfor mance monito ring

Spectrum detection

FFT spectrum detection data collection can be performed on the Web LMT or WebNIC. l For details about FFT spectrum detection data collection using the Web LMT, see section "Monitoring FFT Frequency Scan" in 3900 Series Base Station LMT User Guide. l On the WebNIC, you can obtain the FFT spectrum detection data as follows: 1. On the Task List tab page in the WebNIC main window, select Based on Customize Collection Item from the Create Task drop-down list. 2. Select the RAT and NE. In the Collection Item Selection area, select FFT Frequency Scanning and click Next. 3. Set parameters for the collection item and create the task according to the guide. 4. After the collection task completes, click the task name and then click Download on the Result Information tab page in the main window to download the collection result.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

220

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Interferenc e RSSI statistic detect monitoring

1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE > Cell Performance Monitoring > RSSI Statistic Monitoring. The RSSI Statistic Monitoring dialog box is displayed. 3. Set parameters and then click Finish to start the monitoring task. 4. After the monitoring task is completed, click Export to export the monitoring file to the specified directory.

Interferenc e detection monitoring

1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > LTE > Cell Performance Monitoring > Interference Detect Monitoring. The Interference Detect Monitoring dialog box is displayed. 3. Set parameters and then click Finish to start the monitoring task. 4. After the monitoring task is completed, click Export to export the monitoring file to the specified directory.

Output power monitoring

Using the Web LMT 1. In the LMT main window, click Monitor. 2. In the navigation tree, choose Monitor > Common Monitoring. Double-click RRU/RFU output power monitoring. The RRU/RFU output power monitoring dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the monitoring task. 4. After the monitoring task is completed, obtain the monitoring files in the save path set in the preceding step.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

221

eRAN11.1 eRAN Troubleshooting Guide

Infor matio n Type

17 Collecting the Information Required for Fault Location

Collectio n Item

Collection Method

Using the U2000 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > Base Station Device and Transport > Device Monitoring > RRU/RFU/BRU Output Power Monitoring. The RRU/RFU/BRU Output Power Monitoring dialog box is displayed. 3. Set parameters and then click Finish to start the monitoring task. 4. After the monitoring task is completed, click Export to export the monitoring file to the specified directory. CPU usage monitoring

Using the Web LMT 1. In the LMT main window, click Monitor. 2. In the navigation tree, choose Monitor > Common Monitoring. Double-click CPU/DSP Usage Monitoring. The CPU/DSP Usage Monitoring dialog box is displayed. 3. Set parameters and the file save path, and then click Submit to start the monitoring task. 4. After the monitoring task is completed, obtain the monitoring files in the save path set in the preceding step. Using the U2000 1. Choose Monitor > Signaling Trace > Signaling Trace Management from the main window of the U2000. The Signaling Trace Management tab page is displayed. 2. In the navigation tree, double-click Trace Type > Base Station Device and Transport > Device Monitoring > CPU Usage Monitoring. The CPU Usage Monitoring dialog box is displayed. 3. Set parameters and then click Finish to start the monitoring task. 4. After the monitoring task is completed, click Export to export the monitoring file to the specified directory.

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

222

eRAN11.1 eRAN Troubleshooting Guide

Index

Index

Issue Draft A (2016-03-07)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

223