71271900 GBSS9 0 Troubleshooting Guide

GBSS9.0

Troubleshooting Guide

Issue 01

Date 2011–8–17

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 writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied.

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

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2011–8–17) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

About This Document

OverviewThis document provides methods for troubleshooting the GBSS in the following scenarios:

l Customers lodge complaints.

l Faults are discovered during routine maintenance.

l Equipment faults occur abruptly.

Product VersionThe following table lists the product versions related to this document.

Product Name Product Version

BSC6900 V900R011C00

BTS3900 BTS3900V100R002C00SPC011

BTS3000 BTS3000V100R009C00SPC011

BTS3012/BTS3012AE/BTS3012II/BTS3006C/BTS3002E

BTS3000V100R008C11SP03 and later

DBS3900 BTS3000V100R008C11 and later

BTS3900/BTS3900A BTS3000V100R008C11 and later

BTS3900B/BTS3900E V100R008 and later

BTS30/BTS312/BTS3012A V302R007 and later

Intended AudienceThis document is intended for:

l Maintenance engineers

l Field engineers

GBSS9.0Troubleshooting Guide About This Document


ii

Organization1 Change in the GBSS Troubleshooting Guide

This chapter describes the changes in the GBSS Troubleshooting Guide.

2 Troubleshooting Procedure

This chapter describes the basic troubleshooting procedure and each step.

3 Common Maintenance Functions

This chapter describes common maintenance functions used during fault location.

4 Handover Problems

This chapter describes how to locate and troubleshoot handover problems.

5 Call Drops

This chapter describes how to locate and troubleshoot call drops.

6 Access Faults

This chapter describes how to locate and troubleshoot access faults.

7 Voice Problems

This chapter describes how to locate and troubleshoot voice problems.

8 PS Counter Problems

This chapter describes how to locate and troubleshoot PS counter problems.

9 PS Channel Faults

This chapter describes how to locate and troubleshoot PS channel faults.

10 Cell PS Service Faults

This chapter describes how to locate and troubleshoot cell PS service faults.

11 IP Transmission Faults

This chapter describes how to locate and troubleshoot IP transmission faults.

12 Interference Problems

This chapter describes how to locate and troubleshoot interference problems.

13 Faults on Main and Diversity RX Channels

This chapter describes how to locate and troubleshoot faults on main and diversity receive (RX)channels.

14 No Traffic

This chapter describes how to locate and troubleshoot no traffic on 3900 series base stations.

ConventionsSymbol Conventions

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



iii

Symbol Description

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

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

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

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

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

General Conventions

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

Convention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are inboldface. For example, log in as user root.

Italic Book titles are in italics.

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

Command Conventions

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


Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

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

{ x | y | ... } Optional items are grouped in braces and separated byvertical bars. One item is selected.

[ x | y | ... ] Optional items are grouped in brackets and separated byvertical bars. One item is selected or no item is selected.



iv


{ x | y | ... }* Optional items are grouped in braces and separated byvertical bars. A minimum of one item or a maximum of allitems can be selected.

[ x | y | ... ]* Optional items are grouped in brackets and separated byvertical bars. Several items or no item can be selected.

GUI Conventions

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


Boldface Buttons, menus, parameters, tabs, window, and dialog titlesare in boldface. For example, click OK.

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

Keyboard Operations

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

Format Description

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

Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently.

Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A meansthe two keys should be pressed in turn.

Mouse Operations

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

Action Description

Click Select and release the primary mouse button without movingthe pointer.

Double-click Press the primary mouse button twice continuously andquickly without moving the pointer.

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



v

Contents

About This Document.....................................................................................................................ii

1 Change in the GBSS Troubleshooting Guide.........................................................................1

2 Troubleshooting Procedure.........................................................................................................22.1 Troubleshooting Flowchart.................................................................................................................................32.2 Collecting Fault Information..............................................................................................................................32.3 Determining a Fault Type...................................................................................................................................6

2.3.1 Fault Types................................................................................................................................................62.3.2 Methods for Determining a Fault Type.....................................................................................................7

2.4 Identifying Fault Causes.....................................................................................................................................82.5 Troubleshooting Faults.......................................................................................................................................9

2.5.1 Overview...................................................................................................................................................92.5.2 Methods for Troubleshooting Faults.........................................................................................................92.5.3 Follow-up Procedure...............................................................................................................................10

3 Common Maintenance Functions............................................................................................113.1 Maintenance Functions for Identifying Voice Problems..................................................................................12

3.1.1 Querying Call Resource Usage of an MS................................................................................................123.1.2 External Voice Loopback........................................................................................................................123.1.3 One-Way Audio Detection......................................................................................................................183.1.4 Crosstalk Detection..................................................................................................................................183.1.5 Optimizing Um Interface Crosstalk.........................................................................................................19

3.2 Maintenance Functions for Identifying Transmission Problems......................................................................193.2.1 Crossed Pair Detection............................................................................................................................203.2.2 Monitoring Port BER Seconds................................................................................................................22

3.3 Maintenance Functions for Identifying Um and RF Problems.........................................................................223.3.1 Monitoring Channel Interference Bands.................................................................................................233.3.2 Detecting Intermodulation Interference by Testing Idle Timeslots.........................................................233.3.3 Scanning Uplink Frequencies..................................................................................................................25

3.4 Maintenance Functions Related to Interface Tracing.......................................................................................283.4.1 Tracing CS Domain Messages of a Single Subscriber............................................................................283.4.2 Tracing PS Domain Messages for a Single Subscriber...........................................................................29

3.5 Maintenance Functions for Identifying PS Problems.......................................................................................313.5.1 Monitoring Channel Status......................................................................................................................31

GBSS9.0Troubleshooting Guide Contents


vi

3.6 Maintenance Functions for Identifying Clock Problems..................................................................................333.6.1 Querying BSC Clock Source Status........................................................................................................333.6.2 Querying BSC Board Clock Status.........................................................................................................343.6.3 Maintaining BTS Clock...........................................................................................................................35

4 Handover Problems.....................................................................................................................374.1 Handover Principles.........................................................................................................................................38

4.1.1 Handover Procedure................................................................................................................................384.1.2 Handover Success Rate...........................................................................................................................40

4.2 Locating Handover Problems...........................................................................................................................434.2.1 Principles.................................................................................................................................................434.2.2 Procedure for Locating Handover Problems...........................................................................................43

4.3 Troubleshooting Handover Problems Due to Hardware Faults........................................................................454.4 Handover Problems Due to Incorrect Data Configurations..............................................................................484.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell.......................................524.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality.......................................................544.7 Troubleshooting Handover Problems Due to NE Faults..................................................................................584.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction................................................................................................................................................................................61

5 Call Drops.....................................................................................................................................665.1 Call Drop Rate..................................................................................................................................................675.2 Locating Call Drops..........................................................................................................................................68

5.2.1 Procedure for Locating Call Drops..........................................................................................................685.2.2 Counters Related to Call Drops...............................................................................................................705.2.3 Types of Call Drops.................................................................................................................................72

5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality......................................................................755.4 Troubleshooting Call Drops Due to Equipment Faults....................................................................................805.5 Troubleshooting Call Drops Due to Transmission Faults................................................................................835.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings...................................................................84

6 Access Faults.................................................................................................................................916.1 Access Principles..............................................................................................................................................936.2 Locating Access Faults.....................................................................................................................................94

6.2.1 Procedure for Locating Access Faults.....................................................................................................956.2.2 Common Causes for Access Faults.........................................................................................................99

6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality...............................................................1036.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion..........................1086.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults..............................................................................................................................................................................1136.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs..............................................................................................................................................................................1166.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion..................................................1196.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission Faults........................1236.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration.......................127



vii

7 Voice Problems..........................................................................................................................1317.1 GSM CS Signal Flow.....................................................................................................................................1327.2 Common Voice Problems and Problem Location Methods...........................................................................1377.3 Troubleshooting One-Way Audio or No Audio.............................................................................................1387.4 Troubleshooting Noise...................................................................................................................................1407.5 Troubleshooting Crosstalk..............................................................................................................................1427.6 Troubleshooting Echoes.................................................................................................................................1447.7 Troubleshooting Discontinuous Voice or Low MOS.....................................................................................146

8 PS Counter Problems................................................................................................................1498.1 PS Counters....................................................................................................................................................1508.2 Locating PS Counter Problems.......................................................................................................................151

8.2.1 Principles for Locating PS Counter Problems.......................................................................................1518.2.2 Procedure for Locating PS Counter Problems.......................................................................................151

8.3 Troubleshooting Low TBF Establishment Success Rates..............................................................................1528.4 Troubleshooting High TBF Call Drop Rates..................................................................................................1588.5 Troubleshooting Low Average Throughput at the RLC Layer......................................................................1638.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes...........................1688.7 Troubleshooting High RLC Data Block Retransmission Rates.....................................................................173

9 PS Channel Faults......................................................................................................................1779.1 Identifying PS Channel Faults........................................................................................................................1789.2 Locating PS Channel Faults...........................................................................................................................1789.3 Troubleshooting PDCH Faults Due to Channel Inactivity.............................................................................1809.4 Troubleshooting PDCH Faults Due to Channel Asynchronization................................................................183

10 Cell PS Service Faults.............................................................................................................18810.1 Remarks on Cell PS Service Faults..............................................................................................................18910.2 Locating Cell PS Service Faults...................................................................................................................18910.3 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations..........................................19010.4 Troubleshooting Cell PS Service Faults Due to Hardware Issues................................................................19210.5 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSC...................19410.6 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues...........................................................195

11 IP Transmission Faults...........................................................................................................19811.1 Troubleshooting FE/GE Transmission Faults..............................................................................................19911.2 Troubleshooting IP Layer Faults..................................................................................................................20411.3 Troubleshooting PPP or MLPPP Link Faults...............................................................................................20611.4 Troubleshooting LAPD Link Faults.............................................................................................................20911.5 Troubleshooting SCTP Link Faults..............................................................................................................21611.6 Troubleshooting IP Path Problems...............................................................................................................22111.7 Troubleshooting DHCP Problems................................................................................................................22311.8 Troubleshooting IP PM Activation Failures.................................................................................................22711.9 Troubleshooting IP Clock Faults..................................................................................................................229



viii

12 Interference Problems.............................................................................................................23612.1 Interference...................................................................................................................................................23712.2 Locating Interference Problems....................................................................................................................23812.3 Troubleshooting Co-channel or Adjacent-Channel Interference..................................................................23912.4 Troubleshooting Intermodulation Interference.............................................................................................24112.5 Troubleshooting Interference from the CDMA Network.............................................................................24612.6 Troubleshooting External Interference.........................................................................................................249

13 Faults on Main and Diversity RX Channels.......................................................................25213.1 Principles of Main and Diversity Reception.................................................................................................25313.2 Locating Faults on Main and Diversity RX Channels..................................................................................25313.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Data Configurations.........25413.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna Connections.......25613.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults..............................261

14 No Traffic..................................................................................................................................26314.1 Introduction to No Traffic............................................................................................................................26414.2 Locating No Traffic......................................................................................................................................26414.3 Troubleshooting No Traffic Due to No Calls...............................................................................................26614.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults......................................................26814.5 Troubleshooting No Traffic Due to Incorrect Data Configurations.............................................................27014.6 Troubleshooting No Traffic Due to Poor Um Interface Quality..................................................................27114.7 Troubleshooting No Traffic Due to Antenna System Faults........................................................................27314.8 Resetting.......................................................................................................................................................276



ix

1 Change in the GBSS Troubleshooting Guide

This chapter describes the changes in the GBSS Troubleshooting Guide.

01 (2011-08-17)This is the first commercial release.

GBSS9.0Troubleshooting Guide 1 Change in the GBSS Troubleshooting Guide


1

2 Troubleshooting Procedure

About This Chapter

This chapter describes the basic troubleshooting procedure and each step.

2.1 Troubleshooting FlowchartThis section shows the troubleshooting flowchart.

2.2 Collecting Fault InformationThis section provides methods for collecting information about faults and describes the faultinformation types.

2.3 Determining a Fault TypeAfter collecting fault information, analyze the symptoms to determine a fault type.

2.4 Identifying Fault CausesTo identify the specific cause of a fault, exclude possible causes by analyzing the symptoms.

2.5 Troubleshooting FaultsThis section provides the methods for troubleshooting faults as well as follow-up procedures.

GBSS9.0Troubleshooting Guide 2 Troubleshooting Procedure


2

2.1 Troubleshooting FlowchartThis section shows the troubleshooting flowchart.

Figure 2-1 shows the troubleshooting flowchart.

Figure 2-1 Troubleshooting flowchart

2.2 Collecting Fault InformationThis section provides methods for collecting information about faults and describes the faultinformation types.

Methods for Collecting Fault Information

Before troubleshooting a fault, collect the following information:

l Fault symptoms



3

l Time, place, and frequency of the faultl Fault range and impactl Equipment operating status before the fault occursl Operations performed on the equipment before the fault occurs and the operation resultsl Alarms generated when the fault occurs and the associated alarmsl Board indicator status when the fault occursl Measures taken after the fault occurs and the effects of measures

The methods for collecting fault information are as follows:

l Obtain the symptoms, time, place, and frequency of the fault from the subscribers andtechnical support engineers.

l Obtain the equipment operating status, symptoms, operations performed before the faultoccurs, as well as measures taken after the fault occurs and the effect of those measuresfrom the equipment operation and maintenance (O&M) engineers.

l Monitor the board indicator status and alarms reported on the LMT to understand thesoftware and hardware operating status.

l Simulate services, measure performance, and trace interface signaling messages tounderstand the fault range and impact.

NOTEIf you encounter severe faults, do not troubleshoot the faults before determining the specific causes. In thiscase, you are advised to collect sufficient information, or contact Huawei for technical support.

Fault Information Typesl Alarm information

Alarm information is exported by the BSS alarm system and reported with any combinationof the following: sounds, lights, indicators, or onscreen indications. Viewing the alarminformation is a common method for analyzing faults.Alarm information includes a description of the fault symptoms and causes, as well as faultrectification suggestions. Alarm information includes detailed information about hardware,links, trunks, and CPU load.In most cases, alarm information is sufficient to locate the specific cause of a fault.Otherwise, you can use the alarm information with other information to locate a fault.

NOTEFor a description of the alarm system, see the BSC6900 GSM LMT User Guide. For details abouthow to handle an alarm, see the BSC6900 GSM Alarm Reference.

l Indicator statusIndicators provide the operating status of boards, circuits, links, optical paths, or nodes.Viewing the indicator status helps quickly locate the general cause of a fault. Becauseindicator status is generally not informative enough to locate a fault, this information isoften used with the alarm information to locate a fault. Table 2-1 uses the SCUa as anexample to describe the board indicators.

Table 2-1 LEDs on the SCUa board

LED Color Status Description

RUN Green ON for 1s and OFF for 1s The board is functional.



4

LED Color Status Description

ON for 0.125s and OFFfor 0.125s

The board is in loadingstate.

ON There is power supply,but the board is faulty.

OFF There is no powersupply, or the board isfaulty.

ALM Red OFF There is no alarm.

ON or blinking There is a fault alarm.

ACT Green ON The board is in activemode.

OFF The board is in standbymode.

LINK (at theEthernet port)

Green ON The link is wellconnected.

OFF The link is disconnected.

ACT (at theEthernet port)

Green OFF There is no datatransmission over theEthernet port.

Blinking There is datatransmission over theEthernet port.

NOTEFor a description of indicators on various boards, see the BSC6900 GSM Hardware Description.Operation and maintenance (O&M) engineers should be familiar with indicators to facilitate faultlocation.

l Dialing test results

Dialing tests are performed to determine whether BSS services are normal. In addition,dialing tests are performed to collect information such as MS signaling, network signaling,and detailed fault symptom descriptions.

l Instrument measurement results

Instrument and meter measurement results are true indication of fault causes. Instrumentmeasurement results are widely used for power supply tests, signaling analysis, waveanalysis, and bit error detection. For example, the procedure for troubleshooting high calldrop rates at a site using a signaling analyzer is as follows:

– Select some signaling messages related to call drops by using a signaling analyzer.

– Analyze the signaling messages. The timing advance (TA) value approaches 63.

– Change the data configuration to reduce the cell radius.



5

NOTEFor details about methods for using an instrument, see the related user guide.

l Traffic statisticsTraffic statistics are generally used to analyze service faults such as call drops and handoverproblems.Traffic statistics can be used with traced signaling messages to troubleshoot high call droprates, low handover success rates, or call exceptions.

NOTEFor details about how to use traffic statistics to analyze problems, see Performance Monitoring. Forcounter meanings, see the BSC6900 GSM Performance Counter Reference.

l Signaling messages traced over interfacesSignaling messages are generally used to identify causes of call connection failures or inter-site signaling interaction failures.

2.3 Determining a Fault TypeAfter collecting fault information, analyze the symptoms to determine a fault type.

You can also Contact Huawei Customer Service Center to determine a fault type.

NOTEIf a severe fault occurs, Contact Huawei Customer Service Center.

2.3.1 Fault TypesThis section lists the fault types covered in this document.

l CS voice problemsl CS service faults

– Handover problems– Call drops– Access problems

l PS service faults– Gb interface faults– PS counter problems– PS channel faults– No PS service available in a cell

l Equipment faults– TDM or IP transmission faults– Interference– Main diversity receive channel faults– No traffic

NOTEDetermine the fault type based on symptoms. Different fault types may have the same symptoms. Forexample, access problems may have the same symptoms as link problems. In this case, methods fortroubleshooting access problems will be linked to the methods for troubleshooting link problems.



6

2.3.2 Methods for Determining a Fault TypeThis section describes methods for determining a fault type.

l MonitoringMonitoring is a common method for determining fault ranges. You can observe alarms,indicator status, and LMT panel status.

l Analysis of Top N deteriorating performance countersThis method can determine a fault type when performance counters deteriorate. With thismethod, you can sort out the Top N deteriorating performance counters for cells and TRXs.Then, you can determine whether performance counters for certain cells or an entire BSCdeteriorate. For specific cases, see 4 Handover Problems.

l Loopback testsLoopback tests can locate transmission, link, and voice problems. Loopback tests areclassified into hardware loopback tests and software loopback tests. For specific cases, see3.1.2 External Voice Loopback.You can determine whether equipment operates normally and software parameters are setcorrectly by checking the status of the transmission equipment, transmission channels,services, and signaling interaction status after loop back tests are performed. Loopbacktests can also be performed to determine whether transmission faults occur or trunkparameters are set incorrectly. During site deployment or trunk capacity expansion, BSStrunk loopback tests can help determine whether trunk parameters and signaling link dataare configured correctly.

NOTELoopback tests are also performed to locate transmission faults.

l Process of eliminationThis method can exclude both software problems and hardware problems. To excludesoftware problems, disable a certain function or feature to check whether a fault can berectified. If the fault is rectified, the function or feature is abnormal. Otherwise, the functionor feature is normal.To exclude hardware problems, replace faulty boards.For example, when troubleshooting co-channel or adjacent-channel interference, replacethe cell ARFCN with an ARFCN without interference (such as an E-GSM900 ARFCN).Then, check whether the interference problem is resolved.

l Regularity identificationIdentifying problem regularity helps to narrow the fault range. When narrowing the faultrange, consider the following factors:

1. Whether a certain board is faulty2. Whether a certain DSP is faulty3. Whether a certain transmission path is faulty4. Whether a certain TRX is faulty5. Whether a certain type of MS is faulty6. Whether a certain type of channel is faulty7. Whether an enabled feature is abnormal, such as Flex TSC, downlink power control,

or BCCH power consumption reduction8. Whether an alarm is reported multiple times



7

For example, if a Cell Out of Service alarm is reported, check whether one or multiple cellsare out of service.

– If only one cell is out of service, the TRX serving this cell may be faulty, or the celldata configurations may be incorrect.

– If multiple cells are out of service, determine whether these cells are served by one ormultiple BTSs.

– If these cells are served by one BTS, check whether any transmission alarms (suchas LAPD or E1 alarms) are reported. If any transmission alarms are reported, a powerfailure or transmission faults may have occurred at the BTS.

– If these cells are served by multiple BTSs, check whether these BTSs are located inthe same area. If these BTSs are located in the same area, the power may have failedor the optical fibers in the area may be damaged.

l Comparison/Interchange

Problems can be identified by comparing faulty components with normal components orby interchanging the possibly faulty components with normal components.

– Use the comparison method when there is only a single fault type.

– Use the interchange method when there are multiple fault types. Interchange can beused for the following items:

1. TRXs and boards

2. Transmission cables

3. Antennas

4. ARFCNs

For example, when severe interference in a certain cell cannot be eliminated aftertroubleshooting cable connection faults, interchange the antenna system for the abnormalcell with that for a normal cell. If the interference is eliminated, the original antenna systemis faulty. For details, see the typical case in 12.4 Troubleshooting IntermodulationInterference.

2.4 Identifying Fault CausesTo identify the specific cause of a fault, exclude possible causes by analyzing the symptoms.

Generally, you need to analyze the causes of the following faults:

l Service faults

– When a CS or PS service fault occurs, check the interfaces within the BSS to determinewhether it is faulty. If the BSS is faulty, continue identifying the fault cause.

– When a handover or access problem occurs, start measuring traffic statistics and tracingsignaling messages. Then, determine the fault location according to protocols.

l Subsystem faults

Subsystem faults include clock, interface link, and equipment faults. These faults havenarrow ranges and are generally associated with alarms. In addition, information includingboard indicators and error messages is available. Therefore, it is easy to identify the causesof subsystem faults.



8

2.5 Troubleshooting FaultsThis section provides the methods for troubleshooting faults as well as follow-up procedures.

2.5.1 OverviewTroubleshooting faults is a process of taking proper measures to rectify faults and restore asystem to good working order. Methods for troubleshooting faults include cable connectioncheck, board replacement, data configuration modification, board switchover, and boardresetting.

Consider the following items when troubleshooting a fault:

l Use different troubleshooting procedures according to fault types.

l Verify that the fault is rectified after the troubleshooting procedure.

l After a fault is rectified, review the troubleshooting process, record the key points, andprovide preventive and improvement measures.

NOTEWhen severe faults occur, Contact Huawei Customer Service Center.

2.5.2 Methods for Troubleshooting FaultsThis section provides methods for troubleshooting faults.

l Fault isolation

Isolation is the act of isolating the fault location from the surrounding service unit to preventthe fault from adversely impacting ongoing services.

For example, when a DSP on a DPU is faulty and the DPU cannot be replaced immediately,run the MML command INH DSP to isolate the DSP. For details, see the typical case in7.4 Troubleshooting Noise.

l Switchover/resetting

During a switchover, services are switched from an active device to a standby device. Youcan compare the system operating status before and after the switchover. By resetting partof a device or the whole device, you can determine the software operating status.

Exercise caution when using switchover/resetting methods for the following reasons:

– Both methods are auxiliary methods used only in an emergency.

– Both methods can prevent a fault from recurring in a short time due to software bugs.However, they cannot identify the root cause of a problem. This may lead to equipmentfaults or operation instability.

Resetting may lead to service interruptions or even system crash, affecting normal BSSoperations. For example, some or all services over the A interface are interrupted. In thiscase, perform the following operations:

1. Check whether any A interface transmission alarms have been reported on the BSC.

2. Reset the MSC interface board communicating with the A interface board.

3. Switch over the active and standby A interface boards.



9

4. When the BSC works in BM/TC separated mode, switch over the active and standbyAter interface boards in the BM subrack.

5. Switch over the XPU boards where SS7 signaling links are configured.6. Perform local loopback tests on the port of the Ater interface board in the BM subrack.

Then, check whether the Ater interface board can receive messages it has sent.l Replacement

If other methods are ineffective, replace faulty equipment such as boards, cables, orantennas.

NOTE

1. If a fault persists after a board is replaced, reinsert the board instead of shipping the board backto Huawei headquarters.

2. If no equipment is available for replacing the faulty equipment, remove and then reinstall theequipment.

2.5.3 Follow-up ProcedureThis section describes the handling operations performed after a fault is rectified.

l After a fault is rectified, query the equipment status, board indicators, and alarms to verifythat the faulty NE is operating normally. In addition, perform dialing tests and check trafficstatistics to verify that services are operating properly.

l If the fault persists, Contact Huawei Customer Service Center.



10

3 Common Maintenance Functions

About This Chapter

This chapter describes common maintenance functions used during fault location.

3.1 Maintenance Functions for Identifying Voice ProblemsThis section describes maintenance functions for identifying voice problems.

3.2 Maintenance Functions for Identifying Transmission ProblemsThis section describes maintenance functions for identifying transmission problems.

3.3 Maintenance Functions for Identifying Um and RF ProblemsThis section describes maintenance functions for identifying Um and RF problems.

3.4 Maintenance Functions Related to Interface TracingThis section describes maintenance functions related to interface tracing.

3.5 Maintenance Functions for Identifying PS ProblemsThis section describes maintenance functions for identifying PS problems.

3.6 Maintenance Functions for Identifying Clock ProblemsThis section describes maintenance functions for identifying clock problems.

GBSS9.0Troubleshooting Guide 3 Common Maintenance Functions


11

3.1 Maintenance Functions for Identifying Voice ProblemsThis section describes maintenance functions for identifying voice problems.

3.1.1 Querying Call Resource Usage of an MSThis section describes how to query the call resource usage of an MS.

Function Description

This function queries the call resource usage of an MS that has set up a call and is used to identifyBSS voice problems. The query can be performed by entering the MS's Mobile StationInternational ISDN Number (MSISDN), International Mobile Subscriber Identity (IMSI),Temporary Mobile Subscriber Identity (TMSI), or International Mobile Equipment Identity(IMEI).

Procedure1. On the LMT, run the MML command DSP CALLRES, then press Enter or click Assist.

2. Set User Query Type to BYTMSI(By TMSI), BYIMSI(By IMSI), BYMSISDN(ByMSISDN), or BYIMEI(By IMEI). The corresponding MS identifier (ID) is displayed.

NOTE

l If you set User Query Type to BYMSISDN(By MSISDN), set the MSISDN to the number ofthe peer end. When querying the call resource usage of the calling MS, set the MSISDN to thecalled number. When querying the call resource usage of the called MS, set the MSISDN to thecalling number (the Calling Line Identification Presentation function must be enabled).

l If you set User Query Type to BYTMSI(By TMSI) or BYIMSI(By IMSI), confirm thereallocation policy configured on the MSC side. If the MS's TMSI is used to set up a call, setUser Query Type to BYTMSI(By TMSI) to query the call resource usage. If the MS's IMSI isused to set up a call, set User Query Type to BYIMSI(By IMSI) to query the call resourceusage.

l If you set User Query Type to BYIMEI(By IMEI), determine whether the MSC can obtain theIMEI.

3. Set the ID based on the specified User Query Type. Then, click Exec.

Operation Results

The query result shows the call resource usage of the MS, including information about the BMsubrack, TC link, A interface, and Ater interface. The query result also includes informationsuch as digital signal processor (DSP) number, channel number, service type, circuitidentification codes (CICs) on the A interface, as well as timeslots occupied by the GEIUA,GEIUB, and GEIUT.

3.1.2 External Voice LoopbackThis section describes how to start or stop external voice loopback and query the status of thecurrent voice loopback.



12

Function DescriptionVoice loopback refers to routing voice data back to its source over the same path it was sent on.By comparing the sent voice with the looped-back voice, voice problems can be identifiedsegment by segment. This function is used to identify voice problems such as one-way audio,no audio, crosstalk, or noise on a BSC or BTS.

Currently, voice loopback can be performed in all 14 positions of the BSC and BTS. Figure3-1, Figure 3-2, and Figure 3-3 show 12 loopback positions in a BSC in three networking modes.The loopback positions are the same for multi-core boards.

Figure 3-1 Abis over TDM + A over TDM

Figure 3-2 Abis over IP + A over TDM



13

Figure 3-3 Abis over TDM + A over IP

NOTE

1. TDM BTSs support only MSC-oriented loopback testing on the TMU. BTSs do not support loopbacktesting on the TRU. Only IP BTSs and high-speed data link control (HDLC) BTSs support both MSC-oriented and MS-oriented loopback testing on the DPTU.

2. In TDM networks, the loopback testing is performed over the Ater and Abis interfaces at 64 Kbit/swhereas services are processed over the two interfaces at 16 Kbit/s or 8 Kbit/s. As a result, a loopbacktest of the channel used by one subscriber may lead to loopback tests of the channels used by othersubscribers on the same 64 Kbit/s timeslot.

Procedurel Choosing menu items

1. Click Device Maintenance on the LMT main page. The Device Maintenance tabpage is displayed.

2. On the BSC Maintenance tab page, choose BSC Maintenance > Maintain UserResources > Remote Speech Channel Loopback. The Remote Speech ChannelLoopback dialog box is displayed.

3. In the Remote Speech Channel Loopback dialog box, set the parameters as required,and click Start. A message is displayed, informing you that the loopback issuccessfully started.

NOTE

l If you select MSISDN in the Trace Object Symbol Type area, set the MSISDN to thenumber of the peer end.

l (Recommended) If the calling party is traced, set the MSISDN to the called number.

l If the called party is traced, set the MSISDN to the calling number (the Calling LineIdentification Presentation function must be enabled).

l If you select TMSI or IMSI in the Trace Object Symbol Type area, confirm thereallocation policy configured on the MSC side.

l If the MS's TMSI is used to set up a call, you can select TMSI in the Trace ObjectSymbol Type area to query the call resource usage.

l If the MS's IMSI is used to set up a call, set Trace Object Symbol Type to IMSI toquery the call resource usage.

l If you select IMEI in the Trace Object Symbol Type area, determine whether the MSCcan obtain the IMEI.



14

4. After the loopback is started, click Query to query the remote speech channelloopback.

5. Click Cancel stop the remote speech loopback.

NOTE

To end a remote speech loopback, select IMSI, IMEI, TMSI, or MSIDSN in the Trace ObjectSymbol Type area to ensure that the parameter setting in the Trace Object Symbol Type areais the same as that is previously set for the loopback.

l Running MML commands

1. After a call is set up successfully, run the MML command STR CALLRESLOP onthe LMT, and press Enter or click Assist.

2. Set the relevant parameters, and click Exec to start the loopback

3. After the loopback is complete, run the MML command STP CALLRESLOP to stopthe loopback.

Operation Results1. The expected loopback effect is TDM three-way audio. That is, subscriber A can

communicate with subscriber B. In addition, during an MS-oriented loopback test of thechannel used by subscriber A, subscriber A can hear his or her own voice and subscriberB can hear subscriber A's voice. Three-way audio is not implemented in IP mode. Therefore,in IP mode, subscriber B cannot hear subscriber A's voice during an MS-oriented loopbackon subscriber A.

2. Three-way audio is implemented for loopback testing in the BSC TC subrack in either TDMor IP mode.

3. When FG2a is configured over the A, Abis, or Ater interface, a subscriber can hear his orher own voice and the peer end's voice during a loopback over these interfaces, but the peerend cannot hear any voice regardless of whether the loopback is MSC- or MS-oriented.

4. During a loopback on an IP BTS, a subscriber can hear his or her own voice and the peerend's voice, but the peer end cannot hear any voice regardless of whether the loopback isMSC-oriented or MS-oriented.

5. Table 3-1 lists the loopback results for various positions when the ID of subscriber A isused to perform loopback. The results are similar if the ID of subscriber B is used.

Table 3-1 Loopback results

Loopback Position andDirection

InterfaceBoard Type

Subscriber A Subscriber B

NSS Interface Unit (MSCDirection)

TDMinterfaceboard

Can hear B but notself

Can hear self butnot A

IP/HDLCinterfaceboard

Cannot hear self orB


NSS Interface Unit (MSDirection)

TDMinterfaceboard

Can hear self butnot B

Can hear A butnot self



15


InterfaceBoard Type




Cannot hear A orself

NSS TC (Near AbisInterface) (MSC Direction)



NSS TC (Near AbisInterface) (MS Direction)



NSS TC (Near A Interface)(MSC Direction)



NSS TC (Near A Interface)(MS Direction)



NSS TNU (Near AbisInterface) (MSC Direction)



NSS TNU (Near AbisInterface) (MS Direction)



NSS TNU (Near AInterface) (MSC Direction)



NSS TNU (Near AInterface) (MS Direction)



NSS Ater Interface Unit(MSC Direction)

TDMinterfaceboard






NSS Ater Interface Unit(MS Direction)

TDMinterfaceboard






BSS Ater Interface Unit(MSC Direction)

TDMinterfaceboard








16


InterfaceBoard Type


BSS Ater Interface Unit(MS Direction)

TDMinterfaceboard






BSS TC (Near AbisInterface) (MSC Direction)



BSS TC (Near AbisInterface) (MS Direction)



BSS TC (Near A Interface)(MSC Direction)



BSS TC (Near A Interface)(MS Direction)



BSS TNU (Near AbisInterface) (MSC Direction)



BSS TNU(Near AbisInterface) (MS Direction)



BSS TNU (Near AInterface) (MSC Direction)



BSS TNU (Near AInterface) (MS Direction)



BSS Interface Unit (MSCDirection)

TDMinterfaceboard






BSS Interface Unit (MSDirection)

TDMinterfaceboard






TMU/PTU (MSCDirection)

Non-IP BTS Can hear B but notself


IP BTS Cannot hear self orB




17


InterfaceBoard Type


TMU/PTU (MS Direction) Non-IP BTS Can hear self butnot B


IP BTS Can hear self butnot B


3.1.3 One-Way Audio DetectionThis section describes how to detect one-way audio or no audio on the BSS.


This function is used to detect one-way audio or no audio by checking uplink and downlinkvoice and data transmission of a BSC or BTS. When one-way audio or no audio is detected,record the call resource information and determine the faulty device to efficiently identify theproblems.

NOTE

l One-way audio logs are saved in \bam\common\fam\famlogfmt\.

l BSC6900 V900R011 does not support one-way audio detection in IP networks.

l The BTS TRXs must support one-way audio detection.

l One-way audio detection cannot be used with the local switching function. Therefore, before enablingone-way audio detection, ensure that the local switching function is disabled.

Procedure1. Run the MML command SET GCELLSOFT to enable one-way audio detection. The

recommended parameter settings are as follows:

l Mute Detect Class1 Switch is set to ENABLE(ENABLE).l Period of Mute Detect Class1 is set to 5.

l Exceptional Frame Threshold of Mute Detect Class1 is set to 25.

l Mute Detect Class2 Switch is set to ENABLE(ENABLE).l Period of Mute Detect Class2 TRAU Frame is set to 2.

l Period of Mute Detect Class2 is set to 4.

Operation Results

Each time the BSC detects one-way audio, a log prefixed by [CDIG] is recorded. To obtain thelog, run the MML command COL LOG.

No tool is required to open the log. You can open the log file in .xls format.

3.1.4 Crosstalk DetectionThis section describes how to detect crosstalk on the BSS.



18


This function detects crosstalk due to abnormal data exchange between a BTS and the BSC.Crosstalk on the Um and A interfaces cannot be detected.

Procedure

CAUTIONThis function must be configured on both the BSC and the BTS.

1. To enable this function on the BSC, run the MML command SET BSCBASIC with CrossCall Detect Time Threshold set to the recommended value 10.

Operation Result

Each time the BSC detects crosstalk, a crosstalk log is recorded. The crosstalk logs are recordedtogether with one-way audio logs. You can run the MML command COL LOG to obtain one-way audio log files prefixed by [CDIG].

No tool is required to open the log files. You can open the log file in .xls format.

3.1.5 Optimizing Um Interface CrosstalkThis section describes how to enable crosstalk optimization for the Um interface.


This function is used when severe crosstalk occurs over the Um interface in a cell. The symptomsof crosstalk over the Um interface are as follows: 1. The crosstalk occurs during a call ratherthan at the beginning of a call. 2. The Um interface quality for a party in the call is poor. 3. Thevoices of two parties at the peer end can be heard.

NOTEWhen this function is enabled, the BSC sends a Channel Rel message to the MS after a call is dropped. Inaddition, the BSC delays the value of the timer T3109 to enable the MS to release Um interface resources.However, traffic may be congested in the cell because channel reassignment is delayed. Therefore,determine whether to enable this function according to site requirements. This function is disabled bydefault.

Procedure

Run the MML command SET GCELLSOFT with Um Interface Crosstalk OptimizationAllowed set to YES(Allowed).

3.2 Maintenance Functions for Identifying TransmissionProblems

This section describes maintenance functions for identifying transmission problems.



19

3.2.1 Crossed Pair DetectionThis section describes how to enable crossed pair detection.

Function DescriptionA crossed pair is classified into big crossed pair and small crossed pair. A big crossed pair refersto crossed TX/RX between two pairs of E1 cables, as shown in Figure 3-4. A small crossed pairrefers to crossed TX/RX between an E1 cable in a pair and an E1 cable in another pair, as shownin Figure 3-5. When a crossed pair occurs on an E1 port of a device, the physical layer signalsare available and no alarm is triggered. However, upper-layer links are disconnected and servicesare interrupted because data from other ports is received.

Figure 3-4 Big crossed pair

Figure 3-5 Small crossed pair

There are a large number of E1 cables at a site and checking E1 connections is time-consuming.BSC6900V900R011 supports crossed pair detection, which helps determine whether a crossedpair is occurring on E1 ports and provides the relevant problem location information. Crossedpair detection applies only to small E1 crossed pairs over the A, Abis, and Ater interfaces.

There are two methods to detect small crossed pairs: loopback detection and alarm-baseddetection. If alarm-based detection is used, ensure that the connection to the peer port is normaland that no loopback occurs. If loopback detection is used, perform remote loopback by



20

connecting TX and RX ports (physical loopback) or by sending commands. Only physicalloopback can be performed on the ports of Ater operation and maintenance links (OMLs).

NOTE

1. To perform loopback detection, do as follows: Set the port on the remote device to remote loopbackor physical loopback without modifying configuration data. Import the test data (containing the portnumber) into the local E1 port. After performing the loopback, check whether the received portinformation is the same as the imported data. If the received port information is the same as the importeddata, the E1 cables are connected correctly. If the received port information is not the same as theimported data, the cables are crossed.

2. To perform alarm-based detection, do as follows: Disable the TX function of the local E1 port, whichcauses the remote E1 port to generate a loss of signal (LOS) alarm. The remote alarm indication (RAI)is inserted into the TX signals of the remote port. If the E1 cables are connected correctly, the localport receives the RAI. If the E1 cables are crossed, no alarm is generated on the local port.

3. The restrictions of the crossed pair function are as follows:

l Crossed pair detection can be performed only on the E1 electrical interfaces of the EIUa or PEUaboards.

l If the RX and TX connectors of the E1 cable for one port are incorrectly connected as a self-loopback on the DDF, this fault cannot be detected using loopback detection.

l When the E1 interface boards work in active/standby mode, this function can be performed onlyon the active board.

l When the E1 interface boards work in active/standby mode, alarm-based detection can beperformed only when the Y-shaped cable networking mode is used.

l Before performing alarm-based detection, there must be no loopback on the remote port.

l Do not perform crossed pair detection unless necessary because doing so may interrupt services.Notify telecom operators of possible impacts on a live network before performing alarm-baseddetection for online maintenance.

l Crossed pair detection commands must be executed in sequence. The next command for crossedpair detection cannot be executed until after the current detection command is executed completely.

l No alarm is reported on the E1 port on which crossed pair detection is to be performed.

l Although loopback detection can be performed on a single port or a whole board, alarm-baseddetection can be performed only on a single port.

Procedure

Run the MML command CHK E1T1CRS to enable crossed pair detection.

Operation Results

After the MML command is executed successfully, a window is displayed, indicating whethercable connections are faulty, as shown in the following figure.

+++ HUAWEI 2009-06-15 16:43:29O&M #27137%%CHK E1T1CRS: SRN=0, SN=15, BT=EIUa, MTHD=ALARM_METHOD, PN=0;%%RETCODE = 0 Execution succeeded.

Check E1/T1 Cross Connection---------------------------- Subrack No. Slot No. Link No. Check Result Cross Link No.

0 15 0 Not Cross <NULL> (Number of results = 1)

--- END



21

3.2.2 Monitoring Port BER SecondsThis section describes how to detect the bit error rate (BER) seconds on an E1/T1 port. Thisfunction helps you learn about the transmission quality of the link corresponding to the port inreal time.

Function DescriptionIf any bit error occurs on the E1/T1 port, you can start this task to obtain data such as BERS,critical BERS, unavailable seconds, frame errors, CRC errors. Based on the data, you canevaluate the operating status of the transmission network and identify the causes for the bit errorsin combination with the performance of the peer end. The AEUa/PEUa/EIUa/OIUa/POUc boardsupports this function.

Procedure1. On the LMT, click Monitor. The Monitor tab page is displayed.2. In the Monitor Navigation Tree, choose Monitor > Common Monitoring. Then, double-

click BERS Monitoring.3. In the BERS Monitoring dialog box that is displayed, set the relevant parameters. Then,

click Submit.

Operation ResultsAfter the monitoring task is started, a monitoring window is displayed, showing the real-timemonitoring result by list and chart. The task name and related parameters are displayed in thetitle bar of the window, as shown in Figure 3-6.

Figure 3-6 Monitoring results

3.3 Maintenance Functions for Identifying Um and RFProblems

This section describes maintenance functions for identifying Um and RF problems.



22

3.3.1 Monitoring Channel Interference BandsThis section describes how to view the interference band of idle channels to monitor interferenceon these channels.

Function DescriptionThis section describes how to detect the interference band of an idle channel to monitor theinterference conditions on the channel.


1. On the LMT, click Device Maintenance. The Device Maintenance tab page isdisplayed.

2. On the BTS Maintenance tab page, choose BTS Maintenance > Monitor ChannelInterference Band. The Monitor Channel Interference Band tab page is displayed.

3. On the displayed Monitor Channel Interference Band tab page, set the relevantparameters. Then, click Start.

NOTE

In the Device Navigation Tree, right-click the target BTS, and choose Monitor ChannelInterference Band from the shortcut menu.

l Running MML commandsRun the MML command DSP CHNJAM to monitor the interference band on a channel.

Operation ResultsFigure 3-7 is an example of the menu operation results. The interference bands on all thechannels are displayed and refreshed every 10s.

Figure 3-7 Monitor Channel Interference Band dialog box

3.3.2 Detecting Intermodulation Interference by Testing IdleTimeslots

This section describes how to detect intermodulation interference to a network by testing idletimeslots on the network.



23

Function DescriptionIn the network optimization phase, to determine whether a certain network is experiencingintermodulation interference, dummy bursts are sent to all idle timeslots in a specific area tocause the strongest interference to the network. A dummy burst test can take between 1 and 24hours. The test can be configured to stop automatically or stopped manually on the LMT.

After an idle timeslot test is started, all the idle timeslots send dummy bursts successively withinthe specified test time. The idle timeslot test is used to test the power on top of the cabinet for aTRX or check for intermodulation interference.l The TRX where the TCH is configured does not transmit power in idle mode. In this case,

the idle timeslot test is required to check the power on top of the cabinet.l The idle timeslot test is also required for the intermodulation interference test to analyze

and compare the traffic measurements of the interference band before and after the idletimeslot test.



2. On the BTS Maintenance tab page, choose BTS Maintenance > Maintain TRX >Test Idle Timeslot. The Test Idle Timeslot dialog box is displayed.

3. In the Test Idle Timeslot dialog box, set the relevant parameters. Then, click Start.The operation result is displayed, as shown in Figure 1.

Figure 3-8 Testing Idle Timeslots


Start or stop the operation by running the following commands:



24

– Run STR TRXBURSTTST to start testing the idle timeslots.– Run STP TRXBURSTTST to stop testing the idle timeslots.

Operation Resultsl Method 1: Compare the interference bands before and after the idle timeslot test. If the

proportion of interference bands 3, 4, and 5 increases, intermodulation interference exists.Figure 3-9 and Figure 3-10 show interference bands before and after the idle timeslot test.

Figure 3-9 Interference bands before the idle timeslot test

Figure 3-10 Interference bands after the idle timeslot test

l Method 2: Check the values of Interference Band Measurement per TRX(MR.Iterf.TRX)

in several measurement periods before and after the idle timeslot test to determine whetherintermodulation interference increases.

3.3.3 Scanning Uplink FrequenciesThis section describes how to configure the scan start time and frequency scan period for multiplefrequencies in a cell and how to query whether there is interference on uplink frequencies withinthe frequency scan period.



25

Function DescriptionThis function is performed on idle channels to obtain the interference level of configuredfrequencies. This function is used to identify frequencies with minor interference by determiningwhether one or more frequencies are experiencing interference.

Procedure1. On the LMT, click Device Maintenance. The Device Maintenance tab page is displayed.2. In the Device Navigation Tree, right-click the target cell and choose Configure

Frequency Scan from the shortcut menu.3. In the Configure Frequency Scan dialog box that is displayed, set the relevant parameters

and click Start.NOTESet the frequency scan start time to a value later than the current LMT time. In addition, select thefrequencies to be scanned according to the frequencies used by the RF module. For example, if theRD module uses P-GSM900 frequencies, select P-GSM900 frequencies.

CAUTIONStart querying the frequency scan results immediately after the frequency scan isconfigured. Otherwise, the query results cannot be reported.

Figure 3-11 Querying frequency scan results

Operation ResultsFigure 3-12 shows an example of frequency scan results. The scan results may be reported aboutfive to six minutes after the scan is started. After the scan results are reported, record the dataabout the scanned frequencies by copying and pasting the data in an .xls document.



26

Figure 3-12 Frequency scan results

CAUTIONView the average rather than the maximum frequency level. For example, when ARFCNs 1 to124 are scanned, CDMA interference exists if the noise floor decreases with an increase in thenumber of scanned ARFCNs and if the average noise floor of ARFCNs 1 to 50 is equal to orgreater than -85 dBm. Figure 3-13 shows a CDMA spectrum with significant interference.

Figure 3-13 CDMA spectrum with interference



27

3.4 Maintenance Functions Related to Interface TracingThis section describes maintenance functions related to interface tracing.

3.4.1 Tracing CS Domain Messages of a Single SubscriberThis section describes how to trace signaling messages of a single subscriber on the A, Abis, orUm interface.

Function DescriptionThis section describes how to trace signaling messages on the A, Abis, or Um interface for aspecified subscriber. The user can be specified by IMSI, IMEI, TMSI, MSISDN, CELLID, orchannel.

Procedure1. On the LMT, Click Trace. The Trace tab page is displayed.2. In the Trace Navigation Tree, choose Trace > GSM Services. Double-click Single User

CS Trace. The Single User CS Trace dialog box is displayed, as shown in Figure 3-14.

Figure 3-14 CS domain message tracing for a single subscriber

3. In the Single User CS Trace dialog box, set the relevant parameters.

l CDT Mode: If you select the CDT mode, you can trace interfaces between internalmodules.

l Debug Mode: If you select the debug mode, you can trace stream data in Abis over IP,Ater over IP, and A over IP scenarios. Interface boards must be selected on the Othertab page.



28

l Location Flag: Indicates information such as cell ID and TA.

NOTE

l If you trace the user messages by MSISDN, you are advised to set the MSISDN to that of thepeer end:

l (Recommended) To trace the calling MS, set the MSISDN to that of the called MS.

l To trace the called MS, set the MSISDN to that of the calling MS, which is displayed on thecalled MS.

l If you trace the user messages by TMSI or IMSI, check the reassignment policies on the MSCside:

l If TMSI is carried, you can trace the MS through the TMSI.

l If IMSI is carried, you can trace the MS through the IMSI.

l If you trace the user messages by IMEI, check whether the IMEI is available to the MSC.

l If you trace the user messages by CELLID, all calls in the cell are traced.

l If you trace the user messages by CHANINFO, the call carried by the specific channel is traced.

4. Click Submit.

Operation Resultsl Successful operation

– No traced message is displayed on the LMT if the Save to OMU trace mode is selected.You can view the tracing result saved on the OMU by referring to Browsing TracedMessages Offline.

– A window shown in Figure 3-15 is displayed if the Report trace mode is selected. Themessage browsing window displays information about each traced message, includingthe task number, task time, RFN, subrack number, slot number, subsystem number,message direction, message type, message source, user ID, and message content.

Figure 3-15 Results of CS domain message tracing for a single subscriber

l If the tracing fails, a dialog box is displayed with a failure cause.

3.4.2 Tracing PS Domain Messages for a Single SubscriberThis section describes how to trace messages of a single subscriber on the Gb, Abis, or Uminterface as well as trace internal messages or Um data blocks for a single subscriber.



29


This section describes how to trace signaling messages and internal messages on the Gb/Abis/Um interface or the data block on the Um interface for a specified subscriber. You can trace thesubscriber by the IMSI or temporary link level identity (TLLI). You can perform this task tolocate a fault in the PS domain in the following procedures: PS service channel assignmentfailure, abnormal TBF release, and PS packet loss or disconnection.

Procedure1. On the Web LMT, click Trace. The Trace tab page is displayed.2. In the Trace Navigation Tree, choose Trace > GSM Services. Double-click Single User

PS Trace. The Single User PS Trace dialog box is displayed, as shown in Figure 3-16.

Figure 3-16 PS domain message tracing of a single subscriber

3. In the Single User PS Trace dialog box, set the relevant parameters.

l The Trace Um Datablock Message can be selected only when Um Interface is selectedunder Trace Interface Type.

– If you start tracing by TLLI, query the TLLI of the MS by running the DSPMSCONTEXT command. During the PS service, the TLLI may be reassigned tothe MS. In this case, run this command to query the new TLLI for the tracingoperation.

l Report Mode: When Trace Um Datablock Message is selected, Um datablockmessages are reported. When Abis Interface is selected, MAC Report must be selected



30

and TRAU Report must be deselected. In this case, messages are reported in themessage format of the Um interface.

l For the description of Trace Mode, see Trace Mode.4. Click Submit.

Operation Resultsl Successful operation

– No traced message is displayed on the LMT if the Save to OMU trace mode is selected.You can view the tracing result saved on the OMU by referring to Browsing TracedMessages Offline.

– A window shown in Figure 3-17 is displayed if the Report trace mode is selected. Themessage browsing window displays information about each traced message, includingthe task number, task time, RFN, subrack number, slot number, subsystem number,message direction, message type, message source, user ID, and message content.

Figure 3-17 Results of PS domain message tracing for a single subscriber

l If the tracing fails, a dialog box is displayed with a failure cause.

3.5 Maintenance Functions for Identifying PS ProblemsThis section describes maintenance functions for identifying PS problems.

3.5.1 Monitoring Channel StatusThis section describes how to monitor channel usage and subchannel usage on a TRX.


If a built-in PCU is configured, you can query the LMT for information about the physical datachannel (PDCH) by using the channel status monitoring function. The information includesApplied Bandwidth, Available Bandwidth, Uplink GPRS TBF, Downlink GPRS TBF, UplinkEGPRS TBF, and Downlink EGPRS TBF.



31

ProcedureNOTE

In the Device Navigation Tree, right-click the target BTS, cell, or TRX, and choose Monitor ChannelStatus from the shortcut menu.

1. Click Device Maintenance. The Device Maintenance tab page is displayed.2. On the BTS Maintenance tab page, choose BTS Maintenance > Monitor Channel

Status. The Monitor Channel Status tab page is displayed.3. On the Monitor Channel Status tab page, set the relevant parameters. Then, click Start.

NOTE

l Each dot in a column represents a sub-channel of the corresponding channel. The SDCCH channel haseight sub-channels, the full-rate TCH has only one sub-channel, and the half-rate TCH has two sub-channels.

l The sub-channel status is indicated with different colors.

l Green indicates that the channel is in normal state. If you move the cursor to the correspondingindicator, you can view the current channel type, applied bandwidth, and available bandwidth fromthe pop-up information. The applied bandwidth and the available bandwidth are equal and bothbandwidths are greater than or equal to 16 Kbit/s. The number of uplink or downlink TBF blocksis proportional to the MSs that can be multiplexed on the current channel.

l Red indicates that the channel is abnormal. If you move the cursor to the corresponding indicator,you can view the current channel type, applied bandwidth, and available bandwidth from the pop-up information. The applied bandwidth is not equal to the available bandwidth, or the availablebandwidth is 0 Kbit/s.

l Blue indicates that the channel is blocked. If you move the cursor to the corresponding indicator,you can view the current channel type and the channel status, which is Locked.

l If a TRX number is marked with *, the TRX is in TRX cooperation state.

Operation ResultsFigure 3-18 shows an example of the results of monitoring channel status.

Figure 3-18 Monitoring channel status

The various channel statuses on the Monitor Channel Status tab page are described as follows:l Idle indicates that the channel is normal but not occupied.l Working indicates that the channel is normal and occupied.



32

l Locked/Shut down indicates that the channel is blocked.

l Subordinate Channel indicates that a channel sharing the same TRX as the current channelis transmitting power. This is a normal state.

l Faulty indicates that the channel is faulty.

l Uninstalled indicates that the channel is not activated.

Right-click the channel to be queried. The detailed information about the channel is displayed,as shown in Figure 3-19.

Figure 3-19 Channel status monitoring result

3.6 Maintenance Functions for Identifying Clock ProblemsThis section describes maintenance functions for identifying clock problems.

3.6.1 Querying BSC Clock Source StatusThis section describes how to query BSC clock source status.


This function is used to check the clock status of the GCGa or GCUa on the M2000 or LMT,including the status of clock source used in the current system, as well as mode of switchingclock sources. If the clock source level is Unavailable, or Phase-locked loop state of currentclock is Unknown, the clock source is lost. In this case, contact the maintenance engineers toresolve the problem until the clock source level is Available, or Phase-locked loop state ofcurrent clock is Trace.



33



2. On the BSC Device Panel tab page, right-click the GCUa and choose Query BSCBoard Clock Status from the shortcut menu.

3. In the Query BSC Board Clock Status dialog box that is displayed, check the boardclock status, as shown in Figure 3-20.

Figure 3-20 Querying BSC clock source status


Run the MML command DSP CLK and set Subrack No. as well as Slot No. to query thestatus of the GCUa or GCGa in the MPS. The GCUa and GCGa are permanently locatedin slots 12 and 13 respectively.

3.6.2 Querying BSC Board Clock StatusThis section describes how to query BSC board clock status.


This function is used to query the status of each BSC board clock. For the GCUa board, you canquery information such as the status of clock source used in the current system, and mode ofswitching clock sources.



34

CAUTIONThis function cannot be used to query the clock status of the FG2a, GOUa, FG2c, or GOUc.



2. On the BSC Maintenance tab page, choose BSC Maintenance > DeviceMaintenance > Query BSC Board Clock Status. The Query BSC Board ClockStatus dialog box is displayed.

3. In the Query BSC Board Clock Status dialog box that is displayed, set the relevantparameters. Then, click Query to query the board clock status, as shown in Figure3-21.

Figure 3-21 Querying results of BSC Board Clock Status


Run the MML command DSP CLK to query the BSC board clock status.

3.6.3 Maintaining BTS ClockThis section describes how to query BTS board clock information.

Function DescriptionThis function is used to query the board clock information and clock type of a BTS.



35


– Starting BTS device panel.– On the BTS device panel, right-click the main control board and choose Maintain Clock

from the shortcut menu.– In the Maintain Clock dialog box that is displayed, set the relevant parameters. Then,

click Query to query the board clock information, as shown in Figure 3-22.

Figure 3-22 Maintain Clock dialog box


– Run the MML command DSP BTSBRD to query the board clock information of a BTS.– Run the MML command LST BTSCLK to query the clock source type of a BTS.



36

4 Handover Problems

About This Chapter

This chapter describes how to locate and troubleshoot handover problems.

4.1 Handover PrinciplesHandovers are performed to ensure service continuity during MS movement and to optimizenetwork performance.

4.2 Locating Handover ProblemsThis section describes how to locate handover problems.

4.3 Troubleshooting Handover Problems Due to Hardware FaultsThis section describes how to troubleshoot handover problems due to hardware faults.

4.4 Handover Problems Due to Incorrect Data ConfigurationsThis section describes how to troubleshoot handover problems due to incorrect dataconfigurations.

4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target CellThis section describes how to troubleshoot handover problems due to traffic congestion in thetarget cell.

4.6 Troubleshooting Handover Problems Due to Poor Um Interface QualityThis section describes how to troubleshoot handover problems due to poor Um interface quality.

4.7 Troubleshooting Handover Problems Due to NE FaultsThis section describes how to troubleshoot handover problems due to NE faults.

4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RATInteractionThis section describes how to troubleshoot handover problems due to inappropriate inter-BSC,inter-MSC, or inter-RAT interaction.

GBSS9.0Troubleshooting Guide 4 Handover Problems


37

4.1 Handover PrinciplesHandovers are performed to ensure service continuity during MS movement and to optimizenetwork performance.

Before a handover, the in-service MS and the serving BTS evaluate the quality of downlink anduplink radio links respectively and submit the measurement reports to the BSC.The BSC thendetermines whether to trigger a handover based on the measurement reports and actual networkconditions.

4.1.1 Handover ProcedureThis section describes the handover procedure. The intra-BSC handover is used as an example.

Figure 4-1 shows an intra-BSC handover procedure.



38

Figure 4-1 Intra-BSC handover procedure

The intra-BSC handover procedure is as follows:

1. An MS sends a measurement report to BTS 1 (the source BTS) on the SACCH over theUm interface.

2. BTS 1 sends the measurement result to the BSC.

3. The BSC determines the target cell based on the measurement result and sends a ChannelActivation message to BTS 2 (the target BTS).

4. BTS 2 enables the power amplifier to receive uplink messages on the channel specified inthe Channel Activation message. Then, BTS 2 sends a Channel Activation Acknowledgemessage to the BSC.



39

5. The BSC sends a Handover Command message to BTS 1, which forwards this message tothe MS on the FACCH. At the same time, the BSC starts timer T3101.

6. The MS sends a Handover Access message to BTS 2 on the FACCH. At the same time,the MS starts timer T3124 if this is an asynchronous handover.

7. BTS 2 sends a Handover Detect message to the BSC.8. If this is an asynchronous handover, BTS 2 sends a PHY INFO message to the MS, which

contains the new timing advance (TA) value calculated by BTS 2. Upon receiving thismessage, the MS stops timer T3124.

9. The MS sends SABM frames to BTS 2 on the FACCH.10. Upon receiving the first SABM frame, BTS 2 sends an Establish Indication message to the

BSC, which informs the BSC that the radio link has been established.11. At the same time, BTS 2 sends a UA frame to the MS on the FACCH, which informs the

MS that the radio link has been established.12. The MS sends a Handover Complete message to BTS 2 on the FACCH. BSC 2 then

forwards this message to the BSC, which informs the BSC that the handover is complete.13. The BSC stops timer T3103 and sends the MSC a Handover Performed message, which

contains the target cell information.14. The BSC sends BTS 1 a Deactivate SACCH message.15. The BSC sends BTS 1 a Release Request message with the cause value of Local End

Release, indicating that the release process is not related to the MS.16. Upon receiving the Release Request message, BTS 1 responds with a Release Confirm

message.17. The BSC sends BTS1 an RF Channel Release message, instructing BTS 1 to release the

original TCH.18. Upon receiving the RF Channel Release message, BTS 1 responds with an RF Channel

Release Acknowledge message, indicating that the original TCH is released and can bereassigned.

4.1.2 Handover Success RateHandover success rates are classified into the following success rates: intra-cell handover, intra-BSC handover, and inter-BSC handover.

FormulaHandover success rate = Number of successful handovers/Number of handover requests

Radio handover success rate = Number of successful handovers/Number of handover commands

Measurement Points in Signaling ProceduresFigure 4-2 and Figure 4-3 show the measurement points in the signaling procedures for intra-BSC handovers and inter-BSC handovers respectively.



40

Figure 4-2 Measurement points in the signaling procedure for intra-BSC handovers

A1: CH320:Number of Incoming Internal Inter-Cell Handover Requests and CH300:Internal Intra-CellHandover RequestsB1: CH321: Number of Incoming Internal Inter-Cell Handover Responses and CH301:Internal Intra-CellHandover CommandsC1: CH323:Number of Successful Incoming Internal Inter-Cell Handovers and CH303:Successful InternalIntra-Cell Handovers



41

Figure 4-3 Measurement points in the signaling procedure for inter-BSC handovers

A2: CH340:Incoming External Inter-Cell Handover RequestsB2: CH341:Incoming External Inter-Cell Handover ResponsesC2: CH343:Successful Incoming External Inter-Cell HandoversA3: CH330:Outgoing External Inter-Cell Handover RequestsB3: CH331:Outgoing External Inter-Cell Handover CommandsC3: CH333:Successful Outgoing External Inter-Cell Handovers

The formulas for calculating the various handover success rates are as follows:

l Handover success rate = (C1: CH323:Number of Successful Incoming Internal Inter-CellHandovers + C3)/(A1: CH320:Number of Incoming Internal Inter-Cell Handover Requests+ A3)

l Radio handover success rate = (C1: CH323:Number of Successful Incoming Internal Inter-Cell Handovers + C3)/(B1: CH321: Number of Incoming Internal Inter-Cell HandoverResponses + B3)

l RH303B:Intra-BSC Handover Success Rate = C1/A1

l RH303C:Intra-BSC Radio Handover Success Rate = C1/B1

l TH343:Success Rate of Incoming External Inter-Cell Handovers = C2/A2

l RH303D:Success Rate of Incoming External Inter-Cell Radio Handovers = C2/B2

l TH333:Success Rate of Outgoing External Inter-Cell Handovers = C3/A3



42

l RH303E:Success Rate of External Outgoing Cell Radio Handovers = C3/B3

NOTEYou can compare the handover success rate with the radio handover success rate to determine whether ahandover is caused by Um interface problems.

l If the handover success rate is lower than the radio handover success rate, check for problems relatedto terrestrial links and network capacity.

l If both the handover success rate and the radio handover success rate are low and nearly equal, checkfor interference and coverage problems.

4.2 Locating Handover ProblemsThis section describes how to locate handover problems.

4.2.1 PrinciplesHandover problems may be caused by inappropriate data configurations, hardware faults,interference, or poor Um interface quality. Determine the specific cause of a handover problembefore resolving the problem.

Determine whether a handover problem occurs on an entire network or in a cell based on thefault range and background information.

l If a handover problem occurs on an entire network, focus on MSC/BSC parameter settingsand signaling interactions.

l If a handover problem occurs in a cell, focus on data configuration, frequency, and thehardware of the problem cell.

Handover problems can be located using the following methods:

1. Analyzing handover traffic statistics2. Checking for top N cells with severe handover problems3. Checking for equipment and transmission alarms4. Checking for interference and coverage problems5. Checking neighboring cell planning data6. Checking parameter settings

4.2.2 Procedure for Locating Handover ProblemsThis section describes the procedure for locating handover problems.

Common ProcedureFigure 4-4 shows the common procedure for locating handover problems.



43

Figure 4-4 Common procedure for locating handover problems

Location Procedure1. Analyze the information contained in 4.1.2 Handover Success Rate, and determine

whether there are top N cells with low handover success rates.l If yes, go to Step 2.l If no, go to 4.7 Troubleshooting Handover Problems Due to NE Faults. Then, check

whether the handover problem is resolved.



44

– If yes, no further action is required.

– If no, go to Step 2.

2. Check whether the source and target cells belong to the same BSC.

l If yes, go to Step 3.

l If no, go to 4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction. Then, check whether the handover problemis resolved.



3. Check whether any hardware alarms have been reported for the problem cell.

l If no, go to Step 4.

l If yes, go to 4.3 Troubleshooting Handover Problems Due to Hardware Faults.Then, check whether the handover problem is resolved.



4. Check whether handover data configurations are correct.


l If no, go to 4.4 Handover Problems Due to Incorrect Data Configurations. Then,check whether the handover problem is resolved.



5. Check whether the channels of the target cell are congested.


l If yes, go to 4.5 Troubleshooting Handover Problems Due to Traffic Congestion inthe Target Cell. Then, check whether the handover problem is resolved.



6. Check whether the Um interface quality is poor.


l If yes, go to 4.6 Troubleshooting Handover Problems Due to Poor Um InterfaceQuality. Then, check whether the handover problem is resolved.



7. If the handover problem persists, Contact Huawei Customer Service Center.

4.3 Troubleshooting Handover Problems Due to HardwareFaults

This section describes how to troubleshoot handover problems due to hardware faults.



45

Symptom

When a hardware fault occurs in a cell, the alarm system reports correlated alarms such astransmission alarms and TRX alarms.

If a handover problem occurred but data configurations are not modified for the problem celland its neighboring cells, check for BTS hardware faults.

Background Information

The alarms related to hardware faults are as follows:

l ALM-21807 OML FaultLink access procedure on the D channel (LAPD) links are required for communication overthe data link layer between the BSC and a BTS. Links used for receiving and transmittingoperation and maintenance (O&M) messages are called operation and maintenance links(OMLs), or LAPD_OMLs. ALM-21807 OML Fault is reported when the BSC detects thatthe LAPD_OML to a BTS is interrupted, or that the handshake between the BSC and aBTS expired.

l BTS LAPD alarms

– ALM-4102 TRX LAPD Link Interrupt Alarm

– ALM-2114 TRX LAPD Link Interrupt Alarm

– ALM-3052 LAPD alarm

– ALM-3572 LAPD alarmThese alarms are reported when a LAPD link is interrupted and the related TRX cannotcommunicate with the BSC. As a result, the TRX cannot provide services and shuts downthe power amplifier. If this TRX is a BCCH TRX, the cells served by the TRX cannotprovide services.

l ALM-2204 TRX Communication AlarmThis alarm is reported when the communication between a TRX and the TMU failed. Whenthis alarm is reported, the TRX cannot operate properly.

l TRX standing wave alarms

– ALM-2156 TRX VSWR Alarm

– ALM-4144 TRX VSWR alarm

– ALM-26529 RF Unit VSWR Threshold CrossedThese alarms are reported when the voltage standing wave ratio (VSWR) detected over aTRX power output port exceeds 3 or when the cable is not properly connected to a DTRUpower output port (TX1, TX2, or TCOM). When this alarm is reported, the servicesprocessed by the TRX are interrupted.

l ALM-28008 Radio Link FailureThis alarm is reported when a BTS detects a radio link exception.

l Clock source exception alarms

– ALM-2208 Clock Reference Abnormal Alarm

– ALM-3146 Clock Reference Abnormal alarm

– ALM-3666 Clock Reference Abnormal alarm

– ALM-4708 Clock Reference Abnormal Alarm



46

– ALM-26262 External Clock Reference ProblemIf a BTS clock is unstable, it may deviate from the other BTS clocks. As a result, handoverfailures and call drops may occur.

Location ProcedureFigure 4-5 shows the procedure for locating handover problems due to hardware faults.

Figure 4-5 Procedure for locating handover problems due to hardware faults

Troubleshooting Procedure1. Check whether any of the hardware alarms listed in Background Information have been

reported.l If yes, go to Step 2.l If no, go to Step 3.

2. Clear hardware alarms.l If the alarms persist, go to Step 3.l If the alarms are cleared, check whether the handover problem is resolved.

– If yes, no further action is required.– If no, go to Step 3.

3. Go to 4.2.2 Procedure for Locating Handover Problems.

Typical CaseSymptom

The success rate for handovers between all the cells under a BTS and their neighboring cellsunder another BTS is 10.7%, whereas normally the success rate should be at least 98%. Thesuccess rate for handovers between the cells under the same BTS is 99.2% during peak hours.

Cause Analysis



47

Possible causes for this problem are: hardware faults, cell channel congestion, incorrectneighboring cell configurations, and clock source exceptions.

Troubleshooting Procedure

1. Check whether neighboring cells are configured properly using a network optimizationtool. Then, check whether any neighboring relationships are missing or redundant on theLMT. Ensure that no neighboring cells are missing or redundant.

2. Check all the TRX boards. All the TRX boards operate normally, and none of the TRXalarms listed in Background Information are reported.

3. Check the TMU. A clock source exception alarm listed in Background Information isreported.

4. Replace the TMU. The alarm is cleared, and the success rate for handovers is at least 99.5%between all the cells under a BTS and their neighboring cells.

4.4 Handover Problems Due to Incorrect DataConfigurations

This section describes how to troubleshoot handover problems due to incorrect dataconfigurations.

Symptoml The signal quality in the serving cell is poor. Handovers often cannot be initiated, and the

call drop rate is high.l The signal level and quality in the neighboring cell is slightly better than the serving cell.

Handovers are performed frequently, which deteriorates voice quality and increases thenumber of call drops.

l If the P/N criterion is set inappropriately, PBGT handovers often fail, and the handoversuccess rate is less than 98%.

Background Informationl Impact of handover threshold settings

Edge handovers are performed when the receive level is continuously less than the valueof Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold during aspecified period. Generally, Edge HO UL RX_LEV Threshold is set to 10, and Edge HODL RX_LEV Threshold is set to 20 in handover algorithm I or 15 in handover algorithmII. If Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold is set toolow, a handover cannot be initiated when it should be. If Edge HO UL RX_LEVThreshold or Edge HO DL RX_LEV Threshold is set too high, handovers are performedfrequently, which reduces the cell coverage area and leads to call drops. Therefore, setEdge HO UL RX_LEV Threshold and Edge HO DL RX_LEV Threshold to appropriatevalues based on the cell coverage. Changing the value of Edge HO UL RX_LEVThreshold or Edge HO DL RX_LEV Threshold can change the coverage area of a cell.If the serving cell coverage is weak, increase the value of Edge HO UL RX_LEVThreshold or Edge HO DL RX_LEV Threshold by 2 dB to 5 dB to expedite handoversto a suitable neighboring cell.

l Impact of neighboring cell configurationsIf neighboring relationships are not configured or configured incorrectly even though thesignal level of a neighboring cell is high, the MS may report incorrect neighboring cell



48

information or may not report any neighboring cell information. As a result, the MS cannotperform a handover or may have difficulty performing a handover.

l Incorrect setting of NCC PermittedNCC Permitted is contained in system information 2 and 6. An MS measures only the signallevel of cells with NCC Permitted set to 1. If NCC Permitted for a serving cell is setincorrectly, an MS cannot hand over to a neighboring cell. NCC Permitted consists of 8bits, with bit 7 being the most significant bit and bit 0 being the least significant bit. Eachbit corresponds to an NCC (0 to 7).

l Inappropriate data configurations for cells with repeaters or RXU co-cellsInappropriate data configurations for cells with repeaters or RXU co-cells may lead toasynchronous handover failures.

l Impact of hysteresis configurationsThe difference between the signal level of a candidate cell and that of the serving cell mustbe greater than the handover hysteresis. Therefore, a large handover hysteresis may leadto handover failures. If the serving cell coverage is weak, decrease the handover hysteresisby 1 to 2 dB to expedite handovers to a suitable neighboring cell. If coverage overlap exists,increase the handover hysteresis by 1 to 2 dB.

l Inappropriate configuration of optimal cell measurement timeDuring common handovers, an MS selects the target cell according to the N/P criteria. Thatis, the MS selects the optimal cell for P seconds in N seconds as the target cell. If two cellsare the optimal cell alternatively, a handover may fail because the handover algorithmcannot determine the target cell. In this case, reduce the optimal cell measurement time byadjusting the values of N and P and ensure that the handover decision is more sensitive tolevel changes. Handover failures may also occur when the receive level of a moving MSfluctuates significantly in a serving cell with complex topography, which makes it difficultfor the target cell to meet the N/P criteria. The following are some N/P parameters:– Handover algorithm II Edge HO Watch Time– Handover algorithm II Edge HO Valid Time– Handover algorithm I Edge HO Watch Time– Handover algorithm I Edge HO Valid Time– Intracell F-H HO Stat Time– Intracell F-H HO Last Time

Location ProcedureFigure 4-6 shows the procedure for locating handover problems due to incorrect dataconfigurations.



49

Figure 4-6 Procedure for locating handover problems due to incorrect data configurations

Troubleshooting Procedure1. Run the MML command LST GCELLHO2GBA2 to check whether neighboring cells are

configured correctly, especially whether any neighboring cells are missing based onmeasurement reports, onsite network planning data, and engineering parameter settings.Then, run the MML command LST GCELLIDLEBASIC to check whether NCCpermitted for the serving cell is set correctly.

l If yes (see Background Information), go to Step 2.



50

l If no, adjust neighboring cell configurations, or run the MML command SETGCELLIDLEBASIC to set NCC permitted to its correct value by referring toBackground Information. Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 2.

2. Check whether the problem cell is configured with a repeater or an RXU co-cell based onthe network plan, data configurations, and engineering parameter settings.l If no, go to Step 3.l If yes, run the MML command LST GCELLSOFT and check whether Directly

Magnifier BTS Flag or Co-Cell Switch is set to Yes.– If yes, go to 3.– If no, run the MML command SET GCELLSOFT to set Directly Magnifier BTS

Flag or Co-Cell Switch to Yes. Then, check whether the handover problem isresolved.– If yes, no further action is required.– If no, go to Step 3.

3. Run the MML command LST GCELLHOBASIC to check whether Edge HO ULRX_LEV Threshold and Edge HO DL RX_LEV Threshold are set correctly by referringto Background Information.l If yes, go to Step 4.l If no, run the MML command SET GCELLHOBASIC to change the value. Then,

check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 4.

4. Run the MML command LST GCELLHOBASIC to check whether Inter-layer HOHysteresis is set correctly by referring to Background Information.l If yes, go to Step 5.l If no, run the MML command SET GCELLHOBASIC to change the value. Then,


5. Run the MML command LST GCELLHOBASIC to check whether parameters relevantto optimal cell measurement time such as Handover algorithm II Edge HO WatchTime and Handover algorithm II Edge HO Valid Time are set correctly by referring toBackground Information.l If yes, go to Step 6.l If no, run the MML command SET GCELLHOBASIC to change the value. Then,



Typical CaseSymptom



51

The handover success rates for some cells are low. The outgoing handovers in these cells arenormal, but the number of incoming cell handovers is 0.

Cause Analysis

Possible causes for this problem are: incorrect data configurations, interference.


1. Check whether the neighboring cells of the problem cell work on the same frequency andhave the same BSIC.No such neighboring cells exist.

2. Check whether the BCCH frequency used by the problem cell has been changed.The BCCH frequency has not been changed.

3. Check whether there is strong interference for the problem cell.The traffic statistics show that the interference bands are normal and that there are a smallnumber of call drops and handovers due to poor voice quality in the problem cell. Even ifthere is strong interference for the problem cell, at least one handover can be performedsuccessfully. Therefore, the handover problem is not caused by interference.

4. Check whether the TRXs are operating properly.The TRXs are operating properly.

5. Check the data configurations for the problem cell.The BSIC of the problem cell has been changed, but the corresponding data of theneighboring cells has not been changed. As a result, the BSC cannot locate the target cellafter initiating a handover request.

6. Change the corresponding data of all neighboring cells. The handover problem is resolved.

4.5 Troubleshooting Handover Problems Due to TrafficCongestion in the Target Cell

This section describes how to troubleshoot handover problems due to traffic congestion in thetarget cell.

SymptomA handover to the target cell fails because the TCH congestion rates are high over several periods.

Background InformationThe possible causes of traffic congestion in the target cell are as follows:

l The number of MSs in the cell increases sharply because of assemblies or other activities.l The network optimization parameters are set inappropriately, which causes a large number

of MSs to camp on the cell.l The handover parameters are set inappropriately, which causes a large number of MSs to

hand over to the cell.l The local switching function is enabled, which causes the number of handover attempts to

increase.

The traffic statistics associated with TCH congestion in the target cell are as follows:



52

l Number of failed internal intra-cell handovers due to congestion– H3029A:Failed Internal Intra-Cell Handovers (No Channel Available) (TCH)– H3229A:Number of Unsuccessful Incoming Internal Inter-Cell Handovers (No Channel

Available) (TCH)l Traffic volume on TCHs

– K3014:Traffic Volume on TCHl TCH congestion rate (all TCHs are occupied)

– K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel)– K3011B:Failed TCH Seizures in TCH Handovers due to Busy TCH (Traffic Channel)

Location ProcedureFigure 4-7 shows the procedure for locating handover problems due to traffic congestion in thetarget cell.

Figure 4-7 Procedure for locating handover problems due to traffic congestion in the target cell

Troubleshooting Procedure1. View the traffic statistics associated with TCH congestion rates listed in Background

Information over several periods to determine whether serious TCH congestion occurredin the cell.l If yes, go to Step 2.l If no, go to Step 3.

2. Run the MML command LST GTRXDEV to check whether TCH Rate Adjust Allow isset to Yes.l If yes, split the cell, expand the cell capacity, or adjust network optimization parameters

to reduce the number of MSs in the cell. Then, check whether the handover problem isresolved.



53

– If yes, no further action is required.– If no, go to Step 3.

l If no, run the MML command SET GTRXDEV to set TCH Rate Adjust Allow toYes. Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, split the cell, expand the cell capacity, or adjust network optimization

parameters to reduce the number of MSs in the cell. Then, check whether thehandover problem is resolved. If yes, no further action is required. If no, go to Step3.


Typical CaseSymptom

Call drops sometimes occur when an MS hands over from the source cell to the target cell.

Cause Analysis

Possible causes of this problem are as follows:

1. There are coverage holes in the target cell after cell coverage is reduced.2. TRXs in the cell are faulty.3. TCHs in the cell are faulty.4. There are no sufficient handover resources in the cell.


1. Check whether the cell coverage and MS signals in the cell are normal.

(1) The cell coverage is normal.(2) MS signals in the cell are normal.

2. Check whether TRXs in the cell are faulty.TRXs in the cell are normal.

3. Check whether TCHs in the cell are faulty.TCHs in the cell are normal.

4. Perform single-user signaling tracing.The following results are found:l When handover failure messages are sent, all TCHs in the target cell are occupied.l When there are available TCHs in the cell, handovers can be performed successfully.These results show that handover failures occur because TCHs in the cell are congestedand handover resources are insufficient.

5. Expand the BTS capacity. The handover problem is resolved.

4.6 Troubleshooting Handover Problems Due to Poor UmInterface Quality

This section describes how to troubleshoot handover problems due to poor Um interface quality.



54

Symptom

Handover failures may occur when an MS fails to receive a handover command message fromthe network, or when an MS fails to occupy the assigned TCH in the target cell.

Background Informationl Interference may deteriorate the signal quality of the target cell. As a result, MSs fail to

occupy TCHs in the target cell even if the signal level of the target cell meets requirements.Common interference consists of uplink or downlink interference, antenna intermodulationinterference, CDMA network interference, and uplink or downlink intra-systeminterference.

– The common methods for locating interference are as follows:

– Interference bands are the bands of uplink interference levels on each TCH that theBTS reports to the BSC when TCHs are in the idle state. There are five interferencebands. The higher the interference band, the higher the interference level. The levelranges for the five interference bands are as follows:

– Interference band 1: -105 to -98 dBm





– Analyze Interference Band Measurement per TRX (MR.Iterf.TRX). If the numberof interference levels in the high interference bands is great, for example, if thepercentage of interference levels in interference bands 4 or 5 exceeds 30%, there isinterference.

– The following counters are associated with interference band measurement.

– AS4207A:Mean Number of TCHFs in Interference Band 1

– AS4207B:Mean Number of TCHFs in Interference Band 2

– AS4207C:Mean Number of TCHFs in Interference Band 3

– AS4207D:Mean Number of TCHFs in Interference Band 4

– AS4207E:Mean Number of TCHFs in Interference Band 5

– AS4208A:Mean Number of TCHHs in Interference Band 1

– AS4208B:Mean Number of TCHHs in Interference Band 2

– AS4208C:Mean Number of TCHHs in Interference Band 3

– AS4208D:Mean Number of TCHHs in Interference Band 4

– AS4208E:Mean Number of TCHHs in Interference Band 5

– The method for locating the interference problem is described as follows:Perform drive tests (DTs) to identify the cell or frequency with strong interference onthe live network. Then eliminate the interference by changing the frequency, or byadjusting the antenna tilt, transmit power, or cell coverage.

l If the Um interface quality is poor, MSs cannot receive any handover commands or physicalinformation. As a result, MSs send handover failure messages with one of the followingcause values: unspecified, timer expiry, protocol error, and other causes.

– The method for checking the Um interface quality is described as follows:



55

Analyze Receive Quality Measurement Distribution per TRX(MR.RecvQualOrig.TRX) to check the Um interface quality. Receive QualityMeasurement Distribution per TRX(MR.RecvQualOrig.TRX) measures thedistribution of receive quality in the measurement reports received on TCHs. Thereceive quality is divided into eight bands ranging from band 0 to 7. Each receive qualityband corresponds to a bit error rate (BER) range. A higher receive quality band indicatesa higher BER and poorer receive quality. If the percentage of uplink or downlink receivequality bands 6 and 7 exceeds 10%, the uplink or downlink transmission quality on theUm interface is poor.

– The following counters are associated with the Um interface quality:– Number of MRs on Downlink TCHF (Receive Quality Rank N)– Number of MRs on Uplink TCHF (Receive Quality Rank N)– Number of MRs on Downlink TCHH (Receive Quality Rank N)– Number of MRs on Uplink TCHH (Receive Quality Rank N)

– The method for improving the Um interface quality is described as follows:Network optimization engineers perform frequency optimization. If the Um interfacequality is not improved, perform DTs to locate and resolve the problem associated withthe receive quality and receive level. This is especially important if the problem is ahigh receive level and poor receive quality.

Location ProcedureFigure 4-8 shows the procedure for locating handover problems due to poor Um interfacequality.

Figure 4-8 Procedure for locating handover problems due to poor Um interface quality



56

Troubleshooting Procedure1. View the traffic statistics associated with interference bands listed in Background

Information to determine whether there is interference in the cell. Generally, there isinterference in the cell if the percentage of interference levels in interference bands 4 and5 exceeds 30%.l If no, go to Step 2.l If yes, remove the interference source or change the frequency by referring to

Background Information. Then, check whether the handover problem is resolved.


– If no, go to Step 2.2. View the traffic statistics associated with uplink and downlink quality listed in Background

Information to check whether the Um interface quality in the cell is satisfactory. Generally,the uplink or downlink transmission quality of the Um interface is poor if the percentageof uplink or downlink quality bands 6 and 7 exceeds 10%.l If yes, go to Step 3.l If no, perform network optimization to improve the Um interface quality by referring

to Background Information. Then, check whether the handover problem is resolved.


– If no, go to Step 3.3. Go to 4.2.2 Procedure for Locating Handover Problems.

Typical Case

Symptom

The intra-BSC incoming radio handover success rate for a cell under a BTS is between 10% and30%, and the handover failure rate is high.

Cause Analysis

There are coverage holes in the areas with heavy traffic, and the signal strength on the uplink isweak.


1. Check the hardware.BTS maintenance boards and channels are normal.

2. Check the handover configuration data.The handover configuration data is correct.

3. Perform DTs on the road 2 km away from the BTS where handovers are frequentlyperformed. If the MS fails to hand over to the target cell, the MS attempts to hand overback to the source cell. Handovers to the source cell are sometimes successful, but the callis dropped immediately after the MS hands over back to the source cell.

4. Perform several dialing tests on a locked frequency. When the MS serves as the callingMS, the dialing tests fail. When the MS serves as the called MS, calls are connected butdropped immediately. The problem location result indicates that the faulty components in



57

the combining and distribution unit (CDU) result in the high uplink channel loss, whichleads to a weak uplink signal strength.

5. Replace the CDU. If the incoming handover success rate exceeds 95%, the handoverproblem is resolved.

4.7 Troubleshooting Handover Problems Due to NE FaultsThis section describes how to troubleshoot handover problems due to NE faults.

SymptomHandover failures occur in most cells under a BSC, but there are no top N cells with sluggishperformance.

Background Informationl Handover failures occur when the BSC clock source operates abnormally.

You can run the MML command DSP CLK to check whether the BSC clock sourceoperates normally.– If Phase-locked loop state of current clock is set to Trace, the BSC clock source

operates normally.– If Phase-locked loop state of current clock is not set to Trace, the BSC clock source

operates abnormally.l The methods for resolving the BSC clock source problem are as follows:

– If a line clock serves as the BSC clock source, check whether the EIUa or OIUa boardthat retrieves line clock signals reports any of the following alarms. If any of thefollowing alarms are reported, clear these alarms by referring to the Alarm Reference.Then, check whether Phase-locked loop state of current clock is set to Trace. IfPhase-locked loop state of current clock is set to Trace or any of the following alarmsare not reported, switch over the active and standby GCUa boards or replace the activeGCUa with a new one to resolve the BSC clock source problem. If the BSC clock sourceproblem persists, Contact Huawei Customer Service Center.ALM-21201 E1/T1 Loss of SignalALM-21202 E1/T1 Loss of Frame AlignmentALM-21203 E1/T1 Remote Alarm Indication SignalALM-21204 E1/T1 Alarm Indication SignalALM-21205 E1/T1 Loss of Multiframe AlignmentALM-21206 E1/T1 LoopbackALM-21207 E1/T1 Excessive Bit Error RateALM-21208 E1/T1 Excessive Slip FramesALM-21209 E1/T1 Online Loopback DetectionALM-21252 SDH/SONET Loss of SignalALM-21253 SDH/SONET MS Remote Defect IndicationALM-21254 SDH/SONET Loss of FrameALM-21255 SDH/SONET Loss of Frame AlignmentALM-21256 SDH/SONET Loss of Cell Delineation



58

ALM-21257 SDH/SONET Signal Degraded– If the BITS clock serves as the BSC clock source, check whether the cable to the SMB

port (CLKIN0/1) on the GCUa is connected properly or the BITS clock source operatesnormally.

Location ProcedureFigure 4-9 shows the procedure for locating handover problems due to NE faults.

Figure 4-9 Procedure for locating handover problems due to NE faults

Troubleshooting Procedure1. Run the MML command DSP CLK to check whether Phase-locked loop state of current

clock is set to Trace.l If yes, go to Step 2.l If no, set Phase-locked loop state of current clock to Trace by referring to

Background Information. Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 2.


Typical CaseSymptom

There are 140 BTSs served by a BSC. The TMU clocks for 27 of the 140 BTSs are in the pull-in state, and the TMU clocks for 38 BTSs are in the free-run state. The handover success rate ofthe BSC is low and clock source exception alarms are reported on a large number of BTSs.

Cause Analysis

The clock source for the transmission equipment operates abnormally.



59


1. Check the BSC board clocks in each subrack.The BSC board clocks in each subrack are normal.

2. Check the distribution of problem BTSs on the BSC.The problem BTSs are distributed on boards in different subracks. This indicates that thehandover problem does not lie in a specific board or subrack.

3. Check the software for the 13 MHz clock frequency of the BTS.4. Change the clock mode and trace mode of the problem BTSs. Only some BTSs properly

trace the BSC clock, which is the upper-level clock. The other BTSs are in the pull-in orfree-run state. Regarding the BTSs that properly trace the BSC clock, the current values ofthese clocks are not between 1500 and 1900 and largely different from the default valuesand standard values. The difference values are larger than 1000. This indicates that the BSCclock may be unreliable. However, the BSC clock check result shows that the BSC clockis operating properly.

5. Figure 4-10 shows the network topology. The problem may lie in the clock source of theSDH equipment. The SDH equipment is Metro2050 and the clock board is STG. The upper-level line clock or local internal clock can be configured as the clock source of the SDHequipment. When the problem occurs, the local internal clock serves as the clock sourceof SDH 2. In this situation, the local internal clock also serves as the clock source of otherSDH equipment.

Figure 4-10 Network topology

6. Configure the upper-level line clock as the clock source of SDH 2, which indicates that

SDH 2 traces the clock of SDH 1. Four hours later, clocks for 8 BTSs are in the lockedstate, but clocks for 42 BTSs are still in the pull-in state and clocks for 15 BTSs are still inthe free-run state. Six hours later, all clocks for the problem BTSs under the BSC are in thelocked state. According to the traffic statistics, the handover success rate has increased from84% to 97%.



60

4.8 Troubleshooting Handover Problems Due toInappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction

This section describes how to troubleshoot handover problems due to inappropriate inter-BSC,inter-MSC, or inter-RAT interaction.

Symptoml The inter-BSC handover failure rate is high.l The inter-RAT handover failure rate is high.

Background InformationThe possible causes of inter-BSC or inter-RAT handover failures are as follows:

l Cell data associated with MSC handovers is configured incorrectly. The cell data includescell global identity (CGI), location area code (LAC), and handover number.

l Cell data associated with handovers to the target BSC is configured incorrectly.l Inter-RAT neighboring cells are configured incorrectly.l Encryption is performed improperly.l The handover procedure is performed improperly.

Location ProcedureFigure 4-11 shows the procedure for locating handover problems due to inappropriate inter-BSC, inter-MSC, or inter-RAT interaction.



61

Figure 4-11 Procedure for locating handover problems due to inappropriate inter-BSC, inter-MSC, or inter-RAT interaction

Troubleshooting Procedure1. Run the MML command DSP CLK to check whether the BSC properly traces the upper-

level clock (MSC clock).



62

l If Phase-locked loop state of current clock is set to Trace, go to Step 2.l If Phase-locked loop state of current clock is not set to Trace, use the BSC to trace

the MSC clock. Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 2.

2. Check whether neighboring cell configurations for the source and target BSCs are correctbased on the network planning data and engineering parameters of the live network. Alsocheck the system information and measurement reports collected during DTs.l If yes, go to Step 3.l If no, correct the neighboring cell configurations. Then, check whether the handover

problem is resolved.– If yes, no further action is required.– If no, go to Step 3.

3. Check whether data configurations for the problem cell served by the MSC are correct. Thedata includes CGI, LAC, and handover number as well as the office to which the problemcell belongs.l If yes, go to Step 4.l If no, correct the data configurations. Then, check whether the handover problem is

resolved.– If yes, no further action is required.– If no, go to Step 4.

4. Check whether the encryption procedure causes handover failures according to thesignaling procedure.l If no, go to Step 5.l If yes, adjust the encryption parameters or encryption procedure of the MSC or BSC.

Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 5.

5. Trace the signaling on the A or E interface to check whether the signaling interactionsbetween the source BSC and the MSC, between MSCs, and between networks are normal.l If yes, go to Step 6.l If no, identify the cause of abnormal signaling interactions by checking the A interface

version, signaling interaction on the E interface, and signaling interaction betweennetworks. Then, check whether the handover problem is resolved.– If yes, no further action is required.– If no, go to Step 6.


Typical Case 1Symptom

According to traffic statistics, the handover success rate for BSC A is lower than the handoversuccess rates for other BSCs. However, the historical traffic statistics show that the handoversuccess rate for BSC A is about 88%.



63

Cause Analysis

The MSC is not configured with any external LAC data.


1. View the success rates for various handovers. The inter-BSC outgoing handover successrate for BSC A is between 50% and 70%.

2. View the cell-level inter-BSC handover success rates. The inter-BSC handover successrates for some cells are small. The geographic display of these problem cells shows thatthese cells are located near the border of the areas served by vendor B's equipment.Therefore, it is suspected that the neighboring cell data of Huawei equipment is notsynchronized because modifications to data configurations for vendor B's equipment wereperformed without notification. However, the check result of neighboring cell data showsthat the data is configured correctly.

3. Perform signaling tracing on the problem cells under BSC A. After a handover request isdelivered, the target cell cannot be identified. The LAC of BSC A is inconsistent with theLAC of vendor B's equipment. Therefore, it is suspected that the MSC serving BSC A maynot be configured with the external LAC data for the cells near the border of the areas servedby vendor B's equipment.

4. Contact MSC maintenance engineers to analyze the problem. The MSC is not configuredwith the LAC data for the cells near the border of the areas served by vendor B's equipment.After the required LAC data is configured, the handover success rate exceeds 96%.

Typical Case 2

Symptom

After a BTS is swapped from BSC TP 01 to BSC TP 03, the outgoing radio handover successrate for vendor M's network is low, but other performance counters are normal. BSC TP 01 andBSC TP 03 are of the same version and served by different MSCs.

Cause Analysis

According to the signaling analysis, the encryption algorithm delivered by vendor M's MSC isincorrect. As a result, the encryption algorithm used by the MS is not the same as that used byvendor M's BTS during handovers.


1. The Huawei MSC is configured with the A5/2 encryption algorithm. The Huawei BSS andvendor M's BSS, however, are configured with A5/0 and A5/1 encryption algorithms. Asa result, after the MS accesses the Huawei network, the MS is not encrypted and notifiesthe Huawei MSC of relevant information.

2. During an outgoing handover to vendor M's network, vendor M's MSC requests that theMS be encrypted and sends the BSC an HO REQ message containing the supportedencryption algorithms A5/0, A5/1, and A5/2. The HO REQ message, however, does notcarry the information element Chosen Encryption Algorithm to show theencryption algorithm used by the MS.

3. Unaware of the encryption algorithm change during the handover, vendor M's MSC selectsthe A5/1 encryption algorithm and does not notify the MS of the encryption algorithmchange using the HO REQ ACK message containing the Layer 3 information element.



64

4. The BSC does not obtain the encryption algorithm change information from the HO REQACK message and instructs the MS to use the original encryption algorithm A5/0.

5. The encryption algorithm used by the MS is not the same as that used by vendor M's BTS.When accessing vendor M's network, the MS fails to receive the Physical Infomessage from vendor M's BTS because the Physical Info message is encrypted bythe A5/1 algorithm. As a result, the MS fails to access vendor M's network and is handedover back to the original channel.

6. Change the encryption algorithm on vendor M's MSC. The handover problem is resolved.



65

5 Call Drops

About This Chapter

This chapter describes how to locate and troubleshoot call drops.

5.1 Call Drop RateThe call drop rate indicates the probability with which an MS will release ongoing callsunexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate userexperience.

5.2 Locating Call DropsThis section describes how to locate call drops.

5.3 Troubleshooting Call Drops Due to Poor Um Interface QualityThis section describes how to troubleshoot call drops due to poor Um interface quality.

5.4 Troubleshooting Call Drops Due to Equipment FaultsThis section describes how to troubleshoot call drops due to equipment faults.

5.5 Troubleshooting Call Drops Due to Transmission FaultsThis section describes how to troubleshoot call drops due to transmission faults.

5.6 Troubleshooting Call Drops Due to Incorrect Parameter SettingsThis section describes how to troubleshoot call drops due to incorrect parameter settings.

GBSS9.0Troubleshooting Guide 5 Call Drops


66

5.1 Call Drop RateThe call drop rate indicates the probability with which an MS will release ongoing callsunexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate userexperience.

FormulaSee the online help for the formulas for calculating the following counters associated with calldrops:l ZTR304A:Call Drop Rate on TCH per cell(Excluding Handover)l ZTR304:Call Drop Rate on TCH per cell(including Handover)

Call Drop Rate on TCH per cell(Excluding Handover) indicates the call drop rate in the stablestate. With regard to the formulas for calculating the two counters, the numerators in bothformulas are the same, except that Successful TCH Seizures in TCH handovers (Traffic Channel)is included in the denominator of ZTR304:Call Drop Rate on TCH per cell(including Handover)but not in the denominator of ZTR304A:Call Drop Rate on TCH per cell(Excluding Handover).Therefore, the value of the former is smaller than that of the latter.

Measurement Points and Signaling ProcedureSee the online help for CM33:Call Drops on Traffic Channel.

According to the measurement points for the call drop rate, call drops are classified into twotypes:l Call drops in the stable state, as shown in Figure 5-1l Call drops in the handover state, as shown in Figure 5-2



67

Figure 5-1 Procedure for Call drops in the stable state

Figure 5-2 Procedure for call drops in the handover state

5.2 Locating Call DropsThis section describes how to locate call drops.

5.2.1 Procedure for Locating Call DropsBefore locating call drops, determine the fault range.



68

Principlesl Before locating call drops, determine whether the fault exists on the entire network or only

in certain cells by analyzing 5.2.2 Counters Related to Call Drops.

l Analyze the proportion of the various types of call drops to determine whether call dropsare caused by poor Um interface quality.

– If the values of CM333:Call Drops due to Abis Terrestrial Link Failure (TrafficChannel) and CM334:Call Drops due to Equipment Failure (Traffic Channel) increase,call drops are not caused by poor Um interface quality. In this case, check for equipmentand transmission faults.

– If the counters indicating call drops due to poor Um interface quality increase, checkfor inappropriate network parameter settings, interference, and coverage problems.

Location Procedure

Figure 5-3 shows the procedure for locating call drops.

Figure 5-3 Procedure for locating call drops



69

5.2.2 Counters Related to Call DropsThe counters related to call drops are classified according to call drop type for easytroubleshooting.

Table 5-1 lists the counters related to call drops.

Table 5-1 Counters related to call drops

Counters related to call drops

CM33:Call Drops on TrafficChannel

CM33C:Call Drops on RadioInterface (Traffic Channel)

CM330:Call Drops on RadioInterface in Stable State(Traffic Channel)

CM331:Call Drops on RadioInterface in Handover State(Traffic Channel)

CM332:Call Drops Due toNo MR from MS for a LongTime (Traffic Channel)

/

CM333:Call Drops due toAbis Terrestrial Link Failure(Traffic Channel)

/

CM334:Call Drops due toEquipment Failure (TrafficChannel)

/

CM335:Call Drops due toForced Handover (TrafficChannel)

/

CM397:Call Drops due tolocal switching Start Failure

/

CM385:Call Drops due toFailures to Return to NormalCall from local switching

/

CM33C:Call Drops on Radio Interface (Traffic Channel) indicates call drops due to poor Uminterface quality, which is the most common cause of call drops on a network. CM333:CallDrops due to Abis Terrestrial Link Failure (Traffic Channel) and CM334:Call Drops due toEquipment Failure (Traffic Channel) indicate call drops due to transmission and equipmentfaults, respectively. Pay attention to these two counters if their values are large.

Table 5-2 lists the counters related to call drops due to poor Um interface quality.



70

Table 5-2 Counters related to call drops due to poor Um interface quality

Counters related to call drops due to poor Um interface quality

CM33C:Call Drops on RadioInterface (Traffic Channel)

CM330:Call Drops on RadioInterface in Stable State(Traffic Channel)

CM3300:Call Drops onTraffic Channel in StableState (Error Indication)

CM3301:Call Drops onTraffic Channel in StableState (Connection Failure)

CM3302:Call Drops onTraffic Channel in StableState (Release Indication)

CM331:Call Drops on RadioInterface in Handover State(Traffic Channel)

H3027Ca:Failed InternalIntra-Cell Handovers (TimerExpired) (TCHF) (TrafficChannel)

H3028Ca:Failed InternalIntra-Cell Handovers (TimerExpired) (TCHH) (TrafficChannel)

H3127Ca:Number ofUnsuccessful OutgoingInternal Inter-CellHandovers (Timer Expired)(TCHF) (Traffic Channel)

H3128Ca:Number ofUnsuccessful OutgoingInternal Inter-CellHandovers (Timer Expired)(TCHH) (Traffic Channel)

H3327Ca:Failed OutgoingExternal Inter-CellHandovers (T8 Expiry)(TCHF) (Traffic Channel)

H3328Ca:Failed OutgoingExternal Inter-CellHandovers (T8 Expiry)(TCHH) (Traffic Channel)

l In the stable state, focus on CM3300:Call Drops on Traffic Channel in Stable State (ErrorIndication) and CM3301:Call Drops on Traffic Channel in Stable State (ConnectionFailure). Generally, call drops in the stable state as indicated by CM3301:Call Drops onTraffic Channel in Stable State (Connection Failure) account for the largest proportion ofcall drops due to poor Um interface quality.



71

l In the handover state, focus on H3127Ca:Number of Unsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHF) (Traffic Channel) and H3128Ca:Number ofUnsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHH) (TrafficChannel) because inter-cell handovers account for a large proportion.

l Analyzing the counters related to call drops helps determine the main cause of call drops.Call drop types whose portion increases from a small value to a large value need specialattention.

5.2.3 Types of Call DropsClassifying call drops into different types helps troubleshoot call drops.

Figure 5-4 describes the types and common causes of call drops.



72

Figure 5-4 Procedure for locating call drops

Call Drops on Um Interface in the Stable State

When a call is in the stable state, call drops may occur after a BTS sends the BSC one of thefollowing messages:



73

l ERROR INDICATION

– When the BTS sends an I frame, the timer T200 starts. If the BTS does not receive anacknowledgment message from the BSC before the timer expires, it resends the I framefor a maximum of 200 times. If the BTS still does not receive an acknowledgmentmessage, the BTS sends the BSC an ERROR INDICATION message with a cause valueof timer T200 expired (N200+1) times (0x01).

– If the BTS detects that the serial numbers of the received I and S frames are out of order,it sends the BSC an ERROR INDICATION message with a cause value of sequenceerror (0x07).

– When the BTS receives an unexpected DM frame, the BTS sends the BSC an ERRORINDICATION with a cause value of unsolicited DM response (0x05).

– The call drops indicated by the ERROR INDICATION message are generally causedby interference or coverage problems, though they may also be caused by inappropriateantenna installation, TRX faults, or incorrect data configurations.

l CONNECTION FAILURE INDICATION

– If the BTS detects that uplink SACCH decoding fails repeatedly within the valuespecified by SACCH Multi-Frames, the BTS sends a CONNECTION FAILUREINDICATION message to the BSC.

– The call drops indicated by the ERROR INDICATION message are generally causedby interference or coverage problems, though they may also be caused by inappropriateantenna installation, TRX faults, or incorrect data configurations.

l RELEASE INDICATION

– In the multi-frame link establishment state, when receiving a DISC frame from an MS,the BTS sends a RELEASE INDICATION message to the BSC.

– The RELEASE INDICATION message is sent during normal release procedures.Therefore, it does not always indicate a call drop. Call drops indicated by the RELEASEINDICATION message seldom occur. They may be caused by inappropriate signalinginteraction problems between the MS and the BSS/NSS, not by poor Um interfacequality.

Call Drops on Um Interface in the Handover State

This type of call drop occurs after a BSC delivers a handover command but does not receive anacknowledgment message before the relevant timer expires.

l Intra-cell handoversWhen Intracell HO Allowed is set to YES(YES) by using the MML command SETGCELLHOBASIC, an interference handover or bad quality handover can be performed.However, if the signal level of the neighboring cell is low, a large number of intra-cellhandovers may increase the call drop rate.

l Inter-cell handoversCall drops during inter-cell handovers are generally caused by interference or coverageproblems, though they may also be caused by inappropriate antenna installation, TRXfaults, incorrect neighboring cell configurations, or a large clock frequency offset.

l Inter-BSC handoversThe causes of call drops during inter-BSC handovers are similar to those of intra-BSChandovers. The main causes are as follows: (1) The neighboring relationship configuredon the BSS is inconsistent with that configured on the NSS; (2) The clock frequency offset



74

is large. These two factors should also be considered for call drops during inter-RAThandovers.

Call Drops Due to No Measurement Report Submitted by the MS

This type of call drop seldom occurs. If a large number of call drops occur because the BSCdoes not receive any measurement reports from an MS within a specified period (five minutesby default), an exception occurs in the interaction between the BSS and the MS. In this case,check the configuration data related to measurement reports as well as the signaling interactionbetween the BSS and the MS. For example, check whether the BTS can decode the extendedmeasurement reports submitted by the MS.

Call Drops Due to Abis Terrestrial Link Faults

This type of call drop seldom occurs. If there are a large number of such call drops, the BSCdetects that radio signaling links (RSLs) are interrupted because the Abis transmission or theBSC/BTS LAPD link transmission is faulty. In this case, check the relevant alarms, Abistransmission, and BSC/BTS LAPD link transmission.

Call Drops Due to Equipment Faults

This type of call drop occurs in cases of abnormal transmission, BSS hardware faults, or incorrectdata configurations. It may also occur in cases of dynamic data configuration (such as frequencymodification or cell deletion) or internal BSC network connection failures. When this type ofcall drop occurs, check the relevant alarms, Abis/Ater/A interface transmission, TRX boards,and BSC DPU/TNU/interface board.

Call Drops Due to Forced Handovers

This type of call drop may occur during handovers triggered by dynamic channel adjustment.This type of call drop may also occur when MSC-triggered handovers or handovers triggeredby the following causes time out: TRX cooperation, channel preemption, cell/TRX/channelblocking, or OM. Dynamic channel adjustment, TRX cooperation, and channel preemption arethe most common causes. If there are a large number of such call drops, check whether the dataconfiguration is correct and whether TRXs become faulty frequently.

5.3 Troubleshooting Call Drops Due to Poor Um InterfaceQuality

This section describes how to troubleshoot call drops due to poor Um interface quality.

Symptom

Call drops due to poor Um interface quality consist of call drops for the Um interface in thestable state and call drops for the Um interface in the handover state.

l With regard to the signaling on the Abis interface, call drops for the Um interface in thestable state refer to the call drops that occur after the BTS sends an ERROR INDICATION,CONNECTION FAILURE INDICATION, or RELEASE INDICATION message to theBSC.



75

l With regard to the signaling on the Abis interface, call drops for the Um interface in thehandover state refer to the call drops that occur when a handover times out after the BSCissues a handover command to an MS.

CM33C:Call Drops on Radio Interface (Traffic Channel) indicates the number of call drops dueto poor Um interface quality.

Background Informationl The cause of call drops on the Um interface can be identified from the aspects of

interference, uplink and downlink level balance, coverage, antenna system, BTS hardware,BSC handover parameters, and the neighboring cell configuration for handover. If the calldrops are caused by incorrect BSC handover parameter settings or incorrect neighboringcell configuration for handover, analyze the problem by referring to 4 HandoverProblems. The relevant descriptions are not included in this section.

l To locate the interference, perform the following operations:

1. Query Receive Quality Measurement Distribution per TRX(MR.RecvQualOrig.TRX). If the receive quality is poor, for example, if the proportionof uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is ahigh probability that call drops will occur.

2. Analyze Interference Band Measurement per TRX(MR.Iterf.TRX). If interferencelevels occur in the higher-level interference bands, for example, the proportion ofinterference levels in interference bands 4 and 5 exceeds 10%, the call drops are causedby uplink interference.

3. Use either of the following methods to determine whether call drops are caused byinterference. One method is to analyze the signaling on the Abis interface. If themeasurement reports (MRs) before call drops show that both the uplink and downlinklevels are satisfactory but the receive quality is poor, call drops are caused byinterference. The other method is to analyze the TEMS signaling collected when calldrops occur. If the downlink level is satisfactory but the carrier-to-interference ratio(CIR) is small before call drops occur, the call drops are caused by interference.

Location ProcedureFigure 5-5 shows the procedure for locating call drops due to poor Um interface quality.



76

Figure 5-5 Procedure for locating call drops due to poor Um interface quality

Troubleshooting Procedure1. Check whether there is any interference. For details, see Background Information.

l If the call drops are caused by interference, check whether there are any interferencesources exist onsite or perform drive tests (DTs) to locate the interference source. Inaddition, check whether repeaters have been installed or whether installed repeaters arefaulty by referring to the following description. If any interference source is found,eliminate it by referring to 12 Interference Problems. Then, go to Step 2.

(1) Run the LST GCELLSOFT command to check whether Directly Magnifier BTSFlag is set to Yes. If Directly Magnifier BTS Flag is set to Yes, the cell isconfigured with repeaters. If Directly Magnifier BTS Flag is set to No, checkwhether other operators' repeaters are installed near the cell or whether anyrepeaters are installed without permission.



77

(2) If repeaters are installed, check whether they are wideband repeaters. If they arewideband repeaters, check whether the uplink or downlink gain is large. If theuplink or downlink gain is large, reduce it as required. Shut down the repeaters ifthey have great impact on the call drop rate.

(3) Check whether repeaters are faulty or whether the uplink or downlink gain isbeyond the normal range. If repeaters are faulty or the uplink or downlink gain isbeyond the normal range, the actual BTS coverage may change, which increasesthe call drop rate. If any repeater problem occurs in the cell, the number of MRswith a large timing advance (TA) value measured for Number of MRs based onTA per TRX(MR.TaDistribOrig.TRX) is great.

l If call drops are not caused by interference, go to Step 3.2. Check whether the call drop problem is resolved.

l If yes, no further action is required.l If no, go to Step 3.

3. Check whether the uplink and downlink levels are balanced.Query Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX).With regard to TRXs, if the proportion of the uplink and downlink level balance class 1 or11 to all uplink and downlink level balance classes exceeds 30%, the uplink and downlinklevels are unbalanced.

NOTEUplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX) indicates the statisticalresult of MRs. If the MRs before call drops show that the uplink and downlink levels are unbalanced, thenthis is the cause of the call drops.

l If yes, go to Step 5.l If no, check whether the equipment transmission and TRX cable connections onsite are

proper, and whether there are any potential risks on the antenna system by referring tothe following description. After the preceding items are checked and the faults arerectified, go to Step 4.– If dual-transmit antennas are configured, ensure that the tilt and azimuth of the

antennas are the same.– Check whether the jumpers are misconnected by analyzing DT data. If the jumpers

are misconnected, the uplink signal level in the cell is significantly lower than thedownlink signal level, and call drops are likely to occur in a cell far away from theBTS. In this situation, reconnect the jumpers.

– If the feeders are damaged, wet, or distorted, or if the connectors are in poor contact,both the transmit power and receive sensitivity are reduced. As a result, call dropsoccur with a high probability. Locate these kinds of problems by referring toALM-4144 TRX VSWR alarm, ALM-2156 TRX VSWR Alarm, or ALM-26529RF Unit VSWR Threshold Crossed. If any feeder is faulty, immediately replace it.If the antenna system is faulty, both the call drop rate and handover failure rate arehigh, and the uplink and downlink receive quality is totally different or both theuplink and downlink receive quality is poor.

4. Check whether the call drop problem is resolved.l If yes, no further action is required.l If no, go to Step 5.

5. Check whether there are any coverage problems.

(1) Query TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX



78

(MR.RecvLevlOrigHalfRate.TRX) to analyze the mapping between the receivequality and receive levels. If poor receive quality mainly maps to low receive levels,call drops in the cell may be caused by poor receive quality, which results fromcoverage problems.

(2) Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If thereare many MRs with a large TA value, the call drops are caused by too-wide coverageor coverage overlaps. Otherwise, the call drops are caused by weak coverage.

(3) Analyze the signaling to locate the cause of the call drops. If the TA value is largewhen an MS accesses the network and if the signal level is low when call drops occur,the call drops are caused by too-wide coverage or coverage overlaps. If the TA valueis small when an MS accesses the network, the call drops are caused by weak coverage.If the proportion of the sum of TA values 0 through 5 to the sum of all the values isless than 90%, check for a coverage problem in the cell based on the coverage scenarioand DT result.l If yes, resolve the problem and go to Step 6.Contact network optimization

engineers to resolve the cell coverage problem. Then, go to Step 6l If no, go to Step 7.


7. Check the Um interface quality.Query TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) orTCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If theproportion of receive quality bands 6 and 7 to all receive quality bands exceeds 10%, theuplink or downlink receive quality is poor.l If the Um interface quality is poor, request network optimization engineers to optimize

frequency data. Then, go to Step 8.l If the Um interface quality is satisfactory, go to Step 9.


9. Perform DTs to check whether either of the following problems occur: high receive leveland poor receive quality; low receive level and poor receive quality.l If yes, request network optimization engineers to analyze and resolve the problem. Then,

go to Step 10.l If no, return to Procedure for Locating Call Drops to continue the processing.

10. Check whether the call drop problem is resolved.l If yes, no further action is required.l If no, return to Procedure for Locating Call Drops to continue the processing.

Typical CaseSymptom

The call drop rate of CELL3 under a BTS reaches 10%, but the call drop rate and congestionrate of CELL1 and CELL2 are normal.

Cause Analysis



79

There is external interference or the coverage is weak.


1. View the traffic statistics. Calls in the cell are dropped because of poor Um interface quality.2. View and analyze the traffic statistics. The distribution of interference levels in interference

bands is regular, specifically, the interference is strong during peak hours and weak duringoff-peak hours.

3. Change the frequencies of CELL3 to ensure that the frequency spacing is 1 MHz or more.The problem persists, and therefore there is no co-channel or adjacent-channel interference.

4. Perform a frequency scan test to locate the external interference source by using a spectrumanalyzer. The test result shows that there is a constant signal with a center frequency of904.14 MHz and a spectrum bandwidth of 300 kHz, which is similar to the signal from ananalog spectrum. The signal strength at the divider ports for CELL3, CELL2, and CELL1is -27 dBm, -40 dBm, and -60 dBm respectively. The higher the signal strength, the greaterthe interference. The traffic volume in the daytime is greater than that at night, and thereforeintermodulation probably occurs. The root cause of the problem appears to be an externalinterference source with a center frequency of 904 MHz. The interference source cannotbe located after DTs are performed by using the spectrum analyzer. Therefore, all testsmust be performed on the rooftop. The test result shows that the interference source is anantenna on a repeater. Interrupt the signal and perform the test again. The test result verifiesthat the antenna is the source of interference signals.

5. Shut down the repeater. The call drop rate of CELL3 is restored to normal.

5.4 Troubleshooting Call Drops Due to Equipment FaultsThis section describes how to troubleshoot call drops due to equipment faults.

SymptomOn the BSC side, call drops due to BSC hardware faults, abnormal internal software processing,or configuration errors are considered as call drops due to equipment faults. These call dropsare indicated by the cause value equipment failure (0x20) carried in the CLEAR REQ messagein the base station subsystem application part (BSSAP) messages traced on the A interface.CM334:Call Drops due to Equipment Failure (Traffic Channel) indicates the number of calldrops due to equipment faults on the BSC side.

Call drops due to BTS hardware faults are also considered as call drops due to equipment faults.BTS hardware faults may deteriorate the Um interface quality or cause coverage problems. Thisleads to an increase in the call drop rate.

Background InformationCall drops due to equipment faults are classified into the following types:l Call drops due to faults in the MSCl Call drops due to BSC or BTS software defectsl Call drops due to BSC or BTS hardware faultsl Call drops due to dynamic configurationl Call drops due to transmission faultsl Call drops due to insufficient BSC resources



80

The following alarms are associated with call drops due to equipment faults.l ALM-21807 OML Faultl ALM-2204 TRX Communication Alarml ALM-2156 TRX VSWR Alarml ALM-4144 TRX VSWR alarml ALM-26529 RF Unit VSWR Threshold Crossedl ALM-3606 DRU Hardware alarml ALM-20241 Board Unavailablel ALM-20243 Board Hardware Faultl ALM-20254 DSP Unavailablel ALM-20231 Link Between TDM Switching Boards in Different Subracks Faultyl ALM-20230 TDM Link Between TDM Switching Board and Service Board Faulty

Location Procedure

Figure 5-6 shows the procedure for locating call drops due to equipment faults.

Figure 5-6 Procedure for locating call drops due to equipment faults



81

Troubleshooting Procedure1. Check whether any of the alarms listed in Background Information are reported.

l If yes, clear the alarms by referring to the Alarm Reference. Then, go to Step 2.l If no, go to Step 3.


3. Check whether the operations, such as dynamically deleting cells or TRXs and modifyingchannel attributes or base station identity codes (BSICs), are performed when call dropsoccur.l If yes, check whether there are no call drops when the relevant operations are not

performed. If there are no call drops, no further action is required. Otherwise, go toStep 4.

l If no, go to Step 4.4. Analyze the signaling on the A interface when call drops occur to check whether the MSC

sends a large number of Reset Circuit messages.l If yes, call drops are caused by circuit resetting. Request core network (CN) engineers

to resolve the problem. Then, go to Step 5.l If no, return to Procedure for Troubleshooting Call Drops to continue the processing.

5. Check whether the call drop problem is resolved.l If yes, no further action is required.l If no, return to Procedure for Troubleshooting Call Drops to continue the processing.


A large number of call drops due to equipment faults occur within a measurement period aftercell BSICs are modified after absolute radio frequency channel number (ARFCN) informationis imported during peak hours.

Cause Analysis

Dynamically deleting cells or TRXs and modifying channel attributes or BSICs may cause calldrops due to equipment faults.


1. Check the traffic statistics measured when call drops occur. Call drops due to equipmentfaults occur only in some cells controlled by the BSC.

2. Check for alarms reported on the BSC when the call drops occur. There are no hardwarealarms.

3. Check the BSC operation logs. The cell BSICs are modified when call drops occur. Whena cell BSIC is dynamically modified on the BSC, calls in the cell are released automaticallyand measured as call drops due to equipment faults. In conclusion, call drops are causedby dynamic BSIC modification.

4. You are advised to dynamically delete cells or TRXs and modify channel attributes orBSICs during off-peak hours.



82


A large number of call drops due to equipment faults occur under a BSC in the early morning.

Cause Analysis

Calls on the circuits are dropped after the MSC sends a Reset Circuit message.


1. Check the traffic statistics measured when call drops occur. Call drops due to equipmentfaults occur on all BTSs under the BSC.

2. Check for alarms reported on the BSC when the call drops occur. There are no hardwarealarms.

3. Check the operation logs. No configuration operations are performed when call drops occur.4. Perform the operations provided in the Tracing Messages on the A Interface on the

problematic BSC. The MSC sends a large number of Reset Circuit messages. It isdetermined that call drops due to equipment faults occur because the circuits on the MSCside are reset.

5. Request MSC engineers to troubleshoot the fault. The call drop problem is resolved.

5.5 Troubleshooting Call Drops Due to Transmission FaultsThis section describes how to troubleshoot call drops due to transmission faults.

SymptomThe relevant alarms are reported, and the values of CM333:Call Drops due to Abis TerrestrialLink Failure (Traffic Channel) or CM334:Call Drops due to Equipment Failure (Traffic Channel)increase. For the relevant alarms, see Background Information.

Background Informationl Generally, Abis interface transmission faults may lead to an increase in the value of

CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel), and the Ater/Ainterface transmission faults may lead to an increase in the value of CM334:Call Drops dueto Equipment Failure (Traffic Channel).

l Abis/Ater/A transmission link instability may increase the call drop rate. Check the relevantalarms to determine the link transmission status. If there are a large number of relevantalarms, contact the transmission engineers. The relevant BSC alarms are as follows:– OML fault alarms

ALM-21807 OML Fault– BTS LAPD alarms

ALM-4102 TRX LAPD Link Interrupt AlarmALM-2114 TRX LAPD Link Interrupt AlarmALM-3052 LAPD alarmALM-3572 LAPD alarm

– BSC LAPD alarms



83

ALM-21511 LAPD Link CongestionALM-21512 LAPD Link Fault

– Optical interface MSP alarmsALM-21311 MSP Multiplex Section K1/K2 MismatchALM-21312 MSP Multiplex Section K2 MismatchALM-21313 MSP Port Protection Mode Mismatch

– Optical Interface Transmission Alarms (ALM-21251 to ALM-21291)– E1/T1 Transmission Alarms (ALM-21201 to ALM-21209)– SS7 Signaling Alarms (ALM-21501 to ALM-21506)

Location ProcedureNone

Troubleshooting Procedure1. Clear the alarms listed in Background Information by referring to the relevant alarm help.2. Check whether CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel)

and CM334:Call Drops due to Equipment Failure (Traffic Channel) return to normal.l If yes, no further action is required.l If no, return to Procedure for Locating Call Drops.

Typical CaseSymptom

The value of CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel) is high.

Cause Analysis

Abis transmission links are interrupted intermittently.


1. View the traffic statistics. Call drops due to equipment faults occur mainly on BTS 17.2. Check the alarms that are generated when the fault occurs. The E1/T1 Remote Alarm and

a large number of TRX LAPD Link Interrupt Alarms are generated. As a result,transmission is interrupted intermittently, LAPD links are interrupted, and the cell is outof service, leading to call drops.

3. Rectify the transmission faults, and clear the relevant alarms. The value of CM333:CallDrops due to Abis Terrestrial Link Failure (Traffic Channel) returns to normal.

5.6 Troubleshooting Call Drops Due to Incorrect ParameterSettings

This section describes how to troubleshoot call drops due to incorrect parameter settings.

SymptomThe call drop rate increases significantly if MSC- or BSC-level parameters are set incorrectly.If some MSC-level parameters are set incorrectly, for example, some parameters are set to



84

different values before and after an MSC cutover, call drops may occur under all BSCs connectedto the MSC. In addition, if the BSC-level parameters are set incorrectly, call drops may occurin some or all of the cells under the BSC.

Background Informationl On the MSC side, the following parameters (mainly referring to timers here) affect the call

drop rate:

– T305, T306, T308, and T338

The MSC uses the timers T305, T306, and T338 to monitor on-hook procedures. T308is used to monitor the resource release procedure. All of these timers must be set duringBSC data configuration. If any is set to an invalid value or too large a value, the MSCtakes a long time to clear a call after the subscriber hangs up. Then, timers such as RadioLink Timeout and T3103 on the BSC side expire, and the call is measured as dropped,and the call drop rate increases.

– Terminate Short Message Timer

This timer prevents the MSC from repeatedly sending a short message. If this timer isset to too large a value, the MSC does not clear any short messages received during alink release. Instead, the MS sends a release message to the BTS, which then sends aRelease Indication message to the BSC. The BSC then sends the MSC a Clear Requestmessage, requesting the MSC to release the call. As a result, the call drop rate increases.

– T310

The MSC uses this timer to monitor incoming calls. The MSC starts this timer uponreceiving a Call Confirm message and stops it upon receiving an Alerting, Connect, orDisconnect message. If this timer is set to too large a value, the value of the timerSACCH Multi-Frames or Radio Link Timeout on the BSS side may decrease to 0 ina poor radio environment. As a result, the MSC releases the call and the call drop rateincreases.

– T313

The MSC uses this timer to monitor the call connection procedure. The MSC starts thistimer upon sending a Connect message and stops it upon receiving a Connect ACKmessage. If the MSC does not receive a Connect ACK message before the timer expires,the MSC clears the call. If this timer is set to too large a value, the BSS sends a ClearRequest message to the MSC after the value of the timer SACCH Multi-Frames orRadio Link Timeout on the BSS side decreases to 0 in the following scenario: TheMSC sends the BSS a Connect message and waits for a Connect ACK message, but theBSS does not receive the Connect message in a poor radio environment or cannotcorrectly decode the message. As a result, the call is dropped and the call drop rateincreases.

– T301

This timer specifies the period during which a phone is ringing. The MSC starts thistimer upon receiving an Alerting message and stops it upon receiving a Connect orDisconnect message. If this timer expires before the MSC receives either message, theMSC sends the calling MS a Disconnect message containing the cause value #19 useralerting, no answer, instructing the calling MS to clear the current call. In addition,the MSC sends the called MS a Disconnect message, containing the cause value #102recovery on timer expiry or cause value #31 normal, unspecified, instructing thecalled MS to clear the current call. If this timer is set to too large a value, the BSC sendsthe MSC a Clear Request message before this timer expires due to poor radio



85

environment or link failures, requesting the MSC to release the current call. As a result,the call drop rate increases.

– T303

The MSC uses this timer to wait for a mobility management (MM) connection. TheMSC starts this timer upon sending a SETUP message and stops it upon receiving aCall Confirm or Release Complete message. If this timer expires before the MSCreceives either message, the MSC clears the current call. If this timer is set to too largea value, the BSS sends the MSC a Clear Request message after the value of the timerSACCH Multi-Frames or Radio Link Timeout on the BSS side decreases to 0 in apoor radio environment. As a result, the call is dropped and the call drop rate increases.

– Short Message ACK Timer

The MSC starts this timer when the network side sends a short message to an MS. Ifthe MS does not respond with a CP_ACK message before the timer expires, the MSCsends the BSC a Clear Command message, instructing the BSC to release radioresources. If this timer is set to too large a value, the MSC does not release the currentcall or clear terrestrial resources and TCH resources over the Um interface after theDisconnect message is issued. Because the MS does not receive a short message fromthe network, the MS sends the BTS a Disconnect message, requesting the BTS to releaselayer-2 links. In this case, the BTS sends a Release Indication to the BSC, and then theBSC sends a Clear Request message to release the current call. As a result, the call droprate increases.

l On the BSC side, the following parameters affect the call drop rate:

– SACCH Multi-Frames

This parameter determines whether an uplink radio link is faulty. Each time the BTSfails to decode measurement reports sent by the MS over the SACCH, the value of thisparameter decreases by 1. Each time the BTS successfully decodes measurement reportssent by the MS over the SACCH, the value of this parameter increases by 2. If the valueof this parameter is 0, the BTS assumes that the uplink radio link is faulty. If the valueof M3101A:Call Drops due to CONN FAIL Received on TCHF (Traffic Channel) inStable State (Radio Link Failure) is large, a large number of calls drop due to poor radioenvironment. In this case, set this parameter to a larger value.

– Radio Link Timeout

This parameter determines the time for disconnecting a call when an MS fails to decodethe messages over the SACCH. Once a dedicated channel is allocated to an MS, thecounter S is enabled and the initial value is set to the value of this parameter. Each timethe MS fails to decode an SACCH message, the counter S decreases by 1. Each timethe MS correctly decodes an SACCH message, the counter S increases by 2. When thecounter S is equal to 0, the downlink radio link is considered as failed. Therefore, whenthe voice or data quality deteriorates to an unacceptable situation and cannot beimproved using power control or channel handover, the connection is re-established orreleased. If the value of M3101A:Call Drops due to CONN FAIL Received on TCHF(Traffic Channel) in Stable State (Radio Link Failure) is large, a large number of callsdrop due to poor radio environment. In this case, set this parameter to a larger value.

– Minimum Access RXLEV

This parameter specifies the minimum receive level for an MS to access the BSS. If thisparameter is set to a small value, some MSs with low signal levels may attempt to accessthe network and call drops are likely to occur. To reduce the call drop rate, set thisparameter to a large value. A large value, however, may affect the call setup successrate and traffic volume.



86

– CS RACH Min. Access LevelThis parameter specifies the signal level threshold for an MS to access the network overthe RACH. If this parameter is set to a small value, some MSs with low signal levelsmay attempt to access the network and call drops are likely to occur. To reduce the calldrop rate, set this parameter to a large value. A large value, however, may decrease thecall setup success rate and paging success rate.

– Handover Completion Message TimersHandover completion message timers consist of T3103A, T3103C, and T8. If any ofthese timers is set to a small value, the BSC may receive no message after timers T3103Aand T3103C expire. Therefore, the BSC assumes that a radio link fails in the sourcecell. Then, the BSC releases channels in the source cell. As a result, call drops occur.If the value of CM331:Call Drops on Radio Interface in Handover State (TrafficChannel) is large, set this parameter to a large value. A large value, however, may leadto TCH congestion.

– T3109This parameter specifies the period during which a BSC waits for a Release Indicationmessage after issuing a Channel Release message. If this parameter is set to a smallvalue, the BSC may release the link before receiving a Release Indication message,resulting a call drop. To reduce the call drop rate, set this parameter to a value 2s longerthan the value of Radio Link Timeout.

– T3111This parameter specifies the period during which channel deactivation is delayed whenthe main signaling link is disconnected. Delaying channel deactivation allows for aperiod of time for link reconnection. If this parameter is set to a small value, a channelmay be deactivated before the link has had a chance to reconnect, resulting a call drop.

– TCH Traffic Busy ThresholdIf the current channel usage reaches or exceeds the threshold specified by this parameter,TCHHs are preferentially allocated to MSs that have newly accessed the network.Otherwise, TCHFs are preferentially allocated to MSs that have newly accessed thenetwork. TCHHs do not have good anti-interference capabilities. Therefore, the calldrop rate may increase if a large number of TCHHs are occupied. Do not set thisparameter to a small value during light congestion.

– Call Reestablishment ForbiddenBlind spots caused by tall buildings or abrupt interference may lead to radio link failuresand call drops. This parameter specifies whether an MS can initiate a call re-establishment procedure to re-establish a dropped call in such a scenario. To reduce thecall drop rate, set this parameter to No to allow call re-establishment. In some scenarios,allowing call re-establishment greatly reduces the call drop rate. However, call re-establishment generally takes a long time, and therefore some subscribers may hang upbefore the call is re-established successfully.

– Handover-related ParametersIf handover-related parameters are not set correctly, handovers may not be performedin time, leading to call drops. To reduce the call drop rate, modify the handover-relatedparameters so that handovers can be performed in time. For details, seeTroubleshooting Handovers.

– Power Control ParametersIf the power control level and quality thresholds are set to small values, call drops arelikely to occur because of low signal level and poor signal quality.



87

– T200 and N200If T200 FACCH/F, T200 FACCH/H, N200 of FACCH/Full Rate, or N200 ofFACCH/Half Rate is set to a small value, the BSC may release data links before a callis terminated, resulting a call drop. If the value of M3100A:Call Drops due to ERR INDReceived on TCHF (Traffic Channel) in Stable State (T200 Expired) is large, set T200and N200 to large values.

– Neighboring RelationshipIf only some neighboring cells are configured in the BA2 list, no neighboring cells maybe suitable for handovers and signal levels may deteriorate, resulting in call drops.Therefore, add suitable neighboring cells to the BA2 list based on the drive test dataand electronic map to prevent call drops due to unavailability of neighboring cells.

– MAIOIn a cell configured with frequency hopping (FH), if MAIO is set to an incorrect value,for example, if MAIOs for different TRXs in a cell are set to the same value, frequencycollision can occur during FH, resulting call drops.

– Disconnect Handover Protect TimerThis is a BSC soft parameter. After receiving a Disconnect message from an MS, theBSC cannot hand over the MS within the period specified by this parameter. When thisparameter is not configured, after being handed over to a target cell, an MS cannot hangup because it does not receive a release acknowledgment message, leading to call drops.Configuring this parameter enables the MS to hang up in this scenario. Do not set thisparameter to a small value.

– Directly Magnifier BTS FlagIf repeaters are installed under a BTS, handovers between repeaters can only beasynchronous because the repeaters are far apart. If synchronous handovers areperformed, the handovers may fail, resulting in call drops. Therefore, when repeatersare installed under a BTS, set Directly Magnifier BTS Flag to Yes to preventsynchronous handovers between cells under the same BTS.

Location ProcedureFigure 5-7 shows the procedure for locating call drops due to incorrect parameter settings.



88

Figure 5-7 Procedure for locating call drops due to incorrect parameter settings

Troubleshooting Procedure1. View the traffic statistics and operation logs to check whether the call drop rate significantly

increases when an MSC cutover is performed or when the related parameters are modifiedon the MSC or the BSC.l If yes, go to Step 2.l If no, Contact Huawei Customer Service Center.

2. Check whether an MSC cutover is performed.l If yes, ensure that the parameters are set to the same values. Then, go to Step 3.l If no, go to Step 4.


4. Check whether related parameter settings were modified on the MSC.l If yes, view the parameter description to check whether parameter setting modification

may cause call drops. If the parameter setting modification causes any call drops, undothe parameter setting modification. Then, go to Step 5.

l If no, go to Step 6.5. Check whether the call drop problem is resolved.



89


6. Check whether any of the relevant parameter settings are modified on the BSC.l If yes, view the parameter description to check whether parameter setting modification

may cause call drops. If the parameter setting modification causes any call drops, undothe parameter setting modification. Then, go to Step 7.

l If no, Contact Huawei Customer Service Center.7. Check whether the call drop problem is resolved.

l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom

After an MSC cutover is performed, the call drop rate increases from 0.4% to 0.7%.

Cause Analysis

Some timers are set to different values before and after the MSC cutover.


1. Analyze the signaling, traffic statistics, and parameter settings. The values of the timersT310, T313, Short Message ACK Timer, and Terminate Short Message Timer afterthe MSC cutover are larger than those before the MSC cutover. Therefore, there is a highprobability that the BSS will release the links. After timers such as Radio Link Timeoutand T3103 on the BSC side expire, the BSC sends a Clear Request message to the MSC.As a result, the call is dropped and a call drop is measured. Table 5-3 lists the parametervalues before and after the MSC cutover.

Table 5-3 Parameter values before and after the MSC cutover

Timer Value Before the MSCCutover (s)

Value After the MSCCutover (s)

T310 20 30

T313 10 30

Short Message ACK Timer 15 20

Terminate Short MessageTimer

30 42

2. Set the preceding timers to the values before the MSC cutover.



90

6 Access Faults

About This Chapter

This chapter describes how to locate and troubleshoot access faults.

6.1 Access PrinciplesAccess performance reflects how much difficulty MSs have in accessing the network. Pooraccess performance may degrade subscriber satisfaction.

6.2 Locating Access FaultsThis section describes how to locate access faults.

6.3 Troubleshooting Access Faults Due to Poor Um Interface QualityThis section describes how to troubleshoot access faults due to poor Um interface quality.

6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH CongestionThis section describes how to troubleshoot low immediate assignment success rates due tostandalone dedicated control channel (SDCCH) congestion.

6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware orTransmission FaultsThis section describes how to troubleshoot low immediate assignment success rates due tohardware or transmission faults.

6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates ofProblem MSsThis section describes how to troubleshoot low immediate assignment success rates due tolocation updates of problem MSs.

6.7 Troubleshooting Low Assignment Success Rates Due to TCH CongestionThis section describes how to troubleshoot low assignment success rates due to traffic channel(TCH) congestion.

6.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission FaultsThis section describes how to troubleshoot low assignment success rates due to hardware ortransmission faults.

6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration

GBSS9.0Troubleshooting Guide 6 Access Faults


91

This section describes how to troubleshoot low assignment success rates due to inappropriateBSC configuration.



92

6.1 Access PrinciplesAccess performance reflects how much difficulty MSs have in accessing the network. Pooraccess performance may degrade subscriber satisfaction.

Access Faultsl In GSM networks, access faults occur during immediate assignment and assignment.

Access performance is a key counter in reflecting customer experience in the GSM network.If the access performance is poor, MSs have difficulty in accessing the network, whichcould negatively affect subscriber satisfaction. The network access performance improveswith the immediate assignment success rate or assignment success rate.

l RA303G:Success Rate of Immediate Assignments specifies the percentage of MSssuccessfully accessing signaling channels. Immediate assignment starts when an MS sendsa channel request message and ends when the MS successfully sets up a channel.

l RCA313:Assignment Success Rate specifies the percentage of MSs successfully initiatingcalls on assigned TCHs. Assignment starts when the time a BSC receives an assignmentrequest message and ends when the BSC receives an assignment completion message.

Access Procedure and Measurement PointsFigure 6-1 shows the access procedure and measurement points.



93

Figure 6-1 Access procedure and measurement points

Table 6-1 Measurement point

Measurement Point Description

A1 K3100:Immediate Assignment Requests

A2 K3101:Immediate Assignment Commands

A3 CA303J:Call Setup Indications (CircuitService)

A4 CA310:Assignment Requests

A5 CA313:Successful Assignments

6.2 Locating Access FaultsThis section describes how to locate access faults.



94

6.2.1 Procedure for Locating Access FaultsBefore locating access faults, determine whether they occur during immediate assignment orassignment.

Possible Causesl The following are the methods for analyzing possible causes of low immediate assignment

rates.– Determine the possible causes of low immediate assignment rates based on the signaling

procedure, as described in Table 6-2.

Table 6-2 Possible causes of low immediate assignment rates

Phase Symptom Possible Cause

SDCCH assignment After receiving randomaccess requests from MSs,the BSC sends animmediate assignmentrejection message becauseno standalone dedicatedcontrol channel (SDCCH)is available.

SDCCH congestion andequipment faults

Channel activation The BSC sends theChannel Act message tothe BTS, and the BTSresponds with the ChannelAct Nack message.

Equipment faults

The BSC sends theChannel Act message tothe BTS, but the BTS doesnot respond.

Equipment andtransmission faults

Immediate assignmentdelivery

After channels areactivated successfully, theBSC sends immediateassignment messages, butthe MSs do not access theassigned channels. As aresult, the BSC does notreceive any EST INDmessages.

Um interface faults andMS faults

– Use a defined formula to calculate immediate assignment success rates, and determine

the possible causes of low immediate assignment success rates according to thecalculation results. Table 6-3 lists the mapping relationship between user-definedformulas and possible causes.



95

Table 6-3 User-defined formulas for calculating immediate assignment success rates

Formula Possible Cause

UmInterfaceFault

ChannelActivationFailure(Equipment andTransmission Faults)

SDCCHCongestion

MS Fault

Immediateassignmentsuccess rate =[CA303J:CallSetup Indications(Circuit Service)/K3100:ImmediateAssignmentRequests] x 100%

√ √ √ √

Immediateassignmentsuccess rate ={CA303J:CallSetup Indications(Circuit Service)/[K3100:Immediate Assignment -(K3101:Immediate AssignmentCommands -CA303J:CallSetup Indications(CircuitService))]} x100%

- √ √ -

Immediateassignmentsuccess rate =[CA303J:CallSetup Indications(Circuit Service)/K3101:ImmediateAssignmentCommands] x100%

√ - - √

l Possible causes of low assignment success rates

Table 6-4 lists the possible causes of low assignment success rates.



96

Table 6-4 Possible causes of low assignment success rates

Counter Possible Cause

CA312:Failed Assignments (ChannelUnavailable)

TCH congestion

A3169A:Failed Assignments (Um Cause) Um interface faults

A3129B:Failed Assignments (FirstAssignment, Terrestrial Resource RequestFailed)

Hardware faults, transmission faults, andincorrect BSC configuration

A3129E:Failed Assignments (CICUnavailable)

BSC faults and MSC faults

A3129E:Failed Assignments (CICUnavailable)

BSC faults and MSC faults

A3129H:Failed Assignments (ClearCommands Sent By MSC)

Normal release and misoperations of peerend users

Location ProcedureCheck whether immediate assignment success rates or assignment success rates are lowaccording to counters related to assignment and immediate assignment.l If immediate assignment success rates are low, locate the problem by referring to Figure

6-2.l If assignment success rates are low, locate the problem by referring to Figure 6-3.



97

Figure 6-2 Procedure for locating low immediate assignment success rates



98

Figure 6-3 Procedure for locating low assignment success rates

6.2.2 Common Causes for Access FaultsThis section describes common causes for low immediate assignment success rates and lowassignment success rates.

Common Causes for Low Immediate Assignment Success RatesFigure 6-4 shows common causes for low immediate assignment success rates.



99

Figure 6-4 Common causes for low immediate assignment success rates

l Um interface faults



100

– The BTS may mistakenly process interference on the Um interface as pseudo-randomaccess signals. This may lead to immediate assignment failures and standalonededicated control channel (SDCCH) congestion.

– In a cell configured with multiple TRXs, the combination loss of broadcast controlchannel (BCCH) TRXs is different from that of non-BCCH TRXs. Therefore, theircoverage areas are also different. If an SDCCH is configured on a non-BCCH TRX, acall far away from the serving cell may fail to access the SDCCH when the call isassigned to the non-BCCH TRX. This leads to a call drop on the SDCCH.

– For details about how to troubleshoot this problem, see 6.3 Troubleshooting AccessFaults Due to Poor Um Interface Quality.

l SDCCH congestion– A sharp increase in the traffic volume or incorrect data configuration may lead to

SDCCH congestion, decreasing immediate assignment success rates.– For details about how to troubleshoot this problem, see 6.4 Troubleshooting Low

Immediate Assignment Success Rates Due to SDCCH Congestion.l TRX and transmission faults

– Hardware faults can generally lead to the return of CHAN ACTIV NACK messages.In a cell configured with multiple TRXs, SDCCH congestion occurs if a faulty TRX isout of service.

– Transmission faults generally lead to channel activation timeout or SDCCH congestion.– For details about how to troubleshoot this problem, see 6.5 Troubleshooting Low

Immediate Assignment Success Rates Due to Hardware or Transmission Faults.l MS faults

– Immediate assignment success rates are low in some cells because certain problem MSsperform location updates or initiate calls in these cells. After sending channel requestsfor location updates, the problem MSs fail to set up links on SDCCHs, leading to lowimmediate assignment success rates on SDCCHs.

– Low immediate assignment success rates because of location updates of problem MSsare caused by MS faults and cannot be resolved on the BSS side. No layer 3 informationis available due to location update failures and therefore the faulty MS cannot bedetermined.

– For details about how to locate this problem, see 6.6 Troubleshooting Low ImmediateAssignment Success Rates Due to Location Updates of Problem MSs.

Common Causes of Low Assignment Success RatesFigure 6-5 shows common causes for low assignment success rates.



101

Figure 6-5 Common causes of low assignment success rates

l Um interface faults

– If there is inter-network interference and repeater interference or severe intra-networkinterference occurs because of insufficient frequencies and tight frequency reuse, MSsmay fail to parse information about the assigned traffic channel (TCH) properly. As aresult, they fail to occupy the TCH, leading to low assignment success rates.



102

– If the signal level is low due to poor coverage, MSs may fail to parse the assigned TCHproperly. As a result, they fail to occupy the TCH, leading to low assignment successrates.

– For details about how to troubleshoot this problem, see 6.3 Troubleshooting AccessFaults Due to Poor Um Interface Quality.

l TCH congestion– When TCHs are congested and become unavailable, new access requests are rejected,

leading to low assignment success rates.– For details about how to troubleshoot this problem, see 6.7 Troubleshooting Low

Assignment Success Rates Due to TCH Congestion.l TRX and transmission faults

– When a TRX or a combiner is faulty, some TCHs become unavailable, leading to lowassignment success rates.

– Poor link transmission quality over the Abis interface and unstable transmission linksmay also lead to TCH assignment failures.

– For details about how to troubleshoot this problem, see 6.8 Troubleshooting LowAssignment Success Rates Due to Hardware or Transmission Faults.

l Incorrect BSC configuration– If the BSC is configured incorrectly and the traffic volume is large, certain resources

may be unavailable during assignment, leading to assignment failures.– For details about how to troubleshoot this problem, see 6.9 Troubleshooting Low

Assignment Success Rates Due to Inappropriate BSC Configuration.l Inconsistent circuit identification code (CIC) status over the A interface

If the circuit management mechanism on the A interface between the MSC and the BSC isfaulty, TCH assignment may be initiated when CICs on the A interface are not idle, leadingto assignment failures. This problem is quite complicated. Therefore, MSC engineers andBSC engineers need to team up to troubleshoot such problems.

l MSC faultsIf the MSC delivers the Clear CMD message during assignment, the assignment fails. Totroubleshoot this problem, contact MSC engineers.

6.3 Troubleshooting Access Faults Due to Poor Um InterfaceQuality

This section describes how to troubleshoot access faults due to poor Um interface quality.

Symptoml The result of signaling tracing over the Abis interface shows that MSs cannot access

channels after the BSC delivers the immediate assignment command during immediateassignment. As a result, the BSC does not receive link establishment indications from BTSsand releases local channels. In addition, the immediate assignment success rate calculatedwith the following formula decreases: Immediate assignment success rate = (CA303J:CallSetup Indications (Circuit Service)/K3101:Immediate Assignment Commands) x 100%.

l The result of signaling tracing over the Abis interface shows that the timer specified forassignment completion responses expires or MSs fail to access new channels after the BSCdelivers the assignment command during assignment. As a result, MSs return to their



103

original channels and send assignment failure messages. In addition, the value ofA3169A:Failed Assignments (Um Cause) increases noticeably.

Background Informationl The access faults over the Um interface can be located from the aspects of interference,

uplink and downlink signal level balance, coverage, antenna system, and BTS hardware.For details about how to locate interference problems, see Interference Problems.

l The following is the method for troubleshooting interference problems.

1. Check Receive Quality Measurement Distribution per TRX(MR.RecvQualOrig.TRX). If the receive quality is poor, for example, if the percentageof uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is ahigh probability that access faults occur.

2. Analyze Interference Band Measurement per TRX(MR.Iterf.TRX). If the percentageof interference levels in the high interference bands is great, for example, thepercentage of interference levels in interference bands 4 or 5 exceeds 10%, accessfaults are caused by uplink interference.

3. Analyze the signaling collected by the TEMS during drive tests (DT) to determinewhether the downlink C/I is normal when MSs access channels. If the signal level isproper but the C/I is poor, access faults are caused by interference.

Location ProcedureFigure 6-6 shows the procedure for locating access faults due to poor Um interface quality.



104

Figure 6-6 Procedure for locating access faults due to poor Um interface quality

Troubleshooting Procedure1. Check for interference. For details, see Background Information.

l If access faults are caused by interference, check for interference sources onsite orperform DTs to locate the interference sources. In addition, check whether repeatershave been installed and, if so, whether they are faulty by using the following procedure.If any interference source is found, eliminate it by referring to InterferenceProblems. Then, go to Step 2.

(1) Run the MML command LST GCELLSOFT to check whether DirectlyMagnifier BTS Flag is set to Yes. If Directly Magnifier BTS Flag is set toYes, the cell is configured with repeaters. If Directly Magnifier BTS Flag is setto No, check whether other operators' repeaters are installed near the cell or whetherany repeaters are installed without permission.

(2) If repeaters are installed, check whether they are wideband repeaters. If they arewideband repeaters, check whether the uplink or downlink gain is large. If theuplink or downlink gain is large, reduce it as required. Shut down the repeaters ifthey have great impacts on the access success rate.



105

(3) Check whether the repeaters are faulty or whether the uplink or downlink gain isbeyond the normal range. If either is case, the actual BTS coverage may change,leading to access faults. If any repeater problems occur in the cell, the number ofMRs with a large timing advance (TA) value measured for Number of MRs basedon TA per TRX(MR.TaDistribOrig.TRX) changes significantly.

l If access faults are not caused by interference, go to Step 3.2. Check whether the access faults are rectified.


3. Check whether the uplink and downlink signal levels are balanced.Check Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX). Ifthe percentage of the uplink and downlink signal level balance class 1 or 11 to all uplinkand downlink signal level balance classes exceeds 30%, the uplink and downlink signallevels are unbalanced.l If yes, go to Step 5.l If no, check whether the transmission equipment and TRX cable connections onsite are

proper, and whether there are any potential risks on the antenna system using thefollowing procedure. After the preceding items are checked and the faults are rectified,go to Step 4.– If dual-transmit antennas are configured, ensure that the tilt and azimuth of the

antennas are the same.– Analyze DT data to check whether the jumpers are incorrectly connected. If they

are incorrectly connected, the uplink signal level in the cell is significantly lowerthan the downlink signal level and access faults are likely to occur in a cell far awayfrom the BTS. In this case, reconnect the jumpers.

– If the feeders are damaged, wet, or distorted, or if the connectors are not tight, boththe transmit power and receive sensitivity are reduced and access faults occur as aresult. Locate these problems by referring to ALM-4144 TRX VSWR alarm,ALM-2156 TRX VSWR Alarm, or ALM-26529 RF Unit VSWR Threshold Crossed.Immediately replace any faulty feeders.

4. Check whether the access faults are rectified.l If yes, no further action is required.l If no, go to Step 5.

5. Check whether there are any coverage problems.

(1) Check TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX) and analyze the mapping between the receivequality and receive signal levels. If receive quality is generally poor at low receivesignal levels, access faults in the cell may be caused by poor receive quality, resultingfrom coverage problems.

(2) Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If manyMRs have large TA values, access faults are caused by wide coverage or coverageoverlap. Otherwise, access faults are caused by weak coverage. If the percentage ofTA values at levels 0 to 5 is less than 90%, check for coverage problems in the cellbased on the coverage scenario and DT result.l If yes, contact network optimization engineers to resolve the problem, and then go

to Step 6.



106

l If no, go to Step 7.6. Check whether the access faults are rectified.


7. Check the Um interface quality.Check TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) orTCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If thepercentage of receive quality bands 6 and 7 exceeds 10%, the uplink or downlink receivequality is poor.l If the Um interface quality is poor, contact the network optimization department to check

and optimize the frequency planning data. Then, go to Step 8.l If the Um interface quality is good, go to Step 9.

8. Check whether the access faults are rectified.l If yes, no further action is required.l If no, go to Step 9.

9. Perform DTs to check whether high receive signal levels with poor receive quality or lowreceive signal levels with poor receive quality occurs.l If yes, contact network optimization engineers to analyze and resolve the problem. Then,

go to Step 10.l If no, return to Figure 5-3.

10. Check whether the access faults are rectified.l If yes, no further action is required.l If no, return to Procedure for locating access faults.

Typical CaseSymptom

After a BSC is swapped at a first office application (FOA) site, the immediate assignment successrates in multiple cells are less than 93% during peak hours due to co-channel and adjacent-channel interference.

Cause Analysis

The cells work on the same frequency and use the same base transceiver station identity code(BSIC), leading to interference.


1. Analyze the signaling traced at the problem site. The signaling shows that most accessattempts fail because the BTS delivers the immediate assignment commands upon receivingchannel requests from MSs, but the MSs do not return any messages. An analysis of thechannel requests shows that the access uplink signal level is about -80 dB and the TA valuesare 0 and 1, which are normal. For details about how to parse the TA value and uplinkaccess signal level from channel request messages, see Figure 6-7.



107

Figure 6-7 Channel request message

2. The results of multiple DTs show that the downlink quality at the junction of problem cell

A and cell B is poor. The result of frequency scanning at the junction shows that the twoBSICs for the broadcast control channel (BCCH) frequencies at the junction are differentbut the signal levels of the BCCH frequencies are similar. This indicates that co-channelinterference occurs. One BCCH frequency belongs to cell A and the other BCCH frequencybelongs to cell B.

3. After the BCCH frequency of cell A is modified, the traffic statistics shows that theimmediate assignment success rate in cell A increases noticeably.

6.4 Troubleshooting Low Immediate Assignment SuccessRates Due to SDCCH Congestion

This section describes how to troubleshoot low immediate assignment success rates due tostandalone dedicated control channel (SDCCH) congestion.

Symptom

The values of CA300J:Channel Requests (Circuit Service) and RR370:Congestion Rate onSDCCH per CELL (due to Busy) or the values of K3004:Traffic Volume on SDCCH,



108

K3000:SDCCH Seizure Requests, and K3001:Failed SDCCH Seizures due to Busy SDCCHincrease noticeably, but the immediate assignment success rate decreases.

Background Informationl SDCCH congestion is probably caused by one of the following causes:

– The traffic volume on an SDCCH increases sharply. As a result, new services cannotbe assigned to the SDCCH, leading to an immediate assignment failure.

– The configuration data is inappropriate, such as the location area (LA) planning, dual-band network parameters, and timer settings.

– The number of functional SDCCHs decreases because some TRXs carrying SDCCHsare faulty, but the traffic volume remains unchanged.

l The methods for troubleshooting SDCCH congestion are as follows:

– For SDCCH congestion caused by heavy traffic on the SDCCH, expand the capacity.Alternatively, modify parameters related to location updates and SDCCH dynamicadjustment.

– SDCCH congestion caused by traffic bursts such as group sending of short messagesand location update at the portal of a tunnel cannot be completely resolved. Relieve theSDCCH congestion by Configuring SDCCH Dynamic Adjustment.

– For SDCCH congestion caused by a decrease in the number of functional SDCCHs dueto hardware faults, rectify the hardware faults. For details, see 6.5 TroubleshootingLow Immediate Assignment Success Rates Due to Hardware or TransmissionFaults.

l The related parameters are as follows:

– CELL_RESELECT_OFFSET (CRO)

This parameter specifies the likelihood with which MSs select a cell. If thecommunication quality in a cell is poor due to heavy traffic or for other causes, ensurethat MSs do not work in this cell. In this case, if you set PENALTY_TIME (PT) to31, TEMPORARY_OFFSET (TO) becomes invalid. C2 equals C1 minus CRO. Userscan set CRO as required. The larger the CRO, the less likely MSs are to select the cell.You can also decrease the value of C2 manually to reduce the likelihood that MSs willselect the cell.

– CELL_RESELECT_HYSTERESIS

This parameter specifies whether to perform inter-LA reselection. It prevents anincrease in the network signaling volume due to frequent location updates and reducesthe possibility of losing paging messages. This parameter is generally set to 6. For dual-band networks in urban areas belonging to different LAs, the value of this parameterranges from 8 to 10.

– When the traffic volume in an area is heavy and the signaling flow is overloadedfrequently, increase the CRH of neighboring cells that belong to different LACs inthis area.

– When the overlapping coverage of neighboring cells that belong to different LAs islarge, increase the CRH.

– When the border coverage of the neighboring cells that belong to different LAs ispoor or the borders are located on high-speed highways or other high-speed areas,set the CRH to a value ranging from 2 to 6 dB.

– Parameters related to SDCCH dynamic adjustment



109

– SDCCH Dynamic Allocation Allowed

When this parameter is set to YES(Yes), dynamic conversion between SDCCHs andtraffic channels (TCH) can be implemented.

– Idle SDCCH Threshold N1

When the number of idle SDCCHs in a cell is less than or equal to the value of thisparameter, the BSC uses the channel allocation algorithm to attempt to find a TCHFthat can be converted to an SDCCH. This parameter is one of the conditions fordynamically converting a TCHF to an SDCCH.

– Cell SDCCH Channel Maximum

Before initiating dynamic conversion from the TCH to the SDCCH, the BSC checkswhether the number of SDCCHs in a cell after the conversion will exceed CellSDCCH Channel Maximum. If the number will exceed Cell SDCCH ChannelMaximum, the BSC does not initiate the conversion.

– TCH Minimum Recovery Time

This parameter specifies the minimum duration for converting an SDCCH back toa TCH.

– Related timers

– T3101

Timer T3101 monitors the immediate assignment procedure. Setting timer T3101to a small value can effectively reduce the SDCCH congestion rate. If timer T3101is set to a large value, the invalid duration for occupying signaling resources isprolonged, resulting in waste of signaling resources. To optimize signaling resourceusage, set timer T3101 to a small value, especially when the queuing function isenabled.

– T3122

An MS starts timer T3122 when receiving the IMMEDIATE ASSIGN REJECTmessage and sends a new channel request message after timer T3122 expires.Increasing the value of timer T3122 can prevent the MS from sending channelrequest messages frequently when no system resource is available, preventingincreases in the load on random access channels (RACH) and common controlchannels (CCCH).

– T3212

Timer T3212 monitors the location update period. Appropriately increasing thevalue of timer T3212 can minimize the SDCCH load, which becomes heavy due toperiodic location updates.

– T3111

Timer T3111 specifies the connection release delay. This timer is used to delaychannel deactivation after the main signaling link is disconnected. This is to reservesome time for another disconnection, if necessary. Timer T311 starts when a TCHis released and when an SDCCH is released. The value of timer T3111 must be thesame as that of timer T3110 on the MS side and is generally two seconds. If timerT3111 is set to a large value, severe SDCCH congestion may occur.

– CS RACH Min. Access Level

If this parameter is set to a small value, a large number of interference signals requestSDCCHs to access the network, leading to the SDCCH congestion. If the parameter isset to a large value, call failures may occur even when signals are available. Therefore,



110

set this parameter according to the actual BTS sensitivity, the lowest MS access signallevel, and the interference.

– Late AssignmentThis function is set on the MSC side. If late assignment is enabled, the calling MS alwaysoccupies the SDCCH when waiting for the called MS to pick up the phone. In this case,the duration of SDCCH occupation increases. As a result, other MSs may fail to requestthe SDCCH, leading to SDCCH congestion.

– Minimum Access RXLEVIf this parameter is set to a small value, the requirement for the access signal level islow. As a result, a large number of MSs attempt to camp on this cell, increasing the cellload and call drop rate and leading to SDCCH congestion.

– TX-integerWhen the network traffic volume is heavy, the immediate assignment success rate islow if the sum of S and T is low. You can adjust the value of T within reason to increasethe sum of S and T. For details about S and T, see the description about TX-integercontained in the MML command SET GCELLIDLEBASIC.

– CELL BAR ACCESS (CBA)This parameter specifies whether accessing a cell is allowed. 0 indicates that accessinga cell is allowed, and 1 indicates that accessing a cell is prohibited. This parameter canbe used with cell bar qualify (CBQ) to determine the cell priority.

Table 6-5 Mapping relationship between CBA, CBQ, cell selection, and cell reselection

CBQ CBA Cell SelectionPriority

Cell ReselectionPriority

0 0 Normal Normal

0 1 Prohibited Prohibited

1 0 Low Normal

1 1 Low Normal

– Cell Bar Qualify (CBQ)

CBQ affects only cell selection.

Location ProcedureFigure 6-8 shows the procedure for locating low immediate assignment success rates due toSDCCH congestion.



111

Figure 6-8 Troubleshooting low immediate assignment success rates due to SDCCH congestion

Troubleshooting Procedure1. Check whether no SDCCH is available due to an increase in the traffic volume.

l If yes, modify the relevant parameters according to the parameter description inBackground Information. If the problem persists, expand the capacity to resolve theproblem. If the problem is resolved after capacity expansion, no further action isrequired. If the problem persists, go to Step 2.

l If no, go to Step 2.2. Check whether the value of RR300:SDCCH Availability is too small.

l If yes, rectify hardware and transmission faults according to 6.5 Troubleshooting LowImmediate Assignment Success Rates Due to Hardware or Transmission Faults.If the problem is resolved after the hardware and transmission faults are rectified, nofurther action is required. If the problem persists, return to Procedure for locatingaccess faults.

l If no, return to Procedure for locating access faults.

Typical CaseSymptom

The immediate assignment success rate of a BSC is low. According to the traffic statistics, certainBTSs are experiencing SDCCH congestion.

Cause Analysis

SDCCH become congested easily when the traffic volume increases sharply. In addition, lowSDCCH availability due to hardware faults may also lead to SDCCH congestion.



112


1. Check RR300:SDCCH Availability. The SDCCH availability is 100%. Therefore, SDCCHcongestion is not caused by hardware faults.

2. Check K3000:SDCCH Seizure Requests and K3001:Failed SDCCH Seizures due to BusySDCCH. The number of SDCCH seizures is about 300 to 400 during peak hours for cellsserved by a BTS in S1/1/1 mode. Each cell is configured with eight SDCCHs, which canprocess 300 to 400 SDCCH seizures during peak hours. However, SDCCH congestionoccurs dozens of times in each cell during peak hours.

3. Check Counters Related to Call Setup Indication. Most SDCCH seizures are caused bylocation updates. Most BTSs experiencing SDCCH congestion are located at the junctionof two LAs along railways. According to the train schedule, four to five trains pass throughthe junction at about the time the SDCCHs become congested. When multiple trains passthrough the junction, a large number of location updates occur abruptly during a very shortperiod, leading to SDCCH congestion.

4. Run the MML command SET GCELLBASICPARA with SDCCH Dynamic AllocationAllowed for cells served by the BTSs at the junction of two LAs along railways set to YES(Yes), and reserve redundant SDCCHs. The problem is resolved.

6.5 Troubleshooting Low Immediate Assignment SuccessRates Due to Hardware or Transmission Faults

This section describes how to troubleshoot low immediate assignment success rates due tohardware or transmission faults.

SymptomThe symptoms of low immediate assignment success rates due to hardware or transmission faultsare as follows:l According to the signaling tracing over the Abis interface, after successful channel

assignment, the BSC sends a Channel Activation message to the BTS. However, the BTSresponds with a Channel Activation Nack message or does not respond.

l After successful channel activation, the BSC delivers an immediate assignment messagebut does not receive an Establish Indication message. The BSC finally releases the call.

l According to the signaling tracing over the Abis interface, after receiving a channel request,the BSC sends the MS an immediate assignment rejection message due to unavailablestandalone dedicated control channels (SDCCHs). The SDCCHs are unavailable becausethe TRX carrying the requested SDCCHs is faulty and reports a large number of Overloadmessages.

l For details about the hardware or transmission fault alarms, see BackgroundInformation.



113

NOTE

l If the BTS returns a Channel Activation Nack message, check the following performance countersbased on the channel types: R3300B:CHAN ACTIV NACK Messages Sent by BTS in ImmediateAssignment Procedure (SDCCH), R3307B:CHAN ACTIV NACK Messages Sent by BTS inImmediate Assignment Procedure (TCHF), and R3308B:CHAN ACTIV NACK Messages Sent byBTS in Immediate Assignment Procedure (TCHH).

l If the BTS does not respond to the channel activation initiated by the BSC, check the followingperformance counters based on the channel types: R3300C:Channel Activation Timeouts in ImmediateAssignment Procedure (SDCCH), R3307C:Channel Activation Timeouts in Immediate AssignmentProcedure (TCHF), and R3308C:Channel Activation Timeouts in Immediate Assignment Procedure(TCHH).

Background Informationl If the BTS or BSC hardware is faulty, immediate assignment may fail. You can find BTS

or BSC hardware faults by checking the following performance counters and alarms.

– The following are the performance counters related to BTS or BSC hardware faults:

– RK3255:TRX Usability

– RR300:SDCCH Availability

– CR330C:Channel Activation Timeouts in Immediate Assignment Procedure

– CR330B:CHAN ACTIV NACK Messages Sent by BTS in Immediate AssignmentProcedure

– The following are the alarms related to BTS or BSC hardware faults that can result inaccess faults:

– ALM-21807 OML Fault

– ALM-2204 TRX Communication Alarm

– ALM-2156 TRX VSWR Alarm

– ALM-4144 TRX VSWR alarm

– ALM-26529 RF Unit VSWR Threshold Crossed

– ALM-3606 DRU Hardware alarm

– ALM-20241 Board Unavailable

– ALM-20243 Board Hardware Faultl If transmission faults occur (for example, delay and frame loss), immediate assignment

fails because channel activation times out or the immediate assignment command fails tobe delivered to the MS. You can find transmission faults by checking the following alarmsrelated to transmission faults that can result in access faults:

– OML fault alarmsALM-21807 OML Fault

– BTS LAPD link alarmsALM-4102 TRX LAPD Link Interrupt AlarmALM-2114 TRX LAPD Link Interrupt AlarmALM-3052 LAPD alarmALM-3572 LAPD alarm

– BSC LAPD link alarmsALM-21511 LAPD Link Congestion



114

ALM-21512 LAPD Link Fault– Alarms related to the Multiplex Section Protection (MSP) of optical ports

ALM-21311 MSP Multiplex Section K1/K2 MismatchALM-21312 MSP Multiplex Section K2 MismatchALM-21313 MSP Port Protection Mode Mismatch


Location ProcedureFigure 6-9 shows the procedure for locating low immediate assignment success rates due tohardware or transmission faults.

Figure 6-9 Procedure for locating low immediate assignment success rates due to hardware ortransmission faults

Troubleshooting Procedure1. Check whether any of the hardware fault alarms listed in Background Information are

reported.



115

l If yes, clear these alarms by referring to the alarm help and go to Step 2.l If no, go to Step 3.

2. Check whether the immediate assignment success rate returns to normal.l If yes, no further action is required.l If no, go to Step 3.

3. According to the signaling tracing over the Abis interface, locate the TRX that reports theOverload messages and replace the TRX. Then, check whether the immediate assignmentsuccess rate returns to normal.l If yes, no further action is required.l If no, go to Step 4.

4. Request transmission device engineers to clear transmission fault alarms. Then, check theperformance counters listed in Background Information to determine whether channelactivation fails or the timer for waiting for the Establish Indication message expires. If theimmediate assignment success rate returns to normal, no further action is required.Otherwise, return to Procedure for locating access faults.

Typical Case

Symptom

After a BTS is deployed, almost all SDCCHs are busy, but some traffic channels (TCHs) areidle. According to the traffic statistics during peak hours, the value of K3001:Failed SDCCHSeizures due to Busy SDCCH is about one thousand. In addition, a large number of LAPD linkfault alarms and clear alarms are reported at an interval of about ten minutes.

Cause Analysis

Almost all SDCCHs are busy, but some TCHs are idle. Although the possibility of incorrect dataconfigurations cannot be ruled out as the cause, the problem is more likely to have resulted fromtransmission faults, because a large number of LAPD link fault alarms and clear alarms havebeen frequently reported.


1. Check the data configurations. The data configurations are correct. Then, exchange thetransmission port on the problem BTS with that on another BTS of the same type. The latterBTS operates properly, but the problem persists. Therefore, the problem is not caused byincorrect data configurations or BSC hardware faults.

2. Replace the TMU and TRXs. The problem persists.3. Request transmission device engineers to test the transmission quality. Error codes are

detected during the transmission. Then, perform transmission testing segment by segment.A board in the intermediate transmission device is faulty. After the faulty board is replaced,the problem is resolved.

6.6 Troubleshooting Low Immediate Assignment SuccessRates Due to Location Updates of Problem MSs

This section describes how to troubleshoot low immediate assignment success rates due tolocation updates of problem MSs.



116

SymptomThe immediate assignment success rates are low in some cells because of location updates ofproblem MSs in these cells. After the problem MSs send channel requests to the BSC becauseof location updates, the BSC assigns standalone dedicated control channels (SDCCHs) to theproblem MSs and sends immediate assignment messages to the problem MSs. The problemMSs, however, do not access these SDCCHs. As a result, a timeout occurs when the BSC waitsfor the ESTABLISH INDICATION messages, leading to low SDCCH immediate assignmentsuccess rates.

Background InformationThe characteristics of low immediate assignment success rates due to location updates ofproblem MSs are as follows:l When the difference between A300F:Channel Requests (Location Updating) and

A3030F:Call Setup Indications (Location Updating) (SDCCH) is similar to A3040:CallSetup Indications Timed Out (SDCCH), the low immediate assignment success rates aredue to location updates of problem MSs. However, the service type contained in the channelrequests sent by some MSs may not be location updates. In this case, you need to determinethe cause of low immediate assignment success rates based on the other characteristics.

l The immediate assignment success rates may be low during peak hours or during off-peakhours.

l Calls are not affected. Aside from the immediate assignment success rates of some cellsduring certain periods, all key performance indicators (KPIs) are normal. In addition, drivetest results are normal, and no subscribers complain about call drops because the MSs retryperiodically or in other cells if location updates fail.

l There is no interference or co-frequency co-BSIC cell.l There is no problem such as uplink and downlink signal-level imbalance.l According to the signaling tracing over the Abis interface, the retry times and retry intervals

of failed location updates meet the network configuration requirements.

Low immediate assignment success rates due to location updates of problem MSs are caused byMS faults and therefore cannot be resolved on the BSS side.

Location ProcedureNone

Troubleshooting Procedure1. Based on the characteristics described in Background Information, determine whether

the low immediate assignment success rates are due to location updates of problem MSs.l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom

A customer complains that the SDCCH immediate assignment success rates in some cells arelow because of location updates.



117

Cause Analysis

Low SDCCH immediate assignment success rates in some cells may be caused by Um interfacefaults, hardware faults, transmission faults, and SDCCH congestion. According to the onsitesymptom, the SDCCH immediate assignment success rates are low only in certain cells and theimmediate assignment failures are due to location updates. Therefore, the problem is most likelyto have resulted from MS faults.


1. Deduce that the problem is caused by MS faults because the problem occurs only in certaincells.

2. Analyze traffic statistics to check whether the low immediate assignment success rates arecaused by location updates. The difference between A300F:Channel Requests (LocationUpdating) and A3030F:Call Setup Indications (Location Updating) (SDCCH) is similar toA3040:Call Setup Indications Timed Out (SDCCH), which indicates that the SDCCH setupfailures are due to location updates.

3. Trace the signaling over the Abis interface. Figure 6-10 shows the problem signaling.According to the time advance (TA) and signal level information in channel requests, theTA values are small and the signal level values are large. In addition, the uplink signalstrength measured by the BTS is lower than -110 dBm during the period in which the BSSwaits for MSs to access the assigned SDCCHs, which indicates that the MSs do not accessthe SDCCHs. As a result, the immediate assignment fails.

NOTEFor details about how to query TA values, see the typical case in 6.3 Troubleshooting Access FaultsDue to Poor Um Interface Quality.

Figure 6-10 Signaling tracing over the Abis interface

4. Analyze the signaling shown in Figure 6-11. According to channel requests, the location

updates are initiated by the same MS. The maximum number of location updates is 4, whichmatches the value of MS MAX Retrans.

NOTEMS MAX Retrans specifies the maximum number of Channel Request messages sent by an MSduring an immediate assignment process. You can query the value of this parameter by running theMML command LST GCELLCCBASIC and set the value of this parameter by running the MMLcommand SET GCELLCCBASIC.



118

Figure 6-11 Channel Request messages consecutively sent by an MS

6.7 Troubleshooting Low Assignment Success Rates Due toTCH Congestion

This section describes how to troubleshoot low assignment success rates due to traffic channel(TCH) congestion.

SymptomAccording to the result of signaling tracing over the A interface, the BSC sends the MSC anassignment failure message containing the cause value of No radio resource available. Inaddition, the values of the following counters increase significantly: ZTA3129J:FailedAssignments per BSC (Channel Unavailable), CA312:Failed Assignments (ChannelUnavailable), and K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel).

Background Informationl The following is the formula for calculating the TCH congestion rate:

(K3021:Failed TCH Seizures due to Busy TCH (Signaling Channel) + K3011A:Failed TCHSeizures due to Busy TCH (Traffic Channel) + K3011B:Failed TCH Seizures in TCH Handoversdue to Busy TCH (Traffic Channel))/(K3020:TCH Seizure Requests (Signaling Channel) +



119

K3010A:TCH Seizure Requests (Traffic Channel) + KK3010B:TCH Seizure Requests in TCHHandovers (Traffic Channel)) x 100%

l If the TCH congestion rate of a cell with a high assignment success rate is greater than 10%,assignment failures are mainly caused by TCH congestion. The following are the commoncauses of TCH congestion in a cell:– The traffic volume in a cell increases.– The cell does not support the half-rate speech versions 1 and 3 in an effort to ensure

speech quality.– Traffic volume in the cell is large because the subscriber density is high or coverage

overlap occurs in the cell.– The traffic volume in the cell sharply increases because emergencies occur or any

neighboring cells are out of service.– The cell is configured with a large number of static packet data channels (PDCHs) or

dynamic PDCHs and processes PS services preferentially.– Some TRXs of the cell are faulty or some channels of the cell are blocked.– Very early assignment is enabled.

l When TCHs are congested, new access requests are rejected because TCHs are unavailable,decreasing the assignment success rate.

Location ProcedureFigure 6-12 shows the procedure for locating low assignment success rates due to TCHcongestion.



120

Figure 6-12 Procedure for locating low assignment success rates due to TCH congestion

Troubleshooting Procedure1. Run the MML command LST GCELLCCACCESS to check whether a cell with a low

assignment rate supports the half-rate speech versions 1 and 3. Run the MML commandLST GTRXDEV to check whether TCH Rate Adjust Allow is set to YES(Yes).



121


l If no, perform the following operations to enable the half-rate speech versions 1 and 3when the speech quality meets the requirement:

(1) Run the MML command SET GCELLCCACCESS with Speech Version set toHALF_RATE_VER1(Half-rate VER 1) and HALF_RATE_VER3(Half-rateVER 3).

(2) Run the MML command SET GTRXDEV with TCH Rate Adjust Allow set toYES(Yes).

(3) Check whether the assignment success rate returns to normal.


– If no, go to Step 2.2. Check whether coverage overlap or unbalanced traffic distribution occurs in the cell where

TCHs are congested according to drive test logs and traffic statistics.

l If yes, reduce the cell coverage by performing operations such as decreasing the power,reducing the antenna tilt, and improving CS RACH Min. Access Level. Then, checkwhether the assignment success rate returns to normal. If yes, no further action isrequired. If no, go to Step 3.

l If no, go to Step 3.3. Check whether any neighboring cells are out of service according to alarm logs.

l If yes, resolve the problem of out-of-service cells. Then, check whether the assignmentsuccess rate returns to normal. If yes, no further action is required. If no, go to Step 4.

NOTEIf TCHs become congested abruptly in the cell because of emergencies such as a gathering, noaction is required.

l If no, go to Step 4.4. Run the MML command LST GTRXCHAN to check whether the cell is configured with

a large number of static packet data channels (PDCHs) or dynamic PDCHs and processesPS services preferentially.

l If yes, reduce the number of PDCHs. Then, check whether the assignment success ratereturns to normal. If yes, no further action is required. If no, go to Step 5.

l If no, go to Step 5.5. Run the MML command LST GCELLBASICPARA to check whether TCH Immediate

Assignment is Yes, that is, whether very early assignment is enabled.

l If yes, run the MML command SET GCELLBASICPARA with TCH ImmediateAssignment set to NO(No) to disable very early assignment. Alternatively, performcapacity expansion. Then, check whether the assignment success rate returns to normal.If yes, no further action is required. If no, go to Step 6.

l If no, go to Step 6.6. Check whether RR307:TCH Availability is less than 100%.

l If yes, some TRXs are faulty or some channels are blocked. Check the TRX status orrun the MML command DSP CHNSTAT to check channel status, and rectify TRX orchannel faults. Then, check whether the assignment success rate returns to normal. Ifyes, no further action is required. If no, return to Procedure for locating accessfaults.

l If no, return to Procedure for locating access faults.



122

Typical Case

Symptom

A customer complains that TCHs are congested in some cells during off-peak hours.

Cause Analysis

TCH congestion is generally caused by problems such as improper parameter settings, hardwarefaults, and large traffic volumes.


1. Analyze the traffic statistics of one of the cells where TCHs are congested. The cell isconfigured with 12 TCHs, and the TCHs are congested twice at a certain time andR3561:Maximum Number of Busy Channels (TCHF) measured at the time is 12. Thisindicates that all TCHs are occupied at the time, resulting in TCH congestion. This indicatesthat all TCHs are occupied at the time, resulting in TCH congestion.

2. Analyze the traffic statistics of all cells where TCHs are congested. The traffic volume ofthese cells during the measurement period is low but all the TCHs are occupied within ashort period. In this case, TCHs are congested when new calls access these cells, leadingto assignment failures.

3. Check the data configuration of these cells. TCH Rate Adjust Allow are all No.

4. Perform the following operations to resolve the problem:

(1) Run the MML command SET GTRXDEV with TCH Rate Adjust Allow set to YES(Yes).

(2) Run the MML command SET GCELLCHMGAD with TCH Traffic BusyThreshold set to a required value.

(3) Run the MML command SET GCELLCHMGBASIC with Enhanced TCH AdjustAllowed set to YES(Yes).

6.8 Troubleshooting Low Assignment Success Rates Due toHardware or Transmission Faults

This section describes how to troubleshoot low assignment success rates due to hardware ortransmission faults.

Symptoml According to the result of signaling tracing over the A interface, the BSC sends the MSC

an assignment failure message containing the cause value of Equipment failure. Inaddition, the values of ZTA312L:Failed Assignments per BSC (Equipment Failure) andA3129B:Failed Assignments (First Assignment, Terrestrial Resource Request Failed)increase.

l When TRXs or combiners of a BTS are faulty, or radio frequency (RF) cables are connectedincorrectly, some channels are unavailable, leading to assignment failures. The signalingtracing result shows that MSs fail to access traffic channels (TCHs) and send assignmentfailure messages on standalone dedicated control channels (SDCCHs).



123

Background Informationl When troubleshooting hardware faults, pay attention to BSC alarms such as DPU fault

alarms, TNU fault alarms, Abis/Ater/A interface board fault alarms, and alarms about cableconnections between TNUs on the BSC side.On the BTS side, pay attention to BTS alarms or check BTS hardware status on the WebLMT; in addition, check whether the RF cables at a site are properly connected.The following are the common hardware fault alarms that can result in access faults:– ALM-21807 OML Fault– ALM-2204 TRX Communication Alarm– ALM-4144 TRX VSWR alarm– ALM-3606 DRU Hardware alarm– ALM-20241 Board Unavailable– ALM-20243 Board Hardware Fault– ALM-20254 DSP Unavailable– ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty– ALM-20230 TDM Link Between TDM Switching Board and Service Board Faulty

l When transmission problems such as delay, frame loss, and LAPD link congestion occur,channel activation times out or messages for inter-subrack communication of the BSC arelost, leading to assignment failures. You can verify whether transmission faults occur bychecking transmission fault alarms. The following are the common transmission faultalarms that can result in access faults:– OML fault alarms

ALM-21807 OML Fault– BTS LAPD link alarms

ALM-4102 TRX LAPD Link Interrupt AlarmALM-2114 TRX LAPD Link Interrupt AlarmALM-3052 LAPD alarmALM-3572 LAPD alarm

– BSC LAPD link alarmsALM-21511 LAPD Link CongestionALM-21512 LAPD Link Fault

– Alarms related to the MSP of optical portsALM-21311 MSP Multiplex Section K1/K2 MismatchALM-21312 MSP Multiplex Section K2 MismatchALM-21313 MSP Port Protection Mode Mismatch


Location ProcedureFigure 6-13 shows the procedure for locating low assignment success rates due to hardware ortransmission faults.



124

Figure 6-13 Procedure for locating low assignment success rates due to hardware or transmissionfaults

Troubleshooting Procedure1. Check whether any of the hardware fault alarms listed in Background Information are

reported.l If yes, clear these alarms by referring to the alarm reference help and go to Step 2.l If no, go to Step 3.

2. Perform dialing tests to check whether the assignment success rates return to normal.l If yes, no further action is required.l If no, go to Step 3.

3. Check whether any of the transmission fault alarms listed in Background Information arereported.l If yes, contact transmission engineers to clear the transmission fault alarms. Then, go

to Step 4.l If no, return to Procedure for locating access faults.

4. Perform dialing tests to check whether the assignment success rates return to normal.l If yes, no further action is required.l If no, return to Procedure for locating access faults.

Typical CaseSymptom

After the capacity of a BSC is expanded by adding BM subracks, the BSC operates properly.The assignment success rates decrease after the TNUs on subrack 1 are switched over.



125

Cause Analysis

This problem occurs after capacity expansion and TNU switchover. Therefore, it is mostprobably caused by incorrect cable connections between subracks of the BSC.


1. View historical alarms. The alarm ALM-20231 Link Between TDM Switching Boards inDifferent Subracks Faulty is reported when the problem occurs.

2. Check the cable connections between TNUs on different subracks. The cable connectionsbetween TNUs on different subracks are incorrect, as shown in Figure 6-14. Figure6-15 shows the correct cable connections between TNUs on different subracks.

Figure 6-14 Incorrect cable connections between TNUs on different subracks

Figure 6-15 Correct cable connections between TNUs on different subracks



126

3. Correct the cable connections between the TNUs by referring to Figure 6-15. Thiscorrection resolves the problem.

6.9 Troubleshooting Low Assignment Success Rates Due toInappropriate BSC Configuration

This section describes how to troubleshoot low assignment success rates due to inappropriateBSC configuration.

SymptomA large number of assignment failures occur during peak hours. The cause value is equipmentfailure or requested terrestrial resource unavailable and the values of ZTA312L:FailedAssignments per BSC (Equipment Failure) and A3129B:Failed Assignments (First Assignment,Terrestrial Resource Request Failed) increases.

Background InformationWhen the number of resources configured for a BSC board exceeds its processing capacity,requesting call-related circuit resources fails during peak hours, leading to assignment failures.For details about the processing capacity of BSC boards, see the BSC6900 GSM HardwareDescription.l If Ater interface resources are insufficient, assignment fails during peak hours and the value

of A3129T:Failed Assignments (No Ater Resource Available) increases.l If the number of circuit identification code (CICs) over the A interface exceeds the number

of calls that all DPUs support, calls fail to request transcoders (TCs) during peak hours,leading to assignment failures.

l In Abis over IP mode, assignment fails if the path type of IPPATH is incorrect. If the BTSare not configured with logical ports, assignment may fail during peak hours.

l In A over IP mode, assignment fails if the media gateway (MGW) IP address carried by anassignment request delivered by the mobile switching center (MSC) is incorrect.

l If cable connections between the TNUs on different subracks are not configured, inter-subrack call assignment fails.

l After A over IP transformation, assignment fails if the BSC is not reset.

Location ProcedureFigure 6-16 shows the procedure for locating low assignment success rates due to inappropriateBSC configuration



127

Figure 6-16 Procedure for locating low assignment success rates due to inappropriate BSCconfiguration



128

Troubleshooting Procedure1. Check whether the value of A3129T:Failed Assignments (No Ater Resource Available)

increases.

l If yes, Ater interface resources are insufficient. Check whether the Ater interfaceresources are blocked or faulty by referring to Maintaining Ater Interface Resources. Ifany Ater interface resources are blocked, unblock them. If any Ater interface resourcesare faulty, replace the transmission cables for the faulty Ater timeslots. If the problempersists, run the MML command ADD ATERCONPATH to add Ater interfaceresources. If the problem is resolved, no further action is required. If the problempersists, go to Step 2.


2. Check whether the number of CICs over the A interface exceeds the number of calls thatall DPUs support.

l If yes, reduce the number of CICs over the A interface or add DPUs. Then, checkwhether the problem is resolved. If yes, no further action is required. If no, go to Step3.


3. If Abis over IP is used, go to Step 4.

If Abis over time division multiplexing (TDM) is used, go to Step 6.

4. In Abis over IP mode, run the MML command LST IPPATH to check whether an IPPATHwith IP path type being EF is configured.


l If no, run the MML command ADD IPPATH to add an IPPATH with IP path typebeing EF(EF). Then, check whether the problem is resolved. If yes, no further actionis required. If no, go to Step 5.

5. In Abis over IP mode, if the problem occurs only during peak hours and the value ofA312F:Number of Assignment Failures (No Abis Resource Available) increasessignificantly, run the MML command LST IPLOGICPORT to check whether the problemBTS is configured with logical ports.


l If no, run the MML command ADD IPLOGICPORT to add a logical port. Then, checkwhether the problem is resolved. If yes, no further action is required. If no, go to Step6.

6. Run the MML command LST SRCONPATH to check whether inter-subrack connectionsare configured.


l If no, run the MML command ADD SRCONPATH to add inter-subrack connections.Then, check whether the problem is resolved. If yes, no further action is required. If no,go to Step 7.

7. If A over IP is used, go to Step 8.

If A over TDM is used, go to Step 10.

8. In A over IP mode, if A over IP transformation is just complete, request transformationengineers to check whether the BSC is reset after the A over IP transformation.




129

l If no, reset the BSC. Then, check whether the problem is resolved. If yes, no furtheraction is required. If no, go to Step 9.

9. In A over IP mode, run the MML command LST IPRT to check whether the MGW IPaddress carried by the assignment request delivered by the MSC is on the destination IPnetwork segment configured for IP route (IPRT).l If yes, go to Step 10.l If no, request MSC engineers to check whether the IP data configuration on the MSC

is consistent with that on the BSC. If the IP data configuration is inconsistent, modifythe IP data configuration based on the actual situation. Then, check whether the problemis resolved. If yes, no further action is required. If no, go to Step 10.

10. Check whether the numbers of resources configured for some BSC boards exceed theprocessing capacity of these BSC boards.l If yes, add BSC boards accordingly and configure resources for the new BSC boards.

Ensure that the numbers of resources configured for the new BSC boards do not exceedthe processing capacity of these BSC boards. Then, check whether the problem isresolved. If yes, no further action is required. If no, Contact Huawei Customer ServiceCenter.

l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom

A BSC uses one POUc as the A interface board and the POUc is configured with more than7000 CICs. When the traffic volume exceeds 4000 Erl, the assignment success rate decreasesand the value of ZTA312L:Failed Assignments per BSC (Equipment Failure) increases sharply.

Cause Analysis

When the traffic volume exceeds 4000 Erl, the assignment success rate decreases and mostassignment failures are due to equipment faults. Therefore, this problem is mostly probablycaused by inappropriate BSC configuration.


1. Check the traffic statistics collected during the period this problem occurs. The value ofA3129T:Failed Assignments (No Ater Resource Available) is 0 and therefore the problemis not caused by insufficient Ater interface resources.

2. Check the number of DPUs. DPUs are sufficient.3. Check inter-subrack connections. Inter-subrack connections are configured.4. Check data configuration. A POUc is used as the A interface board and is configured with

more than 7000 CICs. The POUc, however, can process a maximum of 3906 CICs. When3906 CICs over the A interface are occupied, a new call can apply for a CIC over the Ainterface successfully but fails to request low voltage differential signal (LVDS) resourcesbecause the LVDS resources are used together with the CICs and the POUc supports amaximum of 3906 LVDS resources. As a result, the assignment success rate decreases.

5. Reduce the number of CICs configured for the POUc. The problem is resolved.



130

7 Voice Problems

About This Chapter

This chapter describes how to locate and troubleshoot voice problems.

7.1 GSM CS Signal FlowAfter a CS call is established in the GSM network, the MS and the network communicate witheach other through the CS signal flow. The method of processing the GSM CS signal flow variesaccording to the transmission mode adopted on the Abis and A interfaces and the configurationmode of the BSC6900 subracks.

7.2 Common Voice Problems and Problem Location MethodsThis section describes common voice problems and the methods used to locate them.

7.3 Troubleshooting One-Way Audio or No AudioThis section describes how to troubleshoot one-way audio or no audio.

7.4 Troubleshooting NoiseThis section describes how to troubleshoot noise.

7.5 Troubleshooting CrosstalkThis section describes how to troubleshoot crosstalk.

7.6 Troubleshooting EchoesThis section describes how to troubleshoot echoes.

7.7 Troubleshooting Discontinuous Voice or Low MOSThis section describes how to troubleshoot discontinuous voice or low mean opinion score(MOS).

GBSS9.0Troubleshooting Guide 7 Voice Problems


131

7.1 GSM CS Signal FlowAfter a CS call is established in the GSM network, the MS and the network communicate witheach other through the CS signal flow. The method of processing the GSM CS signal flow variesaccording to the transmission mode adopted on the Abis and A interfaces and the configurationmode of the BSC6900 subracks.

Abis over TDM and A over TDM

Figure 7-1 shows the CS signal flow in Abis over TDM, Ater over TDM, A over TDM, andBM/TC separated mode.

NOTE

l The Abis, Ater, and A interface boards can be the EIUa/OIUa/POUc board. The boards shown in Figure7-1, Figure 7-2, and Figure 7-3 are only examples.

l The INT in the figure stands for the interface board. You can use different interface boards as required.

Figure 7-1 GSM CS signal flow (1)

As shown in Figure 7-1, the CS signal flow on the uplink is as follows:

1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.2. The CS signals are demultiplexed in the Abis interface board. Each CS signal uses a 64

Kbit/s timeslot and is transmitted to the TNUa board and then to the Ater interface board.3. The CS signals are multiplexed in the Ater interface board. Each full-rate CS signal uses a

16 Kbit/s sub-timeslot, and each half-rate CS signal uses an 8 Kbit/s sub-timeslot. The CSsignals are then transmitted to the Ater interface board in the TCS over the Ater interface.

4. The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signaluses a 64 Kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.

5. The DPUc board performs speech codec and rate adaptation on the CS signals, which areconverted to 64 Kbit/s PCM frames. The 64 Kbit/s PCM frames are transmitted to the TNUaboard, to the A interface board, and then to the MSS over the A interface.

The downlink flow is the reverse of the uplink flow.

Figure 7-2 shows the CS signal flow in Abis over TDM, Ater over IP, A over TDM, and BM/TC separated mode.



132




Kbit/s timeslot. The CS signals are transmitted to the TNUa board and then to the DPUcboard.

3. The CS signals are converted from TRAU frames to PTRAU frames in the DPUc board.4. The CS signals are transmitted to the SCUa board and then to the Ater interface board.5. The CS signals are multiplexed in the Ater interface board. Each full-rate CS signal uses a


6. The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signaluses a 64 Kbit/s timeslot and is transmitted to the SCUa board and then to the DPUc board.

7. The DPUc board adjusts the order of PTRAU frames, eliminates jitter, and performs speechcodec and rate adaptation on CS signals, which are converted to 64 Kbit/s PCM frames.The 64 Kbit/s PCM frames are transmitted to the TNUa board, to the A interface board,and then to the MSS over the A interface.


In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-3 shows theCS signal flow in Abis over TDM and A over TDM mode.





133


Kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.3. The DPUc board performs speech codec and rate adaptation on the CS signals, which are

converted to 64 Kbit/s PCM frames. The 64 Kbit/s PCM frames are transmitted to the TNUaboard, to the A interface board, and then to the MSS over the A interface.


Abis over IP and A over TDMFigure 7-4 shows the CS signal flow in Abis over IP, Ater over TDM, A over TDM, and BM/TC separated mode.

NOTE

l The Abis interface board can be the PEUa/FG2a/GOUa/POUc/FG2c/GOUc board, and the Ater and Ainterface boards can be the EIUa/OIUa/POUc board. The boards shown in Figure 7-4, Figure 7-5, andFigure 7-6 are only examples.




1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.2. The CS signals are transmitted from the Abis interface board to the SCUa board and then

to the DPUc board.3. The DPUc board reorders PTRAU frames, eliminates jitter, and converts PTRAU frames

into TRAU frames. Then, the TRAU frames are transmitted to the TNUa board and thento the Ater interface board.

4. The CS signals are multiplexed in the Ater interface board in the MPS/EPS, and then aretransmitted to the Ater interface board in the TCS.

5. The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signaluses a 64 Kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.

6. The DPUc board performs speech codec and rate adaptation on the CS signals, which areconverted to 64 Kbit/s PCM frames. The 64 Kbit/s PCM frames are transmitted to the TNUaboard, to the A interface board, and then to the MSS over the A interface.




134

Figure 7-5 shows the CS signal flow in Abis over IP, Ater over IP, A over TDM, and BM/TCseparated mode.




Kbit/s timeslot and is transmitted to the SCUa board and then to the Ater interface board.3. The CS signals are multiplexed in the Ater interface board. Each full-rate CS signal uses a


4. The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signaluses a 64 Kbit/s timeslot and is transmitted to the SCUa board and then to the DPUc board.

5. The DPUc board adjusts the order of PTRAU frames, eliminates jitter, and performs speechcodec and rate adaptation on CS signals, which are converted to 64 Kbit/s PCM frames.The 64 Kbit/s PCM frames are transmitted to the TNUa board, to the A interface board,and then to the MSS over the A interface.


In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-6 shows theCS signal flow in Abis over IP and A over TDM mode.





135

1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.

2. The CS signals are transmitted to the SCUa board and then to the DPUc board.

3. The DPUc board reorders PTRAU frames, eliminates jitter, and performs speech codec andrate adaptation on the PTRAU frames, which are converted into 64 Kbit/s PCM frames.

4. The 64 Kbit/s PCM frames are transmitted to the TNUa board, to the A interface board,and then to the MSS over the A interface.


Abis over TDM and A over IP

In the case of A over IP, the Ater interface does not exist. Figure 7-7 shows the CS signal flowin Abis over TDM and A over IP transmission mode.

NOTE

l The Abis interface board can be the EIUa/OIUa/POUc board, and the A interface board can be the FG2a/GOUa/FG2c/GOUc/POUc board. The boards shown in Figure 7-7 are only examples.




1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.

2. The CS signals are demultiplexed in the Abis interface board. Each CS signal uses a 64Kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.

3. The DPUc board converts TRAU frames into RTP frames, adjusts the order of RTP frames,and eliminates jitter.

4. The SCUa board transmits the CS signals to the A interface board, which then transmitsthe signals to the MSS over the A interface.


Abis over IP and A over IP

In the case of A over IP, the Ater interface does not exist. Figure 7-8 shows the CS signal flowin Abis over IP and A over IP transmission mode.



136

NOTE

l The Abis interface board can be the PEUa/FG2a/GOUa/POUc/FG2c/GOUc board, and the A interface boardcan be the FG2a/GOUa/PEUa/FG2c/GOUc/POUc board. The boards shown in Figure 7-8 are onlyexamples.




1. The uplink CS signals are sent from the BTS to the Abis interface board in the MPS/EPS.2. The Abis interface board encapsulates the CS signals in PTRAU frames, which are

transmitted to the SCUa board and then to the DPUc board.3. The DPUc board converts PTRAU frames into RTP frames, reorders RTP frames, and

eliminates jitter.4. The SCUa board transmits the CS signals to the A interface board, and then the A interface

board transmits the signals to the MSS over the A interface.


7.2 Common Voice Problems and Problem LocationMethods

This section describes common voice problems and the methods used to locate them.

Common Voice ProblemsCommon voice problems include one-way audio, no audio, noise, crosstalk, echo, discontinuousvoice, low mean opinion score (MOS), and TFO establishment failures.

The causes of the common voice problems are as follows:l Poor Um interface quality

Voice problems are generally caused by poor Um interface quality, which may be causedby weak coverage, interference (for example co-channel, adjacent-channel, external, orintermodulation interference), or frequent cell handovers. Common symptoms of poor Uminterface quality are discontinuous voice and temporarily muted voice.

l Chip faults



137

The following chips become faulty with a relatively high probability: DSP chips on theDPU, as well as TDM chips on the DPU, TNU, or interface boards. Chip faults may leadto one-way audio or noise.

l Transmission faults

Common symptoms of transmission faults include the following: one-way audio orcrosstalk due to incorrect cable connection or incorrect timeslot connection in thetransmission equipment, noise or long delay in the case of satellite or microwavetransmission, one-way audio due to packet loss on the IP transmission equipment, anddiscontinuous voice due to bit errors on the optical transmission equipment.

l A over IP transformation

After A over IP transformation, the transcoder (TC) is moved to the MSC. In A over IPmode, one-way audio and call drops may easily occur especially when AMR is used orduring handovers due to difficult interconnection between NEs from different vendors.

l Clock exceptions

In Abis/A over TDM mode, frames may be lost or slip during voice transmission if theBTS/BSC clock source or the GCK board is abnormal.

l Incorrect equipment configurations

Voice problems may easily occur in A over IP mode if equipment is not configuredaccording to the configuration rules.

Problem Location Methodsl 3.1.3 One-Way Audio Detection

l 3.1.2 External Voice Loopback

l 3.1.1 Querying Call Resource Usage of an MS

l 3.4.1 Tracing CS Domain Messages of a Single Subscriber

l 3.1.4 Crosstalk Detection

l 3.1.5 Optimizing Um Interface Crosstalk

l 3.2.1 Crossed Pair Detection

7.3 Troubleshooting One-Way Audio or No AudioThis section describes how to troubleshoot one-way audio or no audio.

Symptom

When one-way audio occurs, only one party in a call can hear the voice of the other party. Whenno audio occurs, neither party can hear the other party's voice.

Background Informationl One-way audio and no audio are common voice problems. They may be caused by weak

coverage, poor engineering quality, chip faults, or software defects.

l 3.1.3 One-Way Audio Detection detects one-way audio and no audio between a BTS andthe controlling BSC. One-way detection cannot detect one-way audio or no audio on theUm interface or between the BSC and the MSC.



138

Location ProcedureFigure 7-9 shows the procedure for locating one-way audio or no audio.

Figure 7-9 Procedure for locating one-way audio or no audio

Troubleshooting Procedure1. If the IP networking mode is used, go to Step 3.

If the TDM networking mode is used, run the MML command SET GCELLSOFT withMute Detect Class1 Switch and Mute Detect Class2 Switch set to ENABLE(ENABLE). Then, check whether the one-way audio logs contain abnormal records.l If yes, one-way audio or no audio occurs between the BTS and the BSC. In this case,

troubleshoot the fault as follows and then go to Step 2.– If one-way audio occurs frequently on a digital signaling processing (DSP) chip,

replace the board where the DSP chip is located, or run the MML command INHDSP to disable the DSP chip.

– If one-way audio occurs mainly on a certain E1/T1 cable over the Abis interface,run the MML command CHK E1T1CRS to check whether there are any crossedpairs.

– If one-way audio occurs mainly on a certain TRX, replace the TRX board.l If no, go to Step 3.

2. Check whether the problem is resolved.l If yes, no further action is required.l If no, go to Step 3.

3. Perform mass dialing testing. When one-way audio or no audio occurs, run the MMLcommand STR CALLRESLOP with Loop Position set to NSSAINTF(NSS Interface



139

Unit). Then, determine whether one-way audio or no audio occurs on the NSS or BSS. Fordetails, see 3.1.2 External Voice Loopback.l If one-way audio or no audio occurs on the NSS, contact MSC engineers to resolve the

problem.l If one-way audio or no audio occurs on the BSS, go to Step 4.

4. Run the MML command STR CALLRESLOP with Loop Position set to BTSTRUDSP(TRU DSP). Then, determine whether one-way audio or no audio occurs over the Uminterface. For details, see 3.1.2 External Voice Loopback.l If one-way audio or no audio occurs over the Um interface, troubleshoot Um interface

problems such as weak coverage. If the problem persists, Contact Huawei CustomerService Center.

l If one-way audio or no audio does not occur over the Um interface, Contact HuaweiCustomer Service Center.

Typical CaseSymptom

A large number of subscribers experience no audio and some subscribers encounter crosstalkwith a probability of about 30% at a site.

Cause Analysis

The cables between TNUs are not connected properly.


1. Enable one-way audio detection. Ten minutes later, the one-way audio logs show that one-way audio occurs in calls from subrack 0 to subrack 3.

2. View the historical alarms. ALM-20231 Link Between TDM Switching Boards in DifferentSubracks Faulty is generated. The alarm information shows that inter-subrack cables arenot connected properly.

3. Check the cable connections. A cable from subrack 0 is mistakenly connected to subrack4. When the cable is connected to subrack 3, the no audio and crosstalk problems areresolved.

7.4 Troubleshooting NoiseThis section describes how to troubleshoot noise.

SymptomOne party in a call can hear certain noises, including bubbling sounds, clicking, and metallicsounds. When the noises are severe, subscribers may not even hear the other party's voice.

Background Informationl These kinds of noises are generally caused by bit errors, which may be caused by one of

the following factors:– Board, connector, or cable connection faults on the path transmitting voice signals– Improper grounding, interference, or clock faults



140

– Interference on radio links– Frame losses or slips due to clocks being out of synchronization– Incorrect DIP switch configurations, for example inconsistent impedance

configurationsl The symptoms vary according to the cause of the bit errors.

– If the noise is due to line bit errors between the BSC and the MSC, it occurs regularlyand fluctuates slightly, because the pulse code modulation (PCM) sample value isaffected.

– If the noise is due to line bit errors on the BSS side, it fluctuates noticeably, becausecompressed voice signals are affected. In this case, parties in a call may hear bubblingsounds, discontinuous voice, or metallic sounds and have difficulty recognizing theother party's words.

– If the noise is due to regular frame losses or slips due to clock problems, it occurs at aspecific time during a call.

l Locating noise is a difficult problem in the telecom industry. Generally, when noises occur,troubleshooting engineers first determine whether faulty chips are responsible for causingthe noises.

Location ProcedureFigure 7-10 shows the procedure for locating noise.

Figure 7-10 Procedure for locating noise

Troubleshooting Procedure1. Determine whether the noise lasts a long time. A noise is considered long if it lasts more

than 10s.



141

l If the noise lasts a long time, Contact Huawei Customer Service Center.

l If the noise does not last a long time, go to Step 2.

2. Perform mass dialing testing. When the noise occurs, run the MML command STRCALLRESLOP with Loop Position set to NSSAINTF(NSS Interface Unit). Then,determine whether the noise occurs on the NSS or BSS. For details, see 3.1.2 ExternalVoice Loopback.

l If the noise occurs on the NSS, contact MSC engineers to resolve the problem.

l If the noise occurs on the BSS, go to Step 3.

3. Run the MML command DSP CALLRES to query the usage of single-user call resourcesand save the results. Then, find out the resource usage regularity. If the noise occurs on afixed DSP chip of a specific board, replace the board, or run the MML command INHDSP to disable the DSP chip.

4. Perform dialing testing to check whether noise is eliminated.

l If yes, no further action is required.


Typical Case

Symptom

A site experiences noises with a probability of about 2% and the calling/called party can hardlyhear the other party's voice.

Cause Analysis

DSP 7 on the board in slot 11 of subrack 1 is faulty. As a result, a bit in the RAM storage unitis stored abnormally.


1. Perform dialing tests at the site. The noise occurs three times for every 100 dialing tests.According to three single-user call resource query results, the noise occurs on DSP 7 onthe board in slot 11 of subrack 1.

2. Run the MML command INH DSP to disable the DSP. Then, perform dialing tests 200times. The noise does not occur.

3. During off-peak hours, enable DSP 7 on the board in slot 11 of subrack 1, and disable DSPson other boards to enable calls to use DSP 7 on the board in slot 11 of subrack 1. The noiseoccurs every time DSP 7 is used.

4. Replace the board in slot 11 of subrack 1. The problem is resolved.

7.5 Troubleshooting CrosstalkThis section describes how to troubleshoot crosstalk.

Symptom

The voice of a third party, not involved in a two-party call, may be heard in addition to or insteadof the voice of the speaking party.



142

Background InformationCommon causes of crosstalk include poor Um interface quality, incorrect cable connections, orincorrect timeslot connections on a switching board. The most common cause is poor Uminterface quality. The symptoms of crosstalk due to poor Um interface quality are as follows:l Crosstalk generally begins partway through a call.l One party in a call experiences poor Um interface quality.l One party in a call can hear the voice of two other parties.

The BSS crosstalk detection function can only detect crosstalk between a BTS and the controllingBSC. The crosstalk information is recorded in the one-way audio log file saved in \bam\common\fam\famlogfmt. This function cannot detect crosstalk between a BTS and an MS or between aBSC and an MSC.

Location ProcedureFigure 7-11 shows the procedure for locating crosstalk.

Figure 7-11 Procedure for locating crosstalk

Troubleshooting Procedure1. Check whether the crosstalk is due to a problem on the Um interface. For details, see

Background Information.l If the crosstalk is due to a problem on the Um interface, run the MML command SET

GCELLSOFT with Um Interface Crosstalk Optimization Allowed set to YES(Allowed). Then, go to Step 2.

l If the crosstalk is not due to a problem on the Um interface, go to Step 3.2. Check whether the problem is resolved.




143

3. Enable the 3.1.4 Crosstalk Detection function to check whether the crosstalk logs containabnormal records.l If yes, you are advised to perform a 3.2.1 Crossed Pair Detection to resolve any

problems on the E1/T1 cables allocated to abnormal calls. Then, go to Step 4.l If no, Contact Huawei Customer Service Center.

4. Check whether the problem is resolved.l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical Case

Symptom

Field engineers at a site receive an average of two customer complaints a day involving crosstalk.Crosstalk problems, however, do not occur during onsite dialing testing.

Cause Analysis

The quality of the Um interface is poor.


1. Check whether the crosstalk is due to a problem on the Um interface. One party cannothear the voice of the other party. Several seconds later, the party hears the voice of twoother parties. This is a common example of Um interface crosstalk.

2. Analyze the traffic statistics for the area where the crosstalk occurs. This area has poorsignal coverage and a large number of call drops occur over the Um interface.

3. Run the MML command SET GCELLSOFT with Um Interface Crosstalk OptimizationAllowed set to YES(Allowed). The problem is resolved.

7.6 Troubleshooting EchoesThis section describes how to troubleshoot echoes.

Symptom

The calling or called party can hear his or her own voice as well as that of the other party.

Background Informationl Echoes can be either acoustic or electrical.

– An acoustic echo occurs when the earphone and microphone of an MS (especially alow-end MS) are not properly isolated from each other.

– An electrical echo occurs when the impedance of the two-wire connector for the hybridconverter at the public switched telephone network (PSTN) end does not match that ofthe four-wire connector and therefore transmitted signals are coupled to the four-wireconnector at the receiving end.

l The BSS side eliminates only acoustic echoes. Electrical echoes must be eliminated by theuniversal media gateway (UMG). In A over IP mode, acoustic echoes must also beeliminated by the UMG because the transcoder (TC) is moved to the UMG.



144

Location ProcedureFigure 7-12 shows the procedure for locating an echo.

Figure 7-12 Procedure for locating an echo

Troubleshooting Procedure1. Check whether the A over IP mode is used.

l If yes, contact MSC engineers to resolve the echo problem.l If no, go to Step 2.

2. Determine the echo type. If you hear an echo when you use an MS to call another MS, itis an acoustic echo. If you hear an echo when you use an MS to call a fixed-line phone, itis an electrical echo.l If it is an electrical echo, contact MSC engineers to resolve the problem.l If it is an acoustic echo, go to Step 3.

3. Check whether the MS encountering the echo problem is served by a Huawei BSC.l If yes, run the MML command SET TCPARA with AEC Switch set to OPEN

(Open) and the other parameters unchanged. Then, go to Step 4.l If no, contact the related BSC vendor to resolve the problem.

NOTEDo not change the values of other AEC-related parameters unless otherwise stated.

4. Check whether the echo has been eliminated.l If yes, no further action is required.



145


Typical Case

Symptom

A subscriber complains that he always hears an echo when using his MS to call a specific MSand occasionally hears an echo when calling other MSs.

Cause Analysis

The earphone and microphone of some MSs are not properly isolated from each other.


1. Check the model of the MS the subscriber is using and confirm that the MS is served by aHuawei BSC.

2. Lab tests show that acoustic echoes occur with a high probability. Determine that it is anacoustic echo because the earphone and microphone of the MS are not properly isolatedfrom each other and the subscriber hears an echo when he or she calls another MS.

3. Run the MML command SET TCPARA with AEC Switch set to OPEN(Open).4. This problem is resolved after AEC is enabled.

7.7 Troubleshooting Discontinuous Voice or Low MOSThis section describes how to troubleshoot discontinuous voice or low mean opinion score(MOS).

Symptom

l Discontinuous voice

Breaks occur in a call and words are lost. When breaks are severe, one party in the callcannot hear enough words to understand the other party.

l Low MOS

The MOS does not meet the customer's requirement.


l MOS

Used to reflect the voice quality of a call, the mean opinion score (MOS) ranges from 1 to5, where 1 indicates the lowest voice quality and 5 indicates the highest voice quality. Aspecialized instrument is required for measuring the MOS, which meets the perceptualevaluation of speech quality (PESQ) standards.

l Tandem Free Operation (TFO)

A voice call from one MS to another requires a dual encoding and decoding process, duringwhich certain speech signals are lost. To resolve this problem, TFO is introduced. WithTFO, when the calling and called parties use the same voice coder, neither party needs tohave the transcoder (TC) activated and nor speech signals are transparently transmittedbetween them, as shown in Figure 7-13.



146

Figure 7-13 TFO

Location Procedurel Discontinuous voice

Discontinuous voice is generally caused by poor Um interface quality. During testing,perform 3.4.1 Tracing CS Domain Messages of a Single Subscriber and analyze thevoice quality and signal level in the measurement reports. If the voice quality is poor or thesignal level is low, check the Um interface. Otherwise, Contact Huawei Customer ServiceCenter.

l Low MOSThe MOS is affected by various factors, such as handovers, call drops, speech versions,Um interface coding rate, and Um interface quality. If the MOS obtained after testing doesnot meet the customer's requirement, analyze the test report or Contact Huawei CustomerService Center.

Troubleshooting ProcedureThe method described in the previous part Location Procedure is recommended whentroubleshooting discontinuous voice and low MOS. If the problems persist, Contact HuaweiCustomer Service Center.

Typical CaseSymptom

Field engineers report that the MOS at a site is 3.0 when the AMR is enabled, whereas theminimum MOS acceptable to the customer is 3.3.

Cause Analysis

The reserved BSC parameters are not set properly. As a result, a large number of frames are lostduring an AMR TCHF-to-TCHH conversion.


1. Analyze the test report. During testing, the MOS is low each time an AMR TCHF-to-TCHHconversion is performed.

2. Contact onsite testing engineers for information about the site. Words are lost on thedownlink each time an AMR TCHF-to-TCHH conversion is performed.

3. Analyze the configuration data and run the MML command LST OTHSOFTPARA.Reserved parameter 3 is not set to 0, as required by Huawei. In this case, the BSC does



147

not request the MSC to set up a downlink conference bridge when an AMR TCHF-to-TCHH conversion is performed. As a result, a large number of frames are lost on thedownlink, leading to a low MOS.

4. Run the MML command SET OTHSOFTPARA: BSCRESERVEDPARA3=8191; tochange the value of Reserved parameter 3. Then, perform another test. The MOS is 3.4,which meets the customer's requirement.



148

8 PS Counter Problems

About This Chapter

This chapter describes how to locate and troubleshoot PS counter problems.

8.1 PS CountersThis section describes the formulas for calculating the values for PS counters.

8.2 Locating PS Counter ProblemsThis section describes how to locate PS counter problems.

8.3 Troubleshooting Low TBF Establishment Success RatesThis section describes how to troubleshoot low temporary block flow (TBF) establishmentsuccess rates.

8.4 Troubleshooting High TBF Call Drop RatesThis section describes how to troubleshoot high TBF call drop rates.

8.5 Troubleshooting Low Average Throughput at the RLC LayerThis section describes how to troubleshoot low average throughput at the radio link control(RLC) layer.

8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding SchemesThis section describes how to troubleshoot low percentage of high-rate coding schemes to allcoding schemes.

8.7 Troubleshooting High RLC Data Block Retransmission RatesThis section describes how to troubleshoot high radio link control (RLC) data blockretransmission rates.

GBSS9.0Troubleshooting Guide 8 PS Counter Problems


149

8.1 PS CountersThis section describes the formulas for calculating the values for PS counters.

l PS counters include TBF Establishment Success Rate, TBF Drop Rate, AverageThroughput of RLC, Rate of RLC with High Coding, and Retransmission Rate of RLCData Block. The formulas for calculating the values for these counters are as follows:– TBF Establishment Success Rate = [Number of successful TBF establishments] x

{100}/[Number of TBF establishment attempts]– TBF Drop Rate = [Number of intermit transfers] x {100}/[Number of successful TBF

establishments]– Average Throughput of EGPRS or GPRS RLC = ([Throughput of downlink EGPRS or

GPRS RLC data blocks] x {8})/(Transmission duration of RLC data blocks/{1000})*([Number of PDCHs carrying EGPRS or GPRS TBFs]/[Sampling times of PDCHmeasurement])

– Rate of RLC with High Coding = [Total number of valid RLC data blocks with highcoding] x {100}/[[Total number of valid RLC data blocks with ALL coding]]

– Retransmission Rate of RLC Data Block = ([Total number of RLC data blocks] - [Totalnumber of valid RLC data blocks]) x {100}/[Total number of RLC data blocks]

l The counters covered in this chapter are as follows:– A9003:Number of Failed Uplink GPRS TBF Establishments due to No Channel– A9103:Number of Failed Downlink GPRS TBF Establishments due to No Channel– A9203:Number of Failed Uplink EGPRS TBF Establishments due to No Channel– A9303:Number of Failed Downlink EGPRS TBF Establishments due to No Channel– A9004:Number of Failed Uplink GPRS TBF Establishments due to MS No Response– A9104:Number of Failed Downlink GPRS TBF Establishments due to MS No Response– A9204:Number of Failed Uplink EGPRS TBF Establishments due to MS No Response– A9304:Number of Failed Downlink EGPRS TBF Establishments due to MS No

Response– A9006:Number of Uplink GPRS TBF Abnormal Releases due to N3101 Overflow (MS

No Response)– A9007:Number of Uplink GPRS TBF Abnormal Releases due to N3103 Overflow (MS

No Response)– A9206:Number of Uplink EGPRS TBF Abnormal Releases due to N3101 Overflow

(MS No Response)– A9207:Number of Uplink EGPRS TBF Abnormal Releases due to N3103 Overflow

(MS No Response)– A9106:Number of Downlink GPRS TBF Abnormal Releases due to N3105 Overflow– A9306:Number of Downlink EGPRS TBF Abnormal Releases due to N3105 Overflow– A9010:Number of Uplink GPRS TBF Abnormal Releases due to No Channel– A9210:Number of Uplink EGPRS TBF Abnormal Releases due to No Channel– A9109:Number of Downlink GPRS TBF Abnormal Releases due to No Channel– A9309:Number of Downlink EGPRS TBF Abnormal Releases due to No Channel



150

– A9009:Number of Uplink GPRS TBF Abnormal Releases due to FLUSH– A9209:Number of Uplink EGPRS TBF Abnormal Releases due to FLUSH– A9108:Number of Downlink GPRS TBF Abnormal Releases due to FLUSH– A9308:Number of Downlink EGPRS TBF Abnormal Releases due to FLUSH– A9008:Number of Uplink GPRS TBF Abnormal Releases due to SUSPEND– A9208:Number of Uplink EGPRS TBF Abnormal Releases due to SUSPEND– A9107:Number of Downlink GPRS TBF Abnormal Releases due to SUSPEND– A9307:Number of Downlink EGPRS TBF Abnormal Releases due to SUSPEND– R9343:Number of Reclaimed Dynamic PDCHs– R9344:Number of Reclaimed Busy Dynamic PDCHs

8.2 Locating PS Counter ProblemsThis section describes how to locate PS counter problems.

8.2.1 Principles for Locating PS Counter ProblemsThis section describes the principles for locating PS counter problems.

The principles for locating PS counter problems are as follows:

l Analyze BSC counters before cell counters, lower-layer links before upper-layer services,as well as symptoms before traffic models.

l Focus on the correlation between counters and absolute counter values.l If counters of a certain type are abnormal, analyze the changes in counter values over a

week, and determine whether the counters are abnormal in the entire BSC or only in certaincells.– If counters are abnormal in the entire BSC, check the BSC equipment, transmission

devices, and network.– If counters are abnormal in certain cells, analyze the problem cells by performing drive

tests and using a signaling analyzer if necessary.

8.2.2 Procedure for Locating PS Counter ProblemsThis section describes the procedure for locating PS counter problems.

Figure 8-1 shows the procedure for locating PS counter problems.



151

Figure 8-1 Procedure for locating PS counter problems

8.3 Troubleshooting Low TBF Establishment Success RatesThis section describes how to troubleshoot low temporary block flow (TBF) establishmentsuccess rates.

Symptom

TBF establishment success rates do not meet customer requirements and PS calls are difficultto set up.



152

Background InformationTBFs are used to transmit PS services. If TBFs fail to be established, PS services cannot beperformed successfully. The TBF establishment success rate indicates the capacity of a dataservice network and the Um interface quality for an MS to access the network.

The causes of low TBF establishment success rates are as follows:

l High frame error rate for Abis transmissionl Insufficient channel resourcesl Poor Um interface qualityl Incorrect parameter settings

Location ProcedureFigure 8-2 shows the procedure for locating low TBF establishment success rates.



153

Figure 8-2 Procedure for locating low TBF establishment success rates

Troubleshooting Procedure1. Select the top N cells with lower TBF establishment success rates.



154

NOTE

Removing these cells can increase the overall TBF establishment success rate.

The following operations should only be performed on the top N cells.

2. Check whether RL9A08:Rate ofTransmitted Error Frames is larger than 1%. If yes, biterrors have occurred during Abis transmission. In this case, contact transmission engineers.

3. Check whether L3188A:MSG DEL IND Messages Sent on Abis Interface is larger than10. If yes, the CCCH is seriously overloaded. In this case, run the MML command SETGTRXCHAN to configure extended broadcast control channels (BCCHs).

4. Find out the causes of TBF establishment failures.

TBF establishment failures are generally caused by insufficient channel resources and noMS response.

l If TBF establishment failures are caused by insufficient channel resources, the valuesfor the following counters are large:

– A9003:Number of Failed Uplink GPRS TBF Establishments due to No Channel

– A9103:Number of Failed Downlink GPRS TBF Establishments due to No Channel

– A9203:Number of Failed Uplink EGPRS TBF Establishments due to No Channel

– A9303:Number of Failed Downlink EGPRS TBF Establishments due to No Channel

l If TBF establishment failures are caused by no MS response, the values for the followingcounters are large:

– A9004:Number of Failed Uplink GPRS TBF Establishments due to MS NoResponse

– A9104:Number of Failed Downlink GPRS TBF Establishments due to MS NoResponse

– A9204:Number of Failed Uplink EGPRS TBF Establishments due to MS NoResponse

– A9304:Number of Failed Downlink EGPRS TBF Establishments due to MS NoResponse

l If TBF establishment failures are caused by insufficient channel resources, go to Step5.

l If TBF establishment failures are caused by no MS response, go to Step 6.

5. To troubleshoot TBF establishment failures due to insufficient channel resources, performthe following steps:

(1) Run the MML command LST GTRXCHAN to check whether Channel Type for theproblem cell is set to PDTCH. If no, run the MML command SET GTRXCHAN toreconfigure the parameter.

(2) Run the MML command DSP PSCELL to check whether the value forR9506:Maximum Number of PDCHs Occupied on DSP is 48 on the digital signalprocessor (DSP) that serves the problem cell. If yes, run the MML command SETPSCELLTODSP to migrate the problem cell to the DSP with the smallest value forR9506:Maximum Number of PDCHs Occupied on DSP.

NOTE

A DSP number consists of the subrack number, slot number, and DSP number.

(3) Run the MML command LST GCELLPSCHM to check whether Maximum RateThreshold of PDCHs in a Cell for the problem cell is smaller than 30.



155

l If yes, run the MML command SET GCELLPSCHM and set Maximum RateThreshold of PDCHs in a Cell to 30.

l If the value is larger than or equal to 30, retain the value.

(4) Run the MML command LST GTRXBASE to check the values for the followingparameters:

l Maximum Number of PDCH: The recommended value is 8.

l Maximum Number of Occupied Abis Timeslots: The recommended value is32.

If the two parameters are not set to the recommended values, run the MML commandSET GTRXBASE to reconfigure the parameters.

(5) Run the MML command LST GCELLPSCHM to query the values for PDCHUplink Multiplex Threshold and PDCH Downlink Multiplex Threshold.

l If the value for PDCH Uplink Multiplex Threshold is smaller than 70, run theMML command SET GCELLPSCHM and change the value to 70.

l If the value for PDCH Downlink Multiplex Threshold is smaller than 80, runthe MML command SET GCELLPSCHM and change the value to 80.

l In other cases, retain the original values.

(6) Check whether the subrack where the DSP serving the problem cell is located is thesubrack accommodating the Abis interface board.

l Run the MML command DSP PSCELL to query the value for Subrack No., whichis the number of the subrack where the DSP serving the problem cell is located.

l Run the MML command LST GTRX to query the value for Out-BSC SubrackNo., which is the number of the subrack accommodating the Abis interface board.

If the two subrack numbers are different, run the MML command SETPSCELLTODSP to migrate the problem cell to the DSP that is located in the subrackaccommodating the Abis interface board.

(7) Run the MML command LST BSCPSSOFTPARA to check whether Allow E DownG Up Switch is set to Open. If no, run the MML command SETBSCPSSOFTPARA to reconfigure the parameter.

CAUTIONSetting Allow E Down G Up Switch to Open may decrease the EDGE downloadrate.

6. To troubleshoot TBF establishment failures due to no MS response, perform the followingsteps:

(1) Set the following parameters:

l If the uplink TBF establishment success rate is low, run the MML command SETGCELLEGPRSPARA to set Uplink Default MCS Type for the problem cell toMCS1.

l If the downlink TBF establishment success rate is low, run the MML commandSET GCELLEGPRSPARA to set Downlink Default MCS Type for the problemcell to MCS2.



156

(2) Check the interference band counters to determine whether interference exists in theproblem cell. If yes, eliminate the interference or change the interfered ARFCN.

(3) Check the uplink and downlink quality counters to determine whether the Um interfacequality is poor. If yes, improve the Um interface quality.

7. Optimize network parameters.

l If the uplink TBF establishment success rate is low, perform the following steps:

(1) Run the MML command SET GCELLPSBASE to increase T3168 to a value notmore than 2000.

A small value indicates a short interval for an MS to determine a TBF establishmentfailure. As a result, when a TBF fails to be established, the average delay for PSservice access decreases, but the TBF establishment success rate in an adverseradio environment also decreases. In addition, the probability of PS servicereaccess increases. Consequently, the number of reassignments increases, wastingsystem resources.

A large value indicates a long interval for an MS to determine a TBF establishmentfailure. As a result, when a TBF fails to be established, the average delay for PSservice access increases, but the TBF establishment success rate in an adverse radioenvironment also increases.

(2) Run the MML command SET GCELLPSPWPARA to change the values forALPHA and GAMMA.

Small values for the two parameters indicate a high output power for MSs and astrong signal strength received by BTSs, but an increase in cell interference.

A large value indicates a low output power for MSs and a decrease in cellinterference, but a weak signal strength received by BTSs.

Therefore, change the values for these two parameters according to siterequirements. Generally, smaller values are appropriate for densely populatedareas and larger values for remote areas.

(3) Run the MML command SET GCELLCCACCESS to increase the value for PSRACH Min. Access Level. The recommended value is -109.

Increasing the value for PS RACH Min. Access Level improves the TBFestablishment success rate, but decreases the number of admitted subscribers andthe traffic volume.

(4) Run the MML command SET GCELLCCACCESS to increase the value forRandom Access Error Threshold. The recommended value is 225.

A small value allows more random access signal errors and easier MS randomaccess, but leads to a high misreporting rate.

A large value reduces the misreporting rate, but reduces the number of admittedsubscribers and the traffic volume too.

l If the downlink TBF establishment success rate is low, perform the following steps:

(1) Run the MML command SET BSCPSSOFTPARA to set Retry Times ofDownlink TBF Reassignment to 4.

A large value increases the downlink TBF establishment success rate, but increasesthe congestion rate during peak hours too.

A small value decreases the congestion rate during peak hours, but decreases thedownlink TBF establishment success rate too.



157

(2) Run the MML command LST BSCPSSOFTPARA to check whether RetryTimes of Downlink TBF Polling is set to 5. If no, run the MML command SETBSCPSSOFTPARA to reconfigure the parameter.A large value increases the downlink TBF establishment success rate, but increasesthe congestion rate during peak hours too.A small value decreases the congestion rate during peak hours, but decreases thedownlink TBF establishment success rate too.

8. If the problem persists, Contact Huawei Customer Service Center.

Typical Case

Symptom

The field engineers at a site report that the TBF establishment success rate decreases by 5%.

Cause Analysis

Maximum Rate Threshold of PDCHs in a Cell for the problem cell is set to 10.


1. Analyze related counters. The TBF establishment success rates are lower than 80% for 10cells.

2. Check the frame error rates for Abis transmission in these cells. The frame error rates areall lower than 1‰.

3. Check the causes of TBF establishment failures. All TBF establishment failures are causedby insufficient channel resources.

4. Check parameter settings. PDCHs are configured, and Allow E Down G Up Switch is setto Open.

5. Check the counters related to the DSPs serving the problem cells. The value forR9506:Maximum Number of PDCHs Occupied on DSP is smaller than 48 for all theproblem cells.

6. Check the value for Maximum Rate Threshold of PDCHs in a Cell. The value is 10 forproblem cells but 30 for normal cells.

7. Change the value for Maximum Rate Threshold of PDCHs in a Cell to 30 for the problemcells. The TBF establishment success rates return to normal.

8.4 Troubleshooting High TBF Call Drop RatesThis section describes how to troubleshoot high TBF call drop rates.

Symptom

The TBF call drop rate indicates network performance stability. If the TBF call drop rate is highduring web browsing, web pages open slowly or even fail to open.


The TBF call drop rate is the ratio of the number of abnormal TBF releases to the number ofTBF establishment successes. The causes of high TBF call drop rates are as follows:



158

l No MS response due to poor Um interface qualityl Loss of MS uplink messages due to network transmission faults or resource preemptionl No MS response after receiving an indication message due to MS incompatibility with the

network

The causes of abnormal TBF releases are as follows:

l Overflow of N3101, N3103, or N3105l Cell reselectionl Channel preemption

Location ProcedureFigure 8-3 shows the procedure for locating high TBF call drop rates.



159

Figure 8-3 Procedure for locating high TBF call drop rates

Troubleshooting Procedure1. Check whether any cells meet the standard for high TBF call drop rates.



160

l If yes, select the top N cells with higher TBF call drop rates. The following operationsshould only be performed on the top N cells.

l If no, the following operations should be performed on all cells on the network.2. Check whether the related parameters are set correctly.

l If the EGPRS call drop rate is high, run the MML command LSTGCELLEGPRSPARA to check the values for the following parameters:– Uplink Fixed MCS Type: Check whether this parameter is set to UNFIXED.– Downlink Fixed MCS Type: Check whether this parameter is set to UNFIXED.– Uplink Default MCS Type: Check whether the value for this parameter is smaller

than or equal to MCS2. If the uplink EGPRS TBF call drop rate is high, decreasethe value for this parameter.

– Downlink Default MCS Type: Check whether the value for this parameter issmaller than or equal to MCS6. If the downlink EGPRS TBF call drop rate is high,decrease the value for this parameter.

If the parameter settings are incorrect, run the MML command SETGCELLEGPRSPARA to change the settings.

l If the GPRS call drop rate is high, run the MML command LST GCELLPSCS to checkthe values for the following parameters:– Uplink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Downlink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Uplink Default CS Type: Check whether this parameter is set to CS1.– Downlink Default CS Type: Check whether this parameter is set to CS2. If the

downlink GPRS TBF call drop rate is high, decrease the value for this parameter.If the parameter settings are incorrect, run the MML command SETGCELLEGPRSPARA to change the settings.

l Run the MML command LST GCELLEGPRSPARA to check whether Bep Periodis set to 5. If no, run the MML command SET GCELLPSPWPARA to change thevalue for this parameter to 5.

l Run the MML command LST GCELLSTANDARDOPTPARA to check the valuesfor the following parameters:– Maximum Value of N3101: Check whether the value for this parameter is larger

than or equal to 20.– Maximum Value of N3103: Check whether the value for this parameter is larger

than or equal to 3.– Maximum Value of N3105: Check whether the value for this parameter is larger

than or equal to 10.If the parameter settings are incorrect, run the MML command SETGCELLSTANDARDOPTPARA to change the settings.

3. For the top N cells with higher TBF call drop rates, check whether the value forRL9A08:Rate ofTransmitted Error Frames is larger than 1%. If the value is larger than 1%,bit errors have occurred during Abis transmission. In this case, contact transmissionengineers.

4. Check the causes of abnormal TBF releases. Abnormal TBF releases are generally causedby poor Um interface quality, lack of channel resources, or cell reselection.l If abnormal TBF releases are caused by poor Um interface quality, the values for the

following counters are large:



161

– A9006:Number of Uplink GPRS TBF Abnormal Releases due to N3101 Overflow(MS No Response)

– A9007:Number of Uplink GPRS TBF Abnormal Releases due to N3103 Overflow(MS No Response)

– A9206:Number of Uplink EGPRS TBF Abnormal Releases due to N3101 Overflow(MS No Response)

– A9207:Number of Uplink EGPRS TBF Abnormal Releases due to N3103 Overflow(MS No Response)

– A9106:Number of Downlink GPRS TBF Abnormal Releases due to N3105Overflow

– A9306:Number of Downlink EGPRS TBF Abnormal Releases due to N3105Overflow

l If abnormal TBF releases are caused by lack of channel resources, the values for thefollowing counters are large:– A9010:Number of Uplink GPRS TBF Abnormal Releases due to No Channel– A9210:Number of Uplink EGPRS TBF Abnormal Releases due to No Channel– A9109:Number of Downlink GPRS TBF Abnormal Releases due to No Channel– A9309:Number of Downlink EGPRS TBF Abnormal Releases due to No Channel

l If abnormal TBF releases are caused by cell reselection, the values for the followingcounters are large:– A9009:Number of Uplink GPRS TBF Abnormal Releases due to FLUSH– A9209:Number of Uplink EGPRS TBF Abnormal Releases due to FLUSH– A9108:Number of Downlink GPRS TBF Abnormal Releases due to FLUSH– A9308:Number of Downlink EGPRS TBF Abnormal Releases due to FLUSH

5. Troubleshoot abnormal TBF releases depending on the causes identified in Step 4.l Poor Um interface quality

Co-channel and adjacent-channel interference, frequency collision due to frequencyhopping (FH), or uplink and downlink imbalance may lead to RLC block decodingfailures and N3101/N3103/N3105 overflow, resulting in abnormal TBF releases. In thiscase, optimize the frequency planning, FH parameter settings, power control parametersettings, and transmit power settings. For details, see 5.3 Troubleshooting Call DropsDue to Poor Um Interface Quality.

l Lack of channel resources– Check whether any boards are faulty. If any boards are faulty, replace the boards.– Check the values for R9343:Number of Reclaimed Dynamic PDCHs and

R9344:Number of Reclaimed Busy Dynamic PDCHs. If the values for the twocounters are large, dynamic PDCHs have been preempted by CS services duringpeak hours. In this case, expand the BTS capacity.

l Cell reselectionCheck whether the cells and routing areas are properly planned. If no, replan them.


Typical CaseSymptom



162

The TBF call drop rate at a site increases by 3%.

Cause Analysis

Frequency interference and insufficient channel resources


1. Check that the parameters for the cells with high TBF call drop rates are set to recommendedvalues.


3. Analyze the counters reported by the field engineers. The causes of high TBF call droprates are as follows:l N3105 overflow

The Um interface quality is poor, which may cause interference.Check the interference band. Severe interference is detected. Check the frequencyplanning. ARFCN 7 experiences interference from a nearby BTS. The related TRX isconfigured with PDCHs.Change the ARFCN, the number of N3105 overflows decreases from several hundredtimes to about 30 times.

l Lack of channel resourcesThe values for R9343:Number of Reclaimed Dynamic PDCHs and R9344:Number ofReclaimed Busy Dynamic PDCHs for the problem cells are high. The reason is that calldrops occur when TBFs are transmitted over TCHs that are converted from dynamicPDCHs during peak hours.As a result, CS and PS channels are congested.

4. Expand the BTS capacity.

8.5 Troubleshooting Low Average Throughput at the RLCLayer

This section describes how to troubleshoot low average throughput at the radio link control(RLC) layer.

SymptomThe download rate is low. The values for the following counters do not meet the standard forlow average throughput at the RLC layer.l TL9333:Average Throughput of Downlink EGPRS RLCl TL9114:Average Throughput of Downlink GPRS RLCl TL9232:Average Throughput of Uplink EGPRS RLCl TL9014:Average Throughput of Uplink GPRS RLC

Background InformationThroughput is the amount of data transmitted per time unit. The higher the throughput, the higherthe PS transmission rate. The causes of low average throughput at the RLC layer are as follows:



163

l Insufficient radio resources, such as insufficient packet data traffic channels (PDTCHs),insufficient idle Abis timeslots and Gb bandwidth in time division multiplexing (TDM)transmission mode, and insufficient MSs multiplexed on a channel.

l Poor radio environment, such as poor Um interface quality, poor Abis transmission quality,and poor Gb transmission quality.

l Incorrect parameter settings, such as incorrect settings for PDCH Downlink MultiplexThreshold, Channel Type, and Bep Period.

l Low MS capabilities, such as low buffer capability, low packet assembly and disassemblycapability, low multislot capability, and low EGPRS service support capability.

Location ProcedureFigure 8-4 shows the procedure for locating low average throughput at the RLC layer.



164

Figure 8-4 Procedure for locating low average throughput at the RLC layer

Troubleshooting Procedure1. Check whether any cells meet the standard for low average throughput at the RLC layer.

l If yes, select the top N cells with lower average throughput at the RLC layer. Thefollowing operations should only be performed on the top N cells.

l If no, the following operations should be performed on all cells on the network.



165

2. Check whether the percentage of high-rate coding schemes to all coding schemes is low.

l If yes, increase the percentage of high-rate coding schemes to all coding schemes. Fordetails, see 8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes toAll Coding Schemes.


3. Check whether the related parameters are set correctly.

l If the EGPRS throughput is low, run the MML command LSTGCELLEGPRSPARA to check the values for the following parameters:

– Uplink Fixed MCS Type: Check whether this parameter is set to UNFIXED.

– Downlink Fixed MCS Type: Check whether this parameter is set to UNFIXED.

– Uplink Default MCS Type: Check whether the value for this parameter is largerthan or equal to MCS2.

– Downlink Default MCS Type: Check whether the value for this parameter is largerthan or equal to MCS6.


l If the GPRS throughput is low, run the MML command LST GCELLPSCS to checkthe values for the following parameters:

– Uplink Fixed CS Type: Check whether this parameter is set to UNFIXED.

– Downlink Fixed CS Type: Check whether this parameter is set to UNFIXED.

– Uplink Default CS Type: Check whether the value for this parameter is larger thanor equal to CS1.

– Downlink Default CS Type: Check whether the value for this parameter is largerthan or equal to CS2.


l Run the MML command LST GCELLEGPRSPARA to check whether Bep Periodis set to 5. If no, run the MML command SET GCELLPSPWPARA to change thevalue for this parameter to 5.

l Run the MML command LST GCELLPSCHM to query the value for Timer ofReleasing Abis Timeslot.

– If the value for Timer of Releasing Abis Timeslot is larger than 15, run the MMLcommand SET GCELLPSCHM to change the value for this parameter to 15.

– If the value for Timer of Releasing Abis Timeslot is smaller than or equal to 15,retain the value.

l Run the MML command LST GCELLPSCHM to query the value for PDCHDownlink Multiplex Threshold.

– If the value for PDCH Downlink Multiplex Threshold is larger than 80, run theMML command SET GCELLPSCHM to change the value for this parameter to80.

– If the value for PDCH Downlink Multiplex Threshold is smaller than or equal to80, retain the value.

l Run the MML command LST BSCPSSOFTPARA to check whether Allow E DownG Up Switch is set to Open. If yes, run the MML command SET



166

BSCPSSOFTPARA to change the value for Allow E Down G Up Switch to CLOSE(Close).

4. For the top N cells with lower average throughput at the RLC layer, check whether thevalue for RL9A08:Rate ofTransmitted Error Frames is larger than 1%. If yes, bit errorshave occurred during Abis transmission. In this case, contact transmission engineers.

5. Poor Um interface quality may lead to a low bit error probability (BEP). Poor Um interfacequality may be caused by co-channel or adjacent-channel interference, frequency collisiondue to frequency hopping (FH), or uplink and downlink imbalance. As a result, high-ratecoding schemes cannot be used, resulting in a decrease in the average throughput at theRLC layer. In this case, optimize the frequency planning, FH parameter settings, powercontrol parameter settings, and transmit power settings. For details, see 5.3Troubleshooting Call Drops Due to Poor Um Interface Quality.

6. If the percentage of high-rate coding schemes to all coding schemes and the number ofavailable packet data channels (PDCHs) increase, the average throughput at the RLC layerincreases. To prevent an increase in the RLC data retransmission rate and occupation ofmore transmission resources, change the values for the following parameters according tosite requirements.l Run the MML command SET GCELLPSCHM to increase the value for Maximum

Rate Threshold of PDCHs in a Cell.– Advantage: The number of available PDCHs increases.– Disadvantage: CS services occupy more PDCHs during peak hours and the

percentage of half-rate coding schemes increases, reducing the mean opinion score(MOS).

l Run the MML command SET BTSIDLETS to add idle Abis timeslots. The formulafor calculating the number of sufficient idle Abis timeslots is as follows: Number ofsufficient idle Abis timeslots = (Number of static PDCHs + Number of TCHFs) xMaximum Rate Threshold of PDCHs in a Cell x 3– Advantage: Idle Abis timeslots are sufficient and each timeslot uses the high-rate

coding scheme.– Disadvantage: Excessive transmission resources are occupied. In Flex Abis

networking mode, CS services are affected if excessive idle Abis timeslots are added.l Run the MML command SET BSCPSSOFTPARA to set Support USF Granularity

4 Switch to SUPPORT(Support).– Advantage: If USF granularity 4 is supported, only one data block needs to have its

coding scheme degraded from 8PSK to GMSK and the other three data blocks canstill use high-rate coding schemes, increasing the percentage of high-rate codingschemes to all coding schemes.

– Disadvantage: None.l Run the MML command SET GCELLPSCHM to set Level of Preempting Dynamic

Channel to LEVEL1(No preempt of CCHs).– Advantage: The number of abnormal temporary block flow (TBF) releases

decreases.– Disadvantage: CS channels may become congested.

l Run the MML command LST BSCPSSOFTPARA to set Level of PreemptingDynamic Channel to 15.– Advantage: The coding schemes can be adjusted quickly.– Disadvantage: The upload rate may decrease.



167


Typical Case

Symptom

The average throughput at the RLC layer decreases at a site after a network swap.

Cause Analysis

l High-rate coding schemes cannot be used due to poor Um interface quality.l High-rate coding schemes cannot be used due to insufficient idle Abis timeslots.


1. Check the settings of the parameters for the cells with low average throughput at the RLClayer. These parameters are set to recommended values.


3. Perform a drive test to obtain the Tems log and check the Um interface quality of thesecells. The Um interface quality of these cells is poor and the carrier-to-interference (C/I)ratio is low. After network optimization engineers improve the Um interface quality, theaverage throughput at the RLC layer in these cells returns to normal.

4. Query the number of idle Abis timeslots in these cells. The idle Abis timeslots in these cellsare insufficient. After more idle Abis timeslots are added, the average throughput at theRLC layer in these cells returns to normal.

8.6 Troubleshooting Low Percentage of High-Rate CodingSchemes to All Coding Schemes

This section describes how to troubleshoot low percentage of high-rate coding schemes to allcoding schemes.

Symptom

The percentage of high-rate coding schemes to all coding schemes indicates data transmissionperformance. If this percentage is low during web browsing, web pages open slowly or even failto open.


The percentage of EDGE high-rate coding schemes to all coding schemes refers to the ratio ofradio link control (RLC) data blocks that use coding schemes MCS7 through MSC9 (includingMSC6 at certain sites) to all data blocks.

The percentage of GPRS high-rate coding schemes to all coding schemes refers to the ratio ofRLC data blocks that use coding schemes CS3 and CS4 to all data blocks.

A high percentage of high-rate coding schemes to all coding schemes increases the transmissionrate but results in a high probability of retransmission too.

The causes of low percentage of high-rate coding schemes to all coding schemes are as follows:



168

l Poor Um interface qualityPoor Um interface quality may lead to a low bit error probability (BEP). In this case, high-rate coding schemes cannot be used.Poor Um interface quality may also lead to an automatic switchover to the LA mode, inwhich data blocks are segmented and retransmitted. In this case, the percentage of high-rate coding schemes to all coding schemes decreases.

l Insufficient idle Abis timeslots, which may affect the coding scheme adjustment. In thiscase, the percentage of high-rate coding schemes to all coding schemes and the transmissionrate significantly decrease.

l High frame error rates for Abis transmission, which may lead to loss and retransmission ofdata blocks. In this case, the percentage of high-rate coding schemes to all coding schemesdecreases.

l Abnormal temporary block flow (TBF) releases, which may lead to data transmission usinglow-rate coding schemes. In this case, the percentage of high-rate coding schemes to allcoding schemes decreases.

Location ProcedureFigure 8-5 shows the procedure for locating low percentage of high-rate coding schemes to allcoding schemes.



169

Figure 8-5 Procedure for locating low percentage of high-rate coding schemes to all codingschemes

Troubleshooting Procedure1. Check whether any cells meet the standard for low percentage of high-rate coding schemes

to all coding schemes.



170

l If yes, select the top N cells with low percentage of high-rate coding schemes to allcoding schemes. The following operations should only be performed on the top N cells.

l If no, the following operations should be performed on all cells on the network.2. Check whether the related parameters are set correctly.

l If the percentage of EGPRS high-rate coding schemes to all coding schemes is low, runthe MML command LST GCELLEGPRSPARA to check the values for the followingparameters:– Uplink Fixed MCS Type: Check whether this parameter is set to UNFIXED.– Downlink Fixed MCS Type: Check whether this parameter is set to UNFIXED.– Uplink Default MCS Type: Check whether the value for this parameter is larger

than or equal to MCS2.– Downlink Default MCS Type: Check whether the value for this parameter is larger

than or equal to MCS6.If the parameter settings are incorrect, run the MML command SETGCELLEGPRSPARA to change the settings.

l If the percentage of GPRS high-rate coding schemes is low, run the MML commandLST GCELLPSCS to check the values for the following parameters:– Uplink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Downlink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Uplink Default CS Type: Check whether the value for this parameter is larger than

or equal to CS1.– Downlink Default CS Type: Check whether the value for this parameter is larger

than or equal to CS2.If the parameter settings are incorrect, run the MML command SETGCELLEGPRSPARA to change the settings.

l Run the MML command LST GCELLPSCS to check whether the thresholds of theuplink and downlink TBF retransmission rates are set to recommended values. If no,run the MML command SET GCELLPSCS to set these parameters to recommendedvalues. For details about the recommended values, see the MML online help.

l Run the MML command LST GCELLPSCS to check whether Bep Period is set to5. If no, run the MML command SET GCELLPSPWPARA to change the value forBep Period to 5.

l Run the MML command LST GCELLPSCHM to query the value for Timer ofReleasing Abis Timeslot. If the value for Timer of Releasing Abis Timeslot is largerthan 15, run the MML command SET GCELLPSCHM to change the value for Timerof Releasing Abis Timeslot to 15.

l Run the MML command LST BSCPSSOFTPARA to check whether Allow E DownG Up Switch is set to Open. If yes, run the MML command SETBSCPSSOFTPARA to change the value for Allow E Down G Up Switch to CLOSE(Close).

3. For the top N cells with lower percentage of high-rate coding schemes to all coding schemes,check whether the value for RL9A08:Rate ofTransmitted Error Frames is larger than 1%.If yes, bit errors have occurred during Abis transmission. In this case, contact transmissionengineers.

4. Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be causedby co-channel or adjacent-channel interference, frequency collision due to FH, or uplinkand downlink imbalance. As a result, high-rate coding schemes cannot be used. In this case,



171

optimize the frequency planning, FH parameter settings, power control parameter settings,and transmit power settings. For details, see 5.3 Troubleshooting Call Drops Due to PoorUm Interface Quality.

5. Run the MML command LST BTSIDLETS to check whether idle Abis timeslotsconfigured for the BTS are sufficient.If Number of idle Abis timeslots ≥ (Number of static PDCHs + Number of TCHFs) xMaximum Rate Threshold of PDCHs in a Cell x 3, idle Abis timeslots are sufficient.If idle Abis timeslots are insufficient, run the MML command SET BTSIDLETS to addidle Abis timeslots.

6. Check whether there are a large number of abnormal TBF releases. If yes, see 8.4Troubleshooting High TBF Call Drop Rates.

7. Optimize the following parameters.

NOTE

To prevent an increase in the RLC data retransmission rate, change the values for the followingparameters according to site requirements.

l Run the MML command SET GCELLPSCHM to increase the value for MaximumRate Threshold of PDCHs in a Cell.– Advantage: The number of available PDCHs increases.– Disadvantage: CS services occupy more PDCHs during peak hours and the

percentage of half-rate coding schemes increases, reducing the mean opinion score(MOS).

l Run the MML command SET BSCPSSOFTPARA to set Support USF Granularity4 Switch to SUPPORT(Support).– Advantage: If USF granularity 4 is supported, only one data block needs to have its

coding scheme degraded from 8PSK to GMSK and the other three data blocks canstill use high-rate coding schemes, increasing the percentage of high-rate codingschemes to all coding schemes.

– Disadvantage: None.l Run the MML command SET GCELLPSCHM to set Level of Preempting Dynamic

Channel to LEVEL1(No preempt of CCHs).– Advantage: The number of abnormal TBF releases decreases.– Disadvantage: CS channels may become congested.

l Run the MML command LST BSCPSSOFTPARA to set Level of PreemptingDynamic Channel to 15.– Advantage: The coding schemes can be adjusted quickly.– Disadvantage: The upload rate may decrease.


Typical CaseSymptom

The percentage of high-rate coding schemes to all coding schemes used at the RLC layer is onlyabout 74% at a site.

Cause Analysis

High-rate coding schemes cannot be used due to insufficient idle Abis timeslots.



172


1. Check the settings of the parameters for the cells with low percentage of high-rate codingschemes to all coding schemes. These parameters are set to recommended values.


3. Check the traffic statistics about interference bands as well as uplink and downlink balancein these cells. The traffic statistics are normal.

4. Query the number of idle Abis timeslots in problem cells. The idle Abis timeslots in thesecells are insufficient. After more idle Abis timeslots are added, the percentage of high-ratecoding schemes to all coding schemes in these cells returns to normal.

8.7 Troubleshooting High RLC Data Block RetransmissionRates

This section describes how to troubleshoot high radio link control (RLC) data blockretransmission rates.

Symptom

The RLC data block retransmission rate indicates data transmission performance. If the RLCdata block retransmission rate is high or the percentage of high-rate coding schemes to all codingschemes is low during web browsing, web pages open slowly or even fail to open.


The RLC data block retransmission rate is the ratio of the number of retransmitted RLC datablocks to the total number of RLC data blocks. This rate is closely related to the percentage ofhigh-rate coding schemes to all coding schemes. If the percentage of high-rate coding schemesto all coding schemes increases, this rate may increase accordingly. Therefore, it is recommendedthat these two KPIs be compromised. High RLC data block retransmission rates are also causedby:

l Poor Um interface quality

Poor Um interface quality may lead to incorrect RLC data blocks received by MSs. In thiscase, the number of RLC data retransmissions increases.

Poor Um interface quality may also lead to an automatic switchover to the LA mode, inwhich data blocks are segmented and retransmitted. In this case, the percentage of high-rate coding schemes to all coding schemes decreases.

l High frame error rates for Abis transmission, which may lead to loss and retransmission ofdata blocks, decreasing the percentage of high-rate coding schemes to all coding schemes.

l Abnormally-released unacknowledged data blocks counted into the total number of datablocks

Location Procedure

Figure 8-6 shows the procedure for locating high RLC data block retransmission rates.



173

Figure 8-6 Procedure for locating high RLC data block retransmission rates

Troubleshooting Procedure1. Check whether any cells meet the standard for high RLC data block retransmission rates.

l If yes, select the top N cells with higher RLC data block retransmission rates. Thefollowing operations should only be performed on the top N cells.

l If no, the following operations should be performed on all cells on the network.

2. Check whether the related parameters are set correctly.

l If the EGPRS retransmission rate is high, run the MML command LSTGCELLEGPRSPARA to check the values for the following parameters:

– Uplink Fixed MCS Type: The recommended value is UNFIXED.

– Downlink Fixed MCS Type: The recommended value is UNFIXED.



174

– Uplink Default MCS Type: The recommended value is MCS2. If the uplinkEGPRS retransmission rate is high, decrease the value for this parameter.

– Downlink Default MCS Type: The recommended value is MCS6. If the downlinkEGPRS retransmission rate is high, decrease the value for this parameter.

If the parameters are not set to the recommended values, run the MML command SETGCELLEGPRSPARA to set the parameters to the recommended values.

l If the GPRS retransmission rate is high, run the MML command LST GCELLPSCSto check the values for the following parameters:– Uplink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Downlink Fixed CS Type: Check whether this parameter is set to UNFIXED.– Uplink Default CS Type: Check whether this parameter is set to CS1.– Downlink Default CS Type: Check whether this parameter is set to CS2. If the

downlink GPRS retransmission rate is high, decrease the value for this parameter.If the parameter settings are incorrect, run the MML command SETGCELLEGPRSPARA to change the settings.

l Run the MML command LST GCELLPSPWPARA to check the values for thefollowing parameters:– ALPHA: Check whether this parameter is set to 0.6.– GAMMA: Check whether this parameter is set to 12.If the parameter settings are incorrect, run the MML command SETGCELLPSPWPARA to change the settings.

3. For the top N cells with higher RLC data block retransmission rates, check whether thevalue for RL9A08:Rate ofTransmitted Error Frames is larger than 1%. If yes, bit errorshave occurred during Abis transmission. In this case, contact transmission engineers.

4. Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be causedby co-channel or adjacent-channel interference, frequency collision due to frequencyhopping (FH), or uplink and downlink imbalance. As a result, high-rate coding schemescannot be used. In this case, optimize the frequency planning, FH parameter settings, powercontrol parameter settings, and transmit power settings. For details, see 5.3Troubleshooting Call Drops Due to Poor Um Interface Quality.

5. Check whether there are a large number of abnormal temporary block flow (TBF) releases.If yes, see 8.4 Troubleshooting High TBF Call Drop Rates.


Typical CaseSymptom

The uplink retransmission rate at a site increased noticeably at 21:00 on January 2 and 13, 2011.

Cause Analysis

According to the traffic statistics, severe interference occurred in the cells with high uplinkretransmission rates at 21:00. All problem cells are P-GSM900 cells.


1. Check whether the parameters for the cells with high RLC data block retransmission ratesare set to recommended values. The parameter settings are correct.



175


3. Analyze the traffic statistics.The uplink RLC data block retransmission rate and the percentage of interference bands 4and 5 were high at 21:00 but normal at 20:00 and 22:00.

4. Locate the interference source.Dot the cells with severe interference on the map. The problem cells are located at countyboundaries.

5. Optimize the network. The Um interface quality becomes satisfactory and theretransmission rate problem is resolved.



176

9 PS Channel Faults

About This Chapter

This chapter describes how to locate and troubleshoot PS channel faults.

9.1 Identifying PS Channel FaultsThis section describes how to identify PS channel faults. You can identify PS channel faults bymonitoring the PS channel status on the LMT or querying the PS channel status using an MMLcommand.

9.2 Locating PS Channel FaultsThis section describes how to locate PS channel faults.

9.3 Troubleshooting PDCH Faults Due to Channel InactivityThis section describes how to troubleshoot packet data channel (PDCH) faults due to channelinactivity.

9.4 Troubleshooting PDCH Faults Due to Channel AsynchronizationThis section describes how to troubleshoot packet data channel (PDCH) faults due to channelasynchronization.

GBSS9.0Troubleshooting Guide 9 PS Channel Faults


177

9.1 Identifying PS Channel FaultsThis section describes how to identify PS channel faults. You can identify PS channel faults bymonitoring the PS channel status on the LMT or querying the PS channel status using an MMLcommand.

Monitoring the PS Channel Status on the LMTFor details, see Monitoring Channel Status.

Querying the PS Channel Status Using an MML CommandRun the MML command DSP PDCH to query the PS channel status of a cell. The PS channelswhose Channel Operation State is Unavailable are faulty.

9.2 Locating PS Channel FaultsThis section describes how to locate PS channel faults.

PrinciplesIf the packet data channels (PDCHs) of all cells under a BTS are faulty, check whether thetransmission and operating status of the BTS are normal. If the PDCHs of some cells underdifferent BTSs are faulty, check whether these cells are assigned to the same digital signalprocessor (DSP). If only certain PDCHs are faulty, refer to Troubleshooting PDCH FaultsDue to Channel Inactivity or Troubleshooting PDCH Faults Due to ChannelAsynchronization.

Location ProcedureFigure 9-1 shows the procedure for locating PS channel faults.



178

Figure 9-1 Procedure for locating PS channel faults

The procedure for locating PS channel faults is as follows:

1. Determine the fault range. If the PDCHs of all cells under a BTS are faulty, check whetherthe transmission and operating status of the BTS and its carriers are normal. If thetransmission and operating status of the BTS and its carriers are normal but the faults persist,go to Step 2.

2. Run the DSP PSCELL command to check whether the cells whose PDCHs are faulty areassigned to the same DSP based on the values of Subrack No., Slot No., and DSP No. inthe command output. If yes, run the SET PSCELLTODSP command to assign these cellsto DSPs carrying light load. If the faults persist, go to Step 3.



179

CAUTIONAssign the problem cells to different DSPs to ensure that the number of activated channelson one DSP does not exceed the upper threshold.

3. PS channel faults are generally due to either channel inactivity or channel asynchronization.For details about how to rectify these faults, see Troubleshooting PDCH Faults Due toChannel Inactivity and Troubleshooting PDCH Faults Due to ChannelAsynchronization.

9.3 Troubleshooting PDCH Faults Due to ChannelInactivity

This section describes how to troubleshoot packet data channel (PDCH) faults due to channelinactivity.

SymptomWhen monitoring the channel status is enabled on the LMT, the icon under a PDTCH of a cellis red. When you click on the red icon, detailed information about the channel status is displayed.If both Applied Bandwidth and Available Bandwidth are 0K as shown in Figure 9-2, thechannel is not activated.

Figure 9-2 Monitor Channel Status tab page

Background InformationThe most common causes for PDCH faults due to channel inactivity are as follows:l Cell Um Administration State is Blocked.l PS cells have not been assigned to a digital signal processor (DSP) and therefore do not

work properly.l The number of activated channels on the DSP where the cells work has reached the upper

threshold.l The low voltage differential signal (LVDS) timeslots on the DSP where the cells work are

insufficient.



180

NOTEOne DPUP is configured with 22 DSPs, where 21 DSPs are configured with 192 LVDS timeslotseach and one DSP is configured with 48 LVDS timeslots. Therefore, you need to query the DSP linkstatus to determine whether the LVDS timeslots on a DSP are sufficient.

The method for determining which DSP has the lightest load is as follows:l Run the MML command DSP DSPLINK to query the status of the LVDS timeslots.l Calculate the number of LVDS timeslots whose Loop State is No Loopback, Allocate

State is Normal and Not Assigned, and Sync State is Synchronized for each DSP. TheDSP with the greatest number of LVDS timeslots with these parameter settings has thelightest load.

Location ProcedureFigure 9-3 shows the procedure for locating PDCH faults due to channel inactivity.



181

Figure 9-3 Procedure for locating PDCH faults due to channel inactivity

Troubleshooting Procedure1. Run the MML command DSP PSCELL to query whether the cells whose PDCHs are faulty

are properly assigned to a DSP. If Subrack No., Slot No., and DSP No. are all 255 in thecommand output, these cells are not properly assigned to a DSP. Run the MML commandSET PSCELLTODSP to assign these cells to a DSP with a light load.

2. Run the MML command DSP PSCELL to check whether Cell Um AdministrationState is Blocked. If yes, refer to ALM-21801 GSM Cell out of Service.

3. Check whether the number of activated channels on the DSP has reached the upperthreshold. If yes, run the MML command SET PSCELLTODSP to assign the cells whosePDCHs are faulty to a DSP with a light load.



182

NOTETo check whether the number of activated channels on a DSP has reached the upper threshold,perform the following steps:

1. Run the MML command DSP PSCELL to query Subrack No., Slot No., and DSP No. of thecells whose PDCHs are faulty.

2. Run the MML command DSP PDCHNUM to check whether Number of Active Channels ofthe DSP is 48. If yes, the number of activated channels on the DSP has reached the upperthreshold.

4. The LVDS timeslots on the DSP configured with 48 LVDS timeslots tend to be insufficient.To determine whether the LVDS timeslots on a DSP are insufficient, perform the followingsteps:

(1) Run the MML command DSP PSCELL to query Subrack No., Slot No., and DSPNo. of the cells whose PDCHs are faulty.

(2) Run the MML command DSP DSPLINK. If the DSP is configured with 48 LVDSlinks and the DSP does not have an LVDS timeslot whose Allocate State is Normaland Not Assigned, the LVDS timeslots on the DSP are insufficient.

(3) Run the MML command SET PSCELLTODSP to assign the cells whose PDCHsare faulty to a DSP with a light load.

5. If the faults persist, Contact Huawei Customer Service Center.

Typical CaseSymptom

Some PDCHs of a cell at a site are faulty.

Cause Analysis

The number of activated channels on the DSP has reached the upper threshold.


1. Query the cell status. The cell is normal.2. Check the channel status. Applied Bandwidth and Available Bandwidth are both 0K.3. Query the DSP where the cell works and the number of static channels on the DSP. The

number of static channels on the DSP exceeds 48.4. Manually assign the cell to a DSP with a light load. The channels of the cell are activated

and the PDCH faults are rectified.

9.4 Troubleshooting PDCH Faults Due to ChannelAsynchronization

This section describes how to troubleshoot packet data channel (PDCH) faults due to channelasynchronization.

SymptomThe query result for the channel status on the LMT is normal. If you refresh the query result,you may find that some faulty PDCHs sometimes automatically correct themselves. When PSservices are being processed, uploading and downloading data may be interrupted and someping packets may be lost. If a PDCH is faulty, detailed information about the channel status is



183

displayed when you click the red icon under the PDCH. If Applied Bandwidth is inconsistentwith Available Bandwidth as shown in Figure 9-4, the PDCH fault is caused by channelasynchronization.

Figure 9-4 Monitor Channel Status tab page

Background InformationTo check whether the DTMU clock synchronizes with the BSC clock and to lock the BSC clock,perform the following steps:

1. On the LMT, choose Device Maintenance > BSC Maintenance > Query BSC BoardClockStatus, as shown in Figure 9-5.If Phase-locked loop state of clock source is Lock, the DTMU clock synchronizes withthe BSC clock.

Figure 9-5 Querying the status of the BSC clock

2. If the DTMU clock does not synchronize with the BSC clock, check historical and active

alarms for clock alarms. If there is a clock alarm, clear it by referring to the alarm help.The clock alarms are as follows:



184

l ALM-20204 Clock Signal Inputs Faultyl ALM-20209 Faulty Phase-Locked Loop of the Board Clockl ALM-20208 Clock Reference Source of Main Control Board Unavailablel ALM-20207 Failure in Locking System Clock Sourcel ALM-20206 Current System Clock Reference Source Status Abnormal

3. On the LMT, choose Device Maintenance > BSC Maintenance > Query BSC BoardClock Status and select a BTS to query the DTMU clock status, as shown in Figure 9-6.If Clock Status is Locked, the BSC clock is locked.

Figure 9-6 Querying the status of the DTMU clock

4. If the BSC clock is not locked, run the MML command SET BTSCLKPARA to set Clock

Mode to BSCCLK(Trace BSC Clock).5. If the BSC clock cannot be locked for a long time (for example, one day), replace the

DTMU.

Location ProcedureFigure 9-7 shows the procedure for locating PDCH faults due to channel asynchronization.



185

Figure 9-7 Procedure for locating PDCH faults due to channel asynchronization

Troubleshooting Procedure1. Check whether the BTS version is the latest one. If no, upgrade the BTS to the latest version.

If the faults persist, go to Step 2.2. Query traffic statistics by referring to RL9A08:Rate of Transmitted Error Frames. If the

frame error rate (FER) is higher than 1%, troubleshoot transmission faults. If the PDCHfaults persist, go to Step 3.

3. Check whether the DTMU clock synchronizes with the BSC clock by referring toBackground Information. If yes, go to Step 4. If no, lock the BSC clock according to theinstructions in Background Information.

4. If the PDCH faults persist, Contact Huawei Customer Service Center.

Typical CaseSymptom

According to the channel status on the LMT at a site, some PDCHs are faulty. After the queryresult is refreshed, the channel status returns to normal.



186

Cause Analysis

The E1 cables are faulty.


1. Check the BTS version at the site. The BTS version is not one of the BTS versions thathave asynchronization problems.

2. Query traffic statistics. The FER over the Abis interface is high and the LAPD Link InterruptAlarm is reported.

3. Troubleshoot transmission faults and replace the E1 cables. The PDCH faults are rectified.



187

10 Cell PS Service Faults

About This Chapter

This chapter describes how to locate and troubleshoot cell PS service faults.

10.1 Remarks on Cell PS Service FaultsIn this chapter, cell PS service faults refer to failures to provide PS services for all subscribersin a cell. If a cell fails to provide PS services for some subscribers, the MSs used by thesesubscribers are probably incompatible with the network. Cell PS service faults of this type canbe rectified with tracing signaling and are not discussed in this document.

10.2 Locating Cell PS Service FaultsThis section describes how to locate cell PS service faults.

10.3 Troubleshooting Cell PS Service Faults Due to Incorrect Data ConfigurationsThis section describes how to troubleshoot cell PS service faults due to incorrect dataconfigurations.

10.4 Troubleshooting Cell PS Service Faults Due to Hardware IssuesThis section describes how to troubleshoot cell PS service faults due to hardware issues.

10.5 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSCThis section describes how to troubleshoot cell PS service faults due to incorrect cableconnections inside the BSC.

10.6 Troubleshooting Cell PS Service Faults Due to Gb Interface IssuesThis section describes how to troubleshoot cell PS service faults due to Gb interface issues.

GBSS9.0Troubleshooting Guide 10 Cell PS Service Faults


188

10.1 Remarks on Cell PS Service FaultsIn this chapter, cell PS service faults refer to failures to provide PS services for all subscribersin a cell. If a cell fails to provide PS services for some subscribers, the MSs used by thesesubscribers are probably incompatible with the network. Cell PS service faults of this type canbe rectified with tracing signaling and are not discussed in this document.

PS services are mobile packet data services developed on the basis of the GSM mobilecommunications system. Packet switched entities are added to the GSM mobile communicationssystem to implement data transmission in packet mode, enabling subscribers to access theInternet or other packet data networks by using mobile terminals that support packet dataservices.

Cells require the following resources to perform PS services: transmission resources, packet datachannels (PDCHs), digital signal processors (DSPs), and Gb interface resources. Cell PS serviceswill fail if any of these resources are unavailable or insufficient.

10.2 Locating Cell PS Service FaultsThis section describes how to locate cell PS service faults.

PrinciplesSignaling tracing is commonly used to locate cell PS service faults. With tracing signaling, youcan locate the points where cell PS services are congested. Before tracing signaling, you cantroubleshoot the following problems or faults to locate cell PS service faults:

1. Incorrect data configurations2. Hardware faults3. Incorrect cable connections inside the BSC4. Gb interface faults

Location ProcedureFigure 10-1 shows the procedure for locating cell PS service faults.



189

Figure 10-1 Procedure for locating cell PS service faults

10.3 Troubleshooting Cell PS Service Faults Due to IncorrectData Configurations

This section describes how to troubleshoot cell PS service faults due to incorrect dataconfigurations.

SymptomAll or some of the cells under a BSC fail to provide PS services.

Background InformationIn addition to the basic parameters for PS services, pay attention to the following configurations:l Um Interface Tag, Abis Interface Tag, and A Interface Tagl The mapping between IPPATH and TRMMAP in Abis over IP mode



190

Location Procedure

Figure 10-2 shows the procedure for locating cell PS service faults due to incorrect dataconfigurations.

Figure 10-2 Procedure for locating cell PS service faults due to incorrect data configurations

Troubleshooting Procedure1. If all the cells under a BSC fail to provide PS services, run the MML command LST

BSCBASIC to check whether A Interface Tag, Um Interface Tag, and Abis InterfaceTag are all GSM_PHASE_2. If no, run the MML command SET BSCBASIC to modifythe parameter settings.

2. If some IP BTSs under a BSC fail to provide PS services, perform the following operationsto check whether the settings of IPPATH and TRMMAP are correct:

(1) Run the MML command LST ADJNODE to query Adjacent Node ID.

(2) Based on Adjacent Node ID, run the MML command LST IPPATH to query IPpath type for all IP paths. If no IP path type is QOS, go to Step c. Otherwise, go toStep 3.

(3) Run the MML command LST TRMMAP to query PS high PRI data path and PSlow PRI data path.

(4) Check whether the query results of PS high PRI data path and PS low PRI datapath contain IP path type. If neither PS high PRI data path nor PS low PRI datapath contains IP path type, run the MML command ADD TRMMAP to add IP pathtype.

3. If the cell PS service faults persist, refer to 10.4 Troubleshooting Cell PS Service FaultsDue to Hardware Issues.



191

Typical CaseSymptom

All the cells under a BSC fail to provide PS services.

Cause Analysis

The SI13 message cannot be delivered because the Um interface tag at the BSC level has beenmodified. As a result, the PS services fail.


1. View the operation logs. GSM Phase has been modified. The records in the operation logsare as follows:Y2011M03D16H09N39S20], [ Y2011M03D16H09N39S21], [/*252862*/SET BSCBASIC: AREACODE=1, CC=1, AVER=GSM_PHASE_1, UMVER=GSM_PHASE_1, ABISVER=GSM_PHASE_1, SUPPORTTFOCODECOPTIMIZE=NO;], [Execution succeeded.]

2. Modify Um Interface Tag, Abis Interface Tag and A Interface Tag. The faults arerectified.

10.4 Troubleshooting Cell PS Service Faults Due toHardware Issues

This section describes how to troubleshoot cell PS service faults due to hardware issues.

SymptomCells that fail to provide PS services are assigned to the same digital signal processor (DSP) andboard fault alarms are reported.

Background InformationCS service faults caused by hardware issues are not discussed in this section. The following arethe hardware faults that affect PS services:l DPUd faultsl Gb interface board faultsl DSP faults

Location ProcedureFigure 10-3 shows the procedure for locating cell PS service faults due to hardware issues.



192

Figure 10-3 Procedure for locating cell PS service faults due to hardware issues

Troubleshooting Procedure1. Check whether the DPUd, FG2a, FG2c, and PEUa report any board fault alarms such as

ALM-20241 Board Unavailable, ALM-20242 Board Subsystem Unavailable, andALM-20243 Board Hardware Fault. If yes, clear the alarms by referring to the alarm help.

2. If no, run the MML command DSP PSCELL to check whether PS services fail in othercells assigned to the same DSP as the problem cell. If the following conditions are met, theDSP is faulty: 1) All the cells assigned to the DSP fail to provide PS services; 2) After thesecells are assigned to other DSPs by running the MML command SET PSCELLTODSP,the cells can provide PS services properly.

3. Run the MML command INH DSP to disable the faulty DSP. If multiple DSPs are faulty,replace the DPUd to reduce the impact on the services of other cells.

4. If the faults persist, refer to 10.5 Troubleshooting Cell PS Service Faults Due to IncorrectCable Connections Inside the BSC.

Typical Case

Symptom

Some cells fail to provide PS services at a site.

Cause Analysis

DSP 10 in slot 8 of subrack 0 is faulty.


1. View the alarm logs. No board alarms are reported.



193

2. Run the MML command DSP PSCELL. All problem cells are assigned to DSP 10 in slot8 of subrack 0 and all cells assigned to that DSP fail to provide PS services.

3. Run the MML command SET PSCELLTODSP to assign all problem cells to other DSPs.These cells can provide PS services again. If these cells are reassigned to DSP 10 in slot 8of subrack 0, they fail to provide PS services again. Therefore, DSP 10 in slot 8 of subrack0 is faulty.

4. Run the MML command INH DSP to disable the faulty DSP because there is no spareDPUd at the site. The faults are rectified.

10.5 Troubleshooting Cell PS Service Faults Due to IncorrectCable Connections Inside the BSC

This section describes how to troubleshoot cell PS service faults due to incorrect cableconnections inside the BSC.

Symptom

Some cells fail to provide PS services.


The Abis interface board and the DPUd board serving the same cell may be installed in differentsubracks because DPUb boards work as a resource pool. If cable connections between subracksare abnormal, some cells fail to provide PS services.

Location Procedure

Figure 10-4 shows the procedure for locating cell PS service faults due to incorrect cableconnections inside the BSC.

Figure 10-4 Procedure for locating cell PS service faults due to incorrect cable connectionsinside the BSC



194

Troubleshooting Procedure1. Run the MML command DSP LINKBTNUTNU to check whether Link Status is

Normal. If no, check that the cables between subracks are connected correctly and securely.If Link Status is Normal, go to Step 2.

2. Run the MML command DSP PSCELL to query Subrack No. of the subrack that servesthe problem cells. All the problem cells are assigned to a DSP on the subrack. Run theMML command LST GTRX to query Out-BSC Subrack No., which specifies the numberof the subrack accommodating the Abis interface board. Check whether the values ofSubrack No. and Out-BSC Subrack No. are the same. If no, run the MML commandSET PSCELLTODSP to assign the problem cells to the DSP on the subrackaccommodating the Abis interface board. If the subrack numbers are the same but PSservices still fail, refer to 10.6 Troubleshooting Cell PS Service Faults Due to GbInterface Issues.

Typical Case

Symptom


Cause Analysis

The cable connection between port 0 in slot 5 of subrack 0 and port 0 in slot 4 of subrack 1 isabnormal.


1. Analyze the Abis interface board and service board serving the problem cells. The Abisinterface board is in subrack 1 and the service board is in subrack 0.

2. Run the MML command DSP LINKBTNUTNU to check the cable connections betweensubrack 1 and subrack 0. The cable connection between port 0 in slot 5 of subrack 0 andport 0 in slot 4 of subrack 1 is abnormal.

3. Troubleshoot the cable connection faults in the equipment room. The cable to port 0 in slot5 of subrack 0 is loose.

4. Tighten the cable. The cable connections between subrack 1 and subrack 0 return to normaland the faults are rectified.

10.6 Troubleshooting Cell PS Service Faults Due to GbInterface Issues

This section describes how to troubleshoot cell PS service faults due to Gb interface issues.

Symptom

Cells fail to provide PS services and Cell Gb Administration State is Blocked in the output ofthe MML command DSP PSCELL.


Cell PS service faults are sometimes caused by the following issues with the Gb interface:



195

l The Gb interface is faulty and bearer channel (BC), network server virtual connection/link(NSVC/NSVL), network service entity (NSE) fault alarms are reported.

l The Gb interface is normal but the SGSN does not respond to some GPRS mobilitymanagement (GMM) signaling.

Location ProcedureFigure 10-5 shows the procedure for locating PS service faults due to Gb interface issues.

Figure 10-5 Procedure for locating cell PS service faults due to Gb interface issues

Troubleshooting Procedure1. Run the MML command DSP PSCELL. If Cell Gb Administration State is Blocked,

Cell Activation State is Active, Cell Operation State is Unblocked, and Cell UmAdministration State is Unblocked, the cell PS service faults are caused by Gb interfaceissues.

2. Clear the following Gb interface alarms by referring to the alarm help:l ALM-21385 Gb BC Failurel ALM-22005 NSE Faultyl ALM-22003 NSVC Disconnectionl ALM-22004 NSVL Faultyl ALM-22009 NSVL Dynamic Configuration Procedure Failurel ALM-22008 PTP BVC Faulty

3. If the faults persist, Contact Huawei Customer Service Center.

Typical CaseSymptom


Cause Analysis

The NSVC is interrupted because the data configuration on the BSC is inconsistent with that onthe SGSN.



196


1. Run the MML command DSP PSCELL. The Cell Gb Administration State in thecommand output is Blocked.

2. Check for BC, NSVC, and NSE fault alarms on the BSC. The alarm ALM-22003 NSVCDisconnection is reported.

3. Refer to the alarm help. The alarm is reported because the data configuration on the BSCis inconsistent with that on the SGSN.

4. Modify the data configurations to ensure that the data configuration is consistent on boththe BSC and the SGSN. The NSVC interruption alarm is cleared.

5. Run the MML command DSP PSCELL. The Cell Gb Administration State in thecommand output is Unblocked.

6. The faults are rectified.



197

11 IP Transmission Faults

About This Chapter

This chapter describes how to locate and troubleshoot IP transmission faults.

11.1 Troubleshooting FE/GE Transmission FaultsThis section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE)transmission faults.

11.2 Troubleshooting IP Layer FaultsThis section describes how to troubleshoot IP layer faults.

11.3 Troubleshooting PPP or MLPPP Link FaultsThis section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Point-to-Point Protocol (MLPPP) link faults.

11.4 Troubleshooting LAPD Link FaultsThis section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) linkfaults.

11.5 Troubleshooting SCTP Link FaultsThis section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) linkfaults.

11.6 Troubleshooting IP Path ProblemsThis section describes how to troubleshoot IP path problems.

11.7 Troubleshooting DHCP ProblemsThis section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP)problems.

11.8 Troubleshooting IP PM Activation FailuresThis section describes how to troubleshoot IP performance monitor (IP PM) activation failures.

11.9 Troubleshooting IP Clock FaultsThis section describes how to troubleshoot IP clock faults.

GBSS9.0Troubleshooting Guide 11 IP Transmission Faults


198

11.1 Troubleshooting FE/GE Transmission FaultsThis section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE)transmission faults.

Symptoml When FE/GE transmission faults occur, packets may be lost or no packets may be received

by the RX end, and the alarms in Table 11-1 may be reported.

Table 11-1 Alarms related to FE/GE transmission faults

Alarm ID Alarm Name

21345 ALM-21345 Ethernet Link Fault

21346 ALM-21346 IP Connectivity CheckFailure

21347 ALM-21347 IP Address Conflict

21351 ALM-21351 IP Excessive Frame ErrorRate

l When FE/GE transmission faults occur, the query result of the MML command DSP

ETHPORT shows that Link Availability Status is Unavailable.l There are two types of FE/GE transmission faults:

– Physical layer faultsThe faults at the physical layer are generally caused by hardware faults. For example,an Ethernet cable is faulty or Ethernet ports on two interconnected devices are faulty.

– Data link layer faultsThe faults at the data link layer are generally caused by incorrect VLAN IDs or transportnetwork interruption.

Background Informationl Port interworking parameters

The port interworking parameters are ETHPORT SPEED and Auto negotiation. Theirrespective settings for both interconnected ports must be consistent based on negotiation.For example, ETHPORT SPEED for both interconnected ports must be set to either100M or AUTO, and the settings of Duplex for both interconnected ports must also beconsistent. Table 11-2 lists the recommended values for the two parameters.

Table 11-2 Recommended values for the ETHPORT SPEED and Duplex parameters

ETHPORT SPEED Duplex

Recommended value 1 FE port: 100M; GE port:1000M

FULL



199

ETHPORT SPEED Duplex

Recommended value 2 FE port: 100M; GE port:1000M

AUTO

Recommended value 3 AUTO AUTO

Run the MML commands DSP ETHPORT and LST ETHPORT to check whether thesettings of the port interworking parameters, especially ETHPORT SPEED and Duplex,are consistent for the two interconnected ports.

l Address Resolution Protocol (ARP)The BSC and BTS have the same procedure for processing data packets. The BSC or BTSfirst queries the next-hop media access control (MAC) address according to the mappingbetween the IP routing table and the ARP table, and then sends the ICMP, SCTP, or UDPpackets. If there is no corresponding ARP table, the BSC or BTS sends an ARP request toquery the next-hop MAC address or the peer IP address on the Layer 2 (L2) network. Figure11-1 shows the procedure for sending an ARP request.

Figure 11-1 Procedure for sending an ARP request

NOTE

l An ARP request is a type of broadcast packet transmitted between two L2 communication nodes.

l On the L2 network, the BSC and BTS send each other ARP requests. On the Layer 3 (L3) network,the BSC and BTS send ARP requests to their respective gateways.

Location Procedurel Physical layer faults

Figure 11-2 shows the procedure for locating physical layer faults.



200

Figure 11-2 Procedure for locating physical layer faults

l Data link layer faults

Figure 11-3 shows the procedure for locating data link layer faults.



201

Figure 11-3 Procedure for locating data link layer faults

Troubleshooting Procedurel Physical layer faults

1. Check whether the Ethernet cable is normal. For example, the maximum transmissiondistance of an Ethernet cable is 100 m. If the Ethernet cable is defective, replace itand check whether the alarms related to FE/GE transmission faults are cleared. If anoptical fiber is used to connect two ports, check whether the optical modules in usemeet the specifications. For example, a 100 Mbit/s optical module is not applicableto a 1000 Mbit/s port. Replace any optical modules that do not meet the specificationsand check whether the alarms related to FE/GE transmission faults are cleared. If thealarms persist, go to Step 2.

2. Run the MML commands DSP ETHPORT and LST ETHPORT to check whetherthe settings of the port interworking parameters, especially ETHPORT SPEED andDuplex, for the two interconnected ports are consistent. If the settings are inconsistent,correct them and check whether the alarms related to FE/GE transmission faults arecleared. If the alarms persist, go to Step 3.

3. Check whether the two interconnected ports are normal by using either of thefollowing fault isolation methods:

(1) Connect a PC to the Ethernet port of the BSC or BTS and check whether thephysical layer faults are rectified.

(2) Connect a PC to the peer device and check whether the PC indicator that showsthe Ethernet cable connection status is ON.



202

NOTE

If the alarms related to FE/GE transmission faults are cleared but the PC indicator is OFF, thepeer port is faulty.

If the alarms related to FE/GE transmission faults persist but the PC indicator is ON, errorsmay have occurred on the BSC or BTS. If errors occurred on the BSC, switch over the IPinterface boards. If errors occurred on the BTS, replace the faulty interface board.

If the alarms related to FE/GE transmission faults are cleared and the PC can power on properly,the port of the BSC or BTS and the peer ports are incompatible. Check whether the portinterworking parameter settings for the two interconnected ports are consistent. Correct anyinconsistent settings and check whether the alarms related to FE/GE transmission faults arecleared.

4. If the alarms persist, Contact Huawei Customer Service Center.l Data link layer faults

1. Run the MML command DSP ARP to check whether there is an ARP tablecorresponding to the next-hop IP address. If there is, the connection between the BSCand the peer device is normal. Check whether the connection between the peer deviceand the next hop is normal. If the connection is not normal, go to Step 2.

2. Run the MML commands DSP ETHVLAN and DSP ETHPORT to query thenumber of data packets received and sent on the BSC port twice at a 3s interval, andrecord the query results. On the local maintenance terminal (LMT), ping the peer IPaddress and run the MML command DSP ARP to check whether there is an ARPtable corresponding to the next-hop IP address. If there is no ARP table correspondingto the next-hop IP address, the faults occur because the corresponding ARP table failsto be generated. Run the MML commands DSP ETHVLAN and DSP ETHPORTagain to query the number of data packets received and sent on the BSC. Comparethis query result with the preceding query results to check whether the number of datapackets received and sent on the BSC port increased. If it increased, go to Step 3. Ifnot, go to Step 4.

3. Have the peer device maintenance engineers check whether VLAN ID has been seton the BSC side.– If it has, check whether VLAN ID is correctly set. If the setting is incorrect, change

the parameter value and check whether the alarms related to FE/GE transmissionfaults are cleared. If the alarms persist, go to Step 4.

– If not, have the peer device maintenance engineers check whether the peer IPaddress is set correctly. If the setting is incorrect, change the peer IP address toensure that the BSC can communicate with the peer device properly.

4. If the data link layer faults persist, Contact Huawei Customer Service Center.

Typical CaseSymptom

Ongoing services become abnormal after A over IP reconstruction.

Cause Analysisl The data configurations may be incorrect.l The FE/GE transmission may fail.


1. Query the data configurations. The data configurations are correct.



203

2. View the alarm information and check the Ethernet cable. The alarm ALM-21345 EthernetLink Fault was reported, but the Ethernet cable is functional.

3. Run the MML command DSP ETHPORT to query the status of the Ethernet port on theBSC side. The query result shows that Duplex is set to Half and Auto negotiation is setto Enable. Therefore, the working mode of the peer port may be configured in forciblemode.

4. Query the status of the peer port. The result shows that Duplex is set to FULL andETHPORT SPEED is set to 100M. After Duplex is set to the same value for the twointerconnected ports, ongoing services return to normal.

11.2 Troubleshooting IP Layer FaultsThis section describes how to troubleshoot IP layer faults.

SymptomWhen the IP layer is faulty, the destination IP address cannot be pinged and the alarms in Table11-3 may be reported.

Table 11-3 Alarms related to IP layer faults

Alarm ID Alarm Name

21345 ALM-21345 Ethernet Link Fault

21581 ALM-21581 Path Fault

Background Informationl IP route

Each host or gateway has a routing table that specifies the routes to the destination IPaddress. When sending a packet, a host, gateway, or router can obtain a route to thedestination IP address of this packet by checking the corresponding routing table.A routing table consists of the destination IP address and the next-hop IP address.In a routing table, routes are classified into the following types:– Default route: This route is automatically selected when other routes specified in a

routing table are unreachable.– Indirect route: The next hop of this route is a router.– Direct route: The next hop of this route is the destination host.

Location ProcedureFigure 11-4 shows the procedure for locating IP layer faults.



204

Figure 11-4 Procedure for locating IP layer faults

Troubleshooting Procedure1. Run the MML command PING IP to check whether the destination IP address can be

pinged. If it cannot be pinged, go to Step 2.

2. Run the MML commands DSP IPRT and LST IPRT to query the route information. Ifthere is no routing table corresponding to the destination IP address, manually configure aroute to the destination IP address and check whether the alarms related to IP layer faultsare cleared. If the alarms persist, go to Step 3.

3. Run the MML command DSP ARP to check whether there is an ARP table correspondingto the destination IP address. If not, refer to Procedure for locating data link layerfaults in section 11.1 Troubleshooting FE/GE Transmission Faults. Then check whetherthe alarms related to IP layer faults are cleared. If the alarms persist, go to Step 4.

4. Run the MML command TRC IPADDR to confirm how many hops are required for aroute from the source IP address to the destination IP address and to determine at whichhop the route is interrupted. Have the transmission maintenance engineers resolve the



205

problem and check whether the alarms related to IP layer faults are cleared. If the alarmspersist, go to Step 5.

5. Capture relevant packets and Contact Huawei Customer Service Center.

Typical CaseSymptom

Transmission links fail to be set up after the A over IP and signaling data configurations arecomplete.

Cause Analysis

1. The BSC boards may be faulty.2. The data configurations may be incorrect.


1. Query the data configurations and alarm information for the BSC boards. The dataconfigurations are complete and correct, and no boards report hardware alarms.

2. Have the MSC maintenance engineers check the port interworking parameters. The settingsof these parameters are correct.

3. Ping the IP address of the MSC on the BSC side. The IP address of the MSC cannot bepinged.

4. Run the MML command TRC IPADDR to query the route information. A router is notforwarding packets.

5. Determine that relevant routes are not configured on the router. After a route to thedestination IP address is configured, transmission links can be set up successfully.

11.3 Troubleshooting PPP or MLPPP Link FaultsThis section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Point-to-Point Protocol (MLPPP) link faults.

Symptoml When a PPP or MLPPP link is faulty, the link status is abnormal and the alarms in Table

11-4 may be reported.

Table 11-4 Alarms related to PPP or MLPPP link faults

Alarm ID Alarm Name

11342 ALM-11342 PPP Link Excessive FrameError Rate

21343 ALM-21343 PPP/MLPPP Link Fault

21344 ALM-21344 MLPPP Group Failure

l When a PPP or MLPPP link is faulty, the query result of the MML command DSP

PPPLNK or DSP BTSPPPLNK shows that Link state is set to DOWN.



206

Background Informationl PPP

PPP is a link layer protocol that supports point-to-point data transmission on full-duplexsynchronous and asynchronous links. It is located at Layer 2 of the IP protocol stack.In the Huawei BSS system, the PPP technology is used for transmission on the Abisinterface in IP over E1 mode.

l MLPPPMLPPP is an extensible protocol that supports binding multiple PPP links into a logicalchannel, which helps to increase bandwidth. These PPP links belong to an MP group andthis logical channel is an MLPPP link.In the Huawei BSS system, the MP technology is used for transmission on the Abis interfacein IP over E1 mode.

Location ProcedureFigure 11-5 shows the procedure for locating PPP or MLPPP link faults.

Figure 11-5 Procedure for locating PPP or MLPPP link faults

Troubleshooting Procedure1. Query the alarm information to check whether E1/T1 transmission is normal. If any of the

alarms listed in Table 11-5 are reported, clear them by referring to the BSC6900 GSMAlarm Reference. If none of the alarms are reported, go to Step 2.



207

Table 11-5 Alarms related to E1/T1 transmission faults

Alarm ID Alarm Name

4714 ALM-4714 E1/T1 Local Alarm

4716 ALM-4716 E1/T1 Remote Alarm

20201 ALM-20201 1PPS State Abnormal

20202 ALM-20202 Time Information ReceptionAbnormal

20203 ALM-20203 Clock Signal Outputs Faulty

20204 ALM-20204 Clock Signal Inputs Faulty

20205 ALM-20205 System Clock ReferenceSource Unavailable

20206 ALM-20206 Current System ClockReference Source Status Abnormal

20207 ALM-20207 Failure in Locking SystemClock Source

20208 ALM-20208 Clock Reference Source ofMain Control Board Unavailable

20209 ALM-20209 Faulty Phase-Locked Loop ofthe Board Clock

2. Query data configurations for PPP or MLPPP links.

l Run the MML command LST PPPLNK or LST BTSPPPLNK to query dataconfigurations for PPP links.

l Run the MML command LST MPLNK or LST BTSMPLNK to query dataconfigurations for MLPPP links.

l If the BTS communicates with the BSC using a router, run the MML command LSTBTSPPPLNK or LST BTSMPLNK to query data configurations for PPP or MLPPPlinks. Then, query the related PPP or MLPPP parameters on the router, such as the PPPnegotiation duration and check format.

If the data configurations are incorrect, correct them and check whether the alarms relatedto PPP or MLPPP link faults are cleared. If the alarms persist, go to Step 3.

3. On the LMT, click Monitor. The Monitor tab page is displayed. In the MonitorNavigation Tree pane, choose Monitor > Common Monitoring > Link PerformanceMonitoring and select the PPP link or MLPPP link whose traffic can be monitored in realtime. Compare the traffic statistics measured at both ends of the PPP link or MLPPP linkto check whether any packets are lost during transmission. If any packets are lost, checkthe transport network quality. If no packets are lost, go to Step 4.

4. If the PPP or MLPPP link faults persist, Contact Huawei Customer Service Center.

Typical CaseSymptom



208

The IP over E1 reconstruction based on the time division multiplexing (TDM) bearer networkfails, and therefore the BTS fails to start up.

Cause Analysis

In TDM transmission mode, the BTS communicates with the BSC directly and no router is used.Therefore, the problem may be caused by incorrect BTS data configurations.


1. Query the BTS data configurations. The port number of the PPP link is not the actual numberof the physical port.

2. Change the port number and restart the BTS. The BTS starts up successfully.

11.4 Troubleshooting LAPD Link FaultsThis section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) linkfaults.

Symptoml When an extended signaling link (ESL) or operation and maintenance link (OML) is faulty,

the BTS software fails to be loaded. When a radio signaling link (RSL) is faulty, the TRXsoftware fails to be loaded. In addition, the alarms in Table 11-6 may be reported.

Table 11-6 Alarms related to LAPD link faults

Alarm ID Alarm Name

21511 ALM-21511 LAPD Link Congestion

21512 ALM-21512 LAPD Link Fault

l When LAPD link faults occur, the query result of the MML command DSP LAPDLNK

shows that UsageStatus is set to Faulty or Congested.

Background InformationLAPD is used for transmission on the Abis interface. LAPD links are categorized into OML,RSL, ESL, and extended maintenance link (EML).

Location Procedurel LAPD link or one-way disconnection

Figure 11-6 shows the procedure for locating the source of LAPD link or one-waydisconnection.



209

Figure 11-6 Procedure for locating the source of LAPD link or one-way disconnection

l Intermittent LAPD link disconnection or congestion

Figure 11-7 shows the procedure for locating the source of intermittent LAPD linkdisconnection or congestion.



210

Figure 11-7 Procedure for locating the source of intermittent LAPD link disconnection orcongestion

Troubleshooting Procedurel LAPD link or one-way disconnection

1. Check the status of the FE/GE, E1/T1, or PPP links. If the FE/GE, E1/T1, or PPP linksare faulty, locate and rectify the faults by referring to 11.1 Troubleshooting FE/GETransmission Faults or 11.3 Troubleshooting PPP or MLPPP Link Faults andcheck whether the alarms related to LAPD link faults are cleared. If the alarms persist,go to Step 2.

2. Capture relevant packets to determine whether the Dynamic Host ConfigurationProtocol (DHCP) process is complete. If the DHCP process failed, locate and rectifythe faults by referring to 11.7 Troubleshooting DHCP Problems and check whetherthe alarms related to LAPD link faults are cleared. If the alarms persist, go to Step3.

3. Run the MML command LST BSCABISPRIMAP or LST BTSVLAN to checkwhether the VLAN ID settings for the uplink or downlink LAPD links andtransmission devices are consistent. If the settings are inconsistent, correct them and



211

check whether the alarms related to LAPD link faults are cleared. If the alarms persist,go to Step 4.

4. Run the MML command PING IP and use 64-byte, 500-byte, 1460-byte, and 1473-byte ping packets to ping the destination IP address. Then, set the differentiatedservices code point (DSCP) to the value the transport network planned for LAPDmessages. If any packets are lost or the transmission delay is long, have thetransmission engineers locate and rectify the faults, and check whether the alarmsrelated to LAPD link faults are cleared. If the alarms persist, go to Step 5. Table11-7 lists the requirements for the Abis over IP transmission quality of service (QoS)on the BSC side.

Table 11-7 Requirements for the Abis over IP transmission QoS

Counters for theAbisover IPTransmissionQoS

One-Way Delay(ms)

One-Way Jitter(ms)

Packet Loss Rate(% or 10-x)

Scenario

RecommendedValue

MaximumValue

RecommendedValue

MaximumValue

RecommendedValue

MaximumValue

Terrestrialtransmission

< 15 ms < 40 ms < 8 ms < 15 ms < 0.05% < 0.1%

Satellitetransmission

< 300 ms < 350 ms < 20 ms < 40 ms < 0.05%

5. On the LMT, trace LAPD messages on the Abis interface in the CS domain by referring

to Tracing CS Domain LAPD Messages on the Abis Interface. You can enter the BTSID alone to trace OML, EML, or RSL messages or enter both the BTS ID and TRXID to trace RSL messages. Tracing these messages helps to check whether thetransmission is normal and whether any packets are lost. If the transmission isabnormal or any packets are lost, have the transmission engineers locate and rectifythe faults and check whether the alarms related to LAPD link faults are cleared. If thealarms persist, go to Step 6.

6. Run the MML command DSP INTERWPFM to query the number of packetsreceived, sent, and discarded as measured by the interworking module.

NOTE

The interworking module measures the number of LAPD packets received and sent by theinterface board.

Before this operation, you can run the MML command LST LAPDLNK to querydata configurations for the LAPD links. If the following command is used:DSP INTERWPFM: SPUSRN=1, SPUSN=0, LNKT=LAPDLNK, LAPDLNKN=0,PIUSRN=0, PIUSN=16;



212

The query results are displayed as follows:+++ PTRM_B012 2011-02-27 10:47:12O&M #3635%%DSP INTERWPFM: SPUSRN=1, SPUSN=0, LNKT=LAPDLNK, LAPDLNKN=0, PIUSRN=0, PIUSN=16;%%RETCODE = 0 Execution succeeded.

Flow Type = UoIP_FLOW //Indicates that the BSC sends packets from the UoIP to the quintuple. Flow Index = 0 //Indicates the stream index. Count of received packet = 562 //Indicates the number of packets sent from the XPU to the interface board. Count of received byte = 23233 //Indicates the number of bytes sent from the XPU to the interface board.Count of discarded packet = 5 //Indicates the number of packets discarded on the interface board. In normal cases, the number should be 0. Count of discarded byte = 210

Flow Type = FIVE_TUPLE_FLOW //Indicates that the BSC receives packets from the quintuple to the UoIP. Flow Index = 25 //Indicates the stream index. Count of received packet = 376 //Indicates the number of packets received on the interface board. Count of received byte = 23304 //Indicates the number of bytes received on the interface board.Count of discarded packet = 0 //Indicates the number of packets discarded on the interface board. In normal cases, the number should be 0. Count of discarded byte = 0(Number of results = 2)

NOTEThe text following // is a detailed explanation of the query results.

In normal cases, the packet receiving and sending process is integrated. If multiplequery results show that the number of received and sent packets increases, thetransmission is normal. If the number of discarded packets increases, the transmissionis abnormal. In this case, Contact Huawei Customer Service Center.In the case of one-way LAPD link disconnection (packets can only be sent), if thequery results show that the number of sent packets increases, the BSC has sent packets.In this case, go to Step 7.

7. In IP over E1/T1 mode, perform an LAPD software or hardware loopback test on theinterface to check whether the problem is caused by faulty NEs or abnormaltransmission.– Run the MML command SET E1T1LOP to perform an LAPD software loopback

test. Set the port on the interface board corresponding to the current LAPD link tolocal loopback mode and trace LAPD signaling messages. If a packet can be sentand received properly, the LAPD link between the XPU and the interface board isnormal.

– Perform an LAPD hardware loopback test on the intermediate transmissiondevices. Connect the TX end to the RX end using an E1/T1 cable and do not connectthe E1/T1 cable to the BTS. Then, trace LAPD signaling messages to locate thefaulty NE.

8. If the problem persists, capture relevant packets and Contact Huawei CustomerService Center.

l Intermittent LAPD link disconnection or congestion



213

1. Query the measurement results of K3004:Traffic Volume on SDCCH andA3039J:SDCCH Seizures for Speech Service to check whether the problem is causedby a heavy traffic volume. If the traffic volume is heavy, add standalone dedicatedcontrol channels (SDCCHs) or expand the transmission capacity. If the traffic volumeis normal, go to Step 2.

2. Run the MML command DSP LAPDLNK to check the LAPD link status.

(1) Current queue length of I frame: If this parameter is set to greater than 90(default value), the ALM-21511 LAPD Link Congestion alarm is reported.

(2) Link status changed cause(3) OverFlow I Frame Count

If any of the preceding parameters are set incorrectly, Contact Huawei CustomerService Center. If the parameters are set correctly, go to Step 3.

3. Check the VLAN and DSCP settings for the port used to forward packets on thetransmission device connected to the LAPD link. If the VLAN priority is low or theDSCP settings are incorrect, some packets are lost during the transmission. Correctany incorrect settings. If the VLAN priority is normal or the DSCP settings are correct,go to Step 4.

4. Check the transport network quality.Run the MML command PING IP and use 64-byte, 500-byte, 1460-byte, and 1473-byte ping packets to ping the destination IP address. If any packets are lost, thetransmission delay is long, or the jitter is large, have the transmission engineers locateand rectify the faults, and check whether the alarms related to LAPD link faults arecleared.



214

NOTEThe following methods can be used to check the transport network quality on the user plane ofthe Abis interface. The operation results can serve as reference for checking the transportnetwork quality on the signaling plane of the Abis interface.

1. Enable the IP Path ping function. Wait for a certain period and run the MML commandDSP IPPATH or query the traffic statistics to check whether any packets are lost, whetherthe transmission delay is long, or whether the jitter is large.

2. In IP over FE mode, run the MML command ACT IPPM to activate the IP PM function.If the packets sent from the BTS to the BSC carry the VLAN ID, only the BTS3900s whosesoftware versions are BTS3000 V100R009C00SPC079 or later support the IP PM function.Then, run the MML command DSP IPPM to query the transport network quality in realtime or monitor the transport network quality by querying the following counters:

l T7663:Maximum RTT Delay of IPPM

l T7668:Average TX Bit Rate of IPPM

l T7669:Average TX Packet Rate of IPPM

l T7670:Peak TX Bit Rate of IPPM

l T7671:Peak TX Packet Rate of IPPM

l T7672:Average RX Bit Rate of IPPM

l T7673:Average RX Packet Rate of Peer End of IPPM

l T7674:Peak RX Bit Rate of Peer End of IPPM

l T7675:Peak RX Packet Rate of Peer End of IPPM

l T7676:Average Forward Packet Loss Rate of IPPM

l T7677:Peak Forward Packet Loss Rate of IPPM

l T7678:Forward Jitter Standard Deviation of IPPM

l T7679:Backward Jitter Standard Deviation of IPPM

l T7680:Average RTT Delay of IPPM

If the transport network quality meets the requirements, go to Step 5.5. If the problem persists, Contact Huawei Customer Service Center.

Typical CaseSymptom

An RSL disconnects intermittently.

Cause Analysis

l The signaling traffic volume may be heavy.l Some packets may be lost during transmission.


1. Query the signaling traffic volume. The signaling traffic volume is not heavy.2. Check whether the uplink and downlink DSCP values for the signaling plane and user plane

are consistent. The uplink and downlink DSCP values for the signaling plane are 46 and48, but the uplink and downlink DSCP values for CS services on the user plane are 38 and46. Therefore, some packets are lost during intermediate transmission.

3. Ping the destination IP address. Some packets are lost.4. Query the measurement results of packets received and sent by the router. Some packets

are lost. Therefore, the router bandwidth is insufficient, and the DSCP and queue prioritysettings are incorrect.



215

5. Increase the router bandwidth and correct the DSCP and queue priority settings. Theproblem is resolved.

11.5 Troubleshooting SCTP Link FaultsThis section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) linkfaults.

Symptoml There are two types of SCTP link faults:

– SCTP link disconnection or one-way disconnection: The TX end sends packets to theRX end but does not receive any response packets from the RX end.

– Unexpected SCTP link disconnection: The SCTP link is intermittently disconnected orcongested.

l When the SCTP link is faulty, the alarms in Table 11-8 may be reported.

Table 11-8 Alarms related to SCTP link faults

Alarm ID Alarm Name

21541 ALM-21541 SCTP Link Fault

21542 ALM-21542 SCTP Link Congestion

22915 EVT-22915 SCTP Link Destination IPChangeover

l When the SCTP link is faulty, the query result of the MML command DSP SCTPLNK

shows that Operation state is set to Unavailable or Congestion.

Background Informationl SCTP

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol used forreliable transmission between the SCTP user application and a connectionless packetnetwork (such as the IP network). In the Huawei BSS system, the SCTP technology isusually used for A over IP.

l To troubleshoot SCTP link faults, trace SCTP messages on the A interface by referring toTracing SCTP Messages on the A Interface. SCTP messages are categorized into INIT,INIT, ACK, DATA, SACK, ABORT, SHUTDOWN, ERROR, COOKIEECHO, andHEARTBEAT.

l Figure 11-8 shows the message interaction process during an SCTP link setup. The firstfour messages are handshake messages, the last four messages are heartbeat messages, andthe rest are data interaction messages.



216

Figure 11-8 Message interaction process during an SCTP link setup

Location Procedurel SCTP link or one-way disconnection

Figure 11-9 shows the procedure for locating the source of SCTP link or one-waydisconnection.



217

Figure 11-9 Procedure for locating the source of SCTP link or one-way disconnection

l Unexpected SCTP link disconnection

Figure 11-10 shows the procedure for locating the source of unexpected SCTP linkdisconnection.



218

Figure 11-10 Procedure for locating the source of unexpected SCTP link disconnection

Troubleshooting Procedurel SCTP link disconnection or one-way disconnection

1. Run the MML command PING IP to ping the peer IP address. If the peer IP addresscannot be pinged, check the router and transport network. If the peer IP address canbe pinged, go to Step 2.

2. Check whether the transmission devices require all packets sent by the BSC to carryVLAN IDs. If the packets carry VLAN IDs, run the MML commands LSTVLANID and LST SCTPLNK to check whether the VLAN IDs are correct. If theVLAN IDs are incorrect, change the parameter value. If the VLAN IDs are correct,go to Step 3.

3. Run the MML command LST SCTPLNK to check whether the settings of the SCTPinterworking parameters, especially the IP address, port number, and maximumtransmission unit (MTU), for the BSC and the MSCare consistent. In addition, ensurethat the MTU value on the transport network is greater than the MTU values on theBSC and MSC sides. If the settings of the SCTP interworking parameters areinconsistent, correct them. If the settings of the SCTP interworking parameters areconsistent, go to Step 4.

4. Check whether the SCTP link is configured with upper-layer applications, such asM3UA configuration data. If not, configure upper-layer applications. If theconfigurations are incorrect, correct them. If the SCTP link is configured with correctupper-layer applications, go to Step 5.

5. On the LMT, trace SCTP messages on the A interface by referring to Tracing SCTPMessages on the A Interface. Set SCTP Link No to the number of the congested SCTP



219

link and enable the SCTP link tracing function. Compare the traced messages withnormal interaction messages to check whether any packets are lost duringtransmission. If any packets are lost during transmission, have the transmissionengineers locate and rectify the faults. If no packets are lost during transmission, goto Step 6.

6. Analyze the SCTP packets traced in Step 5. If one end does not receive packets,capture packets at the other end to check whether the packets were sent. For example,if the BSC sends an INIT ACK packet but does not receive the COOKIEECHO packetfrom the MSC, capture packets on the MSC side to check whether the COOKIEECHOpacket was sent. To capture packets, use the Ethereal (Wireshark) software or connecta PC to the mirrored port on the switch installed between the output port and thetransport network. If the COOKIEECHO packet was sent, it may have been lost onthe transport network or BSC interface board. In this case, have the transmissionengineers locate and rectify the faults. If no COOKIEECHO packet was sent, errorsmay have occurred on the MSC side. In this case, have the MSC vendor for technicalsupport. If the transmission is normal and the MSC operates properly, go to Step 7.

7. If the problem persists, Contact Huawei Customer Service Center.l Unexpected SCTP link disconnection

1. Check whether related transmission alarms, such as the FE or E1 fault alarms, arereported when the problem occurs. If the alarms are reported, optimize the transportnetwork. If the alarms are not reported, go to Step 2.

2. On the LMT, trace SCTP messages on the A interface by referring to Tracing SCTPMessages on the A Interface. Compare the traced messages with normal interactionmessages to check whether any packets are lost during transmission. Analyze thereceived and sent packets to identify the possible causes. For example, the problemmay occur because heartbeat messages cannot be received or one end sends the Abortmessage. If the transmission is abnormal, have the transmission engineers locate andrectify the faults. If errors occur on an NE, contact the NE vendor for technical support.If the transmission is normal and the NE operates properly, go to Step 3.

3. Analyze the SCTP messages traced in Step 2. If some packets are lost duringtransmission, check whether the FE port attributes for the two ends are consistent byreferring to 11.1 Troubleshooting FE/GE Transmission Faults. If the FE portattributes are consistent, run the MML command PING IP to calculate the packet lossrate on the transport network and have the transmission engineers locate and rectifythe faults. If no packets are lost during transmission, go to Step 4.

4. If the SCTP link configurations are correct and the IP addresses of both ends can bepinged, run the MML command MOD SCTPLNK to initiate link negotiation again.If the link negotiation fails, go to Step 5.


Typical CaseSymptom

The SCTP link fails to be set up after the A over IP reconstruction and signaling dataconfigurations are complete.

Cause Analysis

l The BSC boards may be faulty.l The data configurations may be incorrect.



220


1. Query the data configurations and alarm information for the BSC boards. The dataconfigurations are complete and correct, and no boards report hardware alarms.

2. Have the MSC maintenance engineers query the settings of the SCTP interworkingparameters. The number of the SCTP port on the MSC side is not the actual number.

3. Have the MSC maintenance engineers change the number of the SCTP port on the MSCside. The SCTP link can be set up successfully.

11.6 Troubleshooting IP Path ProblemsThis section describes how to troubleshoot IP path problems.

Symptoml When an IP path problem occurs, CS or PS service may fail to be performed and the alarms

in Table 11-9 may be reported.

Table 11-9 Alarms related to IP path problems

Alarm ID Alarm Name

21581 ALM-21581 Path Fault

21582 ALM-21582 Path Congestion

21352 ALM-21352 IP Path Excessive PacketLoss Rate

l You can run the MML command DSP IPPATH to check whether an IP path problem

occurs. If Operation state in the command result is Unavailable, an IP path problem hasoccurred.

Background InformationAn IP path is a logical link carried on the physical link on an IP transport network. Each IP pathis allocated virtual bandwidth. An IP path is used to perform admission control. During networkaccess, the system performs admission control based on the service type and bandwidth used bythe IP path.

An IP path manages only the transmission resources occupied by subscriber services.

Location ProcedureFigure 11-11 shows the procedure for locating IP path problems.



221

Figure 11-11 Procedure for locating IP path problems

Troubleshooting Procedure1. Check whether the IP path configurations are correct.

l Run the MML command LST IPPATH to check whether Local IP address and PeerIP address are set correctly.

l Run the MML command DSP IPPATH to check whether the IP path status is normaland the bandwidth is configured correctly. If Operation state is set to Unavailable orthe remaining bandwidth is insufficient, IP path admission may fail.

If yes, go to Step 2. If no, correct the IP path configuration.2. Check whether IP route configurations are correct.

l Contact relevant personnel to check configurations for routes to the intermediate routedevices and core network configurations.

l Run the MML commands LST IPRT and DSP IPRT to query the routing tables forthe interface boards and check whether there is a route to the peer IP address of the IPpath. Before configuring an IP path for a BSC, ensure that the output port is available.If the output port is unavailable, first configure an IP route. Then, configure an IP path.

If yes, go to Step 3. If no, correct the corresponding configurations.3. Check whether the end-to-end transmission route corresponding to the IP path is operating

properly.l Check whether VLAN configurations are correct if VLAN planning data is available.

– Check whether the VLAN ID is configured correctly on the BSC side whenconfiguring an IP path or running the MML command ADD VLANID. You areadvised to run the MML command ADD VLANID to configure a VLAN ID



222

corresponding to the next-hop IP address and set VLANID Flag to DISABLE(Disable) for the MML command ADD IPPATH.

– Run the MML command SET BTSVLAN to check whether the VLAN IDs for theCS voice, CS data, high-priority PS, low-priority PS, signaling, or other data packetsare configured correctly.

l Run the MML command PING IP on the LMT to ping the gateway address and peerIP address of the IP path, respectively. If the peer IP address of the IP path cannot bepinged, run the MML command TRC IPADDR with Destination IP address set tothe peer IP address of the IP path to locate the problem.

If yes, go to Step 4. If no, correct configurations or rectify the transmission route fault.Then, check whether the IP path problem is resolved.

4. If the IP path problem persists, Contact Huawei Customer Service Center.

Typical CaseSymptom

After data is configured for A over IP reconstruction, the signaling becomes normal, but callsfail to be set up and the BSC sends the assignment failure messages to the core network.

Cause Analysis

l The device boards may be faulty.l Data configurations may be incorrect.


1. Query data configurations and alarm information about the BSC boards. Dataconfigurations are complete and correct and no hardware alarms are reported on any boards.

2. Query the status of the IP path and data configurations for the peer core network. The IPpath cannot be used and no route is configured on the peer core network.

3. Configure a route. The IP path problem is resolved.

11.7 Troubleshooting DHCP ProblemsThis section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP)problems.

SymptomWhen a DHCP interaction failure occurs, the BTS software fails to be loaded for an excessivelong period of time

Background Informationl A BTS can obtain configuration information and set up a cell only when DHCP interaction

is working properly. Upon startup, the BTS sends the BSC a DHCP request. Then, the BSCresponds with a DHCP response that carries the following information: BSC IP address,BTS IP address, BTS port IP address, extend signaling link (ESL) or layer 2 managementlink (L2ML), and VLAN configuration. After receiving the DHCP response from the BSC,the BTS sets up an ESL and obtains operation and maintenance link (OML) data for follow-up procedures. Figure 11-12 shows a typical DHCP interaction procedure.



223

Figure 11-12 Typical DHCP interaction procedure

Location ProcedureFigure 11-13 shows the procedure for locating DHCP problems.

Figure 11-13 Procedure for locating DHCP problems

Troubleshooting Procedure1. Check whether the transmission at the physical layer is normal. If the FE/GE transmission

is used at the physical layer, locate and rectify the transmission faults by referring to 11.1Troubleshooting FE/GE Transmission Faults. If the E1/T1 transmission is used at the



224

physical layer, check whether the alarms in Table 11-10 are reported. If the alarms arereported, clear them by referring to the BSC6900 GSM Alarm Reference. If the alarms arenot reported, go to Step 2.

Table 11-10 Alarms related to E1/T1 transmission faults

Alarm ID Alarm Name

4714 ALM-4714 E1/T1 Local Alarm

4716 ALM-4716 E1/T1 Remote Alarm

20201 ALM-20201 1PPS State Abnormal

20202 ALM-20202 Time Information ReceptionAbnormal

20203 ALM-20203 Clock Signal Outputs Faulty

20204 ALM-20204 Clock Signal Inputs Faulty

20205 ALM-20205 System Clock ReferenceSource Unavailable

20206 ALM-20206 Current System ClockReference Source Status Abnormal

20207 ALM-20207 Failure in Locking SystemClock Source

20208 ALM-20208 Clock Reference Source ofMain Control Board Unavailable

20209 ALM-20209 Faulty Phase-Locked Loop ofthe Board Clock

2. Check whether BSC data configurations are correct.

l Run the MML command LST BTSESN to check whether the BTS ESN is configured.l Run the MML command LST IPRT to check whether route configurations are correct

and complete. In Layer 3 networking, both the route to the BTS and the route to theBTS gateway must be configured.

l Run the MML command LST BTSVLAN to check whether VLAN IDs are correctlyconfigured for the packets of different service types. If packets whose service type isOther Data are not configured with VLAN IDs, IP addresses cannot be pinged. Whenthis occurs, the ARP table of the peer device may fail to be updated, and the BTS mayfail to trace a clock.

l If the BTS is configured with a VLAN ID, enable the VLAN detection function for theBSC during remote commissioning.To enable the BTS detection function, run the MML command SETBTSOTHPARA to set BTS Detect Switch to OPEN(OPEN). When the BTS detectionfunction is enabled, the BSC performs addressing based on the BTS IP address andsends the BTS a UDP packet containing the VLAN ID information. After BTS remotecommissioning is successful, run the MML command SET BTSOTHPARA to set BTSDetect Switch to CLOSE(CLOSE) to disable the BTS detection function. If data



225

configurations are incorrect, correct the data configurations. Then, check whether thealarms are cleared. If the alarms persist, go to Step 3.

3. Check whether the data configurations for transmission devices are correct.l If the Layer 3 networking mode is used for the Abis interface, ensure that the gateway

router close to the BTS has been configured with DHCP relay data. If the transmissiondevice has been commissioned successfully, the DHCP problem may lie in dataconfigurations.

l Check whether the data configurations for packet transport network (PTN) devices andLayer 2 switches are correct.– Check whether the port attribute of the PTN device is Access, Tag Aware, or Hybrid.

If the port attribute is Tag Aware, packets with VLAN IDs cannot be sent over theport.

– Check whether VLAN configurations for Layer 2 switches are the same as those forthe BTS.

If the data configurations are incorrect, correct them and check whether the alarms arecleared. If the alarms persist, go to Step 4.

4. Perform the following operations to check whether the BSC collects statistics on the DHCPpackets reported by an unknown electronic serial number (ESN): Run the MML commandCLR BTSESN. Then, wait for five minutes and run the MML command DSP BTSESNto query BTS ESNs. If any BTS ESNs are queried, the DHCP problem may result fromincorrect ESN configurations. In this situation, modify the incorrect ESN and checkwhether the DHCP problem is resolved. If the DHCP problem persists, go to Step 5.

5. Check whether the BSC or BTS has sent any DHCP packets by capturing packets on theBSC or BTS mirrored port. If the BSC or BTS has sent a DHCP packet but the packet failsto be captured at the peer end, contact transmission engineers to identify the reason whythe packets are discarded. Then, check whether the DHCP problem is resolved. If the DHCPproblem persists, go to Step 6.

6. Check whether the BTS sends any DHCP packets or the BSC responds to the BTS afterreceiving any DHCP request packets. Record the fault symptom and save the locationinformation. Then, go to Step 7.

7. If the DHCP problem persists, Contact Huawei Customer Service Center.

Typical CaseSymptom

When a test is performed in Abis over IP, two newly deployed BTSs, BTS B with VLAN 101and BTS C with VLAN 102, fail to set up links to the BSC. BTS A with VLAN 100, however,is operating properly. After the data configurations for BTS A and BTS B interchange, BTS Bconfigured with VLAN 100 operates properly. The gateway addresses of BTS B and BTS Ccannot be pinged, but the gateway address of BTS A can be pinged successfully.

Cause Analysis

l BTS ESN configurations may be incorrect.l The BTS gateway may not be configured with the DHCP relay function.l VLAN configurations for transmission devices may be incorrect.l BSC route configurations may be incorrect.




226

1. Check whether BTS ESN configurations are correct. If the check result is correct and BTSB configured with VLAN 100 operates properly after the data configurations for BTS Aand BTS B interchange, the BTS ESN configurations are correct.

2. Check whether the Layer 3 switch is configured with the DHCP relay function. The checkresult shows that the Layer 3 switch is configured with the DHCP relay function.

3. Check the VLAN configurations for the BTS and Layer 3 switch as well as for the signalingplane on the BSC. The check result shows that VLAN configurations for the three BTSsare the same except the VLAN IDs and the Layer 3 switch uses the same mechanism toprocess VLAN IDs 100, 101, and 102. After the BTS VLAN self-learning switch is turnedon, the DHCP problem persists.

4. Check the BSC route configurations. The check result shows that the route configurationsfor BTS A are different from those for BTSs B and C. BTS A is configured with a networksegment route and a BTS route. However, both BTS B and BTS C are configured with aBTS route. After BTSs B and C are configured with network segment routes, the two BTSscan set up links to the BSC. A network segment route contains a route to the DHCP relay.In Layer 3 networking, only unicast DHCP packets can be sent between the DHCP relayagent (BTS gateway) and the DHCP server (BSC). Use the unicast DHCP Discover packetas an example. The source IP address of the DHCP Discover packet is the IP address of theDHCP relay agent and the destination IP address of the DHCP Discover packet is the IPaddress of the DHCP server. After receiving a DHCP Discover packet, the DHCP serverneeds to send a DHCP Offer packet to the DHCP relay agent. In this situation, the DHCPserver must be configured with a network segment route or with two routes: one route tothe BTS and one route to the DHCP relay agent.

11.8 Troubleshooting IP PM Activation FailuresThis section describes how to troubleshoot IP performance monitor (IP PM) activation failures.

Symptom

During IP PM activation, an error message is displayed, indicating that IP PM activation fails.The activated IP PM is faulty and the ALM-21341 IP PM Activation Failure is reported. Duringpacket capturing, the BTS or BSC does not receive any IPPM ACT ACK frames after sendingIPPM ACT frames.

Background Informationl IP PM uses forward monitoring (FM) and backward reporting (BR) frames to monitor

packet loss on paths. The Tx end sends FM frames to the Rx end and notifies the Rx endof the number of sent packets. Then, the Rx end responds with BR frames and notifies theTx end of the number of received packets. The Tx end then calculates the delay, jitter,packet loss when FM frames are sent from the Tx end to the Rx end, and calculates thebandwidth change when BR frames are sent from the Rx end to the Tx end. The intervalfor sending FM frames or the number of FM frames sent by the Tx end each time can bespecified.

Location Procedure

Figure 11-14 shows the procedure for locating IP PM activation failures.



227

Figure 11-14 Procedure for locating IP PM activation failures

Troubleshooting Procedure1. Check whether the transmission at the physical layer for GBSS9.0 is normal. In IP over

E1, IP PM is not supported. In IP over FE/GE, check whether FE/GE alarms are reported.Clear any reported FE/GE alarms. Then, check whether the problem is resolved. If theproblem persists, go to Step 2.

2. Compare the packets captured on the BSC and BTS to check whether the DSCP values inthe IP PM activation response packets from the BTS are consistent with those in the IP PMactivation request packets from the BSC. During packet transmission, the intermediatetransmission device may modify the DSCP values in the packets based on the dataconfigurations for the intermediate transmission device. If the DSCP values areinconsistent, contact maintenance engineers who manage the intermediate transmissiondevice to modify the data configurations. Then, check whether the problem is resolved. Ifthe problem persists, go to Step 3.

3. Check whether the BSC sends FM frames and receives BR frames by capturing packets onthe BSC mirrored port, and check whether the BTS sends BR frames and receives FMframes by capturing packets on the BTS mirrored port. If any sent packets are not received,contact transmission engineers to locate the problem. Then, check whether the problem isresolved. If the problem persists, go to Step 4.


Typical CaseSymptom

The IP PM function on the Abis interface fails to be activated.

Cause Analysis



228

l The DSCP values in packets may be modified by the transmission device.

l Packets may be discarded on the transport network.


1. Check whether packets are discarded on the transport network. The result shows that nopackets are discarded on the transport network.

2. Analyze the captured packets. The DSCP values in the IP PM activation response packetsfrom the BTS are inconsistent with those in the IP PM activation request packets from theBSC. During packet transmission, the intermediate transmission device changes the DSCPvalues in packets.

3. Modify data configurations for the intermediate transmission device to ensure that DSCPvalues in packets cannot be changed.

4. Run the MML command ACT IPPM on the LMT to activate IP PM.

11.9 Troubleshooting IP Clock FaultsThis section describes how to troubleshoot IP clock faults.

Symptom

IP clock links may fail to be set up and the BTS may fail to lock the IP clock. When the precedingfaults occur, the alarms in Table 11-11 may be reported.

Table 11-11 Alarms related to IP clock faults

Alarm ID Alarm Name

26262 ALM-26262 External Clock ReferenceProblem

26263 ALM-26263 IP Clock Link Failure

Background Informationl The recommended Huawei IP clock server versions are as follows:

– IPCLK1000 V100R002C01SPC200 and later

– The recommended versions apply on the IPCLK1000 V1 or V2 hardware platform.

NOTE

l The recommended versions support only the IEEE 1588v2 protocol.

l After the BTS3900 is upgraded to GBSS9.0, the recommended versions support only the IEEE1588v2 protocol.

l After the BTS3900 or BTS3012 is upgraded to V900R011C00 in Abis over IP, the IP clock serverversion must match the BTS version.

l Digital-to-analog (DA) value

A phase-locked loop (PLL) for clock is a self-compensation system. It controls the voltageoutput to adjust the oscillator for generating an output signal based on the DA value. The



229

DA value is derived from the frequency offset between the clock source and the currentclock.

Location Procedurel IP Clock Link Setup Failures

Figure 11-15 shows the procedure for locating IP clock link setup failures.

Figure 11-15 Procedure for locating IP clock link setup failures

l IP Clock Lock Failures

Figure 11-16 shows the procedure for locating IP clock lock failures.



230

Figure 11-16 Procedure for locating IP clock lock failures

Troubleshooting Procedurel IP Clock Link Setup Failures

1. Check whether the BTS IP address can be pinged on the IP clock server LMT. If theBTS IP address cannot be pinged, rectify the fault by referring to 11.1Troubleshooting FE/GE Transmission Faults and 11.2 Troubleshooting IP LayerFaults. Then, check whether the problem is resolved. If the problem persists, go toStep 2.

2. Run the MML command DSP LICUSAGE to check whether the IP clock license isavailable. If the IP clock license is not available, apply for a license file. Then, checkwhether the problem is resolved. If the problem persists, go to Step 3.

3. Check whether the data configurations for the clock are correct.– Run the MML commands LST BTSIPCLKPARA, DSP BTSCLK, and DSP

BTSBRD on the BSC LMT to check whether Clock Protocol Type is configuredcorrectly (for example, the 1588v2 precision time protocol (PTP)). Also, checkwhether the IP address of the clock source is configured correctly and whether theDomain values of the two ends are the same. To query the Domain value, run theMML command DSP PTPPARA on the Huawei IP clock server LMT.

– In Layer 3 networking mode, run the MML command LST BTSIPRT on the BSCLMT to check whether the route to the IP clock server is configured.

– If the IP clock servers are configured in active/standby mode, check whether theroutes to the IP clock servers are configured.

– Check whether the VLAN configurations for the uplink and downlink areconsistent with those on the transport network.



231

– Run the MML command LST SRVVLANPARA on the IP clock server LMTto query the VLAN configurations for the downlink.

– Run the MML command LST BTSVLAN on the BSC LMT to query theVLAN configurations for the uplink.

If the VLAN configurations for the uplink and downlink are inconsistent with thoseon the transport network, correct the VLAN configurations. Then, check whetherthe problem is resolved. If the problem persists, go to Step 4.

4. Check whether the IP clock server is operating properly.

(1) Run the MML command LST SOFTWARE on the IP clock server LMT tocheck whether the IP clock version supports the configured clock protocol.

(2) Check whether any alarms affecting clock packets are reported.(3) Run the MML command DSP BRD on the IP clock server LMT to check whether

the boards are operating properly.(4) Run the MML command DSP WORKSTATUS on the IP clock server LMT to

check whether the IP clock can send packets only when the server is running.(5) Run the MML command DSP ETHPORT on the IP clock server LMT to check

whether Ethernet ports are normal.(6) Run the MML command DSP ETHMAC on the IP clock server LMT to check

whether the media access control (MAC) address is lost.

If the IP clock server is faulty, rectify the faults. Then, check whether the problem isresolved. If the problem persists, go to Step 5.

5. Check whether the data configurations for the IP clock server are correct.

(1) Run the MML command DSP CLIENTMODE on the IP clock server LMT tocheck whether the current client mode, Ethernet port type, and number of BTSsmeet the requirements.

(2) In Layer 3 networking mode, run the MML command LST IPRT on the IP clockserver LMT to check whether the route to the client is configured.

If the data configurations for the IP clock server are incorrect, correct them. Then,check whether the problem is resolved. If the problem persists, go to Step 6.

6. Locate the faulty NE.Run the MML command DSP BTSIPCLK on the BSC LMT to check the status ofthe BTS clock links. An example of the command output is as follows:DSP BTSIPCLK: IDTYPE=BYID, BTSID=0;DSP BTSIPCLK Link Status Result------------------------------- Client IP Server IP Link State Active State 10.100.2.9 10.100.100.1 DOWN Not Activated The link status is closely related to the clock packet interaction between the IP clockand the BTS. Figure 11-17 shows the procedure for clock packet interaction betweenthe IP clock and BTS.



232

Figure 11-17 Procedure for clock packet interaction between the IP clock and BTS

If Link State is UP, link maintenance packets can be sent between the IP clock andBTS clock. This means that the first four steps shown in the preceding figure areperformed.

The activation status refers to the status of sending or receiving clock synchronizationpackets. If clock synchronization packets are sent or received successfully, the linkactivation succeeds. This indicates that interactions in Steps 5 through 7 shown inFigure 11-17 are performed successfully. If no clock synchronization packets are sentor received, the link activation has failed.

– If Link State is DOWN, trace IP clock messages and capture packets on the BTSmirrored port.

NOTETo trace IP clock messages, perform the following operations:

1. Log in to the IP clock server LMT, select Trace Management in the maintenancewindow, and double-click IPCLK_TRACE.

2. In the displayed window, type the BTS IP address in ClientIP. Type 319 or 320 inCLIENT PORT to trace packets on any port for five minutes. Port 320 is used to tracelink setup packets and port 319 is used to trace clock packets.

3. Check whether signaling can be traced on the ports and whether any interactionoperations fail to be performed in any step. If any packets fail to be sent, an NE maybe faulty. In this situation, Contact Huawei Customer Service Center. If packets aresent but fail to be received, the transport network may be faulty. In this situation, locatethe NE that discards packets.

– If Link State is UP and Activate State is Not Activated, start message tracing byusing the method shown in Note and check whether Step 5, 6, or 7 shown in Figure11-17 fails to be performed.

– If any packets fail to be sent, certain NEs may be faulty. In this situation, ContactHuawei Customer Service Center.

– If packets are sent but fail to be received, the transport network may be faulty.In this situation, locate the NE that discards packets.



233

CAUTIONCheck whether packets are lost on the transmission device close to the BTS or thetransmission device connected to the IP clock server based on the captured packets.

Check whether the BTS has sent any request packets by capturing packets on thetransmission device close to the BTS. You are advised to use Hub to capture packets.If the BTS has not sent any request packets, contact Huawei for technical support. Ifthe BTS has sent request packets, certain request packets may be discarded by thetransport network. If there is no Hub or switch between the BTS and the transmissiondevice, use the Huawei proprietary protocol as the BTS IP clock protocol. Then, checkwhether clock packets can be captured on the transmission device that is closest to theBTS. If any clock packets can be captured, the transmission device may have discardedsome clock packets.

After the preceding operations are performed, the faulty NE can be located. If thetransmission device does not discard any packets, go to Step 7.


l IP Clock Lock Failures

1. Check whether the BTS DA value is correct.

Run the MML command DSP BTSBRD on the BSC LMT to query the DA value. Ifthe BTS fails to lock the IP clock because of an incorrect DA value and theALM-26262 External Clock Reference Problem is reported, run the MML commandSET BTSCLKPARA on the BSC LMT to change the DA value or turn off the tracerange restriction switch. If the problem persists, go to Step 2.

2. Check whether clock synchronization packets are sent successfully.

(1) Run the MML command DSP PTPPARA on the IP clock server LMT.List protocol para------------------ Cast Mode = Unicast Domain = 0 Annouce = 1/64hz Sync = 16hz Receipt = 3 Priority1 = 128 priority2 = 128 The recommended send rate for clock synchronization packets is 16 Hz. Restartthe IP clock server after setting this parameter.

(2) View the messages traced on the IP clock server to check whether clocksynchronization packets are sent successfully. For details, see the description ofIP Clock Link Setup Failures.

(3) Run the MML command DSP IPCLKLNK on the IP clock server LMT. Viewthe number of clock synchronization packets sent on the link specified in theMML command and check whether clock synchronization packets are sentsuccessfully.

(4) Capture packets on the transmission device close to the IP clock to check whetherclock synchronization packets are sent successfully. If clock synchronizationpackets fail to be sent, modify the data configurations or Contact HuaweiCustomer Service Center to resolve the IP clock problem. Then, check whetherthe problem is resolved. If the problem persists, go to Step 3.



234

3. Check whether the quality of service (QoS) indicator of the transport network isnormal and whether the jitter is too large. If the jitter is too large, improve the transportnetwork quality. Then, check whether the problem is resolved. If the problem is notresolved, go to Step 4.


Typical CaseSymptom

An IP clock link fails to be set up, but the IP address for the communication between the IP clockand the BTS can be pinged.

Cause Analysis

l The IP clock version may not be supported.l Certain NEs may process clock packets abnormally.l The transmission device may discard packets.


1. Check the IP clock version. The IP clock version meets the requirements.2. Trace messages on both the IP clock and BTS. The BTS constantly sends the Announce

request messages, but the IP clock does not receive any messages. This indicates that theAnnounce request messages fail to be received on the IP clock server. The possible causemay be that the transmission device discards packets.

3. Locate the faults in NEs. The location result shows that a switch imposes limitations on the1588v2 clock packets, which results in packet losses. After the limitations are removed,the BTS locks the IP clock successfully.



235

12 Interference Problems

About This Chapter

This chapter describes how to locate and troubleshoot interference problems.

12.1 InterferenceInterference affects many aspects of network performance, such as voice quality, networkcoverage and capacity, as well as the call drop rate, handover success rate, and congestion rate.Reducing or eliminating interference is critical to network planning and optimization.

12.2 Locating Interference ProblemsThis section describes how to locate interference problems.

12.3 Troubleshooting Co-channel or Adjacent-Channel InterferenceThis section describes how to troubleshoot co-channel or adjacent-channel interference.

12.4 Troubleshooting Intermodulation InterferenceThis section describes how to troubleshoot intermodulation interference.

12.5 Troubleshooting Interference from the CDMA NetworkThis section describes how to troubleshoot interference from the CDMA network.

12.6 Troubleshooting External InterferenceThis section describes how to troubleshoot external interference.

GBSS9.0Troubleshooting Guide 12 Interference Problems


236

12.1 InterferenceInterference affects many aspects of network performance, such as voice quality, networkcoverage and capacity, as well as the call drop rate, handover success rate, and congestion rate.Reducing or eliminating interference is critical to network planning and optimization.

Generation of Interference

To expand the GSM network capacity, frequencies must be reused. Frequency reuse enablescells that are far enough away from each other to use the same frequency. The distance betweenthe cells is the reuse distance, and the ratio of the reuse distance to the cell radius is the reusefactor. Reuse of a large number of frequencies increases the network capacity. However,interference increases as the reuse distance decreases.

There are two types of interference on the GSM network: internal interference or intra-systeminterference, and external interference. Interference caused by frequency reuse is internalinterference. Other types of internal interference include intermodulation, spurious, and blockinginterference. Interference from other network systems, such as CDMA or other radio devices,is external interference.

NOTE

l Intermodulation interference is when a receiver receives multiple strong signals and the front-end non-linear components of the receiver have intermodulation products on the available frequency bands.

l Blocking interference is when non-linear signal distortion occurs because both undesired stronginterference signals and desired signals saturate the non-linear components of the receiver.

l Spurious interference is when interference sources cause additive interference to the working frequencyband of a receiver. Additive interference includes out-of-band frequency leakage, amplified noise floor,and intermodulation signals. Spurious interference decreases the signal-to-noise ratio and increases thenoise floor of the receiver.

Impact of Interference

Strong network interference may have the following impacts on calls:

l Calls fail to be set up even if signals can be received properly. Poor uplink quality leads tounclear voice signals for the called MS.

l Both originated- and terminated-calls fail to be set up. A call easily drops after the prompttone starts.

Strong network interference has the following impacts on traffic statistics:

l Uplink interference is detected by using interference band traffic statistics along with theinterference band thresholds and usage scenarios. For example, if interference band 2 isrecorded in traffic statistics for boundary networks with loose frequency reuse, interferencemay occur. If interference band 4 or 5 is recorded in traffic statistics for urban areas withtight frequency reuse, strong interference may occur.

l The values of RA303G:Success Rate of Immediate Assignments and RCA313:AssignmentSuccess Rate are small.

l The values of ZTR104C:Call Drop Rate on SDCCH and ZTR304:Call Drop Rate on TCHper cell(including Handover) are large.

l The value of RH303:Handover Success Rate is small.



237

l The measurement results of TCHF Receive Level Measurement and TCHH Receive LevelMeasurement show a large proportion of calls with high level and low receive quality.

The drive test results are as follows:l A large number of call drops occur on the Um interface.l Frequent handovers occur and the number of failed handovers increases.l There are a large number of calls with high receive level and low receive quality.

12.2 Locating Interference ProblemsThis section describes how to locate interference problems.

Principles for Locating Interference ProblemsThe following are common types of uplink interference on the GSM network:l Passive intermodulation interferencel Co-channel interference or adjacent-channel interferencel Interference from repeatersl Interference from the CDMA networkl External interference

Use the interference characteristics to determine the interference type.

Background Informationl 3.3.3 Scanning Uplink Frequencies.l Dummy burst tests are used to obtain the maximum network interference during network

optimization. This kind of testing sends dummy bursts on all idle timeslots in a specifiedarea to cause the strongest interference to a network. A dummy burst test can take between1 and 24 hours. The test can be configured to stop automatically or stopped manually onthe LMT. For details about how to perform a dummy burst test, see 3.3.2 DetectingIntermodulation Interference by Testing Idle Timeslots.

Procedure for Locating Interference ProblemsFigure 12-1 shows the procedure for locating interference problems.



238

Figure 12-1 Procedure for locating interference problems

12.3 Troubleshooting Co-channel or Adjacent-ChannelInterference

This section describes how to troubleshoot co-channel or adjacent-channel interference.

Symptom

As with intermodulation interference, co-channel interference or adjacent-channel interferenceduring peak hours greatly differs from that during off-peak hours. However, co-channel oradjacent-channel interference does not affect the downlink power of interfered cells becausethese types of interference are caused by MSs in other cells.

Cells with co-channel or adjacent-channel interference are not affected by dummy burst testsperformed in the early morning. You can determine which cells are affected by these types ofinterference according to the interference band traffic statistics at different measurement points.



239

Background InformationFrequencies must be reused in GSM networks. If a reuse distance is smaller than the cell radius,co-channel or adjacent-channel interference may occur. Other causes such as clutter reflectionmay also lead to co-channel or adjacent-channel interference. If the carrier-to-interference ratio(C/I) is less than 12 dB or the carrier-to-adjacent ratio (C/A) is less than -6 dB, there isinterference on the networks.

Location ProcedureFigure 12-2 shows the procedure for locating co-channel or adjacent-channel interference.

Figure 12-2 Procedure for locating co-channel or adjacent-channel interference

Troubleshooting Procedure1. Check whether co-channel or adjacent-channel interference occurs in a cell.

Import the engineering parameters of both serving cell and neighboring cells into afrequency analysis tool, and use the frequency check function to check whether someneighboring cells share the same or adjacent ARFCN that causes the strongest interferencewith the serving cell.l If yes, change the ARFCN that causes the strongest interference. Then, go to Step 2.l If no, perform operations according to section Procedure for Locating Interference

Problems.2. Check Interference Band Measurement per TRX(MR.Iterf.TRX) and determine whether

the interference band decreases.l If yes, no further action is required.l If no, see Procedure for Locating Interference Problems.

Typical CaseSymptom



240

Dialing tests are conducted by locking the ARFCNs of some cells. The test results show thatvoice quality is acceptable for calls that use the traffic channel (TCH) on broadcast controlchannel (BCCH) TRXs of the cells but is poor for calls that use the TCHs on non-BCCH TRXsof the cells.

Cause Analysis

Adjacent-channel interference occurs between the BCCH TRXs and the non-BCCH TRXs. Toresolve this problem, replan the ARFCNs.


1. Check Interference Band Measurement per TRX(MR.Iterf.TRX) of these cells. Theinterference band decreases during off-peak hours whereas the interference band increasesduring peak hours. This indicates that the cells are experiencing uplink interference.

2. Perform dummy burst tests in the cells during off-peak hours. The test results show thatthe interference band does not increase noticeably, indicating that the adjacent-channelinterference in these cells is the major source of interference.

3. Check the frequency plan. The cells in urban areas use 1x3 frequency reuse mode andfrequency hopping (FH). The ARFCN for the BCCH TRXs of the cells with blockedARFCNs is 111. In FH mode, the ARFCNs for the non-BCCH TRXs of the cells are 98,101, 104, 107, and 110. ARFCN 111 for the BCCH TRXs is adjacent to ARFCN 110 forthe non-BCCH TRXs.

4. Make calls to occupy TCHs on the BCCH TRXs. ARFCN 110 configured for the non-BCCH TRXs causes little adjacent-channel interference and has little impact on voicequality.

5. Make calls to occupy TCHs on the non-BCCH TRXs. The BCCH TRXs continuouslytransmit signals and therefore the decreasing strength of uplink and downlink signals dueto power control causes strong adjacent-channel interference and greatly impacts voicequality.

6. Change the hopping sequence for these cells. Voice quality on the non-BCCH TRXsimproves.

12.4 Troubleshooting Intermodulation InterferenceThis section describes how to troubleshoot intermodulation interference.

Symptom

Passive intermodulation interference is broadband interference caused by the downlink signalsin the BTS antenna system. This type of interference is closely related to BTS downlink transmitpower and cell traffic.

According to the traffic statistics on interference bands, the passive intermodulation interferenceis stronger during peak hours than during off-peak hours. However, passive intermodulationinterference cannot be determined simply by the difference in strength between peak and off-peak hours. Co-channel or adjacent-channel interference or interference from the CDMAnetwork is also stronger during peak hours than during off-peak hours.

A dummy burst test can be performed in the early morning to determine the interference type.If the interference band increases in the simulated full-power signal transmission scenario,passive intermodulation interference is the interference type.



241

If the percentage of interference bands 4 and 5 increases by 10% or above, passiveintermodulation interference is the interference type.

Background InformationWhen two radio frequency (RF) signals are received by a non-linear device or discontinuoustransmission medium, new absolute radio frequency channel numbers (ARFCNs) are generated.The formula for determining the relationship between input signals and intermodulation productsbased on the typical non-linear model is as follows:

x indicates the input signals and f(x) indicates the final products. When two monophonic signalsare used as input signals, new ARFCNs are also generated. Signals from the new ARFCNs areconsidered intermodulation products.

Based on the trigonometric sum-to-product formulas, the intermodulation results of the non-linear products (X1^2) x X2 and X1 x (X2^2) are as follows: The third-order intermodulationproducts are 2f1-f2 and 2f2-f1, the fifth-order intermodulation products are 3f1-2f2 and 3f2-2f1,or the seventh-order intermodulation products are 4f1-3f2 and 4f2-3f1. The intermodulationresults at other levels are calculated the same way. Generally, the higher the intermodulationlevel, the lower the frequencies of the intermodulation products.

The antenna is a passive device used to transmit RF signals. The possible causes ofintermodulation in an antenna system are as follows:l The antenna connectors are dirty or damaged; the interior silver coating of antenna feeders

are damaged; or metal filings are left in the connectors due to frequent reassembling.l The antenna connectors are not securely connected or sealed.l The half-wave dipole sealed in the antenna protective cover is corroded.l The feeder that connects the antenna connectors to the half-wave dipole is corroded.l The feeder and jumper are not routed properly. There is stress in the connectors.

Location ProcedureFigure 12-3 shows the procedure for locating intermodulation interference.



242

Figure 12-3 Procedure for locating intermodulation interference



243

Troubleshooting Procedure1. Check whether any BTS connectors are loose.

Check all the BTS connectors, including the connectors of cables between the combinerand TRXs, for both the uplink and downlink.l If yes, tighten the connectors. Screw down the connectors using a wrench turned at an

angle of less than 90 degrees. Then, go to Step 2.l If no, go to Step 3.

2. Check whether the intermodulation interference is eliminated.l If yes, no further action is required.l If no, go to Step 3.

3. Check whether the combiner is faulty.Check whether the interference affects channel A or channel B of the DDPU. For 3012series base stations, the DFCU and DDPU implement signal combining. For 3006C seriesbase stations, the DDPM implements signal combining. For 3900 series base stations, thesignal combining function is integrated into the TRX boards.l If yes, replace the faulty DDPU. Then, go to Step 4.l If no, go to Step 5.


5. Check whether the CDMA network filter is faulty.l If yes, replace the faulty CDMA network filter. Then, go to Step 6.l If no, go to Step 7.


7. Check whether the surge protector is faulty.l If yes, replace the faulty surge protector. Then, go to Step 8.l If no, go to Step 9.


9. Check whether the coupling repeater is faulty.l If yes, disconnect the faulty coupling repeater from the problem cell. Then, go to Step

10.l If the coupling repeater is not installed or is faulty, go to Step 11.


11. Check whether the upper jumper, lower jumper, or jumper connector is faulty.If there is a spectrum analyzer whose noise floor is less than -90 dBm and whose scanningspeed is less than 0.1s, connect the spectrum analyzer to the uplink output connector of the



244

combiner. Then, gently shake the antenna jumper for about 30 seconds. Ensure that thedistance between the connector and the shaking point is 20 to 40 cm, the amplitude is 3 to5 cm, and the frequency is 1 Hz.l If yes, replace the faulty jumper. Gently shake the connector between the new jumper

and the feeder. If the noise floor of the receive band changes irregularly, reassemble thefeeder connector. Then, go to Step 12.

l If no, go to Step 13.If the spectrum analyzer does not meet the requirements, replace the uplink and downlinkjumpers, and reassemble the feeder connector. Then, go to Step 12.


13. Check the antenna of the problem cell.l Switch the antennas of the problem cell and the neighboring cell, or replace the faulty

antenna. Then, go to Step 14.14. Check whether the intermodulation interference is eliminated.

l If yes, no further action is required.l If no, the feeder may be faulty but this rarely occurs. If the problem persists after the

faulty antenna is replaced, see Procedure for Locating Interference Problems.

Typical Case

Symptom

As displayed on the site maintenance terminal (SMT), a cell under a BTS working on the 900MHz frequency band is persistently affected by interference band 5. Traffic statistics collectedfor a few weeks also indicate that interference band 5 persists. In addition, cells under anotherBTS in the same coverage area of the antenna for the problem cell are also interfered. However,the interference persists even after the ARFCNs are replanned.

Cause Analysis

The performance of the antenna system deteriorates.


1. Replan frequencies in the problem cell and observe the traffic statistics on frequencyscanning. The interference persists after the frequency replanning, and all three ARFCNsof the cell are changed. Therefore, there is a low probability that frequency replanningcaused the interference. In addition, the main and diversity signal levels of ARFCNs on allthe frequency bands exceed -80 dBm, which indicates that the interference is not causedby improper frequency planning.

2. Conduct tests on site. The voltage standing wave ratio (VSWR) and the TRX power arenormal, but the interference persists after the TRXs and DDPUs of the problem cell and anormal cell are switched. This indicates that the interference is not caused by hardwarefaults.

3. Conduct drive tests in the surrounding areas of the BTS. The voice quality is poor (level7) when a call is set up only in the problem cell. The voice quality is good when a call isset up in other cells. This indicates that the interference is not caused by externalinterference.



245

4. Check the antenna system on the rooftop. The horizontal spacing between antennas of the900 MHz and 1800 MHz cells exceeds 5 m, indicating that the interference is not causedby antenna spacing. The type of antennas for one 900 MHz cell is different from the othercells and this type of antenna looks older than others. Therefore, antennas of this type mightbe faulty. After the antennas of the problem cell and a normal cell are switched, theinterference disappears from the problem cell but occurs in the normal cell. This indicatesthat the interference is caused by faulty antennas.

5. Replace the faulty antennas. The interference is eliminated.

12.5 Troubleshooting Interference from the CDMANetwork

This section describes how to troubleshoot interference from the CDMA network.

SymptomInterference from the CDMA network is generated when the CDMA downlink signals block theGSM 900 MHz uplink frequency bands or reach the GSM receivers at GSM uplink receivefrequency bands (885 MHz to 925 MHz).

There is only a slight difference in the level of interference from the CDMA network betweenpeak hours and off-peak hours. CDMA downlink signals are transmitted at the frequency bandof 870 MHz to 880 MHz. The smaller the uplink absolute radio frequency channel number(ARFCN) configured for TRXs, the stronger the interference. Figure 12-4 shows an exampleof the CDMA interference spectrum scanned using the uplink frequency scanning function.

Figure 12-4 CDMA interference spectrum

Background InformationCDMA 800 MHz frequency bands and GSM 900 MHz frequency bands use adjacentfrequencies. If the CDMA network is not sufficiently isolated from GSM BTSs, interference



246

may be generated. In particular, the CDMA downlink signals are likely to affect GSM 900 MHzuplink frequency bands, increasing the receive noise floor. The closer the CDMA downlinksignals are to GSM frequency bands, the lower the anti-interference capability of the GSMnetwork. The smaller the ARFCNs configured for TRXs, the stronger the interference. The typesof CDMA network interference are as follows:

l Blocking interference

Blocking interference, also known as intermodulation interference, is generated whenstrong CDMA downlink signals are received by the GSM receivers. This type ofinterference is determined by detecting uplink receive signals using a spectrum analyzer.Generally, if the level of the detected CDMA downlink signals exceeds -20 dBm, GSMuplink receive quality is affected.

l Tailing interference

Tailing interference, also known as spurious interference, is a type of co-channelinterference generated when CDMA transmit signals are received on GSM uplinkfrequency bands. This type of interference can be detected using uplink frequency scanning.If the noise floor of the TRXs configured with smaller ARFCNs is higher whereas the noisefloor of the TRXs configured with larger ARFCNs is lower, tailing interference or spuriousinterference is generated.

To prevent the signals generated on CDMA 800 MHz frequency bands from affecting GSM 900MHz frequency bands, use one of the following methods:

l Add frequency guard bands.

This optimizes the spurious emission performance of power amplifiers, and the blockingand intermodulation performance of receivers. This is the optimal method for eliminatinginterference from the CDMA network, but the spectrum utilization decreases.

l Increase the antenna isolation.

The antenna isolation is closely related to antenna position, height, downtilt, and polardiagram.

During installation, the antenna isolation must exceed 50 dB. The formulas for calculatingthe horizontal and vertical antenna isolation are as follows:

Horizontal antenna isolation = 22 + 20 x log(dh/λ) + G1 + G2 + g1 + g2

Vertical antenna isolation = 28 + 40 x log(dV/λ)

dh indicates the horizontal spacing, dv indicates the vertical spacing, G1 and G2 indicatethe gains of the transmit antenna and receive antenna in the maximum radiation direction,g1 and g2 indicate the relative gains of the transmit antenna and receive antenna in theconnection direction, and λ indicates the carrier wavelength.

According to the two formulas, the vertical antenna isolation is generally larger than thehorizontal antenna isolation. Therefore, place the transmit antenna 2 m away from thereceive antenna vertically when CDMA and GSM are co-sited. The relative gains of thetransmit antenna and receive antenna should be as small as possible when CDMA and GSMare not co-sited or the antennas are installed at the same height. To ensure small relativegains for the transmit and receive antennas, the main lobes of the two antennas must beparallel or the back lobes of one antenna must face the other antenna with a horizontalspacing of 6 m or more.

l Install filters.

This helps to eliminate spurious interference from the CDMA network, or blocking andintermodulation interference from the GSM network, but requires additional installationcosts.



247

Location ProcedureFigure 12-5 shows the procedure for locating interference from the CDMA network.

Figure 12-5 Procedure for locating interference from the CDMA network

Troubleshooting Procedure1. Check whether blocking interference is generated.

l If yes, install a CDMA network filter on the GSM BTS. Then, go to Step 2.l If no, go to Step 3.

2. Check whether the interference from the CDMA network is eliminated.l If yes, no further action is required.l If no, go to Step 3.

3. Check whether spurious interference is generated.l If yes, install a filter or optimize the antenna system on the CDMA network. Then, go

to Step 4.l If no, see Procedure for Locating Interference Problems.

4. Check whether the interference from the CDMA network is eliminated.l If yes, no further action is required.l If no, see Procedure for Locating Interference Problems.

Typical CaseSymptom



248

Voice quality deteriorates in several cells under a GSM BTS in a city. According to the trafficstatistics analysis, the high quality indicator (HQI) decreases, the percentage of interferencebands 3 to 5 increases, the radio access success rate decreases, and the call drop rate increasesin these cells. This indicates that the network performance is severely affected.

Cause Analysis

The frequency scanning results show that both E-GSM frequency bands (800 MHz to 890 MHz)and P-GSM frequency bands (890 MHz to 915 MHz) are affected by interference. The smallerthe ARFCNs configured for TRXs, the stronger the interference. The frequencies of the CDMAtransmit signals range from 870 MHz to 880 MHz and a CDMA antenna is installed 5 m awayfrom the GSM antenna. Therefore, you determine that the interference in the problem cells isfrom the CDMA network.


Install a CDMA network filter on the GSM BTS and perform a dialing test. The dialing testresults show that the voice quality is good, the uplink HQI increases to about 95%, the percentageof interference bands 3 to 5 decreases noticeably, and the related KPIs return to normal.

12.6 Troubleshooting External InterferenceThis section describes how to troubleshoot external interference.

SymptomExternal interference is generated irregularly and its sources are difficult to identify. To locatethe sources of external interference, analyze long-term traffic statistics on interference bands tofind out at what time external interference occurs, and scan frequencies when externalinterference is most likely to be generated.


l Interference from repeaters

Repeaters are used to extend the BTS coverage during the early phase of networkdeployment. However, a repeater may cause interference to BTSs in the followingsituations:

– The donor antenna and the service antenna are not sufficiently isolated because therepeaters are not installed properly. This causes self oscillation and affects the BTS.

– The intermodulation signal level of repeaters using non-linear wideband amplifiers ismuch greater than the standard level. Repeaters working at high power are likely tocause strong intermodulation interference to neighboring BTSs.

– Cascaded repeaters amplify the same frequencies of the transmitted signals, whichcauses a delay for signal transmission. If the delay exceeds the specified time window,co-channel interference is generated.

Repeaters are generally the main cause of external interference, especially in metropolitanareas.

l Interference from radar stations

The decimeter wave radar of the 1970s or 1980s uses frequencies that are the same as oradjacent to GSM frequencies. The decimeter wave radar transmits at between tens to



249

hundreds of kilowatt power, causing a great volume of out-band spurious emissions as wellas interference to neighboring BTSs.

l Interference from cordless telephone sets operating at 900 MHzIn certain areas, the bandwidth for analog 900 MHz cordless telephones is 30 kHz and thebandwidth for digital 900 MHz cordless telephones is 2 MHz. These telephones transmitsignals between 902 MHz to 920 MHz in frequency hopping (FH) mode. Therefore, if anoutdoor antenna provides high power for these telephones, it may cause interference toneighboring BTSs.

l Interference from other radio devices or interference generators on the same frequenciesCertain types of radio devices use GSM frequency resources, which may cause interferenceto neighboring BTSs.

Location ProcedureFigure 12-6 shows the procedure for locating external interference.

Figure 12-6 Procedure for locating external interference

Troubleshooting Procedure1. Check whether there are external interference sources.

Identify the external interference sources by analyzing 24-hour or even 7-day trafficstatistics on uplink interference bands for all the cells.Signals from one interference source may affect multiple cells. Therefore, traffic statisticson interference bands for neighboring cells are also required. If the interference affectsmultiple cells and/or is eliminated from multiple cells at the same time, these cells areprobably affected by the same interference source. Knowing this helps locate theinterference source.

(1) To locate the interference source onsite, perform the following operations: 1. Place aYagi antenna and a scanner on a rooftop in a problem cell when the interference is thestrongest. Connect the Yagi antenna to the scanner with the frequency range set to870 MHz to 915 MHz. 2. Use the Yagi antenna to scan for interference in differentdirections and monitor the frequencies of interference signals displayed on thescanner. 3. Use a compass to locate the source of the strongest interference and keepa record of the direction. Then, change the Yagi antenna direction to within 30 degrees



250

of the line indicating the direction of the strongest interference source and observe theinterference amplitude for 2 to 5 minutes. Then, repeat steps 1 through 3 in otherproblem cells and use the Yagi antenna to triangulate the location of the source of thestrongest interference.

(2) To locate the interference source in the surrounding areas of a problem site, you cancarry a Yagi antenna and a scanner to the most likely location of an interference source.Search for the interference source in places free of obstacles, such as buildings, tonarrow down the search range. You need to determine whether there are schools,government offices, or public security agencies in the search area because they mayuse interference devices. Then, repeat the preceding operations in all other areas whereinterference sources are likely to exist until you find the interference source.

l If yes, eliminate the external interference sources. Then, go to Step 2.l If no, Contact Huawei Customer Service Center.

2. Check whether external interference is eliminated.l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom

The traffic statistics displayed on the M2000 show that the call drop rate increases noticeably.The LMT shows that the interference bands for all channels in cell 1 are band 3.

Cause Analysis

This problem is caused by the interference from a television station antenna.


1. Change the absolute radio frequency channel numbers (ARFCNs) and FH groups for thecell. The problem persists. Therefore, this problem is not caused by co-channel or adjacent-channel interference.

2. Switch the feeders for cell 1 (a severely interfered cell) and cell 2 (a normal cell) to thejumper connectors of the DDPU. All the channels in cell 1 can process services properlybut the interference band in cell 2 changes to band 3. Therefore, the antenna connectionsare correct and the problem may be caused by the feeder or antenna configuration.

3. Switch the jumpers for cell 1 and cell 2 to the antenna connectors. All the channels in cell1 return to normal but all the channels in cell 2 are affected by interference band 3. Inaddition, the antenna was only recently installed. Therefore, this problem may be causedby external interference.

4. A television antenna is installed on the tower where the antenna for cell 1 is located andthe output power of the television antenna was increased from 200 W to 500 W recently.Power off the television antenna. The interference is eliminated immediately.



251

13 Faults on Main and Diversity RXChannels

About This Chapter

This chapter describes how to locate and troubleshoot faults on main and diversity receive (RX)channels.

13.1 Principles of Main and Diversity ReceptionWhen main and diversity RX channels are faulty, related alarms are reported.

13.2 Locating Faults on Main and Diversity RX ChannelsThis section describes how to locate faults on main and diversity RX channels.

13.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect DataConfigurationsThis section describes how to troubleshoot faults on main and diversity RX channels due toincorrect data configurations.

13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect AntennaConnectionsThis section describes how to troubleshoot faults on main and diversity RX channels due toincorrect antenna connections.

13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware FaultsThis section describes how to troubleshoot faults on main and diversity RX channels due tohardware faults.

GBSS9.0Troubleshooting Guide 13 Faults on Main and Diversity RX Channels


252

13.1 Principles of Main and Diversity ReceptionWhen main and diversity RX channels are faulty, related alarms are reported.

The alarms related to main and diversity RX channels are ALM-4176 Main receive channelalarm and ALM-4178 Diversity receive channel alarm. The alarms can be triggered only whenthere is a certain amount of traffic. Therefore, do not check for faults on main and diversity RXchannels during off-peak hours, such as in the early morning.

If TRXs are in main and diversity RX mode:l When the main RX signal level is lower than the diversity RX signal level and the difference

exceeds the upper threshold (32 dB), the alarm ALM-4176 Main receive channel alarm isreported.

l When the diversity RX signal level is lower than the main RX signal level and the differenceexceeds the upper threshold (32 dB), the alarm ALM-4178 Diversity receive channel alarmis reported.

Only the main or diversity RX channels receive signals when the alarms related to diversity ormain RX channels are reported. As a result, the BTS coverage decreases.

13.2 Locating Faults on Main and Diversity RX ChannelsThis section describes how to locate faults on main and diversity RX channels.

Principles of Locating Faults on Main or Diversity RX ChannelsWhen an alarm related to main and diversity RX channels is reported, check for the followingproblems or faults:l Incorrect data configurationsl Incorrect feeder connectionsl Hardware faults

Procedure for Locating Faults on Main and Diversity RX ChannelsFigure 13-1 shows the procedure for locating faults on main and diversity RX channels.



253

Figure 13-1 Procedure for locating faults on main and diversity RX channels

13.3 Troubleshooting Faults on Main and Diversity RXChannels Due to Incorrect Data Configurations

This section describes how to troubleshoot faults on main and diversity RX channels due toincorrect data configurations.

Symptom

Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receivechannel alarm are reported.

Background Informationl Single path: One board uses only one path to connect to the antenna.l Double paths: One board uses two paths to connect to the antenna.l 1TX or 2TX: One or two paths are used for transmitting signals.l 2RX: Two paths are used for receiving signals.l Power boost technology (PBT): One TRX is configured with one carrier. One radio

frequency (RF) signal from the TRX is divided into two small RF signals and thentransmitted to the power amplifier where the signals are combined and amplified.

l Transmit diversity: One baseband signal is divided into two signals to produce a multipatheffect, increasing the downlink RX signal level of an MS.



254

l 4-way diversity: The 4-way RX signals are transmitted to one carrier.

Location ProcedureFigure 13-2 shows the procedure for locating faults on main and diversity RX channels due toincorrect data configurations.

Figure 13-2 Procedure for locating faults on main and diversity RX channels due to incorrectdata configurations

Troubleshooting Procedure1. On the LMT, run the MML command LST GTRXDEV to check whether Receive

Mode and Send Mode match the physical connections.l If no, run the MML command SET GTRXDEV to modify Receive Mode and Send

Mode according to the antenna configuration table. Then, go to Step 2.l If yes, go to Step 3.

2. Check whether the alarms related to the main and diversity RX channels are cleared.l If yes, no further action is required.l If no, go to Step 3.

3. Check whether the data configuration on the LMT matches the physical connections.l For the BTS3012, check whether the number of paths required by carriers in send mode

is consistent with the number of paths provided by DDPUs. For example, if four pathsare required for a cell configured with four carriers and send mode set to NoCombining but only one DDPU is configured, the data configuration is incorrect. Runthe MML command LST BTSANTFEEDERCONNECT to query the configuration



255

for antenna connections. If the configuration is inconsistent with the physicalconnections, run the MML command SET BTSANTFEEDERCONNECT to modifythe configuration.

l For the BTS3900, check whether the data configuration is consistent with the physicalconnections based on TRX type. For example, if the only one carrier on a DRFU isbound to path 0 on a TRX but the DRFU is actually connected to port TX2 on the TRX,modify the data configuration or change the physical connections. Run the MMLcommand LST GTRX to query the TRX data configuration. If the data configurationis inconsistent with the physical connections, run the MML command RMVTRXBIND2PHYBRD to delete the binding relationship between the carriers and thepaths on the TRXs. Then, run the MML command ADD TRXBIND2PHYBRD to addthe binding relationship between the carriers and the paths on the TRXs.

l If no, modify the data configuration or change the physical connections. Then, go toStep 4.

l If yes, return to Procedure for locating main and diversity receive channel faults.

4. Check whether the alarms are cleared.


l If no, return to Procedure for locating main and diversity receive channel faults.

Typical Case

Symptom

A cell under site A is configured with only one carrier and the carrier-related alarms ALM-4176Main receive channel alarm and ALM-4178 Diversity receive channel alarm are reported.

Cause Analysis

The cell is configured with only one carrier and uses only one path to connect to the antenna.Therefore, the cell cannot implement 2RX.


On the LMT, run the MML command SET GTRXDEV with Receive Mode set toINDEPENDENT(Independent Receiver) and Send Mode set to DTIC(TransmitIndependency or Combination).

13.4 Troubleshooting Faults on Main and Diversity RXChannels Due to Incorrect Antenna Connections

This section describes how to troubleshoot faults on main and diversity RX channels due toincorrect antenna connections.

Symptom

Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receivechannel alarm are reported. The BTSs that report these alarms encounter problems. For example,the BTS coverage decreases, MSs have difficulty accessing the network, call drops due tohandovers increase, and the packet switched (PS) service rate decreases.



256

Swapped BTSs are more likely to encounter antenna connection errors than newly deployedBTSs. Field engineers can use traffic statistics and signaling data in the early phase to locatesuch problems.

Background InformationThe following are the performance counters related to main and diversity RX channels:l S4556:Average Main Level in the Customized MRl S4557:Average Diversity Level in the Customized MR

The following are the formulas for calculating the main and diversity RX signal levels:l Main RX signal level (dB) = 10 x log10(S4556) - 120l Diversity RX signal level (dB) = 10 x log10(S4556) - 120

Location ProcedureFigure 13-3 shows the procedure for locating faults on main and diversity RX channels due toincorrect antenna connections.

Figure 13-3 Procedure for locating faults on main and diversity RX channels due to incorrectantenna connections



257

Troubleshooting Procedure1. Check whether the cables between the TRXs and the radio frequency (RF) modules are

faulty.

Calculate the main and diversity RX signal levels according to the preceding formulasmentioned in background information. For the carriers of the TRXs connecting to the sameRF module, if the main RX signal level is different from the diversity RX signal level,check whether any cables between the TRXs and the RF module are faulty.

l If yes, replace the faulty cables. Then, go to Step 2.


2. Check whether the alarms related to the main and diversity RX channels are cleared.



3. Check whether a jumper or feeder connected to an antenna connector for the RF moduleis faulty.

Calculate the main and diversity RX signal levels according to the preceding formulasmentioned in background information. For the carriers of all the TRXs connecting to thesame antenna connector, if the main RX signal level is different from the diversity RXsignal level, check whether a jumper or feeder connected to an antenna connector for theRF module is faulty.

l If yes, replace the faulty jumper or feeder. Then, go to Step 4.





5. Check whether the antenna connections between two cells are crossed.

Calculate the main and diversity RX signal levels according to the preceding formulasmentioned in background information. For the carriers of all the TRXs in two cells underthe same BTS, if the main RX signal level is different from the diversity RX signal level,check whether the antenna connections between the two cells are crossed pairs.

l If yes, correct the antenna connections. Then, go to Step 6.





Typical Symptoms of Incorrect Antenna Connections

BTS Type Fault Type Symptom

BTS3012 Faults incablesbetween theTRXs and theDFCU orDDPU

For the carriers of some TRXs connected to the DFCU orDDPU, if the main RX signal level is different from thediversity RX signal level, the RXM or RXD cables betweenthe TRXs and the DFCU or DDPU may be faulty.



258


Faults in thefeeder orjumperconnected toan antennaconnector forthe DFCU orDDPU

For the carriers of all the TRXs connected to the sameantenna connector, the main RX signal level is differentfrom the diversity RX signal level.

Crossed pairsbetween themain anddiversity RXchannels ofthe two cells

For the carriers of all the TRXs in two or more cells underthe same BTS, the main RX signal level is different fromthe diversity RX signal level.

BTS3900 Incorrectconfigurationof the TRXsend andreceivemodes

For all carriers of a TRX connected to an RF module, themain RX signal level is different from the diversity RXsignal level.

Faults inantennasconnected toTRXs

When there are two TRXs in combined-cabinet mode:l There is a great difference in the RX signal level between

the main and diversity RX channels of only one cellunder the BTS.

l For all carriers of one TRX, the main RX signal level islower than the diversity RX signal level; for all carriersof another TRX, the diversity RX signal level is lowerthan the main RX signal level.

When there is only one TRX:l There is a great difference in the RX signal level between

the main and diversity RX channels of only one cellunder the BTS.

l For all carriers of the TRX, the main RX signal level isdifferent from the diversity RX signal level.

Crossed pairsbetween themain anddiversity RXchannels oftwo cells

When there are two TRXs in combined-cabinet mode:l There is a great difference in the RX signal level between

the main and diversity RX channels of two or more cellsunder the BTS.

l For all carriers of one TRX, the main RX signal level islower than the diversity RX signal level; for all carriersof another TRX, the diversity RX signal level is lowerthan the main RX signal level.



259


When there is only one TRX:l There is a great difference in the RX signal level between

the main and diversity RX channels of two or more cellsunder the BTS.

l For all carriers of the TRX, the main RX signal level isdifferent from the diversity RX signal level.

BTS3900/BTS3012

Inappropriatethresholds forthe RX signallevel of themain anddiversity RXchannels

For the BTS3012, the threshold is set to 6 dB or larger; forthe BTS3900, the threshold is set to 10 dB or larger.

Low RXsignal level ofmain anddiversity RXchannels

The main and diversity RX signal level is lower than -98dB. (This can be used as a supplementary method todetermine incorrect antenna connections.)

Typical CaseSymptom

A site frequently encounter problems such as interference, one-way audio, sharp decreases inthe RX signal level, and MS access failures.

Cause Analysis

The feeders for the main and diversity RX channels of the two cells are crossed. As a result, themain and diversity RX signal level difference exceeds 10 dB.

Location Procedure

1. Query the performance measurement results by choosing MR Measurement(MR) > Userdefined MRs per TRX > User defined MRs per TRX >TRX_EXT_MAIN_RX_AVR_LEV on the M2000.

2. Calculate the main and diversity RX signal levels of the two cells according to the precedingformulas.

3. Analyze the main and diversity RX signal level of all carriers in the two cells. The mainand diversity RX signal level difference exceeds 10 dB. In addition, the RX signal level ofpath A in cell 1 is high and that of path B in cell 1 is low, whereas the RX signal level ofpath A in cell 2 is high and that of path B in cell 2 is low. This indicates that the antennaconnections between the two cells are crossed.

4. Check for crossed pairs of feeders onsite and reconnect the feeders. The alarms are cleared.



260

13.5 Troubleshooting Faults on Main and Diversity RXChannels Due to Hardware Faults

This section describes how to troubleshoot faults on main and diversity RX channels due tohardware faults.

SymptomAlarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receivechannel alarm are reported.

Location ProcedureFigure 13-4 shows the procedure for locating faults on main and diversity RX channels due tohardware faults.

Figure 13-4 Procedure for locating faults on main and diversity RX channels due to hardwarefaults

Location Procedure1. Check whether any BTS boards are faulty

by exchanging the faulty boards with the functional boards.l If yes, replace the faulty boards. Then, go to Step 2.l If no, Contact Huawei Customer Service Center.

2. Check whether the alarms such as ALM-4176 Main receive channel alarm and ALM-4178Diversity receive channel alarm are cleared.l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom



261

After the capacity expansion from S3 to S3/2, the BTS312 operates properly. During the twodays after capacity expansion, the newly added TRXs report the alarm ALM-4178 Diversityreceive channel alarm every hour or two.

Cause Analysis

The possible causes are as follows:l The antenna is not connected properly.l The radio frequency (RF) cables that connect to the diversity RX ports on the TRXs and

the diversity RX cables that connect to the combining and distribution units (CDUs) on thetop of the cabinet are loose or damaged.

l The TRXs are faulty.l There is multipath interference in the radio environment.l The data configuration is incorrect.

Location Procedure

1. Check the data configuration of the newly added TRXs. The data configuration is correct.2. Check and reconnect all the RF cables, and replace all the diversity RX cables. Then,

perform dialing tests. The alarms persist.3. Replace the CDUs connected to the TRXs reporting alarms. Then, perform dialing tests.

The alarms persist.4. Exchange the slots between the TRXs reporting alarms and the TRXs not reporting alarms.

Then, perform dialing tests. The alarms are cleared.



262

14 No Traffic

About This Chapter

This chapter describes how to locate and troubleshoot no traffic on 3900 series base stations.

14.1 Introduction to No TrafficWhen no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannotbe occupied.

14.2 Locating No TrafficThis section describes how to locate no traffic.

14.3 Troubleshooting No Traffic Due to No CallsThis section describes how to troubleshoot no traffic due to no calls.

14.4 Troubleshooting No Traffic Due to Transmission or Equipment FaultsThis section describes how to troubleshoot no traffic due to transmission or equipment faults.

14.5 Troubleshooting No Traffic Due to Incorrect Data ConfigurationsThis section describes how to troubleshoot no traffic due to incorrect data configurations.

14.6 Troubleshooting No Traffic Due to Poor Um Interface QualityThis section describes how to troubleshoot no traffic due to poor Um interface quality.

14.7 Troubleshooting No Traffic Due to Antenna System FaultsThis section describes how to troubleshoot no traffic due to antenna system faults.

14.8 ResettingThis section describes how to perform resetting.

GBSS9.0Troubleshooting Guide 14 No Traffic


263

14.1 Introduction to No TrafficWhen no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannotbe occupied.

IntroductionWhen no traffic occurs, a cell or some TRXs serving the cell become faulty. As a result, cellcoverage may be affected. In some cases, subscribers in an area cannot make calls. Therefore,when no traffic occurs, immediately resolve the problem to minimize the impact.

The alarms associated with no traffic are reported at the TRX level. No traffic may occur in aBTS, cell, board, or TRX on the board, depending on the cell configurations.

Associated AlarmThe ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX isassociated with no traffic. This alarm is reported when a TRX does not detect any traffic (nocalls can be set up in a cell) during a consecutive period of time. The alarm is cleared when acall accesses the network successfully.

Run the SET GTRXRLALM command on the LMT to set Begin Time of WLA Detection,End Time of WLA Detection, and Statistical Period of No-traffic based on the actual trafficdistribution.

SymptomWhen there is no traffic for a long time, the following symptoms may occur:l The value of K3014:Traffic Volume on TCH for a cell is close to zero during peak hours.l MSs fail to access a cell or cannot search for the cell.l The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on

TRX is reported for cells where the BCCH TRX is configured with TCHs.

14.2 Locating No TrafficThis section describes how to locate no traffic.

PrinciplesResource usage failures caused by special traffic models or board faults may lead to no traffic.Possible causes are antenna system problems, incorrect data configurations, hardware problems,interference, poor Um interface quality, or software problems. You can locate and troubleshootthe problems based on the live network conditions.

To locate the problems, first determine the search scope, such as site, cell, or TRX according tothe problem feedback information and traffic statistics. If no fault is found after the locationprocedure is performed on the site, cell, or TRX, reset the software and hardware to restoreservices.

The location procedure involves the following operations:



264

l Analyzing the KPIs associated with a cell or TRXl Checking the alarm parameter settingsl Handling the transmission and equipment alarmsl Checking the parameter settingsl Locating interferencel Resetting the faulty board to check whether the board software is faultyl Locating antenna system faults

Location ProcedureFigure 14-1 shows the procedure for locating no traffic.



265

Figure 14-1 Procedure for locating no traffic

14.3 Troubleshooting No Traffic Due to No CallsThis section describes how to troubleshoot no traffic due to no calls.

SymptomThe ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX isreported, or the value of K3014:Traffic Volume on TCH is zero.



266

This problem may be caused by special coverage conditions. For example, there are no travelersat a popular tourist attraction during the off-season, no subscribers in certain districts or nostudents in schools during holidays, or there is no traffic in some cells in the early morning. Inthese conditions, change the settings of the correlated alarm parameters to improve alarmdetection accuracy.

Background InformationThe parameters associated with this alarm are Wireless Link Alarm Flag, Statistical Periodof No-traffic, Begin Time of WLA Detection, and End Time of WLA Detection. You canrun the LST GTRXRLALM command to query the settings of the preceding parameters andrun the SET GTRXRLALM command to change the settings.

Location ProcedureFigure 14-2 shows the procedure for locating no traffic due to no calls.

Figure 14-2 Procedure for locating no traffic due to no calls

Troubleshooting Procedure1. Check whether the settings of the correlated alarm parameters are correct.

Begin Time of WLA Detection, End Time of WLA Detection, and Statistical Period ofNo-traffic must be set according to the traffic distribution.l If the parameter settings are incorrect, change the parameter settings. Then, go to Step

2.l If they are correct, return to Procedure for locating no traffic.

2. Check whether the no traffic problem is resolved.l If yes, no further action is required.l If no, return to Procedure for locating no traffic.

Typical CaseSymptom



267

The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX isfrequently reported on a BTS3900 and is automatically cleared after a period of time.

Cause Analysis

The site served by the BTS3900 is a school amid summer vacation. The alarm is reported becauseno phone calls were made during summer vacation.


1. Trace the RSL signaling on the Abis interface for the problem cell. No channel requestsare reported in the cell. Query the forward and reverse power of the TRX power amplifier.The forward and reverse power as well as the downlink transmit power of the TRX arenormal.

2. Perform drive tests (DTs). Subscribers can make calls in the area covered by the cell. Thisindicates that the BTS is operating properly.

3. Change the settings of the correlated alarm parameters to ensure that the ALM-28008 RadioLink Failure alarm is not reported during summer vacation.

14.4 Troubleshooting No Traffic Due to Transmission orEquipment Faults

This section describes how to troubleshoot no traffic due to transmission or equipment faults.

SymptomWhen a transmission or equipment fault occurs in a cell, the alarm system reports alarms suchas RF Unit VSWR Threshold Crossed, Trx Temperature Alarm, Transmission alarm, and TRXConfig Mismatch Alarm. In this situation, the cell may be out of service, or the TRX may beshut down.

Background InformationTransmission or equipment faults include:l Faults in the BTS transmission management unitl BTS TRX faultsl BTS antenna faults

The following alarms are associated with hardware or antenna faults:l ALM-21807 OML Faultl ALM-26235 RF Unit Maintenance Link Failurel ALM-26529 RF Unit VSWR Threshold Crossedl ALM-11272 Hardware Alarml ALM-26503 RF Unit Optical Module Transmit/Receive Fault

The following alarms are associated with transmission faults:l ALM-21807 OML Faultl ALM-11280 E1/T1 remote alarml ALM-25800 E1/T1 Loss of Signal



268

l ALM-25803 E1/T1 Loss of Frame Alignment

Location ProcedureFigure 14-3 shows the procedure for locating no traffic due to transmission or equipment faults.

Figure 14-3 Procedure for locating no traffic due to transmission or equipment faults

Troubleshooting Procedure1. Check whether any alarms associated with no traffic due to transmission or equipment

faults are reported.l If yes, clear the alarms listed in Background Information by referring to the Alarm

Reference. Then, go to Step 2.l If none of these alarms are reported, return to Procedure for locating no traffic.


Typical CaseSymptom

An onsite MRFU has no traffic and reports the ALM-4812 Optic Module Abnormal Alarm andthe ALM-28008 Radio Link Failure with Specific Problem of No Traffic on TRX.

Cause Analysis

The optical module between the MRFU and the BBU is faulty, and therefore the link betweenthe TRX and the BBU is disconnected.


1. Analyze the RSL signaling on the Abis interface. All calls assigned to the MRFU fail to beinitiated because the MRFU does not receive any link setup indication messages after theassignment command is delivered.

2. Query the alarm information on the LMT. The alarms associated with optical module faultsare reported.



269

3. Replace the onsite optical module with a new one. The no traffic problem is resolved.

14.5 Troubleshooting No Traffic Due to Incorrect DataConfigurations

This section describes how to troubleshoot no traffic due to incorrect data configurations.

Symptom

The alarm system reports the ALM-28008 Radio Link Failure alarm with Specific Problem ofNo Traffic on TRX.


The ALM-28008 Radio Link Failure is reported if certain parameters are set incorrectly or certainfunctions are enabled.

l If mobile country code (MCC), mobile network code (MNC), location area code (LAC),cell identity (CI), and network parameters are not set correctly, no traffic in a cell mayoccur.

l Enabling energy saving functions may result in no traffic. For example, when the intelligentshutdown of TRX power amplifier function or dynamic cell shutdown function is started,the BTS checks the traffic volume of a cell or TRX. Upon determining that the trafficvolume of a cell or TRX is low, the BTS powers off the cell or TRX to reduce powerconsumption. After the cell or TRX is powered off, there is no traffic in the cell or on theTRX.

Location Procedure

Figure 14-4 shows the procedure for locating no traffic due to incorrect data configurations.

Figure 14-4 Procedure for locating no traffic due to incorrect data configuration



270

Troubleshooting Procedure1. Check whether the parameters listed in Background Information are set correctly.

l If no, change the parameter settings. Then, go to Step 2.l If yes, return to Procedure for locating no traffic.


Typical Case

Symptom

The traffic volumes of three cells under a BSC at site A suddenly decrease to zero and no channelrequests are reported in these cells. However, the traffic volumes of the cells are restored tonormal after several hours.

Cause Analysis

The dynamic cell shutdown function is enabled.


1. View the traffic statistics. Several hours before no traffic occurs, the number of channelrequests reported in the cell gradually decreases. When the no traffic problem occurs, thenumber of channel requests decreases to zero.

2. Analyze the operation logs when the problem occurs and when it is resolved. Before theproblem occurs, the dynamic cell shutdown function is enabled. As a result, the BSCconstantly checks the cell load. If the cell load is less than Same Coverage Cell LoadThreshold (with the default value of 50%) within Same Coverage Cell Load Stat.Time, the cell is shut down and has no traffic. After the dynamic cell shutdown functionis disabled, the problem is resolved.

14.6 Troubleshooting No Traffic Due to Poor Um InterfaceQuality

This section describes how to troubleshoot no traffic due to poor Um interface quality.

Symptom

If the Um interface quality is poor, an MS may fail to receive an IMM ASS CMD or ASS CMDmessage from the BSC, or the BTS cannot decode an EST IND message from an MS. As a result,the target cell fails to be occupied.

Background Informationl Interference may deteriorate the signal quality of the target cell. As a result, MSs fail to

occupy channels in the cell even if the downlink receive level of the target cell is favorable.l Poor coverage on the uplink and downlink may deteriorate the Um interface quality, and

therefore MSs fail to receive the messages from the BTS.



271

Location ProcedureFigure 14-5 shows the procedure for locating no traffic due to poor Um interface quality.

Figure 14-5 Procedure for locating no traffic due to poor Um interface quality

Troubleshooting Procedure1. View the traffic statistics associated with interference bands to check whether there is

interference in the cell.l If yes, remove the interference source or replace the interfered frequency. Then, go to

Step 2.l If no, go to Step 3.

2. Check whether the no traffic problem is resolved.l If yes, no further action is required.l If no, go to Step 3.

3. View the traffic statistics associated with the uplink and downlink signal quality to checkwhether the Um interface quality was poor before no traffic occurred.l If yes, perform network optimization to improve the Um interface quality. Then, go to

Step 4.l If no, go to Step 5.



272

4. Check whether the no traffic problem is resolved.



5. Perform operations provided in 14.8 Resetting. Then, go to Step 6.

6. Check whether the no traffic problem is resolved.


l If no, return to Procedure for locating no traffic.

Typical Case

Symptom

There is no traffic on an onsite TRX and the alarm system reports the ALM-28008 Radio LinkFailure alarm with Specific Problem of No Traffic on TRX. The system occasionally clearsthe alarm, but the traffic volume is low.

Cause Analysis

There is severe uplink interference on the frequency used by the problem TRX.


1. Analyze the traffic statistics when the problem occurred. Although few assignmentcommands were delivered to the problem TRX, no TCHs were assigned to the MSs.

2. Analyze the RSL signaling on the Abis interface. Channel requests are reported in the celland there is traffic in the cell. However, MSs fail to access the assigned TCHs on theproblem TRX, and do not send any link setup indication messages.

3. Check that no operations are performed on the cell before and after the problem occurs.

4. Analyze the traffic statistics associated with the TRX interference bands. Most uplinkinterference bands of the TRX are interference band 5 and the TRX is configured in non-frequency hopping (non-FH) mode.

5. Change the frequency used by the TRX. The problem is resolved. This indicates that theproblem is caused by single-frequency interference.

14.7 Troubleshooting No Traffic Due to Antenna SystemFaults

This section describes how to troubleshoot no traffic due to antenna system faults.

Symptom

If the no traffic problem persists after the possible causes of no calls, transmission or equipmentfaults, incorrect data configuration, or poor Um interface quality are excluded, the problem maybe caused by antenna system faults.

Antenna system faults refer to incorrect antenna connections and faulty cables to the antenna.If the antenna system is faulty, the TRXs with no traffic may be bound to the same transmit path.



273

Background Informationl If the antenna system is faulty, the BTS cannot transmit downlink signals properly. As a

result, no coverage or poor coverage problem may occur, or uplink signals cannot be sentto or decoded by the BTS.

l If the antenna connections are incorrect, the coverage area of the BCCH TRX in the cellmay be different from the coverage areas of non-BCCH TRXs. As a result, MSs fail toaccess the assigned TCHs on non-BCCH TRXs after they initially access the TCHs on theBCCH TRX. This results in no traffic on non-BCCH TRXs.

Location ProcedureFigure 14-6 shows the procedure for locating no traffic due to antenna system faults.

Figure 14-6 Procedure for locating no traffic due to antenna system faults



274

Troubleshooting ProcedureUse TEMS or Probe MSs to perform drive tests (DTs). If TEMS or Probe MSs are not available,use common MSs.

1. Check whether the dialing tests can be performed on the TRX power output port.Use a TEMS MS to lock the BCCH frequency of the faulty cell and perform dialing testson the TRX power output port.l If the dialing tests cannot be performed and the frequency cannot be scanned on the

TRX power output port, replace the board with a new one. Then, go to Step 2.l If the dialing tests can be performed, go to Step 3.


3. Check whether the antenna connections are consistent with configurations.

l If no, correct the antenna connections. Then, go to Step 4.l If yes, go to Step 5.


5. Check whether the antenna tilt is correct and whether the tilt direction is consistent withthe coverage area.

l If no, adjust the antenna tilt. Then, go to Step 6.l If yes, go to Step 7.


7. Check whether the distributed indoor antenna system is powered off or faulty.

l If yes, contact the manufacturer of the distributed indoor antenna system to rectify thefault. Then, go to Step 8.

l If no, go to Step 9.8. Check whether the no traffic problem is resolved.


9. Check whether the antenna system is faulty.Use one cable to connect the TRX of cell A to the antenna of cell B and use one cable toconnect the TRX of cell B to the antenna of cell A. If the problem is resolved, the problemis caused by antenna system faults.l If yes, reconnect the cables to the antenna system or replace the components in the

antenna system. Then, go to Step 10.l If no, Contact Huawei Customer Service Center.



275

10. Check whether the no traffic problem is resolved.l If yes, no further action is required.l If no, Contact Huawei Customer Service Center.

Typical CaseSymptom

The onsite traffic volume suddenly decreases to zero and the ALM-28008 Radio Link Failurealarm with Specific Problem of No Traffic on TRX is reported on the system and is not clearedfor several days.

Cause Analysis

The distributed indoor antenna system is powered off, and therefore no downlink signals areavailable. As a result, MSs fail to access the network.


1. View the traffic statistics when the problem occurs in the cell. No channel requests arereported in the cell, but the interference band messages are reported. The downlink transmitpower may be abnormal.

2. Reset the board hardware and software. The problem persists.3. Perform the dialing tests onsite. No cell signals can be searched for in the coverage area.4. Locate faults in the distributed indoor antenna system. The antenna connections are correct

and calls can be initiated on the TRX power output port.5. Locate faults in the distributed indoor antenna system again. Extra power is supplied to the

distributed indoor antenna system. This indicates that no traffic occurs because thedistributed indoor antenna system is powered off.

14.8 ResettingThis section describes how to perform resetting.

CAUTIONExercise caution when performing resetting because resetting may affect or interrupt services.

Select the module to be reset according to the problem occurrence range.l If there is no traffic on a BTS, reset the BTS.l If there is no traffic in a cell, reset the board where the BCCH TRX of the cell is located.

Reset the software first. If the problem persists, reset the hardware.l If there is no traffic on a TRX, reset the board where the TRX is located. Reset the software

first. If the problem persists, reset the hardware.

To perform resetting, do as follows:l To reset a BTS, run the RST BTS command with Reset Type set to BTSSOFT(Reset BTS

Software) and Reset Level set to 4-LEVEL(Level-4). For details about the parametersettings, see the MML Command Reference.



276

l To reset the board software, run the RST BTSBRD command with Reset Type set toSOFTWARE(Software Reset). For details about the parameter settings, see the MMLCommand Reference.

l To reset the board hardware, run the RST BTSBRD command with Reset Type set toHARDWARE(Hardware Reset). For details about the parameter settings, see the MMLCommand Reference.

If the no traffic problem is caused by software errors, resolve the problem by resetting thesoftware or hardware. After the problem is resolved, Contact Huawei Customer Service Centerto determine the root cause of the problem.



277

71271900 GBSS9 0 Troubleshooting Guide

Documents

coding scheme degraded

ieee 1588v2 protocol

establishment success rates

performs speech codec

primary mouse button

ho req message

device navigation tree

dhcp relay agent