RAN Troubleshooting Guide: Huawei Technologies Co., LTD

RAN Troubleshooting Guide
Issue
01
Date
2011-08-11
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

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

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 01 (2011-08-11)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd
About This Document
About This Document

Change History
This chapter describes the changes in the RAN Troubleshooting Guide.
01 (2011-08-11)
This is the first commercial release of RAN12.0.
Issue 01 (2011-08-11)

ii
Contents
Contents
About This Document .................................................................................................................... ii
1 Overview......................................................................................................................................1-1
1.1 Purpose .......................................................................................................................................................... 1-1
1.2 Intended Audience ......................................................................................................................................... 1-1
1.3 Organization .................................................................................................................................................. 1-1
1.4 Reference Documents ................................................................................................................................... 1-1
2 Troubleshooting Process and Methods .................................................................................2-1

2.1 About This Chapter ....................................................................................................................................... 2-1
2.2 Troubleshooting Process ............................................................................................................................... 2-1
2.2.1 Collecting and Recording Fault Information ....................................................................................... 2-3
2.2.2 Determining Fault Scope and Type ...................................................................................................... 2-3
2.2.3 Locating Fault Cause ........................................................................................................................... 2-3
2.2.4 Troubleshooting ................................................................................................................................... 2-4
2.2.5 Ensuring that System Is Repaired ........................................................................................................ 2-4
2.2.6 Recording the Troubleshooting Process ............................................................................................... 2-4
2.2.7 Contacting Huawei for Technical Support ........................................................................................... 2-4
2.2.8 Troubleshooting Emergency Faults...................................................................................................... 2-4
2.3 Common Methods of Locating Faults ........................................................................................................... 2-6
2.3.1 Original Information ............................................................................................................................ 2-6
2.3.2 Analyzing Alarms................................................................................................................................. 2-6
2.3.3 LED Status ........................................................................................................................................... 2-7
2.3.4 User Tracing ......................................................................................................................................... 2-7
2.3.5 Interface Tracing .................................................................................................................................. 2-8
2.3.6 Traffic Statistics ................................................................................................................................... 2-8
2.3.7 Comparison and Interchange ............................................................................................................... 2-8
2.3.8 Upgrade and Rollback .......................................................................................................................... 2-9
2.4 Collecting Fault Information ......................................................................................................................... 2-9
2.4.1 Information Required for Technical Support ....................................................................................... 2-9
3 Guide to Collecting Fault Information ..................................................................................3-1

3.1 About This Chapter ....................................................................................................................................... 3-1
3.2 Classification of Information for Fault Location ........................................................................................... 3-1
3.2.1 Classification of the RNC Fault Information ....................................................................................... 3-1
Issue 01 (2011-08-11)

iii
Contents
3.2.2 Classification of the NodeB Fault Information .................................................................................... 3-1

3.3 Information for the RNC Fault Location ....................................................................................................... 3-2
3.3.1 MySQL Database ................................................................................................................................. 3-2
3.3.2 OMU Logs ........................................................................................................................................... 3-2
3.3.3 Alarm Logs .......................................................................................................................................... 3-2
3.3.4 Operation Logs from a Maintenance Console...................................................................................... 3-2
3.3.5 Host Logs ............................................................................................................................................. 3-2
3.3.6 Traffic Statistics ................................................................................................................................... 3-2
3.3.7 CDT of a Single Subscriber ................................................................................................................. 3-2
3.3.8 Signaling Tracing Messages on Interfaces ........................................................................................... 3-3
3.4 Guide to Collecting the RNC Fault Information ........................................................................................... 3-3
3.4.1 Backing Up the Database ..................................................................................................................... 3-3
3.4.2 Collecting OMU Logs.......................................................................................................................... 3-4
3.4.3 Collecting Alarm Logs ......................................................................................................................... 3-5
3.4.4 Collecting Operation Logs from a Maintenance Console .................................................................... 3-5
3.4.5 Collecting Host Logs ........................................................................................................................... 3-6
3.4.6 Collecting Traffic Statistics .................................................................................................................. 3-6
3.4.7 Collecting CDT Messages of a Single Subscriber ............................................................................... 3-6
3.4.8 Collecting Signaling Tracing Messages on Interfaces ......................................................................... 3-9
3.4.9 Downloading the Collected Log Files.................................................................................................. 3-9
3.5 Information for the NodeB Fault Location .................................................................................................... 3-9
3.5.1 NodeB CDT Logs ................................................................................................................................ 3-9
3.5.2 NodeB CHR Logs ................................................................................................................................ 3-9
3.5.3 NodeB Main Board and Board Logs .................................................................................................. 3-10
3.5.4 Running the Python Script on the NodeB LMT ................................................................................. 3-10
3.5.5 Real-time LMT Tracing ..................................................................................................................... 3-10
3.5.6 Collecting the NodeB Fault Information on the M2000 .................................................................... 3-10
3.6 Guide to Collecting the NodeB Fault Information ...................................................................................... 3-10
3.6.1 Collecting NodeB CDT Logs ............................................................................................................. 3-10
3.6.2 Collecting NodeB CHR Logs ............................................................................................................ 3-14
3.6.3 Collecting NodeB Main Board and Board Logs ................................................................................ 3-15
3.6.4 Running the Python Script on the NodeB LMT ................................................................................. 3-16
3.6.5 Real-time LMT Tracing ..................................................................................................................... 3-18
3.6.6 Managing the NodeB on the M2000 .................................................................................................. 3-19
4 RNC Troubleshooting ...............................................................................................................4-1

4.1 Cell Setup Failure .......................................................................................................................................... 4-1
4.1.1 Description ........................................................................................................................................... 4-1
4.1.2 Possible Causes .................................................................................................................................... 4-1
4.1.3 Troubleshooting Methods .................................................................................................................... 4-1
4.1.4 Troubleshooting Procedure .................................................................................................................. 4-1
4.2 Service Setup Failure .................................................................................................................................... 4-5
Issue 01 (2011-08-11)

iv
Contents
4.2.1 Description ........................................................................................................................................... 4-5

4.2.2 Possible Causes .................................................................................................................................... 4-5
5 NodeB Troubleshooting ...........................................................................................................5-1

5.1 RTWP Abnormality ....................................................................................................................................... 5-1
5.1.1 Description ........................................................................................................................................... 5-1
5.1.2 Possible Causes .................................................................................................................................... 5-1
5.2 Delivery Failure in NodeB Licenses by the M2000 ...................................................................................... 5-5
5.2.1 Description ........................................................................................................................................... 5-5
5.2.2 Possible Causes .................................................................................................................................... 5-5
6 Troubleshooting Transmission Faults ...................................................................................6-1

6.1 IP QoS-related Problems ............................................................................................................................... 6-1
6.1.1 Interrupted IP Transmission on an FE Port .......................................................................................... 6-1
6.1.2 IP Packets Lost ..................................................................................................................................... 6-3
6.1.3 Verification Methods ............................................................................................................................ 6-5
6.2 ATM QoS-related Problems ........................................................................................................................ 6-14
6.2.1 Interrupted ATM Transmission .......................................................................................................... 6-14
6.2.2 ATM Cells Lost .................................................................................................................................. 6-19
6.2.3 Verification Methods .......................................................................................................................... 6-24
7 Acronyms and Abbreviations ..................................................................................................7-1
Issue 01 (2011-08-11)

1 Overview
Overview
1.1 Purpose
This document provides information on how to identify and repair common faults on RAN
devices that are working in a live network. Operation and maintenance (OM) personnel
should use this guide in the following scenarios:
z
User complaints are received.
Faults are detected in the routine maintenance processes.
Emergency faults are detected in the equipment.
1.2 Intended Audience

This guide is intended for system engineers and OM personnel.
1.3 Organization
This guide consists of the following chapters:
z
Chapter 1 Overview
Chapter 2 Troubleshooting Process and Methods
Chapter 3 Guide to Collecting Fault Information
Chapter 4 RNC Troubleshooting
Chapter 5 NodeB Troubleshooting
Chapter 6 Troubleshooting Transmission Faults
1.4 Reference Documents

The references to this guide are as follows:
z
BSC6900 UMTS OMU Administration Guide
LMT online help
Issue 01 (2011-08-11)

1-1
2 Troubleshooting Process and Methods
Troubleshooting Process and Methods
2.1 About This Chapter

This chapter describes the process for troubleshooting, common methods of fault location,
and how to get technical support from Huawei.
2.2 Troubleshooting Process

The troubleshooting process is shown in Figure 2-1.
Issue 01 (2011-08-11)

2-1
Figure 2-1 Process for troubleshooting
Issue 01 (2011-08-11)

2-2
2.2.1 Collecting and Recording Fault Information

Fault Information to Be Collected
When a fault occurs, OM personnel must start troubleshooting by obtaining fault information,
which serves as a reference. OM personnel should collect as much fault information as
possible. Collect the following information before any operation:
z
Symptoms, including details and basic data
Time, location, and frequency of occurrence
Scope and impact
Equipment running status before the fault occurred
Operations performed on the equipment before the fault occurred, and the results of these
operations
Measures taken to deal with the fault, and the results
Alarms resulting from the fault
Status of board LEDs
Methods of Collecting Fault Information

To collect fault data, do as follows:
z
Consult the personnel who reported the fault about symptoms, time, location, and
frequency of the fault.
Consult the OM personnel about the equipment running status before the fault occurred,
operations performed on the equipment before the fault occurred, fault symptoms, and
measures taken to deal with the fault and the results.
Observe board LEDs, the OM subsystem, and the alarm management system to obtain
information about the status of system software and hardware.
Estimate the impact of the fault by testing services, measuring performance, and tracing
interface messages or signaling messages.
Strategies for Collecting Fault Information

Strategies for collecting fault information are as follows:
z
Do not handle a fault hastily. Collect as much information as possible before attempting
to repair the fault.
Maintain good communication with other departments and OM personnel of other sites.
Ask them for technical support if necessary.
2.2.2 Determining Fault Scope and Type

After collecting all available fault information, analyze the fault symptoms, and determine the
fault scope and type.
2.2.3 Locating Fault Cause

To locate the cause of the fault, first compare and analyze possible causes, and then eliminate
causes that are unlikely or impossible.
Issue 01 (2011-08-11)

2-3
2.2.4 Troubleshooting
To repair faults and restore the system, troubleshoot different faults using proper measures
and procedures. Troubleshooting consists of checking cables, replacing boards, modifying
data configuration, switching over boards, and resetting boards.
2.2.5 Ensuring that System Is Repaired

Test the system again after troubleshooting to ensure that the fault is repaired. Ensure the
system works properly by observing the status of board LEDs and alarm information, and
perform dial tests to ensure that all services are operational.
2.2.6 Recording the Troubleshooting Process

It is important to record the troubleshooting process in a way that OM personnel can use in
the future. When the troubleshooting/repair action is complete, OM personnel should:
z
Review the entire troubleshooting process
Note key points of the process
Summarize methods for improvement of the system which could avoid recurrence of the
faults of the same type.
Ensure notes are recorded in a logbook or other method that OM personnel will have future access to.
2.2.7 Contacting Huawei for Technical Support

Use the following methods to contact Huawei for technical support, if needed.
z
Telephone: (86) (755) 28560000 [Shenzhen, China] or 400-830-2118
Fax: (86) (755) 28560111
E-mail: support@huawei.com
Website: http://support.huawei.com
http://support.huawei.com contains contact information for the local office in your region.
2.2.8 Troubleshooting Emergency Faults

Issues regarding user access and key performance indicators (KPI) are two types of
emergency problems that may exist in a live network.
When the following emergency situations occur, follow the process for troubleshooting
emergency faults.
z
Call quality and access for many users in a live network are affected.
KPIs, such as call drop rate and access success rate, deteriorate so much that the call
quality and access for many users in a live network are seriously affected.
The KPI Exceed Threshold alarm (ID: 22302) is generated, and the performance
statistics are such that emergency measures must be taken.
The services in one subsystem, one subrack, or the entire radio network controller (RNC)
are affected.
All the services in one interface board are affected, or one digital signal processor (DSP)
is faulty.
Issue 01 (2011-08-11)

2-4
NOTE
If the services in one NodeB are affected, it is not an emergency fault.
Process for Troubleshooting Emergency Faults

The process for troubleshooting emergency faults is shown in Figure 2-2.
Figure 2-2 Flow chart for troubleshooting emergency faults
Process Description
When emergency situations occur, follow these three steps:
1. Check associated alarms and operation logs.
Check associated alarms to identify, isolate, and roll back the services rapidly and efficiently.
Issue 01 (2011-08-11)

2-5
Analyze operations logs to determine the following:

z
Emergency faults could have been caused by operator error.
If errors (for example incorrect settings) were introduced into the core network (CN),
neighboring RNCs (NRNCs), or transmission devices.
If modification of any RNC, CN, or NRNC parameters has been made. If this has been
done, then restore the preceding parameters, and check if services are restored.
2. Determine the impact and scope of the faults, and try to recover the network.
3. Check if network services are fully restored.
---End
2.3 Common Methods of Locating Faults

