RAN Troubleshooting Guide(RAN10.0_01)

RAN

10.0

Troubleshooting Guide

Issue 01

Date 2008-05-30

Part Number

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For anyassistance, please contact our local office or company headquarters.

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

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

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

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but the statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

http://www.huawei.com

mailto:[email protected]

Contents

About This Document.....................................................................................................................1

1 Introduction to RAN Troubleshooting..................................................................................1-11.1 RAN Troubleshooting Process........................................................................................................................1-21.2 RAN Troubleshooting Methods......................................................................................................................1-41.3 Huawei Technical Support..............................................................................................................................1-7

1.3.1 Contacting Huawei for Technical Support.............................................................................................1-71.3.2 Files to be Sent to Huawei Technical Support.......................................................................................1-8

2 Troubleshooting Voice Services..............................................................................................2-12.1 Definitions of Voice Service Problems...........................................................................................................2-22.2 Conversation Noise.........................................................................................................................................2-22.3 One-Way Audio..............................................................................................................................................2-62.4 Reference Information of Voice Services.....................................................................................................2-10

3 Troubleshooting Video Phone Services................................................................................3-13.1 Definitions of Video Phone Service Problems................................................................................................3-23.2 Low Quality Video Phone Images..................................................................................................................3-23.3 Signal Flow of Video Phone Services.............................................................................................................3-4

4 Troubleshooting Packet Switched Services..........................................................................4-14.1 Definitions of PS Service Problems................................................................................................................4-24.2 PS Service Problems on the Control Plane.....................................................................................................4-24.3 PS Service Problems on the User Plane..........................................................................................................4-54.4 Bad Performance in User Data Transmission.................................................................................................4-84.5 Signal Flow of PS Services...........................................................................................................................4-11

5 Troubleshooting the Access to the Network.........................................................................5-15.1 Defintions of Network Access Problems........................................................................................................5-25.2 UE Failure to Search the Network..................................................................................................................5-25.3 UE Failure to Access the Network or Frequent UE Disconnections from the Network.................................5-45.4 UE Failure to Make a Call on the Network.....................................................................................................5-75.5 Procedure for the UE to Select the Network...................................................................................................5-9

6 Troubleshooting Handover......................................................................................................6-16.1 Definitions of Handover Problems..................................................................................................................6-36.2 Intra-RNC Soft Handover Failure...................................................................................................................6-3

RANTroubleshooting Guide Contents

Issue 01 (2008-05-30) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

i

6.3 Inter-RNC Soft Handover Failure...................................................................................................................6-66.4 Hard Handover Failure....................................................................................................................................6-76.5 Inter-System Handover Failure.......................................................................................................................6-96.6 Signal Flow of a Handover............................................................................................................................6-13

7 Troubleshooting RAN Clocks................................................................................................. 7-17.1 Definitions of Clock Problems........................................................................................................................7-27.2 NodeB Clock Problems: Causes and Related Alarms.....................................................................................7-27.3 RNC Clock Problems: Causes and Related Alarms........................................................................................7-27.4 Signal Flow of a Clock System.......................................................................................................................7-3

8 Troubleshooting RAN Interface Links..................................................................................8-18.1 Definitions of Interface Link Problems...........................................................................................................8-28.2 Interface Link Problems: Causes and Related Alarms....................................................................................8-2

9 Troubleshooting RAN Radio Frequency Performance.......................................................9-19.1 Definitions of RF Problems ............................................................................................................................9-29.2 NodeB RF Fault: Causes and Related Alarms................................................................................................9-29.3 Signal Flow of the RAN RF System...............................................................................................................9-3

10 Collecting RAN Fault Location Data..................................................................................10-110.1 Collecting RNC Fault Location Data..........................................................................................................10-2

10.1.1 Collecting RNC Fault Location Data.................................................................................................10-210.1.2 Collecting Error Logs from the RNC FAM.......................................................................................10-410.1.3 Collecting RNC Alarm Data..............................................................................................................10-510.1.4 Collecting Error Logs from a BAM Server........................................................................................10-610.1.5 Collecting Operation Logs from the RNC LMT................................................................................10-710.1.6 Collecting RNC Self-Diagnostic Output Data...................................................................................10-710.1.7 Collecting Call Data Tracing Messages.............................................................................................10-910.1.8 Collecting Signaling Tracing Messages on Standard Interfaces......................................................10-1210.1.9 Collecting RNC Configuration Data................................................................................................10-15

10.2 Push-Button RNC Data Collection Guidelines.........................................................................................10-1610.3 Collecting NodeB Fault Location Data.....................................................................................................10-17

10.3.1 Collecting NodeB NMPT Logs........................................................................................................10-1710.3.2 Collecting NodeB Board Logs.........................................................................................................10-1910.3.3 Collecting Signaling Tracing Messages on the Iub Interface...........................................................10-2110.3.4 Collecting CHR data........................................................................................................................10-22

ContentsRAN


ii Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-05-30)

Figures

Figure 1-1 RAN Troubleshooting Process...........................................................................................................1-2Figure 2-1 Procedure for troubleshooting noise in calls......................................................................................2-3Figure 2-2 Iu interface loopback..........................................................................................................................2-5Figure 2-3 Procedure for troubleshooting one-way audio in calls.......................................................................2-7Figure 2-4 Iu interface loopback..........................................................................................................................2-9Figure 2-5 Protocol stack of voice services in the WCDMA system.................................................................2-10Figure 2-6 RAB Assignment Request messages................................................................................................2-11Figure 2-7 RANAP Security Mode Command messages..................................................................................2-12Figure 3-1 Procedure for troubleshooting low quality VP services.....................................................................3-2Figure 3-2 Protocol stack for the signal flow of VP services...............................................................................3-4Figure 4-1 Procedure for troubleshooting PS service problems on control plane................................................4-3Figure 4-2 Procedure for troubleshooting PS service problems on the user plane..............................................4-6Figure 4-3 Procedure for troubleshooting bad performance in user data transmission........................................4-9Figure 4-4 Data transmission paths for PS services...........................................................................................4-11Figure 5-1 Procedure for troubleshooting UE failure to search the network.......................................................5-3Figure 5-2 Procedure for troubleshooting UE failure to search the network.......................................................5-5Figure 5-3 Procedure for troubleshooting UE failure to make a call on the network..........................................5-7Figure 5-4 Cell selection and reselection of the UE.............................................................................................5-9Figure 6-1 Procedure for troubleshooting the intra-RNC soft handover failure..................................................6-4Figure 6-2 Procedure for troubleshooting the hard handover failure...................................................................6-7Figure 6-3 Procedure for troubleshooting the inter-system handover failure....................................................6-10Figure 6-4 Signal Flow of an Intra-RNC Soft Handover...................................................................................6-13Figure 6-5 Signal Flow of an Inter-RNC Soft Handover...................................................................................6-14Figure 6-6 Signal Flow of an Intra-RNC Hard Handover..................................................................................6-15Figure 6-7 Signal flow of an inter-RNC hard handover.....................................................................................6-16Figure 6-8 Signal flow of an inter-system handover..........................................................................................6-17Figure 7-1 RNC clock structure...........................................................................................................................7-4Figure 7-2 Iub interface clock synchronization mode..........................................................................................7-5Figure 7-3 GPS clock synchronization mode.......................................................................................................7-6Figure 7-4 External reference clock synchronization mode.................................................................................7-7Figure 9-1 Signal flow of the RAN RF system....................................................................................................9-3Figure 10-1 RNC FAM log file..........................................................................................................................10-4Figure 10-2 CHR path and file name.................................................................................................................10-5

RANTroubleshooting Guide Figures


iii

Figure 10-3 RNC FAM log file..........................................................................................................................10-6Figure 10-4 Self-diagnoses.................................................................................................................................10-7Figure 10-5 Self-diagnostic file path..................................................................................................................10-9Figure 10-6 CDT tracing..................................................................................................................................10-10Figure 10-7 Setting the CDT tracing................................................................................................................10-11Figure 10-8 CDT tracing message file.............................................................................................................10-12Figure 10-9 Trace management........................................................................................................................10-13Figure 10-10 Iu interface tracing......................................................................................................................10-14Figure 10-11 File path for tracing messages on standard interfaces................................................................10-15Figure 10-12 COL LOG parameters................................................................................................................10-16Figure 10-13 NMPT log file transfer...............................................................................................................10-18Figure 10-14 NMPT log file.............................................................................................................................10-19Figure 10-15 Board log file transfer.................................................................................................................10-20Figure 10-16 NodeB signaling tracing messages on the Iub interface.............................................................10-21Figure 10-17 Standard signaling interface tracing...........................................................................................10-22Figure 10-18 Setting CHR Switch....................................................................................................................10-23

FiguresRAN


iv Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-05-30)

Tables

Table 1-1 Categories of faults occurring in RAN.................................................................................................1-3Table 7-1 NodeB clock fault causes and related alarms.......................................................................................7-2Table 7-2 RNC V100R010 clock fault causes and related alarms ......................................................................7-3Table 7-3 RNC V200R010 clock fault causes and related alarms ......................................................................7-3Table 8-1 Fault causes and related alarms of interface links for the NodeB........................................................8-2Table 8-2 Fault causes and related alarms of interface links for the RNC...........................................................8-3Table 9-1 NodeB RF fault causes and related alarms...........................................................................................9-2Table 10-1 RNC fault location data....................................................................................................................10-3

RANTroubleshooting Guide Tables


v

About This Document

Purpose

This document describes the troubleshooting methods for the Wideband Code Division MultipleAccess (WCDMA) Radio Access Network (RAN) products in service. With this document,maintenance engineers or technicians can troubleshoot the following problems:

l Complaints from users

l Faults in routine maintenance

l Burst equipment faults

l Alarms

Related Versions

The following table lists the product versions related to this document:

Product Name Version

RNC V100R010

V200R010

NodeB V100R010

V200R010

Intended Audience

This document is intended for:

l System engineers

l RNC site maintainers

l NodeB site maintainers

Update History

Refer to Changes in RAN Troubleshooting Guide.

RANTroubleshooting Guide About This Document


1

Organization

1 Introduction to RAN Troubleshooting

This part describes the process and methods of RAN troubleshooting and the technical supportfrom Huawei.

2 Troubleshooting Voice Services

This part presents the troubleshooting cases of voice services.

3 Troubleshooting Video Phone Services

This part describes the faults occurring in VP services and the troubleshooting methods. It alsopresents cases for troubleshooting VP services.

4 Troubleshooting Packet Switched Services

This part describes the faults occurring in PS services and the troubleshooting methods. It alsopresents cases for troubleshooting PS services.

5 Troubleshooting the Access to the Network

This part describes the faults occurring to voice services and the troubleshooting methods. Italso presents cases for troubleshooting voice services.

6 Troubleshooting Handover

This part describes the faults occurring in different types of handover and the troubleshootingmethods. It also presents cases for troubleshooting handover failures.

7 Troubleshooting RAN Clocks

This part describes the relationship between the clock fault causes and related alarms. It alsopresents cases for troubleshooting clock failures. The clock faults refer to the faults occurringin clock source and clock board.

8 Troubleshooting RAN Interface Links

This part describes the fault causes and related alarms of the RAN interface links. It also presentsthe cases of troubleshooting interface links.

9 Troubleshooting RAN Radio Frequency Performance

This part describes the fault causes and related alarms of RF performance. It also presents thecases of troubleshooting RF performance.

10 Collecting RAN Fault Location Data

When the RAN devices are faulty and the field engineers cannot immediately locate or clear thefaults, collect the RAN fault location data and contact Huawei for technical support.

Conventions

1. Symbol Conventions

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

About This DocumentRAN


2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-05-30)

Symbol Description

DANGERIndicates a hazard with a high level of risk that, if not avoided,will result in death or serious injury.

WARNINGIndicates a hazard with a medium or low level of risk which, ifnot avoided, could result in minor or moderate injury.

CAUTIONIndicates a potentially hazardous situation that, if not avoided,could cause equipment damage, data loss, and performancedegradation, or unexpected results.

TIP Indicates a tip that may help you solve a problem or save yourtime.

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

2. General Conventions

Convention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files,directories,folders,and users are in boldface. Forexample,log in as user root .

Italic Book titles are in italics.

Courier New Terminal display is in Courier New.

3. Command Conventions


Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italic.

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

{x | y | ...} Alternative items are grouped in braces and separated by verticalbars.One is selected.

[ x | y | ... ] Optional alternative items are grouped in square brackets andseparated by vertical bars.One or none is selected.

{ x | y | ... } * Alternative items are grouped in braces and separated by verticalbars.A minimum of one or a maximum of all can be selected.

RANTroubleshooting Guide About This Document


3


[ x | y | ... ] * Alternative items are grouped in braces and separated by verticalbars.A minimum of zero or a maximum of all can be selected.

4. GUI Conventions


Boldface Buttons,menus,parameters,tabs,window,and dialog titles are inboldface. For example,click OK.

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

5. Keyboard Operation


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

Key1+Key2 Press the keys concurrently.For example,pressing Ctrl+Alt+Ameans the three keys should be pressed concurrently.

Key1,Key2 Press the keys in turn.For example,pressing Alt,A means the twokeys should be pressed in turn.

6. Mouse Operation

Action Description

Click Select and release the primary mouse button without moving thepointer.

Double-click Press the primary mouse button twice continuously and quicklywithout moving the pointer.

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

About This DocumentRAN


4 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-05-30)

1 Introduction to RAN Troubleshooting

About This Chapter

This part describes the process and methods of RAN troubleshooting and the technical supportfrom Huawei.

1.1 RAN Troubleshooting ProcessRAN troubleshooting process consists of collecting fault information, determining the fault areaand type, diagnosing fault causes, clearing the fault, checking whether the equipment or theservice is restored, and contacting Huawei for technical support.

