RAN Troubleshooting Guide

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 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 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 recommendations in this document are provided "AS IS" without warranties, guarantees or representations 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 recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

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

Website:

http://www.huawei.com

Email:

[email protected]

Issue 01 (2011-08-11) (2011-08-11)

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

i

RAN Troubleshooting Troubleshooting Guide

About This Document

About This Document Change History This chapter describes the changes in the RAN Troubleshooting Guide.

01 (2011-08-11) (2011-08-11) This is the first commercial release release of RAN12.0.

Issue 01 (2011-08-11) (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 4.2.3 Troubleshooting Methods ............................................ ................................................................. ....... 4-6 4.2.4 Troubleshooting Procedure .................................................................................................................. 4-6

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.1.3 Troubleshooting Methods ............................................ ................................................................. ....... 5-2 5.1.4 Troubleshooting Procedure .................................................................................................................. 5-2 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 5.2.3 Troubleshooting Methods ............................................ ................................................................. ....... 5-5 5.2.4 Troubleshooting Procedure .................................................................................................................. 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)


v


1 Overview

1

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: 

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: 

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: 

BSC6900 UMTS OMU Administration Guide



LMT online help

Issue 01 (2011-08-11)


1-1


2

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: 

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: 

Consult the personnel who reported the fault about symptoms, ti me, 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: 

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:   

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

Telephone: (86) (755) 28560000 [Shenzhen, China] or 400-830-2118



Fax: (86) (755) 28560111



E-mail: [email protected]



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

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: 

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



Application Scenarios 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 t roubleshooting 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.

Application Scenarios 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 t he 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: 

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

Application Scenarios 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: 

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

Application Scenarios 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.

Application Scenarios 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



Application Scenarios 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.

Application Scenarios 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: 

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

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: 

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: 

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



Issue 01 (2011-08-11)

NodeB fault information on the M2000


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 t he 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: 

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 t he 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 1. Run the following MML command: 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 1. Run the following MML command: 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.

2. Obtain log files. 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.

5. Obtain log files. After the preceding commands are 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 path of the saved logs. ---End

3.4.6 Collecting Traffic Statistics 1. Run the following MML command: COL LOG: LOGTYPE=PFM_RESULT-1;

2. Obtain log files. 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 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: Run the following command: 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: 

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: 

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 t he 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

4

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  

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

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

1

Demo_BSC6900_V900R013_UO_20110727.dat

2

license.dat

Y

N

(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


4 RNC Troubleshooting =

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

Run the following command: 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.

4.2.2 Possible Causes 

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 C N side.



Resources of certain cells, such as power, code, transmission, and channel element (CE) resources, are congested.

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

4.2.4 Troubleshooting Procedure 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: 

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: 

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 t hrough 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 t he 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, collect information using the following table and contact Huawei technical support:

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

Run the following command:

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.

Related files in the bam\common\measResult directory

Binary logs

Get the CALL FAULT, DEBUG, and CHR logs generated 20 minutes before and after the fault occurs.

Related files in the 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



Information to Be Collected Method

Result

Iu interface tracing result file

LMT tracing files

Issue 01 (2011-08-11)

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.


4-14


5 NodeB Troubleshooting

5

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: 

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: 

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 −106±4 dBm. The RTWP is 102 dB or less than −110 dB or if the abnormal if its value is continuously greater than −  RTWP peak value is continuously greater than 80 dB.

5.1.2 Possible Causes Abnormally high RTWP: 

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: 

The value for Attenuation of RX Channel is too large.



The antenna is not properly installed.

Issue 01 (2011-08-11)


5-1



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

5.1.4 Troubleshooting Procedure 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 s etting 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 t ype 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




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.

3. If you still cannot locate the cause of the problem after performing the preceding procedure, collect the following information and contact Huawei technical support:  

Issue 01 (2011-08-11)

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.


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.

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

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

5.2.4 Troubleshooting Procedure 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: 

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. 4. 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:

Issue 01 (2011-08-11)


5-7


5 NodeB Troubleshooting Troubleshooting


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) (2011-08-11)


5-8


6

6 Troubleshooting Troubleshooting Transmission 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: 

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 EVT-22852 Active/Standby Ethernet Port Switchover Event

The following alarms are reported on the NodeB: 

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 

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) (2011-08-11)


6-1

RAN Troubleshooting Troubleshooting Guide 


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 alarms and events, conduct ping tests, trace IP packets, query the ARP tables 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." Methods ."

Troubleshooting Procedure 1. Troubleshoot the physical layer. Check whether the duplex mode for Ethernet ports on the NodeB i s 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." Methods." Check whether optical cables are connected correctly. Remove one optical cable from t he 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 interconnected ports on the two devices must be consistent. Otherwise, Otherwise, the two devices cannot communicate with each other. Further, Further, note the following: 

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 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 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 differentiated services code point (DSCP) values. For details, see section 6.1.3 "Verification Methods." Methods."

Issue 01 (2011-08-11) (2011-08-11)


6-2


6 Troubleshooting Transmission Faults

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.



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: 

ALM-21542 SCTP Link Congestion



ALM-21352 IP Path Excessive Packet Loss Rate




The following alarms are reported on the NodeB:

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 

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.

Troubleshooting Methods If some IP packets are lost, analyze the reported alarms and events, conduct ping tests, or trace IP packets. 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." Methods ."

Troubleshooting Procedure 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." 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. devices. Ensure that cables cables do not cross. If you still cannot cannot locate the fault, connect a PC to the t he 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 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." Methods."

Issue 01 (2011-08-11) (2011-08-11)


6-4





Method

Result


Run the RNC MML command EXP CFGMML to obtain RNC configurations and obtain the NodeB configuration file using the LMT or M2000.


Networking and cable cable connections

Check cable connections 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 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 NodeB MML TRACERT command to trace IP packets.

Execution results



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 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 following figure:

Issue 01 (2011-08-11) (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) (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

3) Analysis of execution results 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 t he 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


3) Analysis of execution results The following figure shows the execution results of the R NC 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. The following alarms are reported on the RNC: 

ALM-21531 SAAL Link Fault







The following alarms are reported on the NodeB:

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.

Troubleshooting Methods 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." The section Troubleshooting Procedure provides guidelines for checking whether faults occur at the physical, data link, or transport layer.

Troubleshooting Procedure 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: 

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: 




ALM-21581 Path Fault ALM-22202 UMTS Cell Unavailable








ALM-25901 Remote Maintenance Link Failure 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. 

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: 

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:


Method

Result






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


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. The following alarms are reported on the RNC: 

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


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: 








In addition, the following alarms are reported on the NodeB: 




ALM-28255 Transport Configuration Failure The alarm ALM-21581 Path Fault is reported if a CC test is conducted on PVCs.

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 

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.

Troubleshooting Methods If some ATM cells are lost, conduct a CC test on a PVC, enable the performance monitoring (PM) function on a PVC, run the R NC MML command DSP AALVCCPFM or LOP VCL, or ping IPoA O&M channels. For details, see section 6.2.3 "Verification Methods." The section Troubleshooting Procedure provides guidelines for checking whether faults occur at the physical, data link, or transport layer.

Troubleshooting Procedure 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: 

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: 




ALM-21581 Path Fault ALM-22202 UMTS Cell Unavailable








ALM-25901 Remote Maintenance Link Failure 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.

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: 

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: 

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:


Method

Result






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




Method

Result



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: 

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: 

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, t he 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 t he 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 ti me, 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.

3) Analysis of execution results 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: 

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. 3) Analysis of execution 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.

3) Analysis of execution results 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

7

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

RAN Troubleshooting Guide

Recommend Documents