2.3.1 Original Information
Description
Original information includes the following data: user fault reports, fault reports from other
sites, abnormalities detected in the maintenance process, and information collected by OM
personnel at the beginning of the fault occurrence.
Application Scenarios
Original information provides an important reference for determining the scope and type of
the faults. In the initial phase of troubleshooting, original information provides a reference for
determining the fault scope and determining possible locations of the faults. Senior OM
personnel are able to locate faults using original information.
Instructions
Original information can be applied to troubleshooting both network element faults and other
faults such as E1T1 faults. In the trunk troubleshooting process, you must connect to the
transport system and map the signaling. Therefore, original information such as whether the
transport system works properly, whether the peer end parameters are modified, and the
definitions of some signaling parameters is vital to the troubleshooting and repair of the faults.
2.3.2 Analyzing Alarms

Description
Reported alarms are important indications to use when locating and repairing faults. When a
fault occurs in the system, associated alarms are displayed on the alarm management system.
For each alarm, detailed troubleshooting methods are provided, which OM personnel should
use.
OM personnel can immediately obtain the reported alarms through phone calls or short
messages by setting related parameters. The alarm box can be set to give audible and visible
indications when certain faults occur.
Issue 01 (2011-08-11)

2-6
Alarms can help in handling equipment faults and service faults.
Instructions
See the local maintenance terminal (LMT) online help for instructions on the alarm system.
See the related online help in the alarm management system for detailed troubleshooting
methods of each alarm.
2.3.3 LED Status

Description
LEDs indicate the status of boards, circuits, links, and nodes. LEDs provide an important
reference for analyzing and locating faults.
LED status is used to locate the general area of the fault. LEDs can indicate a specific fault or
can be used to locate other faulty equipment. All information gathered from LEDs can be used
to facilitate later operations. After observing the LED status of a board, circuit, link, or node,
check any associated alarms.
Instructions
For details about the board LED status, see the related online help section in the related
hardware description.
2.3.4 User Tracing

Description
User tracing, based on one IMSI, can trace and display standard interface messages, internal
interface messages, and internal status information in a chronological order on the OM
monitor.
User tracing has the following benefits:
z
Real-time tracing results
Able to trace all the standard interfaces
Can be used during high traffic
Applicable to various scenarios for analyzing the call procedure and for tracing VIP
users
User tracing can locate recurring faults in call services.
Instructions
For instructions on user tracing, see the OM online help.
Issue 01 (2011-08-11)

2-7
2.3.5 Interface Tracing

Description
Interface tracing can trace and display all the information over one standard or internal
interface, in a chronological order on the monitor.
Interface tracing has the following benefits:
z
Real-time tracing results
Traces all messages over the interface for a specific period of time
Tracing of messages can be used for link management
Interface tracing can locate faults in calls, for example, low put-through rate of calls in a
commercial network.
Instructions
For instructions on interface tracing, see the LMT online help.
2.3.6 Traffic Statistics

Description
Traffic statistics are used to collect real-time statistics from various problems such as call
drops, handover failures, and low put-through rates.
Traffic statistics are applied to KPI analysis and performance analysis.
Instructions
Traffic statistics can be obtained through the M2000 or Nastar.
2.3.7 Comparison and Interchange

Description
OM personnel can compare the faulty components or symptoms with their normal equivalents
to locate faults. Comparison is applied in simple scenarios.
If the fault scope and area cannot be determined after the replacement of some components
with spare parts, then interchange a component that is suspected of being faulty with known
good components that are being used in the system. For example, replace a board or optical
cable that is suspected faulted with an equivalent item that is known to be good. Then
compare the status before and after the operation to determine if the fault was repaired or to
further determine the scope and area of the fault. Interchange is applied in complex scenarios.
Issue 01 (2011-08-11)

2-8
Comparison and interchange are used when faults occur after NE hardware, software or a new
feature is introduced that may have caused a service outage.
Instructions
Use this method to compare the performances and KPIs before and after hardware or software
is changed, or a new feature is introduced.
2.3.8 Upgrade and Rollback

Description
If the running version of an NE is outdated and has bugs fixed in later versions, upgrade the
NE to a later version.
If KPIs deteriorate or services are interrupted after the upgrade, contact Huawei technical
support to check whether a version rollback needs to be performed.
An upgrade is recommended when the current version has bugs that are fixed in later versions.
A rollback is required when the updated version causes KPIs to deteriorate or services to be
interrupted.
Instructions
For details, see the relevant upgrade guide.
2.4 Collecting Fault Information

2.4.1 Information Required for Technical Support
If faults are difficult to identify or solve, then prepare the following information, and contact
Huawei for technical support.
Collecting General Fault Information

The general information required is as follows:
z
Full name of the office
Contact name and number
Time when the fault occurred
Detailed symptoms of the fault
Version of the host software
Measures taken to deal with the fault, and the results
Severity and expected repair time
Issue 01 (2011-08-11)

2-9
Collecting Fault Location Information

For details on collecting fault information, see Chapter 3 "Guide to Collecting Fault
Information."
Issue 01 (2011-08-11)

2-10
3 Guide to Collecting Fault Information
Guide to Collecting Fault Information
3.1 About This Chapter

If you encounter faults in the RAN devices that cannot be located and corrected onsite,
contact Huawei for technical support. For ease of locating the faults by technical support
personnel, collect as much information as possible. This chapter describes how to collect
comprehensive information for fault location and present it to the technical support center.
3.2 Classification of Information for Fault Location

3.2.1 Classification of the RNC Fault Information
When an RNC is faulty, collect the following information:
z
Database information
OMU logs
Alarm logs
Operation logs from a maintenance console
Host logs
Traffic statistics
CDR of a single subscriber
Signaling tracing messages on standard interfaces
3.2.2 Classification of the NodeB Fault Information

When a NodeB is faulty, collect the following information:
z
NodeB call detail trace (CDT) logs
NodeB call history record (CHR) logs
NodeB main board and board logs
Data after running the Python script on the NodeB LMT
Real-time LMT tracing
NodeB fault information on the M2000
Issue 01 (2011-08-11)

3-1
3.3 Information for the RNC Fault Location

3.3.1 MySQL Database
The MySQL database is used to locate faults in the OMU database. In addition, you can roll
back the OMU services by restoring the database with a database backup file. See section
3.4.1 "Backing Up the Database" for procedures to back up the database.
3.3.2 OMU Logs

OMU logs consist of event logs on the OMU recorded by the operating system, logs recorded
by the MySQL database, and operation logs of each OMU module. See section 3.4.2
"Collecting OMU Logs" for procedures to collect OMU logs.
3.3.3 Alarm Logs

Current alarm logs show the status of the RNC. Comparison between the history and current
alarm logs can reveal changes in the RNC status. The alarms are classified into fault alarms
and event alarms. Obtain both types of alarm information for a fault that is difficult to locate.
See section 3.4.3 "Collecting Alarm Logs" for procedures to collect alarm logs.
3.3.4 Operation Logs from a Maintenance Console

Operation logs record all the MML commands executed on a maintenance console during a
certain period of time. Analyze operation logs for parameter modification and other key
operations such as reset and switchover that may be causing faults in the network. See section
3.4.4 "Collecting Operation Logs from a Maintenance Console" for procedures to collect
operation logs from a maintenance console.
3.3.5 Host Logs

Error logs provide useful information for locating FAM host faults. Host error logs provide
the following key information for fault location:
z
Various error information and running trace of the front administration module (FAM)
host
Reset record of the host boards or the DSPs
Trace of failed calls
See section 3.4.5 "Collecting Host Logs" for procedures to collect host logs.
3.3.6 Traffic Statistics

Traffic statistics are gathered mainly by recording counter values on the RNC. The traffic
statistics are the basis for solving faults related to network KPIs. Analyze traffic statistics to
detect KPI changes and locate the causes for KPI degradation. See section 3.4.6 "Collecting
Traffic Statistics" for procedures to collect traffic statistics.
3.3.7 CDT of a Single Subscriber

To analyze the causes for failed call flows in detail, OM personnel need records of a typical
call flow. The CDT facilitates fault location by providing a comprehensive recording of call
flow information. See section 3.4.7 "Collecting CDT Messages of a Single Subscriber" for
procedures to collect the CDT of a single subscriber.
Issue 01 (2011-08-11)

3-2
3.3.8 Signaling Tracing Messages on Interfaces

To obtain information on standard interfaces (Iu, Iub, Iur, and Uu), analyze signaling tracing
messages or a single UE tracing. Use the tracing information to analyze if messages on the
interfaces connecting Huawei equipment and peer vendor equipment are correct. See section
3.4.8 "Collecting Signaling Tracing Messages on Interfaces" for procedures to perform
signaling tracing messages on interfaces.
3.4 Guide to Collecting the RNC Fault Information

3.4.1 Backing Up the Database
Use either of the following two methods to back up the database:
Database Backup Using an MML Command

Prerequisite: You have successfully logged in to the LMT.
1. Run the BKP DB MML command. Set the backup file directory and file name, and save the
file in a designated directory.
Example:
In the Windows operating system, run the following command:
BKP DB: BACKUPPATH="D:\BACKUP", FILENAME="2010.08.20.BAK";
In the Linux operating system, run the following command:
BKP DB:BACKUPPATH="/", FN="20020930.BAK";
2. Obtain the backup data.
Log in to the OMU through an FTP client or through telnet, and obtain the backup file from
the designated directory (or default directory).
---End
Database Backup with a Tool

1. Double-click the omu_backup_linker.exe file that is saved in the directory
mbsc\bam\common\services\ on the OMU.
a.
In the Windows operating system, log in to the active OMU. Start the
omu_backup_linker tool.
b.
In the Linux operating system, log in to the active OMU. Run the cd
/mbsc/bam/common/services command. This command switches the current directory to
the directory in which the tool is located.
Run the /omu_backup_linker command, and then press Enter to start the tool, as shown in
the following figure.
Issue 01 (2011-08-11)

3-3
2. Start the backup.

After the message "Please input a valid bkp_res_type:" is displayed, type backup, and press
Enter.
Type a valid backup file pathname, and press Enter to begin the backup. If the message
"Backup OMU database succeed!" is displayed, then the database has been successfully
backed up on the OMU, as shown in the following figure.
---End
3.4.2 Collecting OMU Logs

1. Run the following MML command:
COL LOG: LOGTYPE=OMU_LOG-1;
2. Obtain log files
The command saves the log files on the OMU. Log in to the OMU through an FTP client or
through telnet, and obtain log files.
Issue 01 (2011-08-11)

3-4
The LST LOGRSTINFO command will query and display the specific path of the saved
logs.
---End
3.4.3 Collecting Alarm Logs

EXP ALMLOG: AWEBLMTP=all;
2. Obtain log files.
After the command is run successfully, a message is displayed indicating the path where log
files are saved, as shown in the following figure.
---End
3.4.4 Collecting Operation Logs from a Maintenance Console

COL LOG: LOGTYPE=OPT_LOG-1, ST=xxxx&xx&xx&xx&xx&xx, ET=
xxxx&xx&xx&xx&xx&xx;
To export operation logs for a specific duration, which is from ST to ET. To export all the
operation logs if there is not parameter ST and ET.
After the preceding command is executed successfully, log files will be saved on the OMU.
Log in to the OMU through an FTP client or through telnet, and obtain log files.
The LST LOGRSTINFO command will query and display the specific path of the saved
logs.
---End
Issue 01 (2011-08-11)

3-5
3.4.5 Collecting Host Logs

Host logs consist of text logs and binary logs.
The steps for collecting host logs are as follows:
1. To collect text logs from subrack X, run the following MML command:
COL FAMLOG: SRN=X, TP=NORMAL;
2. To collect CHR logs, run the following MML command:
COL LOG: LOGTYPE=3G_CHR_LOG-1;
CHR logs record all information about failures such as essential procedures and error records.
3. To collect PCHR logs, run the following MML command:
COL LOG: LOGTYPE=UPCHR_LOG-1;
The performance call history record (PCHR) records 20 signaling messages and the status of
the air interface before services of a user are terminated. PCHR is used to analyze problems
related to KPIs.
4. To collect debug logs, run the following MML command:
COL LOG: LOGTYPE=DEBUG_LOG-1;
Debug logs record the status of most modules in the MPU. Debug logs are used to locate
faults related to resource allocation and services.
After the preceding commands are executed successfully, log files will be saved on the OMU.
The LST LOGRSTINFO command will query and display the path of the saved logs.
---End
3.4.6 Collecting Traffic Statistics

COL LOG: LOGTYPE=PFM_RESULT-1;
After the preceding command is executed successfully, log files will be saved on the OMU.
The LST LOGRSTINFO command will query and display the path of the saved logs.
3.4.7 Collecting CDT Messages of a Single Subscriber

1. Start CDT tracing.
Choose Trace > UMTS Services, and double-click UE Trace. Then enter the IMSI or TMSI
of the subscriber to be traced, as shown in the following figure.
Issue 01 (2011-08-11)

3-6
2. Trace CDT including the L2 data report.

By default, tracing and recording layer 2 (L2) messages are not performed during the CDT
tracing task. To perform tracing and recording, enable the debug mode.
On the UE tab, select Debug Mode.
---End
On the Other tab, finish the tracing and recording configuration, as shown in the following
figure.
Issue 01 (2011-08-11)

3-7
For data transmission faults, ensure that faults that occur in the first 100 seconds are traced. If no fault
appears in the first 100 seconds, restart tracing.
3. Collect CDT data.