1.2 RAN Troubleshooting MethodsRAN troubleshooting methods include user tracing, interface signaling tracing, trafficmeasurement, alarm analysis, test analysis, network packet catchers, comparison and doublereplacement, GENEX series tools, and OMStar.

1.3 Huawei Technical SupportIf you have questions during the troubleshooting, collect necessary information and contactHuawei for technical support.

RANTroubleshooting Guide 1 Introduction to RAN Troubleshooting


1-1

1.1 RAN Troubleshooting ProcessRAN troubleshooting process consists of collecting fault information, determining the fault areaand type, diagnosing fault causes, clearing the fault, checking whether the equipment or theservice is restored, and contacting Huawei for technical support.

Figure 1-1 shows the RAN troubleshooting process.

Figure 1-1 RAN Troubleshooting Process

Collecting Fault InformationThe following information must be collected before the troubleshooting:

l Fault symptoms

l Time, location, and frequency

l Area and impact

l Running status of the equipment before a fault occurs

l Operations and related results before a fault occurs

l Measures and related effects after a fault occurs

l Alarms and associated alarms when a fault occurs

l States of board LEDs when a fault occurs

To collect the fault information, use the following methods:

1 Introduction to RAN TroubleshootingRAN


1-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-05-30)

l Consult the person who reports the fault about symptoms, time, location and frequency ofthe fault.

l Consult equipment maintainers about the running status of equipment, fault symptoms,operations before a fault occurs, measures and effects after a fault occurs.

l Observe board LEDs and alarm management system on the LMT to obtain informationabout the running status of system software and hardware.

l Examine the impact of the fault by means of service presentation, performancemeasurement, and interface or signaling tracing.

Note the following suggestions when you collect the fault information:

l Beware of collecting fault information especially when a major problem occurs. Ensurethe actual situations before working out solutions for the next step. Do not solve the problemat random.

l Maintain good relations with maintainers from other offices and relevant departments,which will greatly facilitate communications and technical consultations.

Determining the Fault Area and TypeAfter you collect fault information, analyze fault symptoms and determine the fault area andtype.

Table 1-1 describes categories of the faults occurring in the RAN.

Table 1-1 Categories of faults occurring in RAN

Category Sub-Category Refer to ...

Faults in services Faults in voice services Troubleshooting Voice Services

Faults in VP services Troubleshooting Video PhoneServices

Faults in packet switchedservices

Troubleshooting Packet SwitchedServices

Faults in network access Troubleshooting the Access to theNetwork

Faults in handover Troubleshooting Handover

Faults in thefunctionalsubsystem

Faults in RAN clocks Troubleshooting RAN Clocks

Faults in RAN interface links Troubleshooting RAN InterfaceLinks

Faults in RAN radio frequencyperformance

Troubleshooting RAN RadioFrequency Performance

NOTE

In this way, you can easily determine the fault area and type according to fault symptoms. These types offault are not entirely irrelevant to each other. For example, a fault in voice services may be caused by theclock problem. In this situation, handling suggestions will be directly referenced to the section thattroubleshoots the clock and they are not described in the scope of troubleshooting voice services.



1-3

Diagnosing Fault Causes

Certain methods are used to compare and analyze possible causes and eliminate impossible onesuntil the immediate causes are finally determined.

l Locating faults in services

– To locate a fault in voice services or packet switched services, you can check the Iu,Iub, and Uu interfaces in turn and then determine whether the fault occurs to the RANbased on the symptoms on the interface. If the fault occurs to the internal componentof the RAN, you should further locate it.

– To locate a fault in handover or in access to the network, you should start the signalingtracing and comparing it with the protocols to locate the fault.

Some methods should be used to locate and analyze specific faults, as listed in 1.2 RANTroubleshooting Methods.

l Faults in the functional subsystem

– Faults occurring to clocks, interface links, and radio frequency performance have manytypes but comparatively narrow range. Faults of this category have simple causes andare displayed through board LEDs (which will blink abnormally), alarms, and errorprompts. You can always troubleshoot these faults in compliance with the LEDinformation, alarm handling suggestions, or error prompts.

Clearing the Faultl Clearing the fault means using proper measures to restore the system. It consists of checking

the cables, replacing the boards, modifying the data configuration, switching over thesystems, and resetting the boards.

l Different procedures should be applied to different faults.

l The system should be checked again after the troubleshooting to ensure that the fault iscompletely cleared.

l Review the whole troubleshooting process, note down the key points in the troubleshooting,and summarize the workaruond and measures for improvement to avoid recurrence of thefaults of the same type.

Checking the Equipment or Services

After you clear the faults, check whether the system works properly by querying the states ofboard LEDs and alarm LEDs, and perform dialing test to ensure that the services are operational.

Contacting Huawei for Technical Support

Collect necessary fault information and contact Huawei for technical support. For details, referto 1.3 Huawei Technical Support.

1.2 RAN Troubleshooting MethodsRAN troubleshooting methods include user tracing, interface signaling tracing, trafficmeasurement, alarm analysis, test analysis, network packet catchers, comparison and doublereplacement, GENEX series tools, and OMStar.




Issue 01 (2008-05-30)

User Tracing

The user tracing, based on the number of one user, can trace and display information about thestandard interfaces, messages in the interfaces, and status of the interfaces of that user in achronological order on the monitor. The user tracing can be applied to locating the fault thatrecurs in call services.

The user tracing has the following benefits:

l Real-time tracing results

l Comprehensive information about the tracing over all the standard interfaces

l Applicable to high traffic

l Applicable to various scenarios for analyzing the call procedure and for tracing VIP users

NOTE

The RNC LMT provides the user tracing function which consists of call tracing and CDT tracing.

Interface Signaling Tracing

The interface signaling tracing can trace and display all the information over one interface, forexample, the Iu, Iub, Iur, or Uu interface, in a chronological order on the monitor. The interfacesignaling tracing is applied to locating the faults in calls of indefinite types, for example, lowput-through rate of calls of an office.

The interface signaling tracing has the following benefits:

l Real-time tracing results

l Complete messages over the interface in a period of time

l Tracing of messages for link management

NOTE

Both the RNC LMT and the NodeB LMT provide the interface signaling tracing function, in which theRNC LMT provides message tracing on the Iu, Iub, and Uu interfaces and the NodeB LMT providesmessage tracing on the Iub interface.

Traffic Measurement

The traffic measurement is to take real-time statistics from various problems such as call dropsand handover during calls. It can be applied to the KPI analysis and performance analysis.

The traffic measurement has the following benefits:

l Providing an overall reflection of calling results, for example, the put-through rate

NOTE

The M2000 client provides the traffic measurement function for the RAN.

Alarm Analysis

When a fault occurs in the system, related alarms are displayed on the LMT. Maintainers canimmediately obtain the reported alarms by setting related parameters, for example, setting analarm icon with the blinking LED. The maintainers can also set the alarm box to obtain specifiedaudio and visual information.



1-5

You can determine fault types and fault location data by checking the alarms or the relevancebetween alarms. In addition, each alarm provides the information about the alarm handlingprocedures and the troubleshooting methods.

The alarm analysis is applied to troubleshooting the faults in services and functional subsystems.

NOTE

Both the RNC LMT and the NodeB LMT provide fault management function. For details about faultmanagement, refer to the RNC LMT User Guide and the NodeB LMT User Guide.

Test Analysis

Test analysis, a way to detect faults, is used to test service-related physical paths and functionalmodules. The fault detection function of the system consists of the detection of E1 faults,detection of SAAL link faults, and detection of clock faults.

The test analysis is applied to troubleshooting faults in services and functional subsystems.

NOTE

Both the RNC LMT and the NodeB LMT provide fault detection function. For details about fault detection,refer to the RNC LMT User Guide and the NodeB LMT User Guide.

Network Packet Catchers

The Sniffer and the Ethereal are two types of software that are used to catch and analyze packetsaccording to the defined conditions in the Ethernet. This greatly facilitates the analysis duringdata forwarding. The packet catchers are applied to troubleshooting the PS services.

NOTE

For details about how to use packet catchers, refer to their user guides.

Comparison and Double Replacement

Comparison is implemented to compare the faulty components with the operational componentsor to compare fault symptoms with operational states. Then you can find out their differenceand locate the faults. This function is often applied to the faults in simple areas.

Double replacement is performed to determine the area or location of a fault by replacing theparts. In this case, components in operational state and components that are probably faulty,such as boards and optical cables, are replaced with each other. Comparison between the runningstates before and after the replacement is used to determine the area or location of the faults.This function is often applied to the faults in complicated areas.

Comparison and double replacement are used to troubleshoot functional modules.

GENEX Series Tools

The GENEX series tools are a suit of tools for radio test, wireless network performance analysis,wireless call tracing, and wireless network planning. The GENEX series tools are applied tonetwork planning and optimization.

The GENEX series tools have the following functions:




Issue 01 (2008-05-30)

l U-Net: provides network preplanning in early phase, such as network estimation andbudget, and also implements network planning, such as network dimensioning andemulation.

l Probe: provides air interface tests in order to obtain network indexes through drive tests.

l Assistant: provides analysis and takes statistics from the drive test data and the RNC data.

l Nastar: obtains post-processed data to locate and analyze the network faults.

NOTE

For details about how to use the GENEX series tools, refer to the manuals of related tools.

OMStar

The WCDMA RAN OMStar (hereinafter referred to as OMStar) is a suit of tools for maintenanceand tests of WCDMA RAN equipment. Through analysis of the D-matrix and of alarms,performance, configuration, and call logs, the OMStar can help maintainers start the diagnosisprocedure in IE browser and locate the faults in the shortest period.

The OMStar is used applied to initial establishment of sites, routine OM, routine inspection, andburst fault handling.

NOTE

For details about how to use the OMStar, refer to the OMStar User Guide.

1.3 Huawei Technical SupportIf you have questions during the troubleshooting, collect necessary information and contactHuawei for technical support.

1.3.1 Contacting Huawei for Technical SupportFor the problems difficult to be located or solved, contact Huawei for technical support.

1.3.2 Files to be Sent to Huawei Technical SupportTo effectively solve the problems, you are recommended to provide the following informationbefore asking Huawei for technical support:

1.3.1 Contacting Huawei for Technical SupportFor the problems difficult to be located or solved, contact Huawei for technical support.

Use the following contact information:

l Telephone: (86-755) 28560000

l Fax: (86-755) 28560111

l E-mail: [email protected]

l Website: http://support.huawei.com

NOTE

For contact information about the local office in your region, log in to the previously mentioned website.



1-7

mailto:[email protected]

http://support.huawei.com

1.3.2 Files to be Sent to Huawei Technical SupportTo effectively solve the problems, you are recommended to provide the following informationbefore asking Huawei for technical support:

Collecting Fault Informationl Full name of the office

l Contact person and telephone number

l Time that the fault occurs

l Fault symptoms in detail

l Version of the host software on the equipment

l Measures taken after the fault occurs and corresponding results

l Severity level of the fault and expected time for troubleshooting

Collecting Fault Location Datal Alarm information

l Host error log

l BAM error log

l Operation log of the LMT

l Self-diagnosis output data

l CDRs of a single user

l Signaling tracing messages on standard interfaces

l Data configuration

For details about how to collect fault information, refer to the 10 Collecting RAN FaultLocation Data.




Issue 01 (2008-05-30)

2 Troubleshooting Voice Services

About This Chapter

This part presents the troubleshooting cases of voice services.

2.1 Definitions of Voice Service ProblemsVoice service problems refer to the problems occurring during calls, such as one-way audio, noaudio, noise, discontinuity, cross talk, echo, and so on.

2.2 Conversation NoiseNoise, discontinuity, low quality calls, or occasional silence may occur during the conversation.

2.3 One-Way AudioDuring a call, only one party can be heard while the other cannot, or neither of them can heareach other.

2.4 Reference Information of Voice ServicesThis part describes the reference information about voice services, which consists of signal flowof voice services, negotiation process of establishing voice services, handover process, andencryption process of voice services.

RANTroubleshooting Guide 2 Troubleshooting Voice Services


2-1

2.1 Definitions of Voice Service ProblemsVoice service problems refer to the problems occurring during calls, such as one-way audio, noaudio, noise, discontinuity, cross talk, echo, and so on.

For information about call establishment, access delay, call drop, coverage effect and othervoice-related problems, refer to 5 Troubleshooting the Access to the Network.

Problems in voice services can be divided into the following two categories:

l One-way audio: includes one-way audio, no audio, and cross talk.

l Noise: includes noise, low quality calls, discontinuous voices, and occasional silence.

One-Way Audio

When A calls B, A can hear B but B cannot hear A.

No Audio

After a call is set up between A and B, they cannot hear each other.

Discontinuity

There is pause during the conversation, that is, the called party can hear a speech with wordsskipped.

Conversation Noise

Strange sound occurs during the conversation, such as sound of bubbles, clatters, and metals. Inserious cases, conversations are totally covered by noise.

Cross Talk

During the conversation, both the called or calling party and a third party can be heard, or a thirdparty instead of the called or calling party can be heard.

Echo

During the conversation, not only the called party but also echo of the calling party can be heard.In serious cases, the echo may interrupt the conversation.

2.2 Conversation NoiseNoise, discontinuity, low quality calls, or occasional silence may occur during the conversation.

Context

Figure 2-1 shows the procedure for troubleshooting noise in calls.

2 Troubleshooting Voice ServicesRAN



Issue 01 (2008-05-30)

Figure 2-1 Procedure for troubleshooting noise in calls



2-3

SN Action Refer to ...

*1-1 Perform tests until the problem recurs. Perform tests until the problemrecurs.

*1-2 Determine whether the problem occurs onthe RAN side.

Determine whether the problemoccurs on the RAN side.

*1-3 Check the quality of radio signals on theRAN side.

Check the quality of radio signals.

*1-4 Check whether packet loss occurs in thenetwork.

Check whether packet loss occursin the network.

*1-5 Initiate single user tracing on the RNC andcheck whether the user is located inhandover area and whether there isrelevance between the moment that noiseappears and the signaling that handed overby the user.

Determine whether the problem iscaused by the handover.

*1-6 Restart the UE and check whether the noisedisappears. If the noise disappears, the UEmay be faulty. In this situation, replace thatUE with a new one and try again.

Determine whether the problemoccurs in the UE.

*1-7 Determine whether the problem occurs inthe encryption mode.

Determine whether the problemoccurs in the encryption mode.

*1-8 Determine whether the services arerestored.

Determine whether the services arerestored.

*1-9 Collect fault location data and contactHuawei for technical support.

1.3 Huawei Technical Support

Procedure

Step 1 Perform tests until the problem recurs.

Based on the feedback from users, perform dialing tests for different offices and areas onspecified sites until the problem recurs.

When the problem recurs, trace the entire signaling process. Maintain the connection betweenthe UE and the network. Observe whether a handover occurs, for example, the 3G-to-2Ghandover and the inter-frequency hard handover.

Step 2 Determine whether the problem occurs on the RAN side.

If the problem recurs and persists, diagnose it through sectional loopback. Initiate the single userloopback on the RNC LMT.

Figure 2-2 shows the single user loopback on the RNC LMT.




Issue 01 (2008-05-30)

Figure 2-2 Iu interface loopback

l If the noise does not disappear after the uplink loopback for a single user, it indicates thatthe problem occurs on the RAN side. Then, refer to the parts from Checking quality of radiosignals to Determine whether the problem occurs in the encryption mode to determinewhere the problem occurs.

l If the noise disappears after the uplink loopback for a single user, it indicates that the problemoccurs in the CN. Then, contact the CN maintainers for troubleshooting.

Step 3 Check the quality of radio signals.

1. Check the signal-to-noise ratio on cells and the received signal power of the UE to determinethe quality of downlink signals.

l If the downlink RSCP is less than –98 dBm, improve the radio environment and thequality of downlink signals.

l If the downlink Ec/Io is less than -18 dB, improve the radio environment and the qualityof downlink signals.

2. Check whether the RTWP of the cell is at a high level. If the RTWP is always higher than–95 dBm, check whether external interference occurs.



2-5

3. Check the uplink signals for a single user by monitoring OLPC on the RNC LMT. If theBLER is higher than 10%，the speech quality may be poor. In this situation, enhance thequality of downlink signals by improving the radio environment.

Step 4 Check whether packet loss occurs in the network.1. Check whether intermittent or fault alarms occur in the transmission process on the NodeB.

If so, clear the alarms on transmission.2. Check whether the clock-related alarms are generated on the NodeB and the RNC. If so,

clear the alarms.

Step 5 Determine whether the problem is caused by the handover.1. Check whether there are similarities between the signaling process records when the

problem recurs, for example, whether an inter-system handover or an inter-frequency hardhandover is performed.

2. If the problem is related to the handover, check whether the problem occurs in theencryption mode or in the UE by referring to Determine whether the problem occurs inthe UE and Determine whether the problem occurs in the encryption mode. If theproblem is not related to the UE or the encryption mode, contact Huawei for technicalsupport.

Step 6 Determine whether the problem occurs in the UE.1. Test the UEs manufactured by different vendors, compare the test results, and check

whether the problem occurs in a specified type of UEs. Even if the UEs under test are ofthe same type, their software versions may vary. For information about UE types andsoftware versions, refer to the instructions delivered with the corresponding UEs.

2. If the problem does not occur after you perform the same test on other UEs, inform thevendors of the faulty UEs.

Step 7 Determine whether the problem occurs in the encryption mode.1. Test tools for the UEs, such as Tems, are required for analyzing whether the encryption

algorithms for UEs during the handover process are consistent with those for the network.2. For hybrid services, check whether the encryption algorithms for PS services are consistent

with those for CS services.3. If the algorithms are inconsistent, modify them and verify whether the mismatch is cleared.

To set encryption algorithm parameters for CS and PS services on the CN side, contact theCN maintainers for technical support.

Step 8 Determine whether the services are restored.

After locating the problem and taking corresponding measures, perform dialing tests on the siteswhere the problem occurs and check whether the problem is cleared.

----End

2.3 One-Way AudioDuring a call, only one party can be heard while the other cannot, or neither of them can heareach other.




Issue 01 (2008-05-30)

ContextOne-way audio or no audio is often related to the equipment, such as the UE, network equipment,and transmission device. The radio coverage or the decryption algorithm is not involved in one-way audio or no audio.

Figure 2-3 shows the procedure for troubleshooting one-way audio in calls.

Figure 2-3 Procedure for troubleshooting one-way audio in calls

SN Action Refer to...


*1-2 Determine whether the problem occurs onthe RAN side.

Determine whether the problemoccurs on the RAN side.



2-7


*1-3 Initiate single user tracing on the RNC andcheck whether the user is located in thehandover area and whether there isrelevance between the moment that noiseappears and the signaling that handed overby the user.

Determine whether the problem iscaused by the handover.

*1-4 Restart the UE and check whether the noisedisappears. If the noise disappears, the UEmay be faulty. In this situation, replace thatUE with a new one and try again.






Procedure


Based on the feedback from users, perform dialing tests for different offices and areas onspecified sites until the problem recurs.

When the problem recurs, trace the entire signaling process. Maintain the connection betweenthe UE and the network. Observe whether a handover occurs, for example, the 3G-to-2Ghandover and the inter-frequency hard handover.

Step 2 Determine whether the problem occurs on the RAN side.

If the problem recurs and persists, diagnose it through sectional loopback. Initiate the single userloopback on the RNC LMT.

Figure 2-4 shows the single user loopback on the RNC LMT.




Issue 01 (2008-05-30)

Figure 2-4 Iu interface loopback

l If the one-way audio does not disappear after the uplink loopback for a single user, it indicatesthat the problem occurs on the RAN side. Then, determine the fault area by referring toCheck whether the problem is caused by the handover to Check whether the servicesare restored.

l If the one-way audio disappears after the uplink loopback for a single user, it indicates thatthe problem occurs in the CN. Then, contact the CN maintainers for troubleshooting.

Step 3 Determine whether the problem is caused by the handover.1. Check whether there are similarities between the signaling process records when the

problem recurs, for example, whether an inter-system handover or an inter-frequency hardhandover is performed.

2. If the problem is related to the handover, check whether the UE is faulty.3. If the problem is not related to the previously mentioned two points, contact Huawei for

technical support.

Step 4 Determine whether the problem occurs in the UE.



2-9

1. Check whether the problem occurs in a specified UE. Even if the UEs under test are of thesame type, their software versions may vary.

2. If the problem does not occur after you perform the same test on other UEs, inform thevendors of the faulty UEs.


After you diagnose the fault and take corresponding measures, determine whether the servicesare restored by performing dialing tests several times on the same location where the problemoccurs.

----End

2.4 Reference Information of Voice ServicesThis part describes the reference information about voice services, which consists of signal flowof voice services, negotiation process of establishing voice services, handover process, andencryption process of voice services.

Signal Flow of Voice Services

Voice services are basic services for the mobile communications systems. Figure 2-5 shows thenetwork elements and protocol processing modules involved in the WCDMA network.

Figure 2-5 Protocol stack of voice services in the WCDMA system

The protocol stack shown in Figure 2-5 is described as follows:l AMR: a voice coding protocol in the WCDMA system. For details, refer to 3GPP

TS26.101–TS26.105.l Uu interface: physical layer processing on the air interface, including channel coding and

decoding, scrambling, spreading, modulating, and transmitting. For details, refer to 3GPPTS25.211–TS25.215.

l FP: a protocol for the user plane on the Iub interface.

l IuUP: a protocol for the user plane on the Iu interface.




Issue 01 (2008-05-30)

l MAC-d: a part of the Uu interface, which can be processed on the UE or the RNC.

After analysis of the modules for protocol processing, the following conclusion can be made tohelp you troubleshoot voice services:

l The WCDMA RAN is not involved in speech encoding and decoding but involved inencryption, decryption, and frame format conversion. Thus if a fault occurs in the RAN, itmay be frame loss or a frame error which causes noise, message loss, or click sound insteadof echo or cross talk.

l Different from the GSM system, the time adjustment mechanism is posed on the Iu and Iubinterfaces. Faults may occur when the time adjustment mechanism is interoperable withother network elements, especially the Iu interfaces of equipment supplied by othervendors, and when the transmission is poor on the Iub interface.

l The air interface quality, which is influenced by coverage of radio signals and externalinterference, directly affects the quality of voice services.

Negotiation Process of Establishing Voice Services

The process of establishing voice services is basic to the WCDMA system. This process is thebasis of analyzing the faults in voice services, where all the voice processing-related parametersare negotiated and the parameters of speech rate and encryption algorithm need to be obtained.

Figure 2-6 shows the parameters of voice services.

Figure 2-6 RAB Assignment Request messages

Figure 2-7 shows the parameters of encryption algorithm.



2-11

Figure 2-7 RANAP Security Mode Command messages

Handover Process

Handover from the 3G system to the 2G system

l At present, all the offices for commercial use can support the handover from the 3G systemto the 2G system. After the handover, the 3G RAN is no longer connected but the 3G CNis still connected to the UE.

Inter-frequency hard handover

l Speech loss is inevitable during the hard handover. Therefore, the quality of voice serviceswill degrade in the case of frequent hard handover, which can be verified through theobservation of traffic statistics or signaling tracing for a single user.

Encryption Process of Voice Services

Individual negotiation of CS and PS services

l When a 3G-to-2G handover is initiated, the encryption algorithm will be negotiated. If thenegotiation result is not consistent, serious noise may arise.

Process of special cases

l For some scenarios of complicated signaling processes, problems may occur in thenegotiation of encryption algorithms. For example, if the 3G-to-2G handover fails, the UEwill automatically roll back to the 3G system and the encryption algorithm will also berestored.




Issue 01 (2008-05-30)

3 Troubleshooting Video Phone Services

About This Chapter

This part describes the faults occurring in VP services and the troubleshooting methods. It alsopresents cases for troubleshooting VP services.

3.1 Definitions of Video Phone Service ProblemsVP service problems mainly refer to low call quality or fuzzy images in VP services.

3.2 Low Quality Video Phone ImagesLow quality VP images include mosaics, fuzzy images, and low speech quality in VP services.

3.3 Signal Flow of Video Phone ServicesThis part describes the protocol processing modules involved in VP services.

RANTroubleshooting Guide 3 Troubleshooting Video Phone Services


3-1

3.1 Definitions of Video Phone Service ProblemsVP service problems mainly refer to low call quality or fuzzy images in VP services.

3.2 Low Quality Video Phone ImagesLow quality VP images include mosaics, fuzzy images, and low speech quality in VP services.

ContextFigure 3-1 shows the procedure for troubleshooting low quality VP services.

Figure 3-1 Procedure for troubleshooting low quality VP services

3 Troubleshooting Video Phone ServicesRAN



Issue 01 (2008-05-30)



*1-2 Determine whether the problem occurs inradio coverage.


*1-3 Check whether packet loss occurs on thenetwork side.

Check whether packet loss occurson the network side.

*1-4 Determine whether the UE is faulty. Determine whether the problemoccurs in the UE.





Procedure


Based on the user's feedback, dialing tests at specified sites are performed until the problemrecurs.

When the problem recurs, trace the entire signaling process. Maintain the connection betweenthe UE and the network. Note whether a handover, especially the hard handover, occurs in theprocess.




l If the downlink Ec/Io is less than -15 dB, improve the radio environment and the qualityof downlink signals.


3. Check the uplink signals for a single user by monitoring the Block Error Rate (BLER) oftransport channels on the RNC LMT. If the BLER is higher than 1%，the speech qualitymay be poor. In this situation, enhance the quality of downlink signals by improving theradio environment.

Step 3 Check whether packet loss occurs on the network side.

1. Check whether intermittent or fault alarms occur in the transmission process on the NodeB.If so, clear the alarms on transmission.

2. Check whether the clock-related alarms are generated on the NodeB and the RNC. If so,clear the alarms.



3-3

3. Take statistics from a single user for the uplink BLER which is currently set to be 0.2%. Ifthe value exceeds 0.2% after analysis of long-period statistics, a problem may occur.

4. Take statistics from the number of uplink packets and determine whether serious packetloss occurs in the strictly defined 64 kbit/s VP services. If there is no convergence of powercontrol or the packet loss is serious, the problem may occur in the UTRAN. In this situation,contact Huawei for technical support.

Step 4 Determine whether the problem occurs in the UE.1. Check whether the problem occurs in a specified UE. Even if the UEs under test are of the

same type, their software versions may vary.2. If the problem does not occur after you perform the same test on other UEs, inform the

vendors of the faulty UEs.

Sometimes, the quality of VP services in one network can be determined only throughcomparison of tests results on VP services in another operator's network.


After solving the previously mentioned problems, initiate VP services again and determinewhether the quality of images and voices is improved. At present, the quality of VP services canbe determined only by arbitrary decisions.

----End

3.3 Signal Flow of Video Phone ServicesThis part describes the protocol processing modules involved in VP services.

Figure 3-2 shows the network elements and protocol processing modules involved in theWCDMA network.

Figure 3-2 Protocol stack for the signal flow of VP services

The protocol stack shown in

Figure 3-2 is described as follows:

3 Troubleshooting Video Phone ServicesRAN



Issue 01 (2008-05-30)

l H324M: Application-layer protocols for VP services, which consist of voice data, videodata, and signaling on the application layer. These data are processed only by the UEs. Forthe UTRAN and the CN, the data are transmitted transparently. This feature can be usedto locate some problems, for example, the problem of good-quality video and bad-qualityvoice can be located in the UE. You can use the earphone instead of the handfree functionto solve this problem.

l Uu interface: physical layer processing on the air interface, including channel encodingand decoding, scrambling, spreading, modulating, and transmitting. For details, refer to3GPP TS25.211-TS25.215.