Click the Submit button. CDT data is saved automatically in the path that you have specified.
The default path for saving CDT data is:

C:\Web LMT\output\MBSC\trace\tmfFile
---End
Issue 01 (2011-08-11)

3-8
3.4.8 Collecting Signaling Tracing Messages on Interfaces

See the LMT online help on for the procedure for collecting signaling tracing messages on
interfaces.
3.4.9 Downloading the Collected Log Files

1. Click File Manager on the LMT, as shown in the following figure.
2. Choose a log file and then click Download. The file is saved in the default directory
Root\bam\common\MeasResult or a designated directory.
---End
3.5 Information for the NodeB Fault Location

3.5.1 NodeB CDT Logs
NodeB CDT logs record the detailed field values for each part of the call tracing process.
Therefore, the logs provide key information for locating faults related to KPIs and high speed
packet access (HSPA) rate. See section 3.6.1 "Collecting NodeB CDT Logs" for procedures to
collect NodeB CDT logs.
3.5.2 NodeB CHR Logs

The NodeB CHR logs mainly record the basic information about calls, including performance
logs for the NodeB and abnormal subscriber logs. See section 3.6.2 "Collecting NodeB CHR
Logs" for procedures to collect NodeB CHR logs.
Issue 01 (2011-08-11)

3-9
3.5.3 NodeB Main Board and Board Logs

The NodeB WMPT logs consist of NodeB configuration files, running logs, call logs, and cell
logs. The NodeB WMPT logs can be used to check whether the NodeB configuration and
module status are normal. See section 3.6.3 "Collecting NodeB Main Board and Board Logs"
for procedures to collect NodeB main board and board logs.
3.5.4 Running the Python Script on the NodeB LMT

The Python script should be run whenever collecting information about NodeB. See section
3.6.4 "Running the Python Script on the NodeB LMT" for procedures to run the Python
script.
3.5.5 Real-time LMT Tracing

Real-time LMT tracings can be used to perform tracings of service resources in a cell and
service resources configured on a board. See section 3.6.5 "Real-time LMT Tracing" for
procedures to run real-time LMT tracing.
3.5.6 Collecting the NodeB Fault Information on the M2000

Various NodeB logs can be obtained through the M2000. See section 3.6.6 "Managing the
NodeB on the M2000" for procedures to collect the NodeB information on the M2000.
3.6 Guide to Collecting the NodeB Fault Information

3.6.1 Collecting NodeB CDT Logs
Cell Tracing
1. On the LMT, click Maintenance on the lower-left corner, choose Trace Management >
Interface Trace Task, and double-click Cell, as shown in the following figure.
2. Set Cell ID to the logical cell ID.
3. Select items to be traced on the Iub and Uu tab pages.
4. Select Autosave on the Basic tab page, enter a saved path in File Name, and click OK to start
tracing.
Issue 01 (2011-08-11)

3-10
---End
User Tracing
1. Log in to the LMT, double-click User to start user tracing.
2. Set Trace Method. If no drive test UE is available, select Chain Time, and the system will
randomly trace less than four UEs. If drive test UE is available, select IMSI.
a.
Set Chain Time for user tracing, as shown in the following figure.
Note that the Begin Time must be the same or earlier than the current time, and the End
Time should be around 24 hours later.
Issue 01 (2011-08-11)

3-11
b.
Set IMSI ID.

Run the following command on the RNC LMT:
MOD UNODEB: NodeB ID = XXX, NodeB Trace Switch=ON;
XXX is the NodeB ID.
Set Trace Method to IMSI, and enter an IMSI ID.
Select Autosave, enter a saved path in File Name, and click OK.
Issue 01 (2011-08-11)

3-12
3. On the IUB and UU tabs, select the CDT items to be traced, and enter the parameters, as
shown in the following two figures.
Issue 01 (2011-08-11)

3-13
4. Select Autosave on the Basic tab page, enter a saved path in File Name, and click OK to start
tracing.
The following figure shows the report of the traced CDT messages.
---End
3.6.2 Collecting NodeB CHR Logs

1. Start the NodeB LMT.
2. Run the following MML command to set the information level of CHR data:
SET CHRLEVEL: CHRLEVEL=DETAIL; CHRUSERTYPE=ALLUSERTYPE
3. Choose either of the following three methods to collect NodeB CHR logs:
Issue 01 (2011-08-11)

3-14
a.
Collect the NodeB CHR using computer onsite. Use this method only if you can log in to
the NodeB directly through the LMT.
Run the following commands:
SET CHRSW: CHRSW=ON, CHRTYPE=ALL, IP=XX.XXX.XXX.XXX,
DSTF=X:\CHRDATA\, USR=admin, PWD=admin;
SET CHRLEVEL: CHRLEVEL=DETAIL; CHRUSERTYPE=ALL USERTYPE;
Ensure that the IP is the IP address of the computer, and the user name and password are
correct. When using the FTP software provided with the NodeB LMT, the user name and
password are admin. The path X:\ CHRDATA must be set up in advance.
b.
Do as follows to collect the NodeB CHR through the FTP client of the M2000. Use this
method only if you can log in to the NodeB LMT using the M2000 client.
Run the following command:
SET CHRSW: CHRSW=ON, IP=XX.XXX.XXX.XXX, DSTF="/export/home/sysm",
USR="ftpuser", PWD="ftpuser";
c.
Do as follows to collect the NodeB CHR through the RNC BAM FTP server. Use this
method only if you can upload data through the RNC BAM FTP server:
SET CHRSW: CHRSW=ON, IP=XX.XXX.XXX.XXX, DSTF=/ftp/, USR=FtpUsr,
PWD=XXXXXXXX;
Note that the path of the BAM FTP server must be one of the following two:
D:\WCDMA RNC\BAM\VersionA\FTP
D:\WCDMA RNC\BAM\VersionB\FTP
4. Six minutes after the command is executed, check whether any logs are uploaded to the path
D:\CHRDATA before the test.
5. After the NodeB CHR is completely uploaded, run the following command to turn off the
CHR function:
SET CHRSW: CHRSW=OFF; SET CHRLEVEL: CHRLEVEL=NONE;
Note that the NodeB CHR collected through the second or third method can be retrieved from
the FTP server.
---End
3.6.3 Collecting NodeB Main Board and Board Logs

Method 1: Start the LMT. Choose Service > Software Management, and double-click Other
File Transfer, as shown in the following figure. Set File Description to Main Board Log
Files, and select Compressed Mode.
Method 2: Log in to the M2000. Choose Software > Browser > NE > Server, choose a
NodeB, and select Other in the displayed window.
Issue 01 (2011-08-11)

3-15
3.6.4 Running the Python Script on the NodeB LMT

1. Put the XXX.pyc file to be executed under any path. Log in to the LMT. Choose Tool >
Script Manage to enable the Script Manage function, as shown in the following figure. In
the following example, the file is put on the desktop.
2. Click Open, and double-click the XXX.pyc file on the desktop, as shown in the following
figure.
Issue 01 (2011-08-11)

3-16
The following figure shows an example of the preceding operations being successful.
3. Right-click the blank area and choose to save the exported results.
Collecting the DSP memory will be used as an example to describe this process.
a.
Issue 01 (2011-08-11)
Double-click the BdamDumpOneDspMemory.pyc file provided by the Research and

Development personnel. Enter the parameters as shown in the pink circled area in the
following figure:

3-17
b.
Upload the board logs for the baseband processing board after running the script. See
section 3.6.3 "Collecting NodeB Main Board and Board Logs" for more details.
---End
3.6.5 Real-time LMT Tracing

The red circled items in the following figure are the most often used when performing
real-time LMT tracing.
Issue 01 (2011-08-11)

3-18
3.6.6 Managing the NodeB on the M2000

Checking the Topology Status on the M2000
Choose Topology > Main Topology to check the network topology.
Running the Related MML Commands

Choose Maintenance > MML Command, and run the corresponding command to view the
NodeB information. For example, run the DSP VER command to view the NodeB version.
Issue 01 (2011-08-11)

3-19
Checking for Alarms

Choose Monitor > Current Fault Alarms. Check whether there are any alarms.
Choose Monitor > History Fault Alarms. Check whether there are any alarms.
Choose Monitor > Event Alarms. Check whether there are any alarms.
Choices are available for the alarm types, event types, and sites.
Uploading NodeB Files

1. Choose Software > Browser. In the left pane, click NE, and choose the target NodeBs.
Issue 01 (2011-08-11)

3-20
2. Choose files to upload in the displayed dialog box.

To upload main board log files, click Other. Select MAINBRDLOG, and select Upload to
NM.
3. Enter the name of the file to be uploaded in the displayed dialog box. Click to select
Compress Upload which reduces upload time. Name the file in the site name + date format
to make it different from previously downloaded files.
Issue 01 (2011-08-11)

3-21
Click OK to begin the upload of NodeB WMPT log to the M2000 server.
4. Click NM Server, and choose the corresponding NodeB in the left pane.
5. Select the previously uploaded file in the displayed dialog box.
Issue 01 (2011-08-11)

3-22
6. Choose Transfer > From NM to Client, specify a path. When the process starts, the selected
file will be uploaded to the local computer.
To upload board logs, choose BRDLOG in 2.
To upload a NodeB configuration file, click the Data tab, as shown in the following
figure.
Select the corresponding path and file name.

Click OK to upload files to the M2000 server.
Issue 01 (2011-08-11)

3-23
---End
Downloading NodeB Configuration Files

1. Click NM Server, and choose the corresponding NodeB in the left pane.
2. Select Data, and choose Transfer > From Client to NM.
3. Choose the NodeB and configuration file in the displayed window. When the process starts, a
configuration file is downloaded to the M2000 server.
Select the downloaded file in the file list under Data. Choose Transfer > From NM to NE,
and the configuration file is sent to the NodeB through the M2000.
---End
Upgrading the NodeB

The requirements for an upgrade are as follows:
z
Back up the configuration file for the NodeB to be upgraded before upgrade.
Check whether the versions before and after the upgrade are recommended in the
upgrade guide.
Issue 01 (2011-08-11)

3-24
Check whether the upgrade-related software has been uploaded to the M2000 server.
Contact Huawei for technical support before a batch upgrade.
To upgrade the NodeBs in batches, do as follows:

1. Choose Software > NE Upgrade Task > NE Upgrade Task, as shown in the following
figure.
2. Choose Create > NodeB in the lower-right corner of the tab.

3. Conduct an upgrade configuration through the NE Upgrade Wizard.
Specify Upgrade type, and select the NEs to be upgraded.
Click the > icon in the dialog box, as shown in the following figure.
Issue 01 (2011-08-11)

3-25
Click Next to select the software version and operation settings. Click Finish to start the
upgrade.
---End
Checking the NodeB FTP Server

File transmission between the NodeB and the M2000 can be implemented using either of the
following two methods:
z
Through the FTP server on the RNC BAM
Through the FTP server on the M2000
To reduce bandwidth usage, the first method is usually adopted. However, in some cases, the
RNC BAM may be not compatible with the NodeB, which leads to the failure in uploading
Issue 01 (2011-08-11)

3-26
and downloading files. In this situation, change the FTP server address of a NodeB to the IP
address of the M2000 OMC.
1. Choose Software > File Server Setting to open the File Server Setting window.
2. Select the NodeB in the left pane. If you select RNC, information of all the NodeBs under the
RNC is displayed.
3. Set the file server in the File Server Name column. If the files cannot be uploaded or
downloaded when the file server is configured in the RNC BAM, change the file server
setting to that of the M2000. The M2000 is the OMC, and appears in the File Server Name
column in the following figure.
---End
Logging In to the NodeB Remotely Through the M2000 Proxy Server

Use one of the following methods to log in to the NodeB through the M2000 proxy server:
Issue 01 (2011-08-11)

3-27
Method 1: Log in to the NodeB directly through the M2000 if your computer is running the
corresponding LMT.
Right-click the selected NodeB, and choose Maintenance Client from the drop-down menu.
The M2000 automatically logs in to the NodeB using the LMT, as shown in the following
figure.
Method 2: Log in to the NodeB through the configured M2000 proxy server.
1. Set the NodeB information on the LMT, as shown in the following figure.
2. Select Proxy Server, and ensure that the Proxy Server IP address is set to that of the M2000.
3. Enter the user name and password for the M2000, and then click Login, as shown in the
following figure.
Issue 01 (2011-08-11)

3-28
---End
Logging in to the NodeB Through the M2000 Interface

1. Enter the IP address for the M2000, as shown in the following figure.
2. Enter the user name and password for the M2000 and click Login.
Issue 01 (2011-08-11)

3-29
3. Select the NodeB in the displayed dialog box and click OK.
---End
Issue 01 (2011-08-11)

3-30
4 RNC Troubleshooting
RNC Troubleshooting
4.1 Cell Setup Failure

4.1.1 Description
After being configured and activated, a cell cannot be set up, and the alarm ALM-22206
UMTS Cell Setup Failed is reported.
4.1.2 Possible Causes

z
The transmission is faulty.
Configurations, such as maximum downlink power and frequencies, on the RNC and
NodeB are inconsistent.
Baseband or RF resources are unavailable on the NodeB side.
The local cell does not exist on the NodeB side.
L2 resource allocation fails.
The corresponding license has not been obtained.
4.1.3 Troubleshooting Methods