l FP: a protocol for the user plane on the Iub interface.

l IuUP: a protocol for the user plane on the Iu interface. For VP services, the transparenttransmission is applied to the IuUP.

l MAC-d: a part of the Uu interface, which can be processed on the UE and the RNCrespectively.



3-5

4 Troubleshooting Packet Switched Services

About This Chapter

This part describes the faults occurring in PS services and the troubleshooting methods. It alsopresents cases for troubleshooting PS services.

4.1 Definitions of PS Service ProblemsThe PS service problems may occur in the CN and the UTRAN.

4.2 PS Service Problems on the Control PlaneThe UE cannot access the PS services or the PC fails to dial up when a problem occurs in PSservices on the control plane.

4.3 PS Service Problems on the User PlaneThe PS service problem occurs on the user plane when the UE is connected or dialed up to thenetwork but cannot visit the webpage. In some cases, the UE even cannot ping the server duringthe tests.

4.4 Bad Performance in User Data TransmissionLow performance in data transmission on the user plane includes the low data transmission ratein FTP and the poor effect of streaming services.

4.5 Signal Flow of PS ServicesThis part describes the signal flow of PS services.

RANTroubleshooting Guide 4 Troubleshooting Packet Switched Services


4-1

4.1 Definitions of PS Service ProblemsThe PS service problems may occur in the CN and the UTRAN.

The control plane carries signaling for the PS services, which is similar to the signaling of theCS services. The user plane carries data for PS services. The differences between PS and CSservices are as follows: the CS services are carried on the TDM or IP paths while the PS servicesare carried only on the IP paths. PS services on the user plane have no definite physical resources.

Common PS service problems in the UTRAN consist of the following:

l Fault in channels on the control plane

l Fault in channels on the user plane

l Low performance of data transmission on the user plane

4.2 PS Service Problems on the Control PlaneThe UE cannot access the PS services or the PC fails to dial up when a problem occurs in PSservices on the control plane.

ContextFigure 4-1 shows the procedure for troubleshooting PS service problems on the control plane.

4 Troubleshooting Packet Switched ServicesRAN



Issue 01 (2008-05-30)

Figure 4-1 Procedure for troubleshooting PS service problems on control plane





*1-3 Start the tracing of a single user on the RNCside and check whether the problem occursin the UE setting.




4-3


*1-4 Start the tracing of a single user at the RNCside and check whether the problem occursin the UE subscription.

Determine whether the problemoccurs in the UE subscription

*1-5 Determine whether the problem occurs inthe UE driver or PC.

Determine whether the problemoccurs in the UE driver or PC.





Procedure


Based on the user's feedback, dialing tests at specified sites are made until the problem recurs.

When the problem recurs, trace the entire signaling process. Maintain the connection betweenthe UE and the network.




l If the downlink Ec/Io is less than –15 dB, improve the radio environment and the qualityof downlink signals.



Check whether the UE settings are correct, for example, the APN, Proxy, password, and website,when the problem recurs. At the same time, check whether the English spelling of the code iscorrect or the parameters of the 3G and 2G network system are confused. If the setting ofparameters is not correct, a primary decision can be made through signaling tracing.

NOTE

For details about UE settings, refer to the user guide of the UE.

Step 4 Determine whether the problem occurs in the UE subscription

1. To check whether the problem is related to specified users, replace the USIM card with anew one and perform tests at the same site.

2. If the problem occurs in one of the USIM cards, contact the CN engineers to check thesubscriber information and accounting information.

Step 5 Determine whether the problem occurs in the UE driver or PC.




Issue 01 (2008-05-30)

1. Check whether the problem occurs in the settings of PC dial-up parameters such as theAPN, subscriber account, and password. The PC driver problem can be diagnosed throughsignaling flow.

2. If the fault still exists when the signaling flow is complete, reinstall the PC driver andperform a test.

3. If the fault persists, replace the PC and test again.


To determine whether the PS services are restored, tests on various services are required, forexample, online services for UE and demand services. If online, note that the webpage isrefreshed to prevent being misled by the pages in the buffer.

----End

4.3 PS Service Problems on the User PlaneThe PS service problem occurs on the user plane when the UE is connected or dialed up to thenetwork but cannot visit the webpage. In some cases, the UE even cannot ping the server duringthe tests.

ContextFigure 4-2 shows the procedure for troubleshooting PS service problems on the user plane.



4-5

Figure 4-2 Procedure for troubleshooting PS service problems on the user plane





*1-3 Start the tracing of a single user on the RNCside and check whether the problem occursin the RNC.

Determine whether the RNC isfaulty.




Issue 01 (2008-05-30)


*1-4 Perform statistical analysis on the RNC sideand determine whether the problem occursin the CN or the application layer.

Determine whether the problemoccurs in the CN or the applicationlayer.

*1-5 Determine whether the UE is faulty. Determine whether the UE is faulty.



*1-7 Collect data on the troubleshooting andcontact Huawei for technical support.


Procedure


Based on the user's feedback, dialing tests at specified sites are made until the problem recurs.



1. Check the Signal-to-Noise Ratio (SNR) on cells and the received signal power of the UEto determine the quality of downlink signals.

l If the downlink RSCP is less than –98 dBm, enhance the quality of downlink signalsby improving the radio environment.

l If the downlink Ec/Io is less than –15 dB, enhance the quality of downlink signals byimproving the radio environment.


3. Check the single user data in the uplink by monitoring OLPC on the RNC LMT. If theBLER of transport channels is higher than 1%, the PS service quality may be at a low level.In this situation, enhance the quality of downlink signals by improving the radioenvironment.

Step 3 Determine whether the RNC is faulty.

l Check whether the process to activate the Packet Data Protocol (PDP) of the UE is completeby tracing the single user signaling on the Iu interface. If the process is not complete, referto Figure 4-2 to locate the problem.

l Check whether there are packets in the uplink or the downlink based on detailed informationabout user tracing. If no packet is found, the problem occurs in the RAN. If only a few packetsare found in the uplink while no packets are found in the downlink, the problem occurs inthe CN, server, or configurations on the router. For details, refer to Determine whether theproblem occurs in the CN or the application layer.

l If the packets cannot be found on the user plane according to the RNC statistics, contactHuawei for technical support.

Step 4 Determine whether the problem occurs in the CN or the application layer.



4-7

1. If a few packets in the uplink and in the downlink can be found on the RNC, further checkwhether the server can be pinged. If no problem occurs, it shows that bottom layer bearingis functional. However, if services such as webpage browsing and VOD are stillunavailable, contact relevant engineers or accounting staff responsible for these services.

2. If the server cannot be pinged, check whether data in the uplink and in the downlink arereceived through the signaling tracing on the CN. If the data are received on the CN, contactthe CN engineers for technical support.

3. If you cannot determine whether the problem occurs in the RNC or the CN, contact Huaweifor technical support.

Step 5 Determine whether the UE is faulty.l If a PC is used, check the firewall of the PC.

l Reinstall the UE driver of the PC and perform a test on the PC.

l Replace the PC and make the test again.


To determine whether the PS services are restored, you can perform tests on various servicessuch as UE access to the Internet and VOD. Note that the webpage must be refreshed when theUE is connected to the Internet and avoid to be misled by the pages in the buffer.

----End

4.4 Bad Performance in User Data TransmissionLow performance in data transmission on the user plane includes the low data transmission ratein FTP and the poor effect of streaming services.

ContextFigure 4-3 shows the procedure for troubleshooting bad performance in user data transmission.




Issue 01 (2008-05-30)

Figure 4-3 Procedure for troubleshooting bad performance in user data transmission





*1-3 Start the tracing of a single user on the RNCside and check whether the problem occursin the RNC.

Determine whether the RNC isfaulty.



4-9


*1-4 Perform statistical analysis on the RNC sideand determine whether the problem occursin the CN or the application layer.

Determine whether the problemoccurs in the CN or the applicationlayer.

*1-5 Determine whether the UE is faulty. Determine whether the problemoccurs in the UE.





Procedure







l If the downlink Ec/No is less than -15 dB, improve the radio environment and the qualityof downlink signals.


Step 3 Determine whether the RNC is faulty.

l Use detailed information about user tracing, check the analysis result of the actual bandwidthof the RNC, and determine whether the bandwidth of the Iub interface is limited. If the Iubbandwidth is insufficient, ask the operator to add more resources.

l If the packets cannot be found on the user plane according to the RNC statistics, refer to 1.3Huawei Technical Support.

l If a large number of retransmissions are found according to detailed information about theuser tracing on the RNC, check radio signals by referring to Check the quality of radiosignals. At the same time, check whether an intermittent alarm or packet loss occurs duringthe transmission.

Step 4 Determine whether the problem occurs in the CN or the application layer.

l If the retransmission of packets in the uplink and downlink of RNC decreases but thetransmission rate becomes lower on the whole, analyze the problem by using a packet catcheron the CN or the PC.




Issue 01 (2008-05-30)

l If the field of packet loss can be found by catching packets on the TCP/IP layer on the CN,server, or UE side, contact the CN engineers for technical support.

l If you cannot determine the causes of packet loss on the RNC or the CN, contact Huawei fortechnical support.


l If a PC is used, check the firewall of the PC.

l Reinstall the UE driver of the PC and perform a test on the PC.

l Replace the PC and perform the test again.

l High performance of PC or UE is required for the high speed download service.


1. To determine whether the PS services are restored, you can perform tests on various servicessuch as UE access to the Internet and VOD.

2. To test the performance of data transmission, download a large file and test its downloadrate. The maximum rate for users to download files depends on the maximum subscriptionrate. If the subscription rate for a user is 128 kbit/s, normally the average download rate isabout 100 kbit/s.

----End

4.5 Signal Flow of PS ServicesThis part describes the signal flow of PS services.

Different from those for CS services, the data transmission paths for WCDMA PS services arerelatively complicated, as shown in Figure 4-4.

Figure 4-4 Data transmission paths for PS services

Figure 4-4 shows the following:



4-11

l The transmission paths for CS and PS services are the same on the physical layer in theUTRAN (including the UE). The protocols of high layers, such as the RLC/PDCP protocol,are more complicated than those of the physical layer.

l CS and PS services have totally different routes on the CN layer where data on all theinterfaces are carried according to the GTP-U protocol.

l The PS services comply with the TCP/IP protocol on the UE side and on the server side,and methods of recording data and analyzing packet loss are available.




Issue 01 (2008-05-30)

5 Troubleshooting the Access to the Network

About This Chapter

This part describes the faults occurring to voice services and the troubleshooting methods. Italso presents cases for troubleshooting voice services.

5.1 Defintions of Network Access ProblemsIf the UE fails to access the network or is disconnected when it is powered on, the problem mayoccur in the network access.

5.2 UE Failure to Search the NetworkThe UE receives no signals and cannot search the network.

5.3 UE Failure to Access the Network or Frequent UE Disconnections from the NetworkThe UE is occasionally faulty when receiving signals; or the UE can receive signals of highquality but fails to access the network; or the UE is frequently disconnected from the network;or the UE always uses the 2G system when the 3G system is available.

5.4 UE Failure to Make a Call on the NetworkThe UE subscribes to the network and receives high-quality signals but fails to make a call orestablish other services.

5.5 Procedure for the UE to Select the NetworkThis part describes how the UE selects the network in normal state.

RANTroubleshooting Guide 5 Troubleshooting the Access to the Network


5-1

5.1 Defintions of Network Access ProblemsIf the UE fails to access the network or is disconnected when it is powered on, the problem mayoccur in the network access.

ContextFault symptoms for the network access problems are as follows:l UE Failure to Search the Network

l UE Failure to Access the Network or Frequent UE Disconnections from the Network

l UE Failure to Make a Call on the Network

5.2 UE Failure to Search the NetworkThe UE receives no signals and cannot search the network.

ContextFigure 5-1 shows the procedure for troubleshooting UE failure to search the network.

5 Troubleshooting the Access to the NetworkRAN



Issue 01 (2008-05-30)

Figure 5-1 Procedure for troubleshooting UE failure to search the network





*1-3 Check whether the problem occurs in thecells on the RNC.

Check whether the problem occursin the cell.

*1-4 Determine whether the UE is faulty. Check whether the UE is faulty.







5-3

Procedure




To locate the fault causes, you can directly check the data collected by the Scanner. If the RSCPand Ec/lo of the cells are very low, you can determine that the problem occurs in radio coverage.If the RSCP is lower than -105 dBm and the Ec/Io is lower than -18 dB, enhance the quality ofsignals by resetting the engineering parameters.

Different UEs have different abilities to search the network. In the same radio environment,some UEs can access the network and make calls while some cannot.

Poor quality of radio signals can be caused by faults in NodeB configurations, cell selections orpower amplifiers. In some buildings, high penetration loss also causes signals in poor quality.Note that during the optimization of radio signals, cells may be wrongly selected or the NodeBsmay be closed due to the faults. In either case, other cells where the call drop occurs may receivesignals of poor quality.

Solution: Improve the quality of radio signals.

Step 3 Check whether the problem occurs in the cell.

Check the related cells covering the site where the problem occurs. Run the DSP CELLcommand on the RNC LMT and the Query type is BYCELL.

If the cell is faulty, the UE on the cell receives no signals and thus fails to access the network.You should clear the fault in the cell first.

Step 4 Check whether the UE is faulty.

1. Check whether the UE is manually searching the network or is set to the GSM mode. Changethe UE into dual mode of automatic searching and reset the UE for tests.

2. Use the same USIM card and replace the UE for tests.


Check whether the service recovers after necessary analysis and measures are taken. Reset theUE to check whether it can access the network, receive signals or make calls through normalvoice services.

----End

5.3 UE Failure to Access the Network or Frequent UEDisconnections from the Network

The UE is occasionally faulty when receiving signals; or the UE can receive signals of highquality but fails to access the network; or the UE is frequently disconnected from the network;or the UE always uses the 2G system when the 3G system is available.




Issue 01 (2008-05-30)

Context

Figure 5-2 shows the procedure for troubleshooting UE failure to access the network or frequentUE disconnections from the network.

Figure 5-2 Procedure for troubleshooting UE failure to search the network





*1-3 Determine whether the problem occurs inthe UE subscription.

Check whether the problem occursin the UE subscription.

*1-4 Determine whether the problem occurs inthe uplink of the cell.

Check whether the problem occursin the uplink of the cell.



5-5






Procedure




Check whether the UE is at the edge of cell coverage or the signals change quickly. To determinethe quality of radio signals, you need to consult network planning engineers.

Solution: Improve the quality of radio signals.

Step 3 Check whether the problem occurs in the UE subscription.1. When the UE searches the network after being powered on, the signal strength may be

displayed for a while and the UE begins to update its location. If the UE fails to update thelocation, it will be disconnected from the network and receives no signals due to its failurein subscription.

2. Check whether the UE is manually searching the network or is set to the GSM mode. If so,change the UE into dual mode of automatic searching and reset the UE for tests.

3. Replace the USIM card and test the UE again.

Step 4 Check whether the problem occurs in the uplink of the cell.1. Check whether the RNC receives the UE signaling in the uplink by tracing the signaling

over the Uu interface.l If the RNC cannot receive the signaling, clear the fault in the cell and then go to step

Step 4.2.l If the RNC receives the signaling, it is an indication that no problem occurs in the uplink

of the cell.2. Check whether the cell is normal by running the DSP CELL command on the RNC LMT.

The Query type is BYCELL.l If the cell is normal but the UE cannot access the network, contact Huawei for technical

support.l If the cell is faulty, contact Huawei for technical support.


Check whether the service recovers after necessary analysis and measures are taken. Reset theUE to check whether it can access the network, receive signals or make calls through normalspeech services.

----End




Issue 01 (2008-05-30)

5.4 UE Failure to Make a Call on the NetworkThe UE subscribes to the network and receives high-quality signals but fails to make a call orestablish other services.

ContextFigure 5-3 shows the procedure for troubleshooting UE failure to make a call on the network.

Figure 5-3 Procedure for troubleshooting UE failure to make a call on the network.







5-7


*1-3 Check whether the problem occurs in thebilling system.

Check whether the problem occursin the billing system.

*1-4 Determine whether the problem occurs inthe cell.

Check whether the problem occursin the cells.




1.3 Huawei Technical Support.

Procedure




To locate the fault causes, you can directly check the data collected by the Scanner. If the RSCPand the Ec/lo of the best cell are quite low, it can be inferred that the problem occurs in radiocoverage. If the RSCP is less than -105 dBm and the Ec/Io is not more than -18 dB, improve thecoverage quality by modifying engineering parameters.

Solution: improve the quality of radio coverage.

Step 3 Check whether the problem occurs in the billing system.

For the default subscribers or the services not subscribed, the UE may receive signals but theservices cannot be used. Contact the CN maintainers to check whether the user defaults thecharges or does not subscribe to the corresponding service.

Step 4 Check whether the problem occurs in the cell.

Check whether the cell is normal by running the DSP CELL command on the RNC LMT. TheQuery type is BYCELL.

l If the cell is normal but the UE fails to access the network, contact Huawei for technicalsupport.

l If the cell is faulty, contact Huawei for technical support.


Check whether the services are restored after taking necessary analysis and measures. Power onand power off the UE to check whether it can access the network, receive signals, and makecalls.

----End




Issue 01 (2008-05-30)

5.5 Procedure for the UE to Select the NetworkThis part describes how the UE selects the network in normal state.

Figure 5-4 shows the process of UE network selection.

Figure 5-4 Cell selection and reselection of the UE



5-9

As stipulated by the protocol, the network searching process of the UE is very complicated.Generally, the network searching process is as follows:

1. Power on the UE and read the IMSI from the USIM card. Then obtain the HPLMN ID andthe previous PLMN ID from the USIM. Select and search the PLMN in the order stipulatedby the TS23.122. Search the cell of each frequency and read the broadcast messages fromwhich you can obtain the PLMN ID of the network.

2. The UE chooses a PLMN and camp on a cell. If the cell meets the requirement for camping,the UE initiates the relocation process for registration. If the relocation is complete, the UEstarts the service normally. If the relocation fails, the UE keeps searching other cells tomake more attempts on relocation.

3. If the UE cannot find the proper cell to camp on, the cell is chosen at random and entersthe state of limited services. In this case, the UE can only intiate calling of limited services.

4. If the UE cannot receive any signal, the UE is in the state of no signals and is searching thenetwork.




Issue 01 (2008-05-30)

6 Troubleshooting Handover

About This Chapter

This part describes the faults occurring in different types of handover and the troubleshootingmethods. It also presents cases for troubleshooting handover failures.

Context

The problems in handover include:

l Soft handover failure including both intra-RNC and inter-RNC soft handover failures

l Inter-frequency hard handover failure

l Inter-system handover failure

6.1 Definitions of Handover ProblemsThe fault symptoms of handover are not as obvious as those of services. The handover problemsoften result in call drops. You can decide whether a problem occurs in the handover throughproblem recurrence and preliminary signaling analysis.

6.2 Intra-RNC Soft Handover FailureCall drops occur during the test; or the soft handover is performed at a very low success rateduring the KPI analysis; or the handover process involves only the NodeBs or the cells of anRNC.

6.3 Inter-RNC Soft Handover FailureCall drops occur during the test; or the soft handover is performed at a very low success rateduring the KPI analysis; or the handover process involves only the NodeBs or the cells of anRNC.

6.4 Hard Handover FailureCall drops occur during the drive test or the hard handover is performed at a low success rateduring the KPI analysis.

6.5 Inter-System Handover FailureCall drops occur during the drive test or the inter-system handover is performed at a low successrate during the KPI analysis.

6.6 Signal Flow of a Handover

RANTroubleshooting Guide 6 Troubleshooting Handover


6-1

The UE handover is classified into five types: intra-RNC soft handover, inter-RNC softhandover, inta-RNC hard handover, inter-RNC hard handover, and inter-system handover. Eachtype corresponds to a signal flow.

6 Troubleshooting HandoverRAN



Issue 01 (2008-05-30)

6.1 Definitions of Handover ProblemsThe fault symptoms of handover are not as obvious as those of services. The handover problemsoften result in call drops. You can decide whether a problem occurs in the handover throughproblem recurrence and preliminary signaling analysis.

6.2 Intra-RNC Soft Handover FailureCall drops occur during the test; or the soft handover is performed at a very low success rateduring the KPI analysis; or the handover process involves only the NodeBs or the cells of anRNC.

ContextFigure 6-1 shows the procedure for troubleshooting the intra-RNC soft handover failure.



6-3

Figure 6-1 Procedure for troubleshooting the intra-RNC soft handover failure




Determine whether the problemoccurs in radio coverage.

*1-3 Determine whether the problem occurs inthe setting of parameters.

Determine whether the problemoccurs in the setting of parameters.




Issue 01 (2008-05-30)


*1-4 Determine whether the transmissionresources or CE resources are limited.

Determine whether thetransmission resources or CEresources are limited.

*1-5 Determine whether the problem occurs inthe NodeB clock.

Determine whether a deviationoccurs in the NodeB clock.

*1-6 Determine whether the handover problem issolved.

Determine whether the handoverproblem is solved.



Procedure


The soft handover problem can be located during its recurrence. You can detect the problemthrough drive tests at the handover site. Preliminary analysis of the detailed signaling recordsshows that the problem occurs in the process of soft handover.

Step 2 Determine whether the problem occurs in radio coverage.

The faults in soft handover consist of the following two types: One is that soft handover cannotbe implemented in coverage holes; the other is that because the handover area is too small, whenthe UE is moving in the handover area, the UE needs to keep measuring its neighboring cells ofthe same frequency and periodically report the measurement results to the RNC to decidewhether to perform the handover. The whole process of handover requires a period of time. Ifthe handover area is too small or the signals change too fast or the signals in the original servicearea suddenly become weak, the UE cannot complete the handover, which may result in calldrops.

l Check whether the coverage holes exist or the handover area is too small.

NOTE

Quantitative analysis of coverage holes and handover areas can be made through drive test devices ofnetwork planning. Coverage holes: You can check whether the signal strength of the cell with optimumsignals is lower than the threshold, for example, the signal strength is lower than –105 dBm. The scopeof handover areas can be decided by the duration when signals alternate in the serving cells.

l Contact network planning engineers to solve the problem in radio coverage.

Step 3 Determine whether the problem occurs in the setting of parameters.

The parameters related to soft handover include neighboring cell configurations and softhandover boolean.

l If the neighboring cell of the same frequency is not configured, soft handover cannot beperformed when the UE is moving to the cell. If the signals in the original service areasuddenly become weak, the UE cannot complete the handover, which may result in call drops.Some neighboring cells are not configured during the network capacity expansion andadjustment. You can further analyze this problem by using drive test devices. For example,



6-5

it is found that the neighboring cells with strong signals are detected but not added to theneighboring cell list. Execute LST INTRAFREQNCELL to check the neighboring cell list.

l Based on the signaling analysis, the UE stays in the soft handover area and reports theassociated measurement results, such as 1A event and 1C event reports but the RNC doesnot initiate the soft handover. When the UE begins to move, signals in the original servicearea are increasingly weak, which results in call drops. In the CS services, the soft handoverboolean is always open. However, the soft handover is not used for high speed PS servicesbut intra-frequency hard handover. Therefore, these services may cause failures in handoveror call drops in application because the boolean of soft handover is not open.

l The problem is solved when you reset the parameters. Run the SETCORRMALGOSWITCH command to modify the soft handover boolean. Run the SETHOCOMM command to modify the rate threshold of soft handover.

Step 4 Determine whether the transmission resources or CE resources are limited.

l When soft handover is performed, two or more radio links are needed. The requirement forCE and AAL2 resources increases. If the resources are insufficient, new radio links cannotbe set up and new cells cannot be added to the active set.

l Check the load of the target cell when the problem occurs. For details about how to checkthe cell load, refer to the RNC Site Maintenance Guide.

l When resources are limited, you can only increase the resources through capacity expansionor adding transmission resources.

Step 5 Determine whether a deviation occurs in the NodeB clock.

At present, most of the UEs can trace only one NodeB clock. Thus the difference between twoNodeB clocks must cause the variation of multi-path signals, which brings about many problems,such as no reporting of measurement results and call drops without reasons.

l The way to diagnose the faults is to check whether the clock-related alarms are reported onthe NodeB. If the alarms are reported, refer to the online help of the alarm subsystem.

l Run the DSP CLKSTAT or DSP CLK(RNC V200R010) command to check whether theNodeB clock is locked.

Step 6 Determine whether the handover problem is solved.

After the UE is reconnected to the network, perform a drive test at the same site to check whetherthe handover is complete. You can perform the test several times if necessary.

----End

6.3 Inter-RNC Soft Handover FailureCall drops occur during the test; or the soft handover is performed at a very low success rateduring the KPI analysis; or the handover process involves only the NodeBs or the cells of anRNC.

Context

Most of the fault causes of the inter-RNC handover and the intra-RNC handover are the same.Refer to 6.2 Intra-RNC Soft Handover Failure.




Issue 01 (2008-05-30)

NOTE

Check the parameter settings of the Iur interface, especially those of neighboring cells. Check whether theparameters of the RNCs are consistent.

6.4 Hard Handover FailureCall drops occur during the drive test or the hard handover is performed at a low success rateduring the KPI analysis.

PrerequisiteFigure 6-2 shows the procedure for troubleshooting the hard handover failure.

Figure 6-2 Procedure for troubleshooting the hard handover failure



6-7





*1-3 Determine whether the problem occurs in thesetting of parameters.

Determine whether the problemoccurs in neighboring cellconfigurations and handoverparameter settings.

*1-4 Determine whether the transmission resourcesor CE resources are limited.

Determine whether the resourcesare limited.

*1-5 Determine whether the problem occurs in theUE.


*1-6 Determine whether the hard handover problemis solved.

Determine whether the hardhandover problem is solved.

*1-7 Collect fault location data and contact Huaweifor technical support.


Procedure


The handover problem can be located during its recurrence. The faults are detected through drivetests at the handover point and then detailed signaling records are made. Preliminary analysisshows that the faults occur in the process of hard handover.

Step 2 The faults related to radio coverage and hard handover consist of the following two types: Oneis that the handover cannot be performed if coverage holes exist; the other is that because thehandover area is too small, the RNC cannot receive the messages of physical channelreconfiguration during the inter-frequency hard handover.l Check the signal strength through the drive test devices of network planning at the handover

site. Check whether the RSCP is higher than –100 dBm and the Ec/Io is higher than –14 dB.If the signals are too weak, optimize the network to ensure the quality of signals.

l Contact network planning engineers to solve the problem in radio coverage.

Step 3 Determine whether the problem occurs in neighboring cell configurations and handoverparameter settings.

The parameters related to hard handover include neighboring cell parameters and hard handoverboolean.

l If the neighboring cell of the same frequency is not configured, the target cell cannot bemeasured when the UE is moving to the cell. If the signals in the original service area becomevery weak, the handover may cause call drops. Some neighboring cells are not configuredduring the network capacity expansion and adjustment. Check the cells of the handover areaby using drive test devices and run the LST INTERFREQNCELL command to checkwhether the neighboring cells are correctly configured.




Issue 01 (2008-05-30)

l Run the LST CORRMALGOSWITCH command to check whether the boolean for theinter-frequency hard handover, compressed mode and active set is open. If the boolean isopen, the hard handover can be performed.