Run the DSP UCELL command to obtain the reason of the latest cell setup failure.
Troubleshoot the problem based on the specific reason.
4.1.4 Troubleshooting Procedure

Run the DSP UCELL command on the RNC LMT to query the reason for the cell setup
failure. Information similar to the following will be displayed.
Issue 01 (2011-08-11)

4-1
If Reason of the latest cell setup failure is NCP unavailable or CCP unavailable, the
link that carries the NCP or CCP may be faulty. Check whether an alarm related to the
corresponding SAAL (for ATM transmission) or SCTP (for IP transmission) link is
reported. If such an alarm is reported, clear the alarm according to the instructions in the
alarm reference.
If Reason of the latest cell setup failure is FP synchronization failure or Common

channel setup failure, the user-plane transmission bearer may be faulty. Check whether
a path alarm is reported. If such an alarm is reported, clear the alarm according to the
instructions in the alarm reference. If no path alarm is reported, check whether the path
negotiation parameters on both the RNC and NodeB are configured correctly and
whether the transmission over the Iub interface is normal.
If Reason of the latest cell setup failure is Power mismatch, check whether the local
cell on the NodeB side is available. If the local cell is unavailable and the alarm
ALM-4033 Local Cell Unusable is reported, clear the alarm according to the instructions
in the NodeB alarm reference. If the local cell is available, check the maximum downlink
power configured on the NodeB and RNC. If the power configured on the NodeB is
smaller than that on the RNC, change the maximum downlink power on either the
NodeB or RNC so that that the power configured on the NodeB is greater than or equal
to that on the RNC.
Run the LST UCELL command on the RNC LMT to query the maximum downlink
power on the RNC side. The following is shown as an example:
Issue 01 (2011-08-11)

4-2
Run the LST LOCELL command on the NodeB LMT to query the maximum downlink
power on the NodeB side. The following is shown as an example:
Issue 01 (2011-08-11)
If Reason of the latest cell setup failure is NodeB return cell setup failure and cause
is "NodeB sends CELL SETUP FAILURE (Frequency acquisition not supported)" in the

4-3
location information about the alarm ALM-22206 Cell Setup Failure, check whether the
frequency configurations on the RNC and NodeB are consistent.
Run the LST UCELL command on the RNC LMT and the LST LOCELL command on
the NodeB LMT to query the frequency configurations.
z
If Reason of the latest cell setup failure is Local cell not reported and cause is "Data
configuration error or inconsistent with physical resources" in the location information
about the alarm ALM-22206 Cell Setup Failure, check whether the NodeB is configured
with a corresponding local cell and whether the local cell ID on the RNC and NodeB is
consistent. Run the LST UCELL command on the RNC and the LST LOCELL command
on the NodeB to query the local cell ID.
If Reason of the latest cell setup failure is Common channel setup failed and reason
of the latest common channel setup failure is "L2 resource allocation failed", log in to the
RNC LMT. View the BSC Device Panel window and check whether DPUs can be
detected. If no DPUs can be detected, insert new DPUs. If DPUs can be detected but are
unavailable, replace them with new ones.
Log in to the RNC LMT. Run the LST LICENSE command and set FN to the file name of
the current license to check the license items. If IP transmission is used over the Iub interface,
IP Transportation in Iub Interface should be ON; if IP/ATM dual-stack transmission is
used over the Iub interface, IUB ATM/IP Dual Stack Transportation Function should be
ON, as shown in the following figure:
+++
WCDMA-RNC
O&M
#138901
2011-08-09 19:53:28
%%LST LICENSE:;%%
RETCODE = 0
Execution succeeded.
List License File Information

----------------------------File
LicenseFileName
IsCurrentLicense
Demo_BSC6900_V900R013_UO_20110727.dat
license.dat
(Number of results = 2)
+++
WCDMA-RNC
O&M
#138902
2011-08-09 19:53:52
%%LST LICENSE: FN="Demo_BSC6900_V900R013_UO_20110727.dat";%%

RETCODE = 0
Execution succeeded.
......
Issue 01 (2011-08-11)
IP Transportation in Iub Interface=ON
MBMS Function=ON
Wide Band AMR=ON
High Speed Uplink Packet Access=ON
RAN Sharing Function=ON
High Speed Downlink Packet Access Function 3.6M=ON
High Speed Downlink Packet Access Function 7.2M=ON
PDCP ROHC Function=ON
LCS over Iur=ON
NACC(Network Assisted Cell Change)=ON
PS Handover Between UMTS and GPRS=ON
IMSI Based Handover=ON
32 HSDPA Users per Cell=ON
64 HSDPA Users per Cell=ON
Streaming Traffic Class on HSDPA=ON
HSDPA State Transition=ON
HSDPA DRD=ON

4-4
=
Enhanced Iu Flex=ON
Streaming Traffic Class on HSUPA=ON
IUB ATM/IP Dual Stack Transportation
Function=ON
If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
Information to Be
Collected
Method
Result
Whether the local

cell on the NodeB
side is normal.
Run the DSP LOCELL

command.
MML reports
Cause of cell setup

failures on the RNC
side
Run the DSP UCELL

command.
MML reports
Messages traced
over the Iub
interface
Trace messages over the Iub

interface on the LMT. After the
tracing, run the following
commands: ADT URESDEA
UCELLACT UCELL
MML reports and the tracing

result file
Configuration script
Run the EXP CFGMML

command.
The configuration script in the

\bam\version_a(b)\ftp\export_
cfgmml directory of the main
area directory of the OMU
RNC alarms

COL LOG:
LOGTYPE=HISTORY_ALAR
M-1;
The ALARM_INFO.zip file in

the
\bam\version_a(b)\ftp\COLL
OGINFO\ALM-LOG
directory of the main area
directory of the OMU
NodeB WMPT logs
Collect the logs from the M2000

through FTP.
The specified FTP server

directory
4.2 Service Setup Failure

4.2.1 Description
Users cannot perform adaptive multi rate (AMR) speech or PS dial-up services.

z
The signaling plane over the Iu interface is faulty.
The user plane over the Iu interface is faulty.
The CN is faulty.
Issue 01 (2011-08-11)

4-5
Iu-related configurations, set by running the ADD TRMMAP, ADD ADJMAP, and ADD
UCNNODE commands, are incorrect or deleted.
The SPU boards or interface boards are faulty.
The Service Area Codes (SACs), Routing area codes (RACs), and Location Area Codes
(LACs) of some cells are not configured on the CN side.
Resources of certain cells, such as power, code, transmission, and channel element (CE)
resources, are congested.

First, check whether the signaling plane and user plane over the Iu interface are faulty. Then,
check how many cells are faulty. If all cells are faulty, check the configurations over the Iu
interface. If only some cells are faulty, check whether the faulty cells are served by one SPU
subsystem or interface board. Then, troubleshoot the faulty cells one by one based on their
specific fault causes.

1. Clear any alarms according to the instructions in the alarm reference.
If the signaling plane over the Iu interface is faulty and any of the following alarms is
reported:
z
ALM-21503 MTP3 DSP Inaccessible
ALM-21505 MTP3 Signaling Link Set Unavailable
ALM-21521 SCCP Subsystem Prohibited
ALM-21553 M3UA Destination Entity Inaccessible
If the user plane of the Iu interface is faulty and the following alarm is reported:
z
ALM-21581 Path Fault
2. Check other RNCs connected to the same CN. If most of them are faulty, check whether the
CN is faulty or has had configurations modified recently.
3. Check whether all cells served by the RNC are abnormal by checking the counters
VS.RAB.AttEstabCS.Conv and VS.RAB.SuccEstabCS.Conv. If all cells are abnormal,
troubleshoot the problem by following steps 3 through 6. If only some cells are abnormal,
troubleshoot the problem by following steps 7 through 13.
4. If IP transmission mode is used over the Iu interface, start Iu-interface tracing to check
whether services fail mainly on certain IP addresses assigned by the CN. If so, check whether
the IP paths and routes to those IP addresses are configured on the RNC.
5. Check whether paths over the Iu interface are consistent with the configurations set by
running the ADD TRMMAP command. Check whether the configuration of the CN node or
Iu-CS AAL2 routers is omitted or deleted.
6. Check the measurement of AAL2 path traffic over the Iu interface by checking the counters
VS.AAL2PATH.PVCLAYER.RXBYTES and VS.AAL2PATH.PVCLAYER.TXBYTES or
check the measurement of IP path traffic over the Iu interface by checking the counters
VS.IPPATH.IPLAYER.RXBYTES and VS.IPPATH.IPLAYER.TXBYTES. If the traffic of
one path is much smaller than that of any other path or is unidirectional, remove that one path
by running the RMV AAL2PATH or RMV IPPATH command to restore the service. If the
usage of each path approaches 100%, new paths need to be added or the path bandwidth needs
to be expanded.
Issue 01 (2011-08-11)

4-6
7. Locate and check the SPU subsystem and interface board that serves the faulty cells. If most
of these cells are served by the same board, perform an active/standby switchover on the
board.
8. Run the DSP UCELL command to check the cell status. If the Operation state of the cell is
Unavailable, check the fault reason.
If the cell is not activated, run the ACT UCELL command to activate the cell. If the cell
setup fails, refer to section 4.1 for troubleshooting.
If the Operation state is Available, run the LST UCELLACCESSSTRICT command to
check whether the cell or user Access Class (AC) is barred, as shown in the following figure.
If Access class x barred indicator or Cell barred indicator for SIB3 is BARRED, change
it to NOT_BARRED.
Run the DSP UCELLCHK command to check whether the power, code, transmission, or CE
resources of the cell are congested, as shown in the following figure.
Issue 01 (2011-08-11)

4-7
Power congestion
Power congestion may be on the uplink or downlink. Run the LST UCELLALGOSWITCH
command to query the call admission control (CAC) algorithm in use.
If the access failure is caused by uplink power congestion, check whether the RTWP is within
the valid range (96.5 dB to 105.5 dB).
Check whether Auto-Adaptive Background Noise Update Switch is ON. If so, deactivate
the cell, and then re-activate the cell to check whether the RTWP becomes normal.
If Auto-Adaptive Background Noise Update Switch is OFF, turn off the uplink CAC
switch or reset the background noise value.
To turn off the uplink CAC switch, run the following command:
MOD UCELLALGOSWITCH: NBMUlCacAlgoSelSwitch=ALGORITHM_OFF
To reset the background noise value, check the average RTWP value (indicated by
VS.MeanRTWP) in the performance statistics, and set the background noise value to the
minimum VS.MeanRTWP. An example command is as follows:
MOD UCELLCAC: BackgroundNoise=61;
The default value of BackgroundNoise is 61. The parameter value depends on the onsite conditions and
is calculated with this formula: Background noise = 112 + BackgroundNoise x 0.1.
Issue 01 (2011-08-11)

4-8
If the access failure is caused by downlink power congestion, check the latest Transmit
Carrier Power (TCP) value and run the LST UCELLCAC command to query the service
admission threshold. If the TCP value exceeds the threshold, the access fails. Check whether
the admission threshold is configured according to the baseline data or network planning data.
If not, change the admission threshold to the correct value. Otherwise, consult Huawei
network planning engineers about whether to adjust the threshold or expand the capacity.
Code congestion
Check whether the Cell code used rate is normal, and trace the code tree to check whether the
cell uses too many code resources. If the minimum available codes are more than the DL
handover reserved spreading factor (SF), the cell capacity is limited and needs to be expanded.
The smaller the SF, the higher the service rate. For example, if the available minimum SF is
SF32 but the configured reserved SF is only SF16, the admission
fails.
Alternatively, you can run the LST UCELLCAC command to check whether the reserved
code of the cell is configured according to the baseline data or the network planning data. If
Issue 01 (2011-08-11)

4-9
the reserved SF is too small (for example, SF4), change it according to the baseline data.
Otherwise, consult Huawei network planning engineers about whether to adjust the SF or to
expand capacity.
Newly admitted users cannot use reserved SFs. As a result, the smaller the SF, the fewer code resources
available for newly admitted users.
Transmission congestion
Run the DSP UCELLCHK command to check whether the Iub interface of the cell is
congested.
If the Iub interface is congested, check whether the reserved bandwidth for the AAL2 path is
within the valid range. By default, the reserved bandwidth is 0, indicating that no bandwidth
is reserved.
Issue 01 (2011-08-11)

4-10
Run the LST TRMFACTOR command to check whether the values configured for service
activation factors are within the valid ranges. For best results, these parameters should be set
to their recommended values.
For PS services, run the LST UUSERGBR command to check whether the guaranteed bit
rate (GBR) is configured according to the baseline data. If the GBR value is too large (such as
384 kbit/s), consult the network planning engineers about whether to decrease the GBR or
adjust the bandwidth. The GBR and bandwidth adjustment is subject to the approval of the
operator.
Issue 01 (2011-08-11)

4-11
CE congestion
Run the DSP UCELLCHK command to check whether CE resources of the cell are
congested. CE congestion can be eliminated by purchasing more CE licenses or deploying
more sites for traffic sharing.
9. Check whether the LAC/SAC/RAC data is configured on the CN side (MSC/SGSN). If the
data is not configured, UEs cannot register or attach themselves to the network. You can trace
the intelligent optimum sample (IOS) of the cell to check whether a UE can register or attach
to the network.
When the LAC/SAC/RAC data is not configured on the CN side, the initial direct transfer messages sent
by the RNC are not responded or are rejected and the signaling connection control part (SCCP)
connection setup fails. As a result, the UE cannot access the network.
10. Check whether the AAL2Path or IPPATH is available and configured correctly.
Run the LST TRMMAP command to check whether the transmission mapping is set
correctly. For example, CS services map RT paths (primary paths) and NRT paths (secondary
paths); R99 PS services map NRT paths (primary paths) and RT paths (secondary paths);
HSPA services map HSPA NRT paths. High Speed Downlink Packet Access (HSDPA)
services and High Speed Uplink Packet Access (HSUPA) services can share the same
TRMMAP. Run the LST AAL2PATH or LST IPPATH command to check whether the
mapped path in the TRMMAP is configured.
Issue 01 (2011-08-11)

4-12
According to the preceding results, the CS services can be set up only after an ATMRT path or
HQ_IPRT path is configured.
11. If you still cannot locate the cause of the problem after performing the preceding procedure,
Information to Be Collected
Method
Result
Configuration data
Run the EXP CFGMML

command.
Related files in the

bam\version_a(b)\ftp\export_cfgmml
directory
OPT_LOG and
HISTORY_ALARM log
The OperateLog.zip file in the

\bam\version_a(b)\ftp\COLLOGINFO
\OPT-LOG directory and
ALARM_INFO.zip file in the
\bam\version_a(b)\ftp\COLLOGINFO
\ALM-LOG directory.
Performance measurement file
Record the performance

measurement data generated 3
hours before and after the fault
occurs.

bam\common\measResult directory
Binary logs
Get the CALL FAULT, DEBUG,

and CHR logs generated 20
minutes before and after the fault
occurs.

bam\common\fam\famlogfmt
directory
IOS tracing result file
When performing the IOS trace,

select five cells that have the most
serious problems based on
counters.
LMT tracing files
Issue 01 (2011-08-11)
COL LOG:
LOGTYPE=HISTORY_ALARM1&OPT_LOG-1;

4-13
Method
Result
Iu interface tracing result file
Trace the signaling (RANAP and

SCCP) over the Iu interface for 5
minutes. If the CS services are
interrupted, the destination
signaling point (DSP) is the MSC;
if the PS services are interrupted,
the DSP is the SGSN.
LMT tracing files
Issue 01 (2011-08-11)

4-14
5 NodeB Troubleshooting
NodeB Troubleshooting
5.1 RTWP Abnormality

5.1.1 Description
The alarm ALM26522 RF Unit RX Channel RTWP/RSSI Unbalanced is reported. This alarm
is reported if the difference between the main received total wideband power (RTWP) and the
diversity RTWP is larger than 6 dBm.
This alarm is reported in any of the following three scenarios:
z
Either the main or diversity RTWP is abnormally high while the other is normal.
Both the main and diversity RTWP are abnormally high.
Either the main or diversity RTWP is abnormally low while the other is normal.
Alternatively, the alarm ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low is reported.
This alarm is reported in either of the following two scenarios:
z
Either the main or diversity RTWP is abnormally low.
The diversity channels are configured with but not connected to antennas.
As specified by the 3GPP standard, the range of RTWP is 1064 dBm. The RTWP is
abnormal if its value is continuously greater than 102 dB or less than 110 dB or if the
RTWP peak value is continuously greater than 80 dB.

Abnormally high RTWP:
z
The value for Desensitization Intensity is too large.
The value for Attenuation of RX Channel is too small.
There is passive intermodulation.
The traffic is heavy due to a large number of users.
There is external interference.
Abnormally low RTWP:

z
The value for Attenuation of RX Channel is too large.
The antenna is not properly installed.
Issue 01 (2011-08-11)

5-1

Check whether the RTWP is abnormally high or low, then troubleshoot the problem
accordingly. If you still cannot locate the cause of the problem, collect the relevant
information and contact Huawei technical support.

Abnormally High RTWP
1. Check the value for Desensitization Intensity
Run the DSP RFDESPARAM and DSP DESENS commands and check whether the value
for Desensitization Intensity in the results of the two commands is 0. A value other than 0
causes the RTWP to be abnormally high.
If the value for Desensitization Intensity is not 0, run the SET RFDESPARAM and SET
DESENS commands to change the value to 0, and observe whether the RTWP value is back
to normal. If so, the RTWP abnormality is caused by the setting of this parameter.
If the value for Desensitization Intensity is 0, go to step 2.
2. Check the value for Attenuation of RX Channel
Run the LST RXATTEN command to check the value for Attenuation of RX Channel.
Then run the LST ALD command to check whether the Tower Mounted Amplifier (TMA) is
configured. If the TMA is not configured, the value for Attenuation of RX Channel must be
0. Otherwise, the RTWP value will be abnormally low. If the TMA is configured, the value for
Attenuation of RX Channel cannot be set to 0. Otherwise, the RTWP value will be
abnormally high. The value for Attenuation of RX Channel = TMA Gain - Feeder loss.
Run the SET RXATTEN command to change the value for Attenuation of RX Channel if
needed.
If the value for Attenuation of RX Channel is correct, go to step 3.
Note that there are two types of TMAs: 12-dB TMA and 24-dB TMA. The value for TMA Gain is fixed
and can be found in the TMA product document.
Feeder loss needs to be calculated based on the length and type of feeder; this information can
be found in the feeder product document.
3. Check whether there is passive intermodulation.
Run the SET TXSW command to shut down the transmit channel. If the RTWP value then
returns to normal, the RTWP abnormality may be caused by the passive intermodulation.
Check the main feeder connection.
If the RTWP value does not return to normal after the shutdown, go to step 4.
4. Check the number of HSUPA subscribers.
Log in to the RNC LMT, and choose Monitor > UMTS Monitoring > Cell Performance
Monitoring. Check whether the number of HSUPA users exceeds 10. If so, ignore this
problem because a large number of HSUPA users usually lead to a high RTWP value.
If the number of HSUPA users is less than 10, go to step 5.
Issue 01 (2011-08-11)

5-2
5. Check whether there is interference.

Log in to the NodeB LMT, choose Maintenance > Realtime Specific Monitoring > Board
RTWP. Check the RTWP tracing data or curve. If the RTWP value is continuously higher
than -90 dBm, the abnormally high RTWP may be caused by interference. Locate the
interference source. The methods for locating an interference source are not covered in this
guide.
If the RTWP value is not continuously higher than -90 dBm, go to step 6.
Issue 01 (2011-08-11)

5-3
Information to Be
Collected
Method
Result
The value for Desensitization

Intensity
Run the DSP RFDESPARAM and DSP DESENS

commands.
MML reports
The value for Attenuation of

RX Channel
Run the LST RXATTEN command.
MML reports
TMA Gain
Run the LST TMAGAIN command.
MML reports
Whether the RTWP values of

the local cell and its
neighboring cells are
abnormally high
Run the STR RTWPRTTST command or choose

Maintenance > Realtime Specific Monitoring > Board
RTWP.
Tracing logs or
RTWP data
Traffic
Check the counters related to the cell traffic.
The counter data or

report
Whether there is passive

intermodulation
Run the SET TXSW command to shut down the

transmit channel. Check whether the RTWP value
returns to normal.
The RTWP value
Abnormally Low RTWP

1. Check the value for Attenuation of RX Channel
Run the LST RXATTEN command to check the value for Attenuation of RX Channel.
Then run the LST ALD command to check whether the Tower Mounted Amplifier (TMA) is
configured. If the TMA is not configured, the value for Attenuation of RX Channel must be 0.
Otherwise, the RTWP value will be abnormally low. If the TMA is configured, the value for
Attenuation of RX Channel cannot be set to 0. Otherwise, the RTWP value will be abnormally
high. The value for Attenuation of RX Channel = TMA Gain - Feeder loss. Run the SET
RXATTEN command to change the value for Attenuation of RX Channel if needed.
2. Check the antenna installation
Check whether the alarm ALM-26529 RF Unit VSWR Threshold Crossed is reported. If so,
the antenna is faulty or not installed.
collect the following information and contact Huawei technical support:
z
NodeB WMPT logs and RRU or RFU logs
RTWP tracing results of the faulty cell. To start a tracing, log in to the NodeB LMT and
choose Maintenance > Realtime Specific Monitoring > Board RTWP. The results
will be generated in 20 minutes.
Issue 01 (2011-08-11)

5-4
5.2 Delivery Failure in NodeB Licenses by the M2000

5.2.1 Description
When the M2000 delivers a NodeB license, the delivery status is displayed Error on the
M2000, as shown in the following figure. However, the query result of the command DSP
LICENSE on the NodeB shows that the license status remains unchanged.

The O&M channels between the M2000 and NodeBs are faulty.
The license control item configurations are incorrect.

Check whether the problem is caused by incorrect license control item configuration. If not,
check whether the O&M channels between the M2000 and NodeBs are faulty. If not, redeliver
the license.

1. Double-click a row with Error, as shown in the preceding figure. Details for the incorrect
control item are displayed, as shown in the following figure:
Issue 01 (2011-08-11)

5-5
Troubleshoot the problem based on the details.

A license control item is switched on if it is set to Y or a number other than 0; it is switched
off if it is set to N or 0. It is not configured if it is set to unsetting (as shown in the following
figure), in which case its default value is used. The item has no limitation if it is set to
unlimited.
Common errors for license control items are as follows:
z
The number of uplink or downlink CEs exceeds the number allowed by the license.
The number of local cells exceeds the number allowed by the license.
The control item HSUPA is switched off.
The number of cells with transmit power of xx exceeds the value of PA[XXdBm].
Issue 01 (2011-08-11)

5-6
The control item DYNC CE is switched off.
2. Check whether the O&M channels between the M2000 and NodeBs are normal and whether
the status of the NodeBs is normal on the main topology of the M2000.
3. Redeliver the license.
Issue 01 (2011-08-11)

5-7
Information to Be
Collected
Method
Result
WMPT logs of three

NodeBs for which the
license delivery fails
On the M2000, choose Software > Software Browser > NE.

Select the corresponding NodeB and click Other on the right side
of the window. Right-click the log to be uploaded and choose
From NE to OMC Server from the shortcut menu.
NodeB WMPT
logs
On the left side of the window, click OMC Server. Select the
corresponding NodeB and click Other on the right side of the
window. Right-click the log to be downloaded to the local PC and
choose Transfer > From NE to OMC Client.
A screen capture for the
license delivery failure
When the license delivery fails, save the screen capture of the
current window in .jpg format.
A screen
capture for the
license delivery
failure
A screen capture for the

detailed cause of the
license delivery failure
Double-click the NodeB with delivery failure and save the screen
capture of the displayed window in .jpg format.
A screen
capture for the
detailed cause
of the license
delivery failure
License file to be
delivered
Obtain the license file to be delivered in .dat format.
License file to
be delivered
Issue 01 (2011-08-11)

5-8
6 Troubleshooting Transmission Faults
Troubleshooting Transmission Faults
6.1 IP QoS-related Problems

6.1.1 Interrupted IP Transmission on an FE Port
Description
IP transmission on an FE port is interrupted, leading to packet exchange failures and service
interruption. Execution results of the RNC MML command DSP ETHPORT show that the
port status is unavailable.
The following alarms and one event are reported on the RNC:
z
ALM-21345 Ethernet Link Fault
ALM-21347 IP Address Conflict
ALM-21541 SCTP Link Fault
ALM-22202 UMTS Cell Unavailable
ALM-21581 Path FaultALM-22214 NodeB Unavailable
EVT-22852 Active/Standby Ethernet Port Switchover Event
The following alarms are reported on the NodeB:

z
ALM-25880 Ethernet Link Fault
ALM-28253 Ethernet Link Abnormal
ALM-25885 IP Address Conflict
ALM-25888 SCTP Link Fault

The alarm ALM-21581 Path Fault is reported if an IP path is under a ping test.
Possible Causes
z
Ethernet cables or optical cables may be incorrectly connected or faulty.
The negotiation mode of the Ethernet ports on the NodeB or RNC is inconsistent with
that of the Ethernet ports on devices interconnected with the NodeB or RNC.
Virtual local area network (VLAN) configurations and Address Resolution Protocol
(ARP) security-related configurations are incorrect.
Route configurations are incorrect or exceptions occur on the devices involved.
Issue 01 (2011-08-11)

6-1