l For inter-frequency hard handover, when the signals are of low quality, the UE sets up thecompressed mode on the network. The inter-frequency hard handover can be performed onlywhen the UE measures the inter-frequency cells. The RNC starts the compressed mode afterthe UE reports the 2D event. Therefore, the reporting of the 2D event cannot be too late incase that the signal quality of the cells becomes worse and the handover cannot be performed.The way to determine the problem is to check the signal changes of the cell by using drivetest devices after the 2D event alarms are reported.

l For inter-frequency hard handover, when the signals are of low quality, the UE sets up thecompressed mode on the network. The inter-frequency hard handover can be performed whenthe UE measures the inter-frequency cells. The hard handover process should be started ifrequired. If the target cell of the RNC requires high-quality signals, the hard handover cannotbe performed even if the cells are measured. When the signal quality of the target cell meetsthe requirement, that of the serving cell becomes worse and thus the handover still cannotbe performed.

l Solution: The problem is solved when you reset the parameters.

Step 4 Determine whether the resources are limited.l When hard handover is performed, two or more radio links are needed for a moment. The

requirement for the CE and AAL2 resources increases. If the resources are insufficient, newradio links cannot be set up and new cells cannot be added to the active set. Thus the signalquality of the serving cell becomes worse, which results in call drops.

l Check the load of the target cell when the problem occurs. For details about how to checkthe cell load, refer to the RNC Site Maintenance Guide.

l When resources are limited, you can only increase the resources through capacity expansionor adding transmission resources.


Some UEs cannot support the compressed mode and so the inter-frequency hard handover cannotbe performed. For example, some old version UEs do not support the inter-frequency hardhandover. You can only replace the UE and make a test again.

Step 6 Determine whether the hard handover problem is solved.


----End

6.5 Inter-System Handover FailureCall drops occur during the drive test or the inter-system handover is performed at a low successrate during the KPI analysis.

ContextNOTE

At present, the inter-system handover is mainly applied to the handover between the 3G and the 2G systems.Many factors, including the devices in these systems, affect the inter-system handover. This part describesthe diagnosis of problems in the RAN of the 3G system.



6-9

Figure 6-3 shows the procedure for troubleshooting the inter-system handover failure.

Figure 6-3 Procedure for troubleshooting the inter-system handover failure




Issue 01 (2008-05-30)



*1-2 Determine whether the problem occurs inthe RAN.

Determine whether the problemoccurs in the RAN.

*1-3 Determine whether the problem occurs inthe setting of parameters.

Determine whether the problemoccurs in the setting of parameters.

*1-4 Determine whether the resources of the 2Gsystem are limited.

Determine whether the resources ofthe 2G system are limited.



*1-6 Determine whether the problem occurs inthe UE.


*1-7 Determine whether the inter-systemhandover problem is solved.

Determine whether the inter-system handover problem is solved.



Procedure


The inter-system handover problem can be located during its recurrence. The faults are detectedthrough drive tests at the handover point and then detailed signaling records are made.Preliminary analysis shows that the faults occur in the process of inter-system handover.

Step 2 Determine whether the problem occurs in the RAN.

Many network elements are involved in inter-system handover. Check whether the faults occurin the RAN by tracing the signaling of single subscribers.

Step 3 Determine whether the problem occurs in the setting of parameters.

The parameters related to the inter-system handover include neighboring cell configurations andinter-system boolean.

l The 3G and the 2G systems are two different networks. Some neighboring cells are notconfigured during the capacity expansion of networks or the resetting of parameters. Theproblem frequently occurs in the network for commercial use. Generally, to solve theproblem, you can make drive tests in the cell where neighboring cells are not configured tomake the fault recur. Then check the information on the cells at the same site of both the 3Gand the 2G systems through drive test devices. Check whether the neighboring cells arecorrectly configured by running the LST GSMNCELL command on the RNC.

l The boolean is used to control the system handover and the compressed mode. Ensure thatthe boolean is open and then perform the inter-system handover. Run the LSTCORRMALGOSWITCH command to query the boolean status.



6-11

l For inter-system handover, when the signals are of low quality, the UE sets up the compressedmode. The inter-sysem handover can be performed only when the UE measures the inter-system neighboring cells. The RNC starts the compressed mode after the alarm on the 2Devent of the UE is reported . Therefore, the reporting of the 2D event cannot be too late incase that the signal quality of the cells becomes worse and the handover cannot be performed.The way to determine the problem is to check the signal changes of the cell by using drivetest devices after the 2D event alarms are reported.

l Parameter settings of inter-system handover include those of the access network. The CN ofthe 3G system also has information on the neighboring cells of the 2G system. Correct settingsensure that the handover is performed normally. If the handover fails, contact the CNmaintenance engineers to check the parameter settings of neighboring cells. To check theparameter settings of the CN, contact the CN engineers for technical support.

l The problem is solved when you reset the parameters.

Step 4 Determine whether the resources of the 2G system are limited.

When inter-system handover is performed, radio link resources are required. If the 2G systemhas much load and the resources are insufficient, new radio links cannot be set up and the inter-system handover cannot be performed.

l Check whether the resources of the 2G system are limited. The CN of the 3G system queriesthe CN of the 2G system. The received response is No resource.

l The problem is solved when you add more resources or more cells where a handover can beperformed.

Step 5 Determine whether the problem occurs in radio coverage.

The faults related to radio coverage and inter-system handover are mainly that the signals changequickly in the handover area. Generally the parameter settings of inter-system handover dependon those of the whole network. However, for some handover areas, for example, railways andhighways, specific adjustment of parameters or coverage improvement is required because theUE can move very fast. Changes of signal quality in the cells are measured by the drive testdevices after the alarm on the 2D event is reported. You can ask the network planning engineersfor evaluation.


Some UEs, usually the old version UEs of the 3G system, cannot support the inter-systemhandover. And most of the 3G UEs support the operation mode of manual setting. If the UE isset to the WCDMA-ONLY mode, the inter-system handover cannot be performed. The UEs ofvarious types have different settings. Most of the UEs are in the network setting list. To checkthe list, refer to the user guide of the UE. This problem is solved when you modify the operationmode of the UE or make a test on the UE that meets your requirements.

Step 7 Determine whether the inter-system handover problem is solved.


----End




Issue 01 (2008-05-30)

6.6 Signal Flow of a HandoverThe UE handover is classified into five types: intra-RNC soft handover, inter-RNC softhandover, inta-RNC hard handover, inter-RNC hard handover, and inter-system handover. Eachtype corresponds to a signal flow.

Signal Flow of an Intra-RNC Soft HandoverFigure 6-4 shows the signal flow of an intra-RNC soft handover.

Figure 6-4 Signal Flow of an Intra-RNC Soft Handover

In different scenarios, the intra-RNC soft handovers can be different. The above figure showsthe common process of adding a new tributary channel through a soft handover. The processmainly includes the following steps:



6-13

1. Establish radio links on a new NodeB.

2. Add a new tributary channel for the UE by sending the message Activeset Update.

3. When the message Activeset Update Complete for the UE is received, the whole processis complete.

Signal Flow of an Inter-RNC Soft Handover

Figure 6-4 shows the inter-RNC soft handover flow.

Figure 6-5 Signal Flow of an Inter-RNC Soft Handover

The signaling processing between the RNCs is added to the signal flow of the inter-RNC softhandover. The SRNC sends the signaling of establishing a radio link to the DRNC over the Iurinterface. Then the DRNC sets up a new radio link for the new NodeB. Other process is the sameas that of the inter-RNC soft handover flow.




Issue 01 (2008-05-30)

Signal Flow of an Intra-RNC Hard HandoverFigure 6-4 shows the intra-RNC hard handover flow.

Figure 6-6 Signal Flow of an Intra-RNC Hard Handover

In the case of intra-frequency handover or lack of resources, the hard handover flow is oftenperformed. Different from the soft handover flow, the intra-RNC hard handover flow connectsthe UE to a new radio link by running the Physical Channel Reconfiguration command. The oldradio link is deleted at the same time.

Signal Flow of an Inter-RNC Hard HandoverFigure 6-4 shows the inter-RNC hard handover flow.



6-15

Figure 6-7 Signal flow of an inter-RNC hard handover

The signaling processing between the RNCs is added to the signal flow of the inter-RNC hardhandover. The SRNC sends the signaling of establishing radio links to the DRNC over the Iurinterface. Then the DRNC sets up a new radio link for the new NodeB. Other process is the sameas that of the inter-RNC hard handover flow.

Signal Flow of an Inter-system HandoverFigure 6-4 shows the inter-system handover flow.




Issue 01 (2008-05-30)

Figure 6-8 Signal flow of an inter-system handover

The inter-system handover, which involves many 3G and 2G network elements, is relativelycomplicated. On the whole, the process is as follows:

1. Handover required by RNC (to CN)2. 3G-to-2G handover required (3G CN to 2G CN)3. Handover command (RNC to UE)4. Handover command (UE to 2G)5. Handover complete (2G CN to 3G CN)6. Original radio link release (3G CN to RNC).



6-17

7 Troubleshooting RAN Clocks

About This Chapter

This part describes the relationship between the clock fault causes and related alarms. It alsopresents cases for troubleshooting clock failures. The clock faults refer to the faults occurringin clock source and clock board.

7.1 Definitions of Clock ProblemsThe clock faults refer to the faults in clock source and clock board.

7.2 NodeB Clock Problems: Causes and Related AlarmsThe NodeB clock problems refer to the faults occurring in the NodeB clock source and clockboard. This part mainly describes the fault causes and related alarms.

7.3 RNC Clock Problems: Causes and Related AlarmsThe RNC clock problems refer to the faults occurring in the RNC clock source and clock board.This part mainly describes the fault causes and related alarms.

7.4 Signal Flow of a Clock SystemThe RAN clock system consists of two parts: the RNC clock system and the NodeB clock system.The RNC clock system can provide clock signals for the NodeB clock system through the Iubinterface. Either of the clock systems can extract clock signals from the GPS or the externalclock reference sources independently.

RANTroubleshooting Guide 7 Troubleshooting RAN Clocks


7-1

7.1 Definitions of Clock ProblemsThe clock faults refer to the faults in clock source and clock board.

7.2 NodeB Clock Problems: Causes and Related AlarmsThe NodeB clock problems refer to the faults occurring in the NodeB clock source and clockboard. This part mainly describes the fault causes and related alarms.

Table 7-1 NodeB clock fault causes and related alarms

Fault Cause Related Alarm

The clock source is lost due to the loss,variation or large offset of the clockreference source; or the errors in systemsettings.

ALM-1020 NodeB Clock Source Abnormal (formacro NodeB)ALM-1008 NodeB Clock Source Abnormal (forBBU)

ALM-1021 GPS Abnormal

The frequency of clock sourcecomponents drifts or the frequency isincorrect.

ALM-1020 NodeB Clock Source Abnormal (formacro NodeB)ALM-1008 NodeB Clock Source Abnormal (forBBU)

ALM-1038 NMPT Secondary PLL Out of Lock(only for macro NodeB)

The clock source components aredamaged. For example, the local clockis lost.

ALM-1032 NMPT-to-Board Clock Abnormal(only for macro NodeB)

ALM-1036 NMPT 10M Clock Abnormal (only formacro NodeB)

ALM-1008 Board Clock Abnormal (for macroNodeB)ALM-1007 Board Clock Abnormal (for BBU)

ALM-1037 NMPT 4x Clock Abnormal (only formacro NodeB)

7.3 RNC Clock Problems: Causes and Related AlarmsThe RNC clock problems refer to the faults occurring in the RNC clock source and clock board.This part mainly describes the fault causes and related alarms.

7 Troubleshooting RAN ClocksRAN



Issue 01 (2008-05-30)

Table 7-2 RNC V100R010 clock fault causes and related alarms


The board module is faulty; or theboard version is incorrect; or theboard is not securely inserted.

ALM-9030 Clock Source Unavailability

ALM-9036 PLL 88915 Faulty

ALM-9037 Crystal Oscillator Faulty

ALM-9031 PLL TRU050 Faulty

Table 7-3 RNC V200R010 clock fault causes and related alarms


The board module is faulty; or theboard version is incorrect; or theboard is not securely inserted.

ALM-232 The Clock Reference Of The GCU/GCGBoard Unusable Alarm

ALM-233 The Current Clock Reference SourceStatus Of The GCU/GCG Board Abnormal Alarm

ALM-234 The Current Clock Reference Source TheGCU/GCG Board 24-Hour Abnormal BeyondThreshold Alarm

ALM-235 The Clock Module Input Resource OfGCU/GCG Board Unusable Alarm

ALM-236 The GCU/GCG Clock Frequency DoublerAbnormal Alarm

ALM-237 The Local Oscillator Signal AbnormalAlarm

ALM-238 The Status Of Phase-Lock Loop Of GCU/GCG Board Changed Alarm

ALM-239 The Clock Reference Source Of GCU/GCG Board Changed Alarm

7.4 Signal Flow of a Clock SystemThe RAN clock system consists of two parts: the RNC clock system and the NodeB clock system.The RNC clock system can provide clock signals for the NodeB clock system through the Iubinterface. Either of the clock systems can extract clock signals from the GPS or the externalclock reference sources independently.

Signal Flow of the RNC Clock SystemThe RNC clock sources include the following:

l BITS clock



7-3

l Iu interface clock

l Satellite synchronization clock

l Local free-run clock

Take the RNC V200R010 as an example. Figure 7-1 shows the RNC clock structure.

Figure 7-1 RNC clock structure

NOTE

The RNC clock module is on the GCUa/GCGa board, as shown in Figure 7-1.

l The RNC can use the GPS timing signals shown in Figure 7-1 only when the RNC isconfigured with the GCGa board, because the GCGa board is configured with a GPS cardbut the GCUa board is not.

l If the RINT (AEUa, PEUa, POUa, AOUa, or UOIa) that extracts the line clock from theCN is located in the RSS subrack, the timing signals travel to the GCUa/GCGa board eitherthrough a backplane channel in the RSS subrack or through the 2 MHz timing signal outputport on the panel of the RINT. In the former case, the channel can be either line 0 channel




Issue 01 (2008-05-30)

or line 1 channel. In the latter case, a clock cable connects the RINT to the GCUa/GCGaboard.

l If the RINT that extracts the clock from the CN is located in an RBS subrack, the timingsignals travel to the GCUa/GCGa board only through the 2 MHz timing signal output porton the panel of the RINT. In this case, a clock cable connects the RINT to the GCUa/GCGaboard.

Signal Flow of the NodeB Clock SystemThe NodeB supports the following three clock synchronization modes:

l Iub interface clock

l GPS clock

l External reference clock

Take the BTS3812E/BTS3812AE as an example. The signal flows of the three modes aredescribed as follows:

Figure 7-2 Iub interface clock synchronization mode

The Iub interface clock is an optional clock synchronization mode, as shown in Figure 7-3.When the GPS clock is taken as the NodeB synchronization clock source, a GPS card must beconfigured in the NMPT board.



7-5

Figure 7-3 GPS clock synchronization mode

The NodeB can provide 2 MHz clock sources for clock synchronization through the externalreference clock as shown in Figure 7-4. The reference clock can be a BITS clock or a 2 MHzclock provided by the transmission equipment. The accuracy of the external reference clockshould be higher than 0.05 ppm as required.




Issue 01 (2008-05-30)

Figure 7-4 External reference clock synchronization mode

NOTE

In addition to the previously-mentioned three modes, the NodeB internal clock is set to the free-run modeto ensure the normal operation of the NodeB. The OCXO of high accuracy is applied to the NodeB as themain clock. The clock should be an enhanced clock with the time limit of 90 days to ensure the normaloperation of the NodeB.



7-7

8 Troubleshooting RAN Interface Links

About This Chapter

This part describes the fault causes and related alarms of the RAN interface links. It also presentsthe cases of troubleshooting interface links.

8.1 Definitions of Interface Link ProblemsThe interface link problems refer to the faults in the interface links between the RAN host systemand other devices, for example, the CN devices.

8.2 Interface Link Problems: Causes and Related AlarmsThis part describes the fault causes and related alarms of interface links for the NodeB and theRNC.

RANTroubleshooting Guide 8 Troubleshooting RAN Interface Links


8-1

8.1 Definitions of Interface Link ProblemsThe interface link problems refer to the faults in the interface links between the RAN host systemand other devices, for example, the CN devices.

8.2 Interface Link Problems: Causes and Related AlarmsThis part describes the fault causes and related alarms of interface links for the NodeB and theRNC.

ContextTable 8-1 shows the fault causes and related alarms of interface links for the NodeB.

Table 8-1 Fault causes and related alarms of interface links for the NodeB


The links are wronglyconnected. For example, thetransmit and receive links areconnected inversely.

ALM-2500 E1/T1 Loss of Signal

ALM-2501 E1/T1 Alarm Indication Signal

ALM-2502 E1/T1 Remote Alarm Indication

ALM-2513 E1/T1 Loopback

ALM-2602 Optical Port Loss of Signal

ALM-2604 Optical Port Multiplex Section AlarmIndication Signal

ALM-2605 Optical Port Line Remote Defect Indication

The transmission quality in thelinks is at a low level, or the linksare faulty, or the boards relatedto transmission are faulty.

ALM-2500 E1/T1 Loss of Signal

ALM-2501 E1/T1 Alarm Indication Signal

ALM-2502 E1/T1 Remote Alarm Indication

ALM-2503 E1/T1 Loss of Frame Alignment

ALM-2504 E1/T1 Loss of Multiframe Alignment

ALM-2505 Excessive E1/T1 Slip Frames

ALM-2507 E1/T1 Bit Error Rate Too High

ALM-2600 Optical Port Out Of Frame

ALM-2601 Optical Port Loss of Frame

ALM-2602 Optical Port Loss of Signal

8 Troubleshooting RAN Interface LinksRAN



Issue 01 (2008-05-30)


ALM-2603 Optical Port Administrative Unit Loss ofPointer

ALM-2604 Optical Port Line Alarm Indication Signal


ALM-2606 Optical Port Loss of Cell Delineation

The parameters are setincorrectly.

ALM-2503 E1/T1 Loss of Frame Alignment

ALM-2504 E1/T1 Loss of Multiframe Alignment


Table 8-2 shows the fault causes and related alarms of interface links for the RNC.

Table 8-2 Fault causes and related alarms of interface links for the RNC


The cables are wronglyconnected, or the modules aremismatched, or the hardware isfaulty.

Fault alarms of ports on interface board

Fault alarms of physical links

The parameters for linkinterconnection are wronglynegotiated, or theinterconnection parameters areinconsistent, or the parametersfor both ends are wronglyinterpreted.

ALM-1802 SAAL Link Unavailable

ALM-1413 MTP-3b Signalling Link Unavailable

ALM-1403 MTP-3b DSP Inaccessible

ALM-1711 Path Unavailable

ALM-1508 Remote SCCP Unavailable

ALM-1901 Path to SGSN Faulty

ALM-2602 PPP/MLPPP Link Down

ALM-1851 SCTP link down

ALM-2010 NCP Faulty

ALM-2011 CCP Faulty

ALM-2008 Common Channel Faulty

ALM-2006 Cell Unavailable

ALM-2026 NodeB Unavailable

RANTroubleshooting Guide 8 Troubleshooting RAN Interface Links


8-3

9 Troubleshooting RAN Radio FrequencyPerformance

About This Chapter

This part describes the fault causes and related alarms of RF performance. It also presents thecases of troubleshooting RF performance.

9.1 Definitions of RF ProblemsThe Radio Frequency (RF) problems refer to the faults in the RF system, including the antennaand feeder system, receive path, and transmit path.

9.2 NodeB RF Fault: Causes and Related AlarmsThe NodeB RF fault refers to the fault caused by the NodeB RF subsystem. This part mainlydescribes the fault causes and related alarms.

9.3 Signal Flow of the RAN RF SystemThis part describes the RAN RF system structure and the RF signal flow in the downlink andthe uplink.

RANTroubleshooting Guide 9 Troubleshooting RAN Radio Frequency Performance


9-1

9.1 Definitions of RF ProblemsThe Radio Frequency (RF) problems refer to the faults in the RF system, including the antennaand feeder system, receive path, and transmit path.

9.2 NodeB RF Fault: Causes and Related AlarmsThe NodeB RF fault refers to the fault caused by the NodeB RF subsystem. This part mainlydescribes the fault causes and related alarms.

Table 9-1 NodeB RF fault causes and related alarms


Antenna systemfaults

ALM-1107 TMA Fault

ALM-1150 Antenna VSWR Abnormal (only for macro NodeB)

ALM-1317 RRU VSWR Abnormal

Receive path faults ALM-1151 MAFU LNA FaultRRU LNA Fault (only for macroNodeB)

ALM-1318 RRU LNA Fault

ALM-1102 MTRU Rx Branch Abnormal

ALM-1308 RRU Rx Branch Abnormal

Transmit path faults ALM-1107 MTRU Tx Branch Switch off

ALM-1306 RRU Tx Gain Abnormal

ALM-1100 MTRU Tx Gain Abnormal

ALM-1313 RRU Tx Branch Switch Off

Antenna equipmentfaults

ALM-1319 RRU ALD Current Abnormal

ALM-2102 RET Hardware Abnormal

ALM-2103 RET Motor Abnormal

ALM-2104 RET Not Adjusted

ALM-2105 RET Data Loss

ALM-2106 RET Position Loss

ALM-1152 ALD Current Abnormal

Equipment or linkfaults

ALM-1101 MTRU DPD Failure

ALM-1106 MTRU Clock Abnormal

9 Troubleshooting RAN Radio Frequency PerformanceRAN



Issue 01 (2008-05-30)


ALM-1111 MTRU-to-MAFU Tx Link Abnormal (only for macroNodeB)

ALM-1113 MTRU Internal Hardware Abnormal (only for macroNodeB)

ALM-1153 MTRU-to-MAFU Control Link Abnormal (only formacro NodeB)

ALM-1307 RRU DPD Failure

Other factors ALM-1104 MTRU Over Current

ALM-1105 MTRU Over Temperature

ALM-1108 MTRU Input Power Too High

ALM-1310 RRU Over Current

ALM-1311 RRU Over Temperature

ALM-1314 RRU Input Power Too High

9.3 Signal Flow of the RAN RF SystemThis part describes the RAN RF system structure and the RF signal flow in the downlink andthe uplink.

Figure 9-1 shows the signal flow of the RAN RF system.

Figure 9-1 Signal flow of the RAN RF system

Downlink signal flow: After the RF modulation and power amplification, the baseband signalsare transmitted from the MTRU to the MAFU. The transmit filter in the MAFU module filtersout the out-band signals and then sends the other signals to the antenna.

Uplink signal flow: After being filtered by the receive filter and amplified by the Low NoiseAmplifier (LNA), the signals received by the antenna are transmitted from the MAFU to the

RANTroubleshooting Guide 9 Troubleshooting RAN Radio Frequency Performance


9-3

MTRU. When the signals go through the process of down-conversion and filtering, they aremodulated into baseband signals in the baseband modules.

For NodeB V200R010 the MTRU and MAFU are united to be WRFU.

NOTE

The Tower Mounted Amplifier (TMA) is an optional module. It filters downlink signals and provides afilter and an LNA for uplink signals.

9 Troubleshooting RAN Radio Frequency PerformanceRAN



Issue 01 (2008-05-30)

10 Collecting RAN Fault Location Data

About This Chapter

When the RAN devices are faulty and the field engineers cannot immediately locate or clear thefaults, collect the RAN fault location data and contact Huawei for technical support.

10.1 Collecting RNC Fault Location DataWhen the RNC is faulty and the field engineers cannot immediately locate or clear the faults,collect the RNC fault location data and contact Huawei for technical support.

10.2 Push-Button RNC Data Collection GuidelinesThe RNC LMT provides simple methods for collecting fault location data. You can collect theBAM and FAM fault location data easily by running the COL LOG command. The returnedmessages include the file path and file name for saving fault data.

10.3 Collecting NodeB Fault Location DataWhen the NodeB is faulty and the field engineers cannot immediately locate or clear the faults,collect the NodeB fault location data and contact Huawei for technical support.

RANTroubleshooting Guide 10 Collecting RAN Fault Location Data


10-1

10.1 Collecting RNC Fault Location DataWhen the RNC is faulty and the field engineers cannot immediately locate or clear the faults,collect the RNC fault location data and contact Huawei for technical support.

10.1.1 Collecting RNC Fault Location DataIn different scenarios, you need to combine different types of data to locate and clear the faults.

10.1.2 Collecting Error Logs from the RNC FAMError logs from the RNC FAM are the most important fault location data, including various errordata, failed message trace during the calling, and cell logs.

10.1.3 Collecting RNC Alarm DataThe past and present RNC alarm data are recorded on the LMT, which indicates the running orchanging status of the RNC.

10.1.4 Collecting Error Logs from a BAM ServerError logs from a BAM server include the event logs, SQL Server logs, and BAM module runninglogs.

10.1.5 Collecting Operation Logs from the RNC LMTThe operation logs from the RNC LMT record all the MML commands executed by users onthe LMT during a period of time. These logs serve as the main reference for checking parametermodifications and key actions such as reset and changeover order.

10.1.6 Collecting RNC Self-Diagnostic Output DataWhen a fault occurs, the fault inside the RNC may not be displayed on the LMT, which indicatesthat the internal part of the RNC is probably faulty. Before locating the fault, you need to checkthe statuses of the links and boards in the RNC.

10.1.7 Collecting Call Data Tracing MessagesWhen a user requires the detailed analysis of call flow fault causes, you can provide a typicalcall flow record of the user. The Call Data Tracing (CDT) is a comprehensive record for faultlocation.

10.1.8 Collecting Signaling Tracing Messages on Standard InterfacesSignaling tracing messages on standard interfaces include the tracing messages on the Iu, Iub,and Uu interfaces, or of a single user. These messages are collected to check whether the interfacemessages are correct when devices of different companies are interconnected.

10.1.9 Collecting RNC Configuration DataThe RNC configuration data are collected from a BAM server. BAM configuration data can beused as a reference for fault location.

10.1.1 Collecting RNC Fault Location DataIn different scenarios, you need to combine different types of data to locate and clear the faults.

Table 10-1 shows the RNC fault location data to be collected.

10 Collecting RAN Fault Location DataRAN



Issue 01 (2008-05-30)

Table 10-1 RNC fault location data

Scenario Fault Location Data

Faults occur in networkaccess, PS services, andhandover.

l RNC alarm data

l Signaling tracing messages on standard interfaces from theRNC LMT

l The CDR of a single subscriber on the test managementsystem

l RNC configuration data

l Operation logs from the RNC LMT

l UE types

In addition, the following data are allowed:l Error logs from the RNC FAM

l RNC self-diagnostic output data

Faults occur in PS services,such as abnormal PS rate,unreachable set rate, andserious rate variation.

l RNC alarm data


l Signaling tracing messages on standard interfaces from theRNC LMT

l The CDR of a single user on the test management system

l Performance tracing (such as throughput, BLER, andtransmit power)


l UE types

In addition, the following data are allowed:l RNC self-diagnostic output data

l Error logs from the RNC FAM

Faults in network access l RNC alarm data




l Call Detail Record

l Push-button NodeB logs and NodeB alarms

RNC board reset or boardfault or broken internal IPClink

l RNC alarm data


l The message returned by the command DSP RSTREASONfrom the LMT


Operation and maintenancefault

l RNC alarm data

l Error logs from a BAM server



10-3

10.1.2 Collecting Error Logs from the RNC FAMError logs from the RNC FAM are the most important fault location data, including various errordata, failed message trace during the calling, and cell logs.

Procedure

Step 1 Collecting text log files

The file path is \BAM\LoadData\FamLog. For RNC V200R010 the path is BAM\Common\Famlog\fmt as shown in Figure 10-1.

Figure 10-1 RNC FAM log file

File format: FNLOGyyyymmddhhmmss_yyyymmddhhmmss.log.zip

l FN: subrack number, 2 digits

l yyyy: year mm: month dd: day hh: hour mm: minute ss: second

For example, 00Log20080425064929_20080425090626.log.zip

Step 2 Collecting CHR data

NOTE

The Call History Record (CHR) in binary format requires specific tools for analysis.

The file path is \BAM\LoadData\FamLogFmt. For RNC V200R010 the path is BAM\Common\Famlog\txt as shown in Figure 10-2.




Issue 01 (2008-05-30)

Figure 10-2 CHR path and file name

File format: FNLOGyyyymmddhhmmss_yyyymmddhhmmss.log.zip

l FN: subrack number, 2 digits

l yyyy: year mm:month dd: day hh: hour mm: minute ss: second

The "zip" means the way to compress the file.

For example: 00Log20080425064929_20080425090626.log.zip

NOTE

When a fault occurs, you only need to collect the log files recording the fault-related time and subracknumber from the two directories.

----End

10.1.3 Collecting RNC Alarm DataThe past and present RNC alarm data are recorded on the LMT, which indicates the running orchanging status of the RNC.

PrerequisiteNOTE

The RNC alarm data are of two types: event alarms and fault alarms. Both types are required for the faultsthat are difficult to locate.

ProcedureOpen the Alarm Browse window and select the fault alarms. Right-click and select Save AllAlarms. Save them as .txt files.



10-5

Figure 10-3 RNC FAM log file

You can decide the directory and file name to save the files.

----End

10.1.4 Collecting Error Logs from a BAM ServerError logs from a BAM server include the event logs, SQL Server logs, and BAM module runninglogs.

Prerequisite

If a fault occurs in the BAM, you should collect BAM logs. Generally, in other cases, BAM logcollection is not required.

Procedure

To collect all the BAM fault location data, run the COL LOG command on the LMT.

The log file name and file path are displayed after you use this command.

The BAM fault data to be collected include module running logs, SQL Server logs, variousoperation logs and alarms, and user operation logs.

----End




Issue 01 (2008-05-30)

10.1.5 Collecting Operation Logs from the RNC LMTThe operation logs from the RNC LMT record all the MML commands executed by users onthe LMT during a period of time. These logs serve as the main reference for checking parametermodifications and key actions such as reset and changeover order.

Procedure

Run the EXP LOG command on the LMT. Save the generated file in \BAM\FTP, generally inD:\Bsc6800\BAM\FTP. For the RNC V200R010 the path is BAM main eara path\FTP.

The file is named as RNC-Y2008M01D09H13N01S52-Y2008M05D09H13N02S09-OLOG.txt. The number in the middle represents the time when the file is named, that is , from2008-01-09-13:01:52 to 2008-05-09-13:02:09.

----End

10.1.6 Collecting RNC Self-Diagnostic Output DataWhen a fault occurs, the fault inside the RNC may not be displayed on the LMT, which indicatesthat the internal part of the RNC is probably faulty. Before locating the fault, you need to checkthe statuses of the links and boards in the RNC.

Procedure

Step 1 Select a self-diagnostic subrack by running the TST SYS command on the LMT.

Figure 10-4 Self-diagnoses

Step 2 After the command is used, the system can automatically detect the fault in the devices orsignaling links of the transport layer.

The self-diagnostic functions include diagnoses of the following:

l Boards and subsystem statuses

l Board self-diagnostic result

l Board clock status



10-7

l Temperature of the WMUX or WMUXb or WFMR board

l Transport links within a WRBS subrack or between the WRBS subracks

l Transport links between the WRBS and WRSS subracks

l DSP, HPI, and TDM of the WFMR

l RFN status

l Internal PVC configuration

For the RNC V200R010 the self-diagnostic of RBS subrack include diagnoses of the following:l Boards and subsystem statuses


l Board clock status

l Temperature of the SCU or DPU board

l Transport links within a RBS subrack or between the RBS subracks

l Transport links between the RBS and RSS subracks

l DSP, HPI, and TDM of the DPU

l RFN status

l Internal PVC configuration

For the RNC V200R010 the self-diagnostic of RSS subrack inculde diagnoses of the following:l Boards statuses


l CPU usage

l Memory usage

l Queue usage

Step 3 In a period of time, the self-diagnostic result is reported in a .txt file and saved in the BAM underthe \BAM\LoadData\WRBSFad, generally in D:\Bsc6800\BAM\LoadData\WRBSFad.l WRBS self-diagnostic file: WRBS17FadResult2005-0907-17-37.txt

l WRSS self-diagnostic file: WRSS02FADRESULT2005-0907-16-26.txt

For the RNC V200R0010 the self-diagnostic result is reported and saved in \LOADDATA\FAD on the BAM server, as shown in Figure 10-5. The self-diagnostic result file is namedaccording to the following rule: Subrack No. + FADRESULT + yyyy/mm/dd/hh/mm/ss.




Issue 01 (2008-05-30)

Figure 10-5 Self-diagnostic file path

----End

10.1.7 Collecting Call Data Tracing MessagesWhen a user requires the detailed analysis of call flow fault causes, you can provide a typicalcall flow record of the user. The Call Data Tracing (CDT) is a comprehensive record for faultlocation.

Procedure

Step 1 Start the LMT and click the Maintenance tab in the left pane. Select CDT, as shown in Figure10-6.



10-9

Figure 10-6 CDT tracing

Step 2 When the CDT tracing window is displayed, enter the IMSI number in the IMSI box. ClickOK, as shown Figure 10-7.




Issue 01 (2008-05-30)

Figure 10-7 Setting the CDT tracing

Step 3 Click OK to start the CDT tracing.

Step 4 If the tracing is started successfully, call the UE to obtain the call detail message.

After the tracing, the message can be automatically saved as a file on the LMT under a constantdirectory as shown in Figure 10-8.



10-11

Figure 10-8 CDT tracing message file

CAUTIONThe CDT file cannot be saved manually, because the system automatically saves the file. Youwill obtain incomplete messages through manual saving. Therefore, it is recommended to usethe file that is automatically saved by the system.

----End

10.1.8 Collecting Signaling Tracing Messages on StandardInterfaces

Signaling tracing messages on standard interfaces include the tracing messages on the Iu, Iub,and Uu interfaces, or of a single user. These messages are collected to check whether the interfacemessages are correct when devices of different companies are interconnected.

Procedure

Step 1 Trace the messages on standard interfaces on the LMT. Select the Maintenance tab in thewindow on the LMT.

Step 2 Click Trace Management, as shown in Figure 10-9.




Issue 01 (2008-05-30)

Figure 10-9 Trace management

Step 3 Double-click an interface tracing message. The tracing message dialog box is displayed.

For example, if you double-click Iu interface tracing, the Iu interface tracing dialog box isdisplayed, as shown in Figure 10-10.



10-13

Figure 10-10 Iu interface tracing

The upper part of the dialog box shows the tracing destination point and the RNC WSPUsubsystem. The messages to be traced are in the lower part and usually they are all selected. Youcan select the options in the dialog box as required. For details about how to trace messages,press F1 for help.

Step 4 Save the messages in the file under the LMT installation directory, as shown in Figure 10-11.




Issue 01 (2008-05-30)

Figure 10-11 File path for tracing messages on standard interfaces

NOTE

The UE tracing on standard interfaces should not be performed concurrently with the CDR tracing on thetest management system. For a single user, the system provides tracing of messages on one interface only.

----End

10.1.9 Collecting RNC Configuration DataThe RNC configuration data are collected from a BAM server. BAM configuration data can beused as a reference for fault location.

Context

The configuration script exported by the MML command is under the \BAM\FTP, generally inD:\Bsc6800\BAM\FTP. For RNC V200R010 the path is BAM main area path\FTP.

The file name is specified when the MML command is executed. If the file name is not specified,the system provides the following file name format by default: CFGMML-YYYYMMDDHHMMSS.txt. For example, if a file name is CFGMML-20050819121344.txt,it represents the time when the file is named.

Procedure

Export all the BAM configuration data by running the EXP CFGMML command on the LMTof the RNC.

----End



10-15

10.2 Push-Button RNC Data Collection GuidelinesThe RNC LMT provides simple methods for collecting fault location data. You can collect theBAM and FAM fault location data easily by running the COL LOG command. The returnedmessages include the file path and file name for saving fault data.

ProcedureCollect fault location data by running the COL LOG command on the LMT. The result is shownin Figure 10-12.

Figure 10-12 COL LOG parameters




Issue 01 (2008-05-30)

NOTE

For the TYPE box:

l If you select BAM, only BAM-related data are collected, including running logs of all BAM modules,event logs and SQL Sever logs of the BAM operating system, subscriber operation logs on the LMT,and alarm data.

l If you select HOST, besides error logs from the RNC FAM, the subscriber execution logs of MMLcommands, alarm data, and self-diagnostic output data are collected.

l If you select ALL, both BAM and HOST logs are collected.

----End

10.3 Collecting NodeB Fault Location DataWhen the NodeB is faulty and the field engineers cannot immediately locate or clear the faults,collect the NodeB fault location data and contact Huawei for technical support.

10.3.1 Collecting NodeB NMPT LogsWhen a fault occurs in the NodeB, collect NodeB NMPT logs. You can save and check theselogs when they are uploaded to the FTP server.

10.3.2 Collecting NodeB Board LogsWhen a fault occurs in a board, the data related to the faulty board need to be collected in additionto the NodeB NMPT logs. You can save and check these data when they are uploaded to theFTP server.

10.3.3 Collecting Signaling Tracing Messages on the Iub InterfaceWhen handling service-related faults in access, call drop or cell setup, you need to collect thereturned Iub messages for fault location and analysis.

10.3.4 Collecting CHR dataWhen handling service-related faults in access, call drop or cell setup, you need to collect thereturned NodeB CHR data for fault location and analysis.

10.3.1 Collecting NodeB NMPT LogsWhen a fault occurs in the NodeB, collect NodeB NMPT logs. You can save and check theselogs when they are uploaded to the FTP server.

Procedure

Step 1 Log in to the NodeB on the LMT to collect data.

Step 2 Select Maintenance in the left pane. Then choose Service > Software Management > OtherFile Transfer , as shown in Figure 10-13.



10-17

Figure 10-13 NMPT log file transfer

Step 3 Double-click Other File Transfer. The dialog box is displayed as shown in Figure 10-14.




Issue 01 (2008-05-30)

Figure 10-14 NMPT log file

l Select Main Board Log Files in the File Description box.

l Enter the file name of an existing file on the LMT host into the Destination File orDirectory box to save the uploaded log file, or click Browse… to select a file.

l Select Upload mode. Compressed Mode is optional. If the compressed mode is selected,the compressed upload file can reduce the actual volume of transmission data.

l Then click Start.

Step 4 When the upload is complete, click Close to close the window.

----End

10.3.2 Collecting NodeB Board LogsWhen a fault occurs in a board, the data related to the faulty board need to be collected in additionto the NodeB NMPT logs. You can save and check these data when they are uploaded to theFTP server.



10-19

Context

CAUTIONIf an alarm of the link in the associated faulty board is reported, that is, a fault occurs in the linkbetween the faulty board and the NMPT, board logs cannot be collected from the LMT.

Procedure


Step 2 Select Maintenance in the left pane. Then choose Service > Software Management > OtherFile Transfer .

Step 3 Double-click Other File Transfer. The dialog box is displayed as shown in Figure 10-15.

Figure 10-15 Board log file transfer

l Select Board Log Files in the File Description box.

l Enter the board-related parameters in Cabinet No., Subrack No., and Slot No..




Issue 01 (2008-05-30)

l Enter the file name of an existing file on the LMT host into the Destination File orDirectory box to save the uploaded log file, or click Browse… to select a file.

l Select Upload mode. Compressed Mode is optional. If the compressed mode is selected,the compressed upload file can reduce the actual volume of transmission data.

l Then click Start.

Step 4 When the upload is complete, click Close to close the window.

----End

10.3.3 Collecting Signaling Tracing Messages on the Iub InterfaceWhen handling service-related faults in access, call drop or cell setup, you need to collect thereturned Iub messages for fault location and analysis.

Procedure


Step 2 Select Maintenance in the left pane. Then choose Service > Trace Management > InterfaceTrace Task > Standard Signaling Interface.

Step 3 Start signaling tracing on standard interfaces as shown in Figure 10-16,

Figure 10-16 NodeB signaling tracing messages on the Iub interface

Step 4 Double-click Standard Signaling Interface Tracing. The check box is displayed as shown inFigure 10-17.



10-21

Figure 10-17 Standard signaling interface tracing

Step 5 Select the associated items to trace the signaling optionally.

Step 6 Select Autosave to automatically save the tracing result in a specified file.

----End

10.3.4 Collecting CHR dataWhen handling service-related faults in access, call drop or cell setup, you need to collect thereturned NodeB CHR data for fault location and analysis.

PrerequisiteThe directory "d:\CHRDATA\" is already created.

Procedure

Run the command SET CHRSW to set the CHR Switch to ON.Then NodeB will report CHR data to CHR local server. When the fault occurs, the CHR dataneed to be collected for 30 minutes and send back.

----End




Issue 01 (2008-05-30)

ExampleSET CHRSW: CHRSW=ON, IP="10.161.215.239", DSTF="d:\CHRDATA\", USR="admin", PWD="*****";

Figure 10-18 shows the setting of this switch.

Figure 10-18 Setting CHR Switch

NOTE

l Make sure the Ftp Server IP, User Name, and Password are correct.



10-23

Documents

RAN Troubleshooting Guide(RAN10.0_01)