z
The Quality of service (QoS) policy for the transport network is inappropriate.
Troubleshooting Methods
If IP transmission on an FE port is interrupted, analyze reported alarms and events, conduct
ping tests, trace IP packets, query the ARP tables by running the DSP ARP command, or
query the routing tables by running the DSP IPRT command.
The section Troubleshooting Procedure provides guidelines for checking whether faults occur
at the physical, data link, or IP layer.
For details on how to conduct a ping test and how to trace IP packets, see section 6.1.3 "Verification
Methods."
Troubleshooting Procedure
1. Troubleshoot the physical layer.
Check whether the duplex mode for Ethernet ports on the NodeB is consistent with that on the
RNC, whether Maximum Transfer Unit (MTU) configurations are appropriate, and whether
there are errors in the IP packets received by the RNC and NodeB. For details, see section
6.1.3 "Verification Methods."
Check whether optical cables are connected correctly. Remove one optical cable from the
transmit end and check whether a relevant alarm is generated on the receive end. If a relevant
alarm is generated, the cable is properly connected.
2. Troubleshoot the data link layer.
Check whether VLAN configurations are correct. For two interconnected devices, VLAN IDs
between interconnected ports on the two devices must be consistent. Otherwise, the two
devices cannot communicate with each other. Further, note the following:
z
If load sharing and VLAN are applied to ports on the active and standby boards of the
RNC, VLAN IDs between these ports must be the same. You can add a VLAN ID to a
specific port by running the ADD VLANID command.
If a VLAN is applied to the NodeB, a VLAN must be also applied to Stream Control
Transmission Protocol (SCTP) links, IP paths carrying user data, common channels
carrying user data, and O&M channels. If an IP clock is configured, a VLAN must be
applied to IP clock links, and the VLAN IDs of these links must be consistent with the
network plan. If the NodeB is configured with multiple next hops, you must distinguish
them according to the network plan when applying the VLAN to the NodeB. You can run
the LST VLANMAP and LST VLANCLASS commands to query VLAN
configurations for the NodeB.
Check whether there are ARP tables corresponding to the RNC, NodeB, and router.
3. Troubleshoot the IP layer.
Check whether IP route configurations are correct and whether these configurations have
taken effect. Devices whose IP addresses belong to different network segments must be
configured with routers.
Check whether the local end is correctly connected to the peer end, and whether the two ends
are correctly connected to the gateway by conducting IP tests. When conducting an IP test,
you are advised to use IP packets with different packet sizes and different differentiated
services code point (DSCP) values. For details, see section 6.1.3 "Verification Methods."
Issue 01 (2011-08-11)

6-2
Locate faults by tracing IP packets. For details, see section 6.1.3 "Verification Methods."
If you are not sure whether faults occur on universal terrestrial radio access network (UTRAN) devices
or in the transport network even though you have ensured that configurations are correct and appropriate,
connect a PC to the NodeB or RNC to narrow down areas where the faults may occur.
Information to Be
Collected
Method
Result
RNC and NodeB

configuration files
Run the RNC MML command EXP CFGMML to

obtain RNC configurations, and obtain the NodeB
configuration file using the LMT or M2000.
WMPT logs, RNC

configuration file, and
alarms reported on the RNC
Networking and cable

connections
Check cable connections and the security and

reliability of the networking.
Detailed networking
Ethernet port status
Run the LST ETHPORT and DSP ETHPORT

commands on the RNC or NodeB LMT to check
the Ethernet port status.
Execution results
ARP tables
Run the DSP ARP command on the RNC or

NodeB LMT to check ARP tables.
Execution results
Routing tables
Run the LST IPRT and DSP IPRT commands on

the RNC or NodeB LMT to check routing tables.
Execution results
Pinged IP packets
Ping the RNC or NodeB IP address using IP

packets with different packet sizes and different
DSCP values.
Execution results
Traced IP packets
Run the RNC MML command TRC IPADDR to

trace IP packets, and run the NodeB MML
command TRACERT to trace IP packets.
Execution results
Configurations and QoS

policy of the transport
network
Check configurations, QoS policy, bandwidth

utilization, and congestion condition of the
transport network.
Operation results
6.1.2 IP Packets Lost

Description
Some IP packets are lost, leading to packet exchange failures and service interruption.
The following alarms are reported on the RNC:
z
ALM-21542 SCTP Link Congestion
ALM-21352 IP Path Excessive Packet Loss Rate
Issue 01 (2011-08-11)

6-3
ALM-25889 SCTP Link Congestion
ALM-25898 IP Path Excessive Packet Loss Rate
Users experience poor speech quality, the call drop rate is high, and the HSPA data rate is low
or greatly fluctuates.
Possible Causes
z
There is strong interference due to poor cable quality.
The negotiation mode of Ethernet ports on the NodeB or RNC is inconsistent with that of
Ethernet ports on the interconnected device.
QoS policy for the transport network is inappropriate.
Bandwidth or data rate is limited.
Faults occur on the transport network or on the devices involved.
If some IP packets are lost, analyze the reported alarms and events, conduct ping tests, or
trace IP packets.
at the physical, data link, or IP layer.
For details on how to conduct a ping test and how to trace IP packets, see section 6.1.3 "Verification
Methods."
1. Troubleshoot the physical layer.
Check whether parameter settings for Ethernet ports on the NodeB or RNC are consistent
with those for Ethernet ports on the interconnected device, whether MTU configurations are
appropriate, and whether there are errors in the IP packets received by the RNC and NodeB.
For details, see section 6.1.3 "Verification Methods."
Check whether Ethernet cables are functioning correctly. Replace one Ethernet cable with a
new one and check whether IP packets are received correctly. If no IP packets are lost, the
replaced Ethernet cable was the cause of the problem. If some IP packets are still lost, the
replaced Ethernet cable is not faulty.
Check whether optical cables are correctly connected to receive ports, transmit ports, active
ports, or standby ports on devices. Ensure that cables do not cross. If you still cannot locate
the fault, connect a PC to the NodeB or RNC to narrow down areas where faults may occur.
2. Ping all the involved routers, the RNC, and the NodeB in sequence.
If some packets are lost when you ping the NodeB from the RNC, ping all the involved
routers and the NodeB in sequence to locate the device where these packets are lost. You can
also perform these operations on the NodeB if some packets are lost when you ping the RNC
from the NodeB.
Conduct IP tests to check whether the local end is connected correctly to the peer end and
whether the two ends are connected correctly to the gateway. When conducting an IP test, use
IP packets with different packet sizes and different DSCP values. For details, see section 6.1.3
"Verification Methods."
Issue 01 (2011-08-11)

6-4
Method
Result
RNC and NodeB configuration

files
Run the RNC MML command

EXP CFGMML to obtain RNC
configurations and obtain the
NodeB configuration file using
the LMT or M2000.
WMPT logs, RNC

configuration file,
and alarms reported
on the RNC
Networking and cable connections
Check cable connections and

the security and reliability of
the networking.
Detailed networking
Ethernet port status
Run the LST ETHPORT and

DSP ETHPORT commands on
both the RNC LMT and
NodeB LMT to check the
Ethernet port status.
Execution results
Pinged IP packets
Ping the RNC or NodeB IP

address using IP packets with
different packet sizes and
different DSCP values.
Execution results
Traced IP packets
Run the RNC MML TRC

IPADDR command to trace IP
packets and run the NodeB
MML TRACERT command to
trace IP packets.
Execution results
Configurations and QoS policy of

the transport network
Check configurations, QoS

policy, bandwidth utilization,
and congestion condition of
the transport network.
Operation results
6.1.3 Verification Methods

Querying Properties of an Ethernet Port
1) Theory
After running the DSP ETHPORT command several times on the RNC or NodeB LMT, save
all the execution results and compare them to obtain the operating status of a specific port.
2) Operation
Run the DSP ETHPORT command at least five times at intervals of 10 seconds. You can run
this command more times and extend the interval to suit onsite conditions.
3) Example
Run the DSP ETHPORT command on the RNC LMT to query the properties of an Ethernet
port, as shown in the following figure:
Issue 01 (2011-08-11)

6-5
Port No. must be set to the port number of the Ethernet port.
Run the DSP ETHPORT command on the NodeB LMT to query the properties of an
Ethernet port, as shown in the following figure:
Port No. must be set to the port number of the Ethernet port.
Clear Statistic specifies whether to clear statistic values from the execution results after the command is
executed.
4) Analysis of execution results

The following figure shows the results of the command executed on the RNC LMT:
Issue 01 (2011-08-11)

6-6
Max transmit unit indicates the maximum size of data that can be transmitted over the
Ethernet port. Currently, this parameter is consistently set to 1500 on all UTRAN devices. For
devices in the transport network, this parameter must be set to a value greater than 1500.
Speed and Duplex indicate the working mode of the Ethernet port. If the RNC is
interconnected with another device, the duplex mode of this port must be consistent with that
of the corresponding port on the interconnected device. Otherwise, some packets may be lost,
errors may occur in received IP packets, or services may be interrupted.
Link Availability Status indicates the current link status. If the value is Unavailable, the IP
transmission is interrupted.
Rx correct bytes indicates the size of correct packets received by this port and Tx correct
bytes the size of correct packets transmitted from this port. By comparing the execution
results of the DSP ETHPORT command from each time, you can determine whether this port
is transmitting and receiving packets correctly.
Rx bad bytes indicates the size of incorrect packets received by this port and Tx bad bytes
the size of incorrect packets transmitted from this port. If values of these two parameters are
not 0, this port has received or transmitted incorrect packets.
Issue 01 (2011-08-11)

6-7
If values of Number of received Multicast frame and Number of received broadcast

frame remain unchanged, this port does not experience storms of broadcast packets or
multicast packets.
Ping
You can ping the NodeB on the RNC or ping the RNC on the NodeB.
1) Theory
When you ping the peer end from the local end, an Internet Control Message Protocol (ICMP)
echo request packet is automatically sent to the peer end. Upon receiving the packet, the peer
end responds with an ICMP packet.
With the Ping function, O&M personnel can check whether a device is connected correctly to
the transport network, whether transmission is stable, whether transmission delay or variation
occurs, and whether packets are correctly transmitted and received. In addition, by pinging all
the involved devices one by one, O&M personnel can locate faults accurately and efficiently.
If you ping another device on the RNC, set the size of ICMP packets, TTL value, DSCP value,
number of ping tests, test frequency, and response expiration threshold. If you ping another
device on the NodeB, set the size of ICMP packets, DSCP value, number of ping tests, and
response expiration threshold.
Set Size of packet to 20, 500, or 1500 and use the DSCP value of 48, 46, 38, 22, 14, or 0 to
perform a ping test. If possible, try all of these values.
2) Example
The following operations are performed on the RNC LMT.
Run the RNC MML command PING IP with Source IP address, Destination IP address,
Subrack No., and Slot No. set to appropriate values. Set Differentiated services code point
to an appropriate value if you want to check whether a specific ICMP packet with a certain
DSCP value is transmitted or received correctly.
The following figure shows the interface where you can set the preceding parameters:
The following table describes the parameters involved:
Issue 01 (2011-08-11)

6-8
Parameter
Meaning
Source IP address
IP address of the local end
Destination IP address
IP address of the peer end
Continue Ping or not
Whether to ping the peer end continuously. If you set this parameter to NO,
you must specify the Packet Number parameter. If you want to check
whether some packets are lost, delay variation occurs, or transmission is
interrupted, set Packet Number to a large value, for example, 1000.
Size of packet
Size of ICMP packets
Reply Time-Out
Response expiration threshold
Interval of send
Ping test interval
Differentiated services code point
DSCP value in an ICMP packet
Time to Live
TTL value in an ICMP packet
The following operations are performed on the NodeB LMT.

Run the NodeB MML command PING with Source IP, Destination IP, Subrack No., and
Slot No. set to appropriate values. Set Differentiated services code point to an appropriate
value if you want to check whether a specific ICMP packet with a certain DSCP value is
transmitted or received correctly.
The following figure shows the interface where you can set the preceding parameters:
Issue 01 (2011-08-11)

6-9

Parameter
Meaning
Packet Size(byte)
Size of ICMP packets
Timeout(ms)
Response expiration threshold
Packet Number
Number of ping tests
Priority Rule
Priority rule for ping packets
DSCP
Appoint Interface
Whether to choose an output port for pinged packets

The following figure shows the execution results of the PING IP command when the
transport network is stable:
As shown in the preceding figure, the delay is shorter than 80 ms, and no packets are lost
because the number of transmitted packets equals the number of received packets.
The following figure shows the execution results of the command when exceptions occur in
the transport network:
Issue 01 (2011-08-11)

6-10
As shown in the following figure, the message "Request time out" is displayed, which
indicates that some packets are lost:
As shown in the preceding figure, if the value of time is greater than 80 ms, the transmission
delay is long. If the value fluctuates with a large difference (for example, over 30 ms), delay
variation occurs. If the message "Request time out" is displayed multiple times, transmission
is interrupted.
Ping test results not only expose faults in the network but also provide the type and severity of
the problem. For example, if some packets are lost, you can figure out a packet loss rate based
on the number of transmitted ICMP packets and the number of received ICMP packets. This
loss rate tells you the severity of the problem.
4) Notes
If you want to check whether IP transmission is interrupted, set Packet Number to a value
greater than 1000 to ensure accurate test results.
Traceroute
1) Theory
Traceroute enables users to obtain next hops on an IP path between the transmit end and
receive end by using ICMP expired packets, ICMP unreachable packets, and the TTL field in
headers of IP packets. If the transmit end sends a router an IP packet with a TTL value of 0,
the router discards the packet and responds with an ICMP expired packet. The transmit end
can then obtain the IP address of this router. By sending ICMP unreachable packets, the
transmit end determines whether packets have reached the destination router. If the receive
Issue 01 (2011-08-11)

6-11
end cannot receive IP packets, you can specify the maximum TTL value and then trace IP
packets to locate faults accurately and efficiently.
2) Operation
The following operations are performed on the RNC LMT.
Run the RNC MML command TRC IPADDR, as shown in the following figure:

Parameter
Meaning
Source IP address
Source IP address
MAX TTL
Maximum TTL value
Number of
TRACERT Packages
Per TTL
Number of traceroute packets when a specific TTL value is used
Reply Time-out
Length of time the sender waits for a response
MTU Detect switch
Switch for an MTU detection
The following operations are performed on the NodeB LMT.

Run the NodeB MML command TRACERT, as shown in the following figure:
Issue 01 (2011-08-11)

6-12

Parameter
Meaning
TTL First
Start TTL value for a traceroute packet
TTL Max
Maximum TTL value for a traceroute packet
UDP Port
Destination UDP port number of a traceroute packet
Probe Packet Number
Number of traceroute packets when a specific TTL value is used
Timeout
Length of time the sender waits for a response
DF Switch
Switch for enabling the MTU detection function. This switch is

turned off by default.
DSCP

The following figure shows the execution results of the RNC MML command TRC IPADDR
when the transport network is stable:
Issue 01 (2011-08-11)

6-13
As shown in the preceding figure, four next hops are displayed.

If errors occur on the IP path, trace the IP packet sent to the destination IP address by setting
the TTL value to 1. The following figure shows the tracing results:
Then, increase the TTL value next time you trace IP packets. If tracing results are displayed as
asterisks when a specific TTL value is used, the corresponding next hop is faulty.
6.2 ATM QoS-related Problems

6.2.1 Interrupted ATM Transmission
Description
ATM transmission is interrupted, leading to cell exchange failures and service interruption.
z
ALM-21531 SAAL Link Fault
Issue 01 (2011-08-11)

6-14
ALM-28255 Transport Configuration Failure
ALM-25901 Remote Maintenance Link Failure

The alarm ALM-21581 Path Fault is reported if a continuity check (CC) test is conducted on permanent
virtual circuits (PVCs).
Possible Causes
E1/T1 cables or optical cables are improperly connected or become faulty.
PVC layer configurations are incorrect.
QoS policy is incorrect.
Exceptions occur on all the devices involved.
If ATM transmission is interrupted, conduct a CC test on a PVC or run the RNC MML
command DSP AALVCCPFM or LOP VCL to check whether a disconnected PVC is
causing the ATM transmission interruption. For details, see section 6.2.3 "Verification
Methods."
at the physical, data link, or transport layer.
1. Check whether E1/T1 port configurations are correct, including the frame format, coding
scheme, scrambling mode, resistance capability, and grounding. To query these
configurations, run the RNC MML commands LST E1T1 and DSP E1T1 or the NodeB
MML command DSP E1T1WORKMODE.
Note the following when checking E1/T1 port configurations:
z
The configured resistance capability of an E1/T1 cable must be consistent with its actual
capability. In addition, its resistance capability on the local end must be consistent with
that on the peer end. 75-Ohm E1/T1 cables require grounding while 120 Ohm E1/T1
cables do not.
Frame format, scrambling mode, and coding scheme of an E1/T1 port on the local end
must be consistent with those of the corresponding E1/T1 port on the peer end.
Otherwise, the status of upper-layer links may become abnormal, the alarm ALM-21221
IMA Link Loss of Frame may be reported on the RNC, and the alarm ALM-25823 IMA
Link Loss of Frame may be reported on the NodeB.
If the coding scheme HDB3 is used, no scrambling mode needs to be activated. If the
coding scheme AMI is used, a scrambling mode must be activated; otherwise, the
IMAGRP negotiation will fail.
2. Check whether E1/T1 cable connections are correct, whether E1/T1 cables are correctly
connected and these cables do not cross, and whether inverse multiplexing over ATM (IMA)
links belong to the same IMA group on both the local end and the peer end.
1) Incorrect E1/T1 cable connections
Issue 01 (2011-08-11)

6-15
According to the network plan, ports 0 and 1 must be connected to B1 and ports 2 and 3 to B2.
The E1/T1 cables, however, are incorrectly connected, as shown in the following figure. In
this case, E1/T1 cables can operate properly but the carried links fail.
As a result, the following alarms are reported on the RNC:

z
ALM-21581 Path Fault ALM-22202 UMTS Cell Unavailable

z

The alarm ALM-21581 Path Fault is reported if a CC test is conducted on PVCs.
Adding new links, deleting existing links, or resetting carried links cannot solve the problem.
To check whether an E1/T1 cable is properly connected, disconnect the cable on the local end
and check the port on the peer end that reports an E1/T1 loss of signal alarm. If the port is the
one specified by the network plan, the cable is correctly connected. Otherwise, the cable is
incorrectly connected.
2) Crossed pair E1/T1 cable connections
As shown in the following figure, three E1/T1 cables cross each other. In this case, no alarms
are reported but the carried IMA or MP links fail. To check whether E1/T1 cables cross each
other, perform the operations described in the preceding section Incorrect E1/T1 cable
connections.
Issue 01 (2011-08-11)

6-16
3) IMA links that belong to the same IMA group on the local end but belong to different IMA
groups on the peer end
As shown in the following figure, device A is connected to device B using two E1/T1 cables
and to device C using another two E1/T1 cables. These four IMA links belong to the same
IMA group on device A, but belong to two different IMA groups on device B and device C.
3. Check whether E1/T1 link quality is high.

Run the STR E1T1ONLTST command to start an E1/T1 online test and run the STP
E1T1ONLTST command to stop the test to check whether bit errors occur in the
corresponding E1/T1 link. If the test results show that the bit error rate (BER) is lower than
0.001%, the link quality is high. Otherwise, the link quality is poor and services will be
affected.
z
Check whether the following PVC settings are correct:
Constant bit rate (CBR)
Real-time variable bit rate (rt-VBR)
Non-real-time variable bit rate (nrt-VBR)
Unspecified bit rate (UBR)
Unspecified Bit Rate Plus (UBR+)
Peak cell rate (PCR)
Sustainable cell rate (SCR)
Receive Cell Rate (RCR)
Minimum cell rate (MCR)
Cell delay variation tolerance (CDVT)
Note the following when checking PVC configurations:

z
Types of services carried on PVCs on the local end must be consistent with those on the
peer end. Bandwidth configurations on the local end must also be consistent with those
on the peer end.
Configured bandwidth of a PVC must not exceed the physical bandwidth of the
corresponding E1/T1 cable or the bandwidth of the corresponding logical port.
Otherwise, some cells may be lost.
Physical bandwidth of an E1/T1 cable or bandwidth of the corresponding logic port must
exceed the sum of the following three rates:
Issue 01 (2011-08-11)

6-17
MCR of the corresponding PVC carrying O&M channels with an ATM service type
of UBR+
PCR of the PVC carrying signaling data with an ATM service type of CBR or
RTVBR
SCR of the PVC carrying speech data with an ATM service type of CBR or RTVBR
If this condition is not met, some cells may be lost.

4. Troubleshoot the transport network and locate the PVC breakpoints.
Query the configurations of all the transmission devices involved, and check performance
counter values and generated alarms of these transmission devices, especially at each PVC
breakpoint.
Analyze the distribution of the PVC breakpoints and highlight all convergence points.
5. If you still cannot locate the cause of the problem after performing this procedure, collect
information using the following table and contact Huawei technical support:
Information to Be
Collected
Method
Result
RNC and NodeB

configuration files
Run the RNC MML command EXP

CFGMML to obtain RNC configurations
and obtain the NodeB configuration file
using the LMT or M2000.
WMPT logs, RNC

configuration file,
and alarms reported
on the RNC

connections
Check cable connections and the security

and reliability of the networking.
Detailed networking
and cable
connection
verification records
Optical port status and

E1/T1 port status
Run the DSP E1T1, DSP IMAGRP, DSP

IMALNK, and DSP OPT commands on
both the RNC LMT and NodeB LMT to
check the optical port status and E1/T1
port status.
Execution results
E1/T1 online test
Run the STR E1T1ONLTST and STP

E1T1ONLTST commands on both the
RNC LMT and NodeB LMT to start and
stop an E1/T1 online test.
Execution results
CC test on a PVC
Run the ACT VCLCC and DSP VCLCC

commands to start a CC test on a PVC and
query the test results.
Execution results
Transport network
configurations and
QoS policy
Check configurations, QoS policy,

bandwidth utilization, and congestion
condition of the transport network.
Operation results
Issue 01 (2011-08-11)

6-18
6.2.2 ATM Cells Lost

Description
Some ATM cells are lost, leading to affected services or even service interruption.
z
ALM-21201 E1/T1 Loss of Signal
ALM-21203 E1/T1 Remote Alarm Indication Signal
ALM-21204 E1/T1 Alarm Indication Signal
ALM-21207 E1/T1 Excessive Bit Error Rate
ALM-21208 E1/T1 Excessive Slip Frames
ALM-21221 IMA Link Loss of Frame
ALM-21532 SAAL Link Congestion

z
ALM-25800 E1/T1 Loss of Signal
ALM-25804 E1/T1 Loss of Multiframe Alignment
ALM-25801 E1/T1 Alarm Indication Signal
ALM-25805 E1/T1 Excessive Slip Frames
ALM-25802 E1/T1 Remote Alarm Indication Signal
ALM-25823 IMA Link Loss of Frame
ALM-25824 IMA Link Out of Delay Synchronization
ALM-25821 IMA/ATM Link Loss of Cell Delineation
ALM-25834 IMA Group Blocked at Far End
ALM-25841 SAAL Link Congestion
If a large number of ATM cells are lost, the following alarms are reported on the RNC:
z
In addition, the following alarms are reported on the NodeB:

z

Users experience poor speech quality or even call drops, and the HSPA data rate is low. IP
over ATM (IPoA) O&M channels transfer MML commands slowly, and the results of the ping
test conducted on these O&M channels show that some packets are lost.
Possible Causes
z
E1/T1 cables or optical cables are improperly connected or become faulty.
There is strong interference on E1/T1 cables or optical cables.
Issue 01 (2011-08-11)

6-19
E1/T1 port configurations are incorrect such as the frame format, coding scheme,
scrambling mode, resistance capability, and slots.
Types of services carried on PVCs on the local end are inconsistent with those of PVCs
on the peer end.
Bandwidth configurations on the local end are inconsistent with those on the peer end.
QoS policy for the transport network is incorrect.
Transport network is congested.
Exceptions occur on all the involved devices.
If some ATM cells are lost, conduct a CC test on a PVC, enable the performance monitoring
(PM) function on a PVC, run the RNC MML command DSP AALVCCPFM or LOP VCL,
or ping IPoA O&M channels. For details, see section 6.2.3 "Verification Methods."
at the physical, data link, or transport layer.
1. Check whether E1/T1 port configurations are correct, including the frame format, coding
scheme, scrambling mode, resistance capability, and grounding. To query these
configurations, run the RNC MML commands LST E1T1 and DSP E1T1 or the NodeB
MML command DSP E1T1WORKMODE.
Note the following when checking E1/T1 port configurations:
z
The configured resistance capability of an E1/T1 cable must be consistent with its actual
capability. In addition, its resistance capability on the local end must be consistent with
that on the peer end. 75-Ohm E1/T1 cables require grounding while 120 Ohm E1/T1
cables do not.
Frame format, scrambling mode, and coding scheme of an E1/T1 port on the local end
must be consistent with those of the corresponding E1/T1 port on the peer end.
Otherwise, the status of upper-layer links may become abnormal, the alarm ALM-21221
IMA Link Loss of Frame may be reported on the RNC, and the alarm ALM-25823 IMA
Link Loss of Frame may be reported on the NodeB.
If the coding scheme HDB3 is used, no scrambling mode needs to be activated. If the
coding scheme AMI is used, a scrambling mode must be activated; otherwise, the
IMAGRP negotiation will fail.
2. Check whether E1/T1 cable connections are correct, whether E1/T1 cables are correctly
connected and these cables do not cross, and whether inverse multiplexing over ATM (IMA)
links belong to the same IMA group on both the local end and the peer end.
1) Incorrect E1/T1 cable connections
According to the network plan, ports 0 and 1 must be connected to B1 and ports 2 and 3 to B2.
The E1/T1 cables, however, are incorrectly connected, as shown in the following figure. In
this case, E1/T1 cables can operate properly but the carried links fail.
Issue 01 (2011-08-11)

6-20
As a result, the following alarms are reported on the RNC:

z
ALM-21581 Path Fault ALM-22202 UMTS Cell Unavailable

z

Adding new links, deleting existing links, or resetting carried links cannot solve the problem.
To check whether an E1/T1 cable is properly connected, disconnect the cable on the local end
and check the port on the peer end that reports an E1/T1 loss of signal alarm. If the port is the
one specified by the network plan, the cable is correctly connected. Otherwise, the cable is
incorrectly connected.
2) Crossed pair E1/T1 cable connections
As shown in the following figure, three E1/T1 cables cross each other. In this case, no alarms
are reported but the carried IMA or MP links fail. To check whether E1/T1 cables cross each
other, perform the operations described in the preceding section Incorrect E1/T1 cable
connections.
3) IMA links that belong to the same IMA group on the local end but belong to different IMA
groups on the peer end
Issue 01 (2011-08-11)

6-21
As shown in the following figure, device A is connected to device B using two E1/T1 cables
and to device C using another two E1/T1 cables. These four IMA links belong to the same
IMA group on device A, but belong to two different IMA groups on device B and device C.
3. Check whether E1/T1 link quality is high.

Run the STR E1T1ONLTST command to start an E1/T1 online test and run the STP
E1T1ONLTST command to stop the test to check whether bit errors occur in the
corresponding E1/T1 link. If the test results show that the BER is lower than 0.001%, the link
quality is high. Otherwise, the link quality is poor and services will be affected.
Check whether the following PVC settings are correct:
z
Constant bit rate (CBR)
Real-time variable bit rate (rt-VBR)
Non-real-time variable bit rate (nrt-VBR)
Unspecified bit rate (UBR)
Unspecified Bit Rate Plus (UBR+)
Peak cell rate (PCR)
Sustainable cell rate (SCR)
Receive Cell Rate (RCR)
Minimum cell rate (MCR)
Cell delay variation tolerance (CDVT)
Note the following when checking PVC configurations:

z
Types of services carried on PVCs on the local end must be consistent with those on the
peer end. Bandwidth configurations on the local end must also be consistent with those
on the peer end.
Configured bandwidth of a PVC must not exceed the physical bandwidth of the
corresponding E1/T1 cable or the bandwidth of the corresponding logical port.
Otherwise, some cells may be lost.
Physical bandwidth of an E1/T1 cable or bandwidth of the corresponding logic port must
exceed the sum of the following three rates:
Issue 01 (2011-08-11)
MCR of the corresponding PVC carrying O&M channels with an ATM service type
of UBR+

6-22
PCR of the PVC carrying signaling data with an ATM service type of CBR or
RTVBR
SCR of the PVC carrying speech data with an ATM service type of CBR or RTVBR
If this condition is not met, some cells may be lost.

4. Troubleshoot the transport network and locate spots where some cells are lost.
Troubleshoot the transport network, locate the spots where some cells are lost, query
configurations of all the involved transmission devices, and check performance counter values
and generated alarms on these transmission devices.
Analyze the distribution of the spots where some cells are lost and highlight all convergence
spots.
5. If you still cannot locate the cause of the problem after performing this procedure, collect
information using the following table and contact Huawei technical support:
Information to Be
Collected
Method
Result
RNC and NodeB

configuration files
Run the RNC MML command EXP

CFGMML to obtain RNC configurations
and obtain the NodeB configuration file
using the LMT or M2000.
WMPT logs, RNC

configuration file,
and alarms reported
on the RNC

connections
Check cable connections and the security

and reliability of the networking.
Detailed networking
and cable
connection
verification records
Optical port status and

E1/T1 port status
Run the DSP E1T1, DSP IMAGRP, DSP

IMALNK, and DSP OPT commands on
both the RNC LMT and NodeB LMT to
check the optical port status and E1/T1
port status.
Execution results
E1/T1 online test
Run the STR E1T1ONLTST and STP

E1T1ONLTST commands on both the
RNC LMT and NodeB LMT to start and
stop an E1/T1 online test.
Execution results
PVC performance
Run the ACT VCLPM command on the

RNC or NodeB LMT to enable the PM
function for a PVC and run the DSP
VCLPM command on the RNC or NodeB
LMT to display the performance
measurement results for the PVC.
Execution results
Run the DSP AALVCCPFM command

on the RNC or NodeB LMT to query the
performance measurement results for a
PVC and run the LOP VCL command on
the RNC or NodeB LMT to start a loop
back test on a PVC.
Issue 01 (2011-08-11)

6-23
Information to Be
Collected
Method
Result
Configurations and
QoS policy of the
transport network
Check configurations, QoS policy,

bandwidth utilization, and congestion
condition of the transport network.
Operation results
6.2.3 Verification Methods

Conducting a CC test on a PVC
Both the RNC and NodeB support CC tests.
1) Theory
CC tests include continuity check tests and loopback tests.
2) Operation
Run the RNC MML command ACT VCLCC to start a CC test on a PVC.
3) Example
Run the RNC MML command ACT VCLCC to start a CC test on the test PVC, as shown in
the following figure:

Parameter
Meaning
Link type
Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support CC tests.
VCL act type
Type of CC test. CC tests include continuity check tests and loopback tests.
Activation mode
Activation mode for a CC test.

When this parameter is set to AUTO, the local end sends an activation cell to the
peer end. Upon receiving an activation response from the peer end, the local end
starts a CC test by sending CC cells.
When this parameter is set to MANUAL, the local end sends an activation cell to
the peer end and then starts a CC test by sending CC cells without waiting for an
activation response. Set this parameter to MANUAL for devices where the CC
function cannot be enabled automatically.
Issue 01 (2011-08-11)

6-24
Parameter
Meaning
Activation direction
Mode for the local end to determine the quality of a PVC.

When this parameter is set to SINK, the local end determines PVC quality based on
CC cells transmitted from the peer end.
When this parameter is set to SOURCE, the local end does not check PVC quality
and only sends CC cells to the peer end.
When this parameter is set to BOTH, the local end periodically sends CC cells to
the peer end, which then responds to these CC cells. Based on the received CC
cells, the local end checks PVC quality.
To conduct a CC test on a PVC (Adjacent node ID = 150; AAL2 path ID = 1; Activation

direction = BOTH), run the following command:
ACT VCLCC: LNKT=AAL2PATH, ANI=150, PATHID=1, VCLTYPE=CC, DR=BOTH,
CCMODE=AUTO;
Run the RNC MML command DEA VCLCC to stop a CC test.
4) Analysis of test results
If the following alarms are reported when software version RAN12.0 or later is used, some
CC cells are lost:
z
ALM-21321 VCL CC Detection Failure
ALM-21322 VCL Alarm Indication Signal
If the following alarms are reported when software version RAN11.0 or earlier is used, some
CC cells are lost:
z
ALM-401 F5 Loss of Continuity Alarm
ALM-402 F5 Alarm Indication Signal Alarm
5) Querying test results

To query test results, run the RNC MML command DSP VCLCC, as shown in the following
figure:
The following figure shows that the test PVC is functioning properly:
Issue 01 (2011-08-11)

6-25
5) Notes
Before conducting a CC test on a PVC, ensure that both the local end and peer end support
the test. Otherwise, the test cannot be started.
Enabling the PM function on a PVC

1) Introduction
As an important O&M function in the ATM transmission scheme, the PM function can
continuously monitor the performance of multiple PVCs and display monitoring results
including the cell loss rate, cell error rate, incorrect cell insertion rate, transmission delay, and
delay variation.
Currently, the PM function enabled on the RNC or NodeB can only detect lost or erroneous
cells.
2) Theory
The transmit end sends an FPM cell whenever a fixed number of cells has been sent to the
peer end. In each FPM cell, the verification code BIP16 records the number of cells
transmitted since the transmission of the previous FPM cell. Upon receiving an FPM cell, the
receive end compares the number of received cells with that indicated by BIP16 value. If the
number of received cells does not equal the BIP16 value, some cells may be lost or incorrectly
inserted. The receive end then responds with a BR cell containing the BIP16 value, the
number of received cells, and comparison result. After receiving the BR cell, the transmit end
calculates QoS-related counters and calculates the number of lost cells, incorrectly inserted
cells, and erroneous cells.
3) Operation
Run the ACT VCLPM command on the RNC or NodeB LMT to enable the PM function.
4) Example
Run the RNC MML command ACT VCLPM to enable the PM function for the test PVC, as
shown in the following figure:
Issue 01 (2011-08-11)

6-26

Parameter
Meaning
Link type
Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support the PM
function.
Activation mode
Activation mode for a performance monitoring task.

When this parameter is set to AUTO, the local end sends an activation cell to the
peer end. Upon receiving an activation response, the local end starts monitoring the
performance of the test PVC by sending PM cells.
When this parameter is set to MANUAL, the local end sends an activation cell to
the peer end and starts sending PM cells without waiting for an activation response.
Activation direction
Mode for the local end to determine the quality of a PVC.

When this parameter is set to SINK, the local end does not send FPM cells and only
responds to FPM cells sent from the peer end with BR cells.
When this parameter is set to SOURCE, the local end sends the peer end FPM cells
and calculates QoS-related counters based on BR cells sent from the peer end.
When this parameter is set to BOTH, the local end sends the peer end FPM cells,
processes FPM cells sent from the peer end, and responds with BR cells.
To enable the PM function for a PVC (Adjacent node ID = 150; AAL2 path ID = 1;
Activation direction = BOTH), run the following command:
ACT VCLPM: LNKT=AAL2PATH, ANI=150, PATHID=1, DR=BOTH, BSIZE=D1024,
PMMODE=AUTO;
Run the RNC MML command DEA VCLPM to disable the PM function for a PVC.
To obtain statistic parameter values within a specific period of time, run the RNC MML
command ACT VCLPM five times at an interval of 3 minutes, and save and compare the
execution results.
5) Querying the performance of the test PVC
To query the performance of the test PVC, run the RNC MML command DSP VCLPM, as
shown in the following figure:
Issue 01 (2011-08-11)

6-27
To obtain statistic parameter values within a specific period of time, run the DSP VCLPM
command five times at an interval of 3 minutes, and save and compare the execution results.
Running the RNC MML command DSP AALVCCPFM

1) Theory
You can run the RNC MML command DSP AALVCCPFM to query the number of
transmitted cells, received cells, bytes, and erroneous bytes for a PVC.
2) Operation
Run the RNC MML command DSP AALVCCPFM, as shown in the following figure:
Issue 01 (2011-08-11)

6-28

Parameter
Meaning
Link type
Type of the test PVC. You can query the performance of SAAL
links, IPoA PVCs, and AAL2 paths.

The following figure shows the execution results of the command:
Run the command multiple times at a fixed interval, and save and compare the execution
results. By doing this, you can obtain the number of transmitted, received, and erroneous cells
over the test PVC.
Pinging IPoA O&M channels

1) Theory
In ATM transmission mode, IPoA O&M channels are configured. By pinging an IPoA O&M
channel, you can check the transmission capability of a PVC carrying the IPoA O&M
channel.
2) Example
Run the RNC MML command LST UNODEBIP to query the IP addresses of a specific
NodeB, as shown in the following figure:
Issue 01 (2011-08-11)

6-29
Run the RNC MML command LST IPOAPVC to locate the PVC that carries the IPoA O&M
channel for the NodeB, as shown in the following figure:
Issue 01 (2011-08-11)

6-30
Run the RNC MML command PING IP with parameters set to appropriate values:
Common parameter settings are as follows:

z
Continue ping or not is set to YES(YES)
Size of packet is set to 64, 500, 1000, or 1500.
When setting a value for Size of packet, try all the preceding common values to obtain
accurate test results.
Issue 01 (2011-08-11)

6-31
As shown in the following figure, the packet loss rate and delay information are displayed in
the execution result:
Conducting a loopback test on a PVC

1) Theory
The RNC sends a probe cell and determines that the loopback test is successful if it receives
the probe cell returned from the peer end within a specific period of time. The test can also
measure the round trip time of a cell.
2) Operation
Run the RNC MML command LOP VCL to start a loopback test on a PVC, as shown in the
following figure:

Parameter
Meaning
Link type
Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support loopback tests.

The following figure shows that the loopback test failed:
Issue 01 (2011-08-11)

6-32
To accurately analyze the PVC quality, run the LOP VCL command multiple times, and save
and compare the execution results.
Issue 01 (2011-08-11)

6-33
7 Acronyms and Abbreviations
Acronyms and Abbreviations
AC
Access Class
AMR
Adaptive multirate
ARP
Address Resolution Protocol
BER
Bit error rate
CAC
Call admission control
CC
Connectivity check
CDT
Call detailed trace
CE
Channel element
CHR
Call history record
CN
Core network
DSCP
DSP
Digital signal processor
DSP
Destination signaling point
FAM
Front administration module
GBR
Guaranteed bit rate
HSDPA
High Speed Downlink Packet Access
HSPA
High speed packet access
HSUPA
High Speed Uplink Packet Access
ICMP
Internet Control Message Protocol
IMA
Inverse multiplexing over ATM
IOS
Intelligent optimum sample
IPoA
IP Over ATM
KPI
Key performance indicator
LAC
Location Area Code
Layer 2
L2
Issue 01 (2011-08-11)

7-1
7 Acronyms and Abbreviations
LMT
Local maintenance terminal
MTU
Maximum Transfer Unit
NRNC
Neighboring RNC
O&M
Operation and maintenance
OMCH
Operating &Maintenance Channel
PCHR
Performance call history record
PM
Performance monitoring
PVC
Permanent virtual circuit
QoS
Quality of service
RAC
Routing area code
RNC
Radio network controller
RTWP
Received total wideband power
SAC
Service Area Code
SCCP
Signaling connection control part
SCTP
Stream Control Transmission Protocol
SF
Spreading factor
TCP
Transmit Carrier Power
TMA
Tower Mounted Amplifier
TTL
Time to live
UTRAN
Universal terrestrial radio access network
VLAN
Virtual local area network
Issue 01 (2011-08-11)

7-2

RAN Troubleshooting Guide: Huawei Technologies Co., LTD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RAN Troubleshooting Guide: Huawei Technologies Co., LTD

Uploaded by

Copyright:

Available Formats

RAN Troubleshooting Guide

